1. bcd
- Posted by a.tammer at hetnet.nl
Apr 14, 2002
hi evrybody,
first of all apologies to Derek, for not mentioning him (being the first to
react) in my last piece.
before i really start putting things together, i'd like to establish limits on
an actual [real world] precision to be achieved by the routines, as well as the
maximum number of digits to be displayable. more or less like setting a standard
for EFP-calculations.
i would appreciate evry1's input on that, including Rob's,Irv's, Ricardo's and
of all those who would like to see a BCD-possibility for EU.
'tho i could do 9 digits in an integer on 2nd thought i choose to do 8 as this
would give a real time-gain on mult() and pow() that will far outweigh the
storage-penalty of 12.5/100.
having said my main piece, i'd like to be quite open with you all. i'm more of a
conceptualist than i'm an EU-progger or even progger per se. most of you
lady(ies) and gents with far more experience than me in EU will be able to do the
actual coding a lot faster than i can. i nevertheless will do it of course, 'tho
i like the idea of a small team with a math-head, a fluent progger/coder working
with me on my concept, which i will put in a small paper (app. 3*A4) today and
post to those willing to join the team by this time to-morrow.
antoine
2. Re: bcd
- Posted by rforno at tutopia.com
Apr 14, 2002
Hi, Antoine!
Thanks for asking my opinion on BCD.
There is a thing I still do not understand: what are the advantages of doing
BCD math instead of using standard binary math with, let's say, cents
instead of dollars, and then converting to dollars and cents only at the
output? This is for commercial applications.
Of course this does not consider huge or very small quantities with many,
many digits precision, but they still could be managed with the approach I
suggest using binary rather than decimal arithmetic, which would be faster.
Regards.
----- Original Message -----
From: <a.tammer at hetnet.nl>
To: "EUforum" <EUforum at topica.com>
Subject: bcd
hi evrybody,
first of all apologies to Derek, for not mentioning him (being the first to
react) in my last piece.
before i really start putting things together, i'd like to establish limits
on an actual [real world] precision to be achieved by the routines, as well
as the maximum number of digits to be displayable. more or less like setting
a standard for EFP-calculations.
i would appreciate evry1's input on that, including Rob's,Irv's, Ricardo's
and of all those who would like to see a BCD-possibility for EU.
'tho i could do 9 digits in an integer on 2nd thought i choose to do 8 as
this would give a real time-gain on mult() and pow() that will far outweigh
the storage-penalty of 12.5/100.
having said my main piece, i'd like to be quite open with you all. i'm more
of a conceptualist than i'm an EU-progger or even progger per se. most of
you lady(ies) and gents with far more experience than me in EU will be able
to do the actual coding a lot faster than i can. i nevertheless will do it
of course, 'tho i like the idea of a small team with a math-head, a fluent
progger/coder working with me on my concept, which i will put in a small
paper (app. 3*A4) today and post to those willing to join the team by this
time to-morrow.
antoine
3. Re: bcd
a.tammer at hetnet.nl wrote:
>before i really start putting things together, i'd like to establish limits
>on an actual [real world] precision to be achieved by the routines,
20 before the decimal point plus 10 after is IMO well over the top.
I used 15,7 for 12 years & I twice needed 16 before and once 8 after.
I'd prefer a variable-length variety, with most values fitting in 8
bytes. There is also an argument for letting the programmer "fix" the
precision so a) you don't actually need to store an exponent against
each number, and b) comparison (esp during a sort) is nice & fast.
> as well
>as the maximum number of digits to be displayable. more or less like setting
>a standard for EFP-calculations.
A Romanian Oil company wanted 16,3. Nothing I've ever done wanted more
than 6dp printed. More common was the case that it had to be printed
in say 10 characters, so after [+/-]9,999.99[space], print 100.00K,
thru [+/-]9,999.99K then M, etc.
>'tho i could do 9 digits in an integer on 2nd thought i choose to do 8 as
>this would give a real time-gain on mult() and pow() that will far outweigh
>the storage-penalty of 12.5/100.
I was thinking along those lines myself after your last post.
>
>having said my main piece, i'd like to be quite open with you all. i'm more
>of a conceptualist than i'm an EU-progger or even progger per se. most of
>you lady(ies) and gents with far more experience than me in EU will be able
>to do the actual coding a lot faster than i can. i nevertheless will do it
>of course, 'tho i like the idea of a small team with a math-head, a fluent
>progger/coder working with me on my concept, which i will put in a small
>paper (app. 3*A4) today and post to those willing to join the team by this
>time to-morrow.
Consider me interested.
On Sun, 14 Apr 2002 18:41:36 -0300, rforno at tutopia.com wrote:
>There is a thing I still do not understand: what are the advantages of doing
>BCD math instead of using standard binary math with, let's say, cents
>instead of dollars, and then converting to dollars and cents only at the
>output? This is for commercial applications.
I struggle to see any real advantages without adding to
atom/object/sequence, or "with bcd" replacing float.
I still want one day to see "if 0.1+0.2=0.3 then" useable, as is,
whether that means I must suffer a performance hit, or not..
>Of course this does not consider huge or very small quantities with many,
>many digits precision, but they still could be managed with the approach I
>suggest using binary rather than decimal arithmetic, which would be faster.
You still have that choice.
Maybe this is just an experiment which may work, may not.
Pete
