• Paul D. Anderson (11/11) Jun 14 2011 I've been working feverishly to generate an implementation of the Genera...
• Don (12/32) Jun 14 2011 Do they use base 10 ?
• Paul D. Anderson (5/35) Jun 14 2011 According to what I've read, there is some uncertainty as to which would...
• Don (7/47) Jun 14 2011 One of the biggest selling points of densely packed decimals is that

Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:

I've been working feverishly to generate an implementation of the General
Decimal Arithmetic specification (http://www.speleotrope.com/decimal). This
will provide arbitrary precision (AP) floating point arithmetic, as well as
fixed length (32, 64, and 128 bits) decimal floating point numbers.

My intention a couple of weeks ago was to tidy it up slightly and publish a
level 0.1 release, but I keep postponing it for another round of fixes.
Apparently this is a never-ending process, so I will make it available, warts
and all.

The git address is: https://github.com/andersonpd/decimal.git

At this point it is just a snapshot of a work in progress, but it's not far
from being usable. My intention is to have a working implementation of the AP
numbers and the 32- and 64-bit fixed numbers by the 4th of July.

There is already a more or less complete implementation of the AP floats
(exclusive of logical ops and exp, log, and power) and some scraps of
implementation of fixed-length numbers.

I have some bikeshed sort of questions regarding both naming and implementation
and I'd like some feedback from the community:

1) I've named the AP numbers "Decimal", but a better name is either
"BigDecimal" or "BigFloat". I'm leaning toward BigDecimal. The fixed size
numbers are "Dec32", "Dec64" and "Dec128". Are these names satisfactory?

2) There are two available representations for the fixed size numbers: densely
packed decimals and binary integer decimals. If anyone knows or cares about the
difference do you have a preference? The binary integer decimals are much
simpler to convert to other types, so I'm implementing those, but it's not much
work to implement the others. If you want more info I can point you to
references.

3) The current design is to back all the fixed size numbers with the AP
numbers. That is, the fixed sized are converted to arbitrary precision,
operated on, and coverted back. The AP numbers are based on std.bigint.BigInt,
so all internal math is performed using BigInts. It is possible, however, to
use uints and ulong arithmetic for Dec32 and Dec64, respectively. But the ints
and longs would have to indicate overflow, etc., so it's not trivial. (I wish
there were CheckedInt struct!) The first releases will use BigInts, but is it
worthwhile to pursue the other?

Any questions or ideas please e-mail me at the address above. (I won't be able
to check my e-mail until this evening (PDT), so if you want a quicker response
use this forum.)

Paul

Don <nospam nospam.com> writes:

Paul D. Anderson wrote:
 I've been working feverishly to generate an implementation of the General
Decimal Arithmetic specification (http://www.speleotrope.com/decimal). This
will provide arbitrary precision (AP) floating point arithmetic, as well as
fixed length (32, 64, and 128 bits) decimal floating point numbers.
 
 My intention a couple of weeks ago was to tidy it up slightly and publish a
level 0.1 release, but I keep postponing it for another round of fixes.
Apparently this is a never-ending process, so I will make it available, warts
and all.
 
 The git address is: https://github.com/andersonpd/decimal.git
 
 At this point it is just a snapshot of a work in progress, but it's not far
from being usable. My intention is to have a working implementation of the AP
numbers and the 32- and 64-bit fixed numbers by the 4th of July.
 
 There is already a more or less complete implementation of the AP floats
(exclusive of logical ops and exp, log, and power) and some scraps of
implementation of fixed-length numbers.
 
 I have some bikeshed sort of questions regarding both naming and
implementation and I'd like some feedback from the community:
 
 1) I've named the AP numbers "Decimal", but a better name is either
"BigDecimal" or "BigFloat". I'm leaning toward BigDecimal. The fixed size
numbers are "Dec32", "Dec64" and "Dec128". Are these names satisfactory?

Do they use base 10 ?
Ie, is it impossible to request a significand length of (say) 2048 bits?

Name = BaseTenOnly ? "BigDecimal" : "BigFloat".

I would expect something called 'BigFloat' to be able to duplicate the 
semantics of the built-in binary floating point types, and 'BigDecimal' 
to duplicate the semantics of the decimal types.
If it can do both, BigFloat is a shorter name.

 2) There are two available representations for the fixed size numbers: densely
packed decimals and binary integer decimals. If anyone knows or cares about the
difference do you have a preference? The binary integer decimals are much
simpler to convert to other types, so I'm implementing those, but it's not much
work to implement the others. If you want more info I can point you to
references.

I suspect densely packed decimals are only really useful as an 
interchange format, when you don't have hardware that uses them 
natively. But I could be wrong.

 3) The current design is to back all the fixed size numbers with the AP
numbers. That is, the fixed sized are converted to arbitrary precision,
operated on, and coverted back. The AP numbers are based on std.bigint.BigInt,
so all internal math is performed using BigInts. It is possible, however, to
use uints and ulong arithmetic for Dec32 and Dec64, respectively. But the ints
and longs would have to indicate overflow, etc., so it's not trivial. (I wish
there were CheckedInt struct!) The first releases will use BigInts, but is it
worthwhile to pursue the other?

