Decimal anomaly 2
Author Message
Decimal anomaly 2

Date: Sat, 21 Sep 2002 12:06:16 GMT
Quote:

> > > > Date: Sun, 15 Sep 2002 11:58:49 GMT
> > > > IMO, QUAD floating point IS a superior feature to PL/I's decimal support
> > > > since with its support you can duplicate PL/I and COBOL 33 digit decimal
> > > > results.

> > > a = '123456789.00'
> > > b = '.0149999999999999'         ! invoke .xx truncation
> > > c = Dadd(a,b,2)
> > > write (*,*) c                   ! outputs 123456789.02

> > > Rounds up when it shouldn't.

> > You have exceeded the 16 significant digit capability of the current
> > routines and output is degrading (gracefully)

>> The first value has 11 signficant digits, well within the capability of
>> double precision, and would be stored as a dp number with around
>> 16 digits.
>> The second number has 15 signficant digits, still within the capacity
>> of a dp number, stored internally with around 16 digits.

>> The product would be computed as dp, with 16 signficant digits.
>> That's the way dp multiplication works.

>> The final result has 11 significant digits.

>> Your proposed float computations for simulating decimal
>> are not reliable.

> You show us a + b  > 16digits and complain that answer is not what you
> expect.

.
Do you understand floating-point arithmetic?
Each mantissa has about 58 significant binary digits.
The product is about 116 digits, of which about 58 are retained.
Many fractions (e.g., 0.1) always have about 58 significant binary digits,
(example -- even 0.1 is held with 58 significant binary digits.)
In the above case a + b --
The result is a double-precision sum of approx 16 digits.
The sum can never exceed approx. 16 digits.
Your routine prints the first 11 significant digits, with an error
in the 11th place.
Others have pointed out similar errors in your routines.
.
Quote:
> You complain about  a * b  above without showing a bad result from me, (I
> never ran this case)..
> You complain that my Dadd routine rounds (avoiding truncation bias) vs. your
> user so desires..
> You posted below PL/I example, (expecting my routines would fail)..

No, I posted an example of PL/I decimal arithmetic, to show that
no rounding/truncation errors occur.

- Show quoted text -

Quote:
>> dec: proc options (main);
>>    dcl a fixed decimal (15,10) init (0);
>>    DCL J FIXED BINARY;

>>    do j = 1 to 10000;
>>       a = a + 0.00001;
>>    end;
>>    put (a);             /* outputs 0.1000000000 */

>> end dec;
.
> my code below duplicates your output..
.
> a = '0.'
> do j = 1,10000
>   a = Dadd(a,'0.00001',10)    ! intermediate values of 'a' generated are
> .00001  .00002  .00003   etc

.
The intermeduate values generated are, in fact,
.0000100000 .0000200000  .0000300000 no?
.
Quote:
> end do
> write (*,*) a      ! outputs 0.1000000000
.
> Your conclusion that my decimal routines are not reliable has not been
> proven...

.
Your program produces wrong values.  I posted the wrong values that
proved it.  Others have posted the wrong results that it produces.
The point is that your method is unreliable and non-portable.
Here's another example.  Your program produces the wrong result for
the first case.
.
b =  '4999999999999999'
c = '.000000000000000001'
a = Dmul(b, c, 2)
write (*,*) a                   ! prints  0.01
.
b =  '4999999999999999'
c = '.00000000000000001'
a = Dmul(b, c, 2)
write (*,*) a                   ! prints  0.05

It's absurd to claim that your procedures "work" when you present
just one or two examples of arithmetic operations.
With a few minutes' work, others have found several instances of failure.
Undoubtedly, other examples exist.

You also rely on a certain FPU which rounds; other architectures
do not round, instead truncating, and which may also produce
wrong results.  In other words, your procedures do not produce consistent
results across platforms.

Fri, 11 Mar 2005 21:17:15 GMT
Decimal anomaly 2

Quote:
> Do you understand floating-point arithmetic?

yes, but you dont, you keep trying to create cases AT THE LIMIT of real(8)
precision so that you can confuse the issue, which is that QUAD precision
would have no problems with ANY of the cases you have presented.

Quote:
> Others have pointed out similar errors in your routines.

