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

> PL/I add truncating, I subsequently added a DaddT routine that truncates if

> 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.

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.