I think that stuff belongs in a FixedInt class rather than in this code.

 
 Any questions or ideas please e-mail me at the address above. (I won't be able
to check my e-mail until this evening (PDT), so if you want a quicker response
use this forum.)
 
 Paul
 

Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:

Don Wrote:

 Paul D. Anderson wrote:
 I have some bikeshed sort of questions regarding both naming and
implementation and I'd like some feedback from the community:
 
 1) I've named the AP numbers "Decimal", but a better name is either
"BigDecimal" or "BigFloat". I'm leaning toward BigDecimal. The fixed size
numbers are "Dec32", "Dec64" and "Dec128". Are these names satisfactory?

 
 Do they use base 10 ?
 Ie, is it impossible to request a significand length of (say) 2048 bits?
 
 Name = BaseTenOnly ? "BigDecimal" : "BigFloat".
 
 I would expect something called 'BigFloat' to be able to duplicate the 
 semantics of the built-in binary floating point types, and 'BigDecimal' 
 to duplicate the semantics of the decimal types.
 If it can do both, BigFloat is a shorter name.
 

They are decimals. Significands are specified in decimal digits, etc.

 2) There are two available representations for the fixed size numbers: densely
packed decimals and binary integer decimals. If anyone knows or cares about the
difference do you have a preference? The binary integer decimals are much
simpler to convert to other types, so I'm implementing those, but it's not much
work to implement the others. If you want more info I can point you to
references.

 
 I suspect densely packed decimals are only really useful as an 
 interchange format, when you don't have hardware that uses them 
 natively. But I could be wrong.
 

According to what I've read, there is some uncertainty as to which would or
should be implemented in hardware, and the iEEE-754 is agnostic about which
representation is preferred.

But this is something that can be easily incorporated later, either way.

 3) The current design is to back all the fixed size numbers with the AP
numbers. That is, the fixed sized are converted to arbitrary precision,
operated on, and coverted back. The AP numbers are based on std.bigint.BigInt,
so all internal math is performed using BigInts. It is possible, however, to
use uints and ulong arithmetic for Dec32 and Dec64, respectively. But the ints
and longs would have to indicate overflow, etc., so it's not trivial. (I wish
there were CheckedInt struct!) The first releases will use BigInts, but is it
worthwhile to pursue the other?

 
 I think that stuff belongs in a FixedInt class rather than in this code.
 

I agree.

 
 Any questions or ideas please e-mail me at the address above. (I won't be able
to check my e-mail until this evening (PDT), so if you want a quicker response
use this forum.)
 
 Paul
 

Don <nospam nospam.com> writes:

Paul D. Anderson wrote:
 Don Wrote:
 
 Paul D. Anderson wrote:
 I have some bikeshed sort of questions regarding both naming and
implementation and I'd like some feedback from the community:

 1) I've named the AP numbers "Decimal", but a better name is either
"BigDecimal" or "BigFloat". I'm leaning toward BigDecimal. The fixed size
numbers are "Dec32", "Dec64" and "Dec128". Are these names satisfactory?

 Do they use base 10 ?
 Ie, is it impossible to request a significand length of (say) 2048 bits?

 Name = BaseTenOnly ? "BigDecimal" : "BigFloat".

 I would expect something called 'BigFloat' to be able to duplicate the 
 semantics of the built-in binary floating point types, and 'BigDecimal' 
 to duplicate the semantics of the decimal types.
 If it can do both, BigFloat is a shorter name.

 
 They are decimals. Significands are specified in decimal digits, etc.
 
 2) There are two available representations for the fixed size numbers: densely
packed decimals and binary integer decimals. If anyone knows or cares about the
difference do you have a preference? The binary integer decimals are much
simpler to convert to other types, so I'm implementing those, but it's not much
work to implement the others. If you want more info I can point you to
references.

 I suspect densely packed decimals are only really useful as an 
 interchange format, when you don't have hardware that uses them 
 natively. But I could be wrong.

 
 According to what I've read, there is some uncertainty as to which would or
should be implemented in hardware, and the iEEE-754 is agnostic about which
representation is preferred.

One of the biggest selling points of densely packed decimals is that 
they are (semi-)compatible with BCD. So I would imagine them to be 
popular in environments where BCD is popular. Such environments are rare 
these days. I didn't mean to imply that most hardware would use densely 
packed decimals. AFAIK the only existing hardware uses binary integer 
decimal.

 
 But this is something that can be easily incorporated later, either way.
 
 3) The current design is to back all the fixed size numbers with the AP
numbers. That is, the fixed sized are converted to arbitrary precision,
operated on, and coverted back. The AP numbers are based on std.bigint.BigInt,
so all internal math is performed using BigInts. It is possible, however, to
use uints and ulong arithmetic for Dec32 and Dec64, respectively. But the ints
and longs would have to indicate overflow, etc., so it's not trivial. (I wish
there were CheckedInt struct!) The first releases will use BigInts, but is it
worthwhile to pursue the other?

 I think that stuff belongs in a FixedInt class rather than in this code.

 
 I agree.
 
 Any questions or ideas please e-mail me at the address above. (I won't be able
to check my e-mail until this evening (PDT), so if you want a quicker response
use this forum.)

 Paul