Not true, YOU are the ONLY person that has run cases..

Quote:
> .
> The intermeduate values generated are, in fact,
> .0000100000 .0000200000  .0000300000 no?

well yes they are, I wanted to save message space..

Quote:
> Here's another example.  Your program produces the wrong result for
> the first case.
> .
> b =  '4999999999999999'
> c = '.000000000000000001'
> a = Dmul(b, c, 2)
> write (*,*) a                   ! prints  0.01
> .
> b =  '4999999999999999'
> c = '.00000000000000001'
> a = Dmul(b, c, 2)
> write (*,*) a                   ! prints  0.05

> It's absurd to claim that your procedures "work" when you present
> just one or two examples of arithmetic operations.

It's absurd to keep posting examples at the limit of real(8) and then
complaining when you dont post what you expected (give your PL/I results)
probably because you are unhappy with your PL/I adding   1234.00 + .0199 and
getting a truncated result 1234.01
I assume if I had available QUAD precision you would post 33 digit examples
stressing the LAST digit of a 33 digit math result and making the same
noise..

Quote:
> Undoubtedly, other examples exist.

Undoubtedly there are infinite examples of  16+ digit arguments also, back
off the nonsensical
xxxxxxxxxxxxxxxxxxxxxxx     xxxxxxxxxxxxxxxxxxxxxxx   {*filter*}and show
a REAL case that fails..

Sat, 12 Mar 2005 00:25:25 GMT
Decimal anomaly 2

Quote:

> > Do you understand floating-point arithmetic?

> yes, but you dont, you keep trying to create cases AT THE LIMIT of real(8)
> precision

11 significant digits is NOT the limit of double precision.

Quote:
> so that you can confuse the issue, which is that QUAD precision
> would have no problems with ANY of the cases you have presented.

> > Others have pointed out similar errors in your routines.

> Not true, YOU are the ONLY person that has run cases..

You know that that is false statement.

Quote:
> > The intermeduate values generated are, in fact,
> > .0000100000 .0000200000  .0000300000 no?

> well yes they are, I wanted to save message space..

> > Here's another example.  Your program produces the wrong result for
> > the first case.
> > .
> > b =  '4999999999999999'
> > c = '.000000000000000001'
> > a = Dmul(b, c, 2)
> > write (*,*) a                   ! prints  0.01
> > .
> > b =  '4999999999999999'
> > c = '.00000000000000001'
> > a = Dmul(b, c, 2)
> > write (*,*) a                   ! prints  0.05

> > It's absurd to claim that your procedures "work" when you present
> > just one or two examples of arithmetic operations.

> It's absurd to keep posting examples at the limit of real(8) and then
> complaining when you dont post what you expected

This product produces a double precision result.  Only one significant
digit s required, and it's wrong.  Do you understand that?
You really don't understand floating-point arithmetic after all.

Quote:
> probably because you are unhappy with your PL/I adding   1234.00 + .0199 and
> getting a truncated result 1234.01

No, I'm perfectly happy with 1234.01.  Because that's what the language
definition states that it should.  I'd be unappy if it gave
something else.
And if I want rounding, I can ask for it.

Quote:
> I assume if I had available QUAD precision you would post 33 digit examples
> stressing the LAST digit of a 33 digit math result and making the same
> noise..

Sat, 12 Mar 2005 20:29:18 GMT
Decimal anomaly 2

Quote:

> > > Do you understand floating-point arithmetic?

> > yes, but you dont, you keep trying to create cases AT THE LIMIT of
real(8)
> > precision

> 11 significant digits is NOT the limit of double precision.

You want more than 11 digits in the answer?  then ask for it by increasing
the .xx request to .xxxxxxx as below.
However the .xx output for the cases below are all correct  = 18518518.35

I count 15 correct digits below, whats your problem?

a = '1234567890.'
write (*,*) dmul(a,'.0149999999999998',7)  ! 18518518.3499998
write (*,*) dmul(a,'.0149999999999999',7)  ! 18518518.3499999
write (*,*) dmul(a,'.0150000000000000',7)  ! 18518518.3500000
write (*,*) dmul(a,'.0150000000000001',7)  ! 18518518.3500001
write (*,*) dmul(a,'.0150000000000002',7)  ! 18518518.3500002

Sun, 13 Mar 2005 17:42:12 GMT
Decimal anomaly 2

Quote:

> > Do you understand floating-point arithmetic?

> yes, but you dont, you keep trying to create cases AT THE LIMIT of real(8)
> precision so that you can confuse the issue, which is that QUAD precision
> would have no problems with ANY of the cases you have presented.

> > Others have pointed out similar errors in your routines.

> Not true, YOU are the ONLY person that has run cases..

You know that that is a false statement, as your postings show:

and you even replied to it twice.

=================================================================

Date: Thu, 19 Sep 2002 16:32:08 GMT

Quote:
> >>... financial-related programs in fortran [which try] to calculate pennies
> >>and dimes using REAL almost **ALWAYS** result in missing cents.

> >... how about posting a simple source using real that loses cents and I

> Can't get much simpler than the following, and I'm already using REAL*8
> to make your task easier.  (Note:  2E14 is considerably above MY net
> worth, but you did ask for a simple example!)

>       PROGRAM Demo1
>       REAL*8 Sum, BigMoney/200 000 000 000 000.00/, Penny/0.01/
>       Sum = BigMoney + Penny
>       WRITE (*,'(F22.2)') Sum
>       END

> The output is (note the penny is gone):
>     200000000000000.00

you exceeded REAL*8 (16digits) when you added the penny..

- Show quoted text -

Quote:
> What is REALLY interesting is something I just happened to discover;
> the ONLY difference is the program name and no "*8" on the declaration:
>       PROGRAM Demo2
>       REAL Sum, BigMoney/200 000.00/, Penny/0.01/
>       Sum = BigMoney + Penny
>       WRITE (*,'(F22.2)') Sum
>       END

> The output is now (note the penny grew a little!-):
>              200000.02

> I'm stepping out on a limb here, but I'm in teacher mode now
> and I think I'm on safe ground:

> Although I am really intrigued by Demo2, the REAL point is that ANY
> attempt to do decimal calculations which involve any-length-decimal-to-
> fixed-length-binary (and back) conversions is liable to drop a bit here
> 'n there, and since the effort to determine JUST WHERE the loss will
> occur may cost more than it's worth, one should solve the problem with
> a method that is more general than simply doubling or quadrupling the
> precision, with true decimal arithmetic perhaps being the best solution.
> After all, given enough time and inflation, today's billion dollars will
> grow to a gazillion, and a once-working program will become another Y2K
> boondoggle!

You havent made your case as yet, perhaps this little test program will
clarify what happens as f22.2 formatting is commanded to output SOMETHING
from a REAL*8 value
program test
real(8) :: x = 1000000000.
integer :: n
do n = 1,10
x = x*10.
write (*,'(f22.2)') x + .01
end do
end program
10000000000.01
100000000000.01
1000000000000.01
10000000000000.01
100000000000000.02
1000000000000000.00
10000000000000000.00
100000000000000000.00
1000000000000000000.00
**********************
32-bit integer routines,  care to try again?

Sun, 13 Mar 2005 23:01:32 GMT
Decimal anomaly 2

Quote:

> > Not true, YOU are the ONLY person that has run cases..

> You know that that is a false statement, as your postings show:

> and you even replied to it twice.

<snip>  irrelevant stuff NOT about my decimal routines..

He never commented about my decimal routines, he was saying that his
financial problems required his special integer routines using cents to
avoid losing cents,  I disagreed and asked him for an example that plain use
of  REAL(8) with ANINT would not fix. His ridiculous example of adding   .01
to a number > 17 digits was his example of losing cents (reminds me of
you)..
He rudely hasnt replied to my clarifying how floating point really works and
asking for another example that lost cents.  Btw, you could learn a lot from
my tabbed table showing the gradual loss of precision around 16 digits.

I repeat NO-ONE except you has shown any examples where they think my
decimal routines dont work, and I note you are ignoring my reply this
morning showing 15 digits for the case where you said my routines only have
11 digit accuracy .

Sun, 13 Mar 2005 23:40:15 GMT

 Page 1 of 1 [ 6 post ]

Relevant Pages