🚀 go-pugleaf

In article <1992Sep9.225858.6523@tc.cornell.edu> bai@msiadmin.cit.cornell.edu (Dov Bai-MSI Visitor) writes:
>
>I ran the DPARA program compiled with MS-FORTRAN 5.0 under MS-DOS,
>OS/2 Vers 2.0 & 1.3. Under both MS-DOS & 1.3 the program ended with
>1 "flaw" - which is quite good grade. Under 2.0 it crashed the system after
>Milestone 90, which tests powers of z^i for small integers z, i.
>What's worse is that it is impossible to restart the program, because
>CHKDSK must be run and it does something to the log file which 
>prevents the program to restart from the previous abort. 
>
>
>So, it looks like the problem is not just with division by 0, but
>other arithemtic as well.
>
>My machine is 386, with 387 Cyrix coprocessor.
 
I tried the same thing on my 386 with IIT FPU.

But first some background: on my machine, trying dividing
1. by 0., I get an answer 1., both in OS/2 2.0 and in DOS 5.0,
with Watcom Fortran 386 9.0 and with MS Fortran 5.1.

I suspected some hardware problem related to the IIT floating point unit,
but I got second thoughts because even disabling the FPU (setting
the environment variable NO87 = 1), under the Watcom compiler, 
the result remains unchanged.

(BTW my Watcom compiler does *not* incorporate the last patches;
I did request them and I'll try again when I get them.)

Now about Paranoia:

For MS Fortran 5.1, I get *exactly* the same behavior for an
OS/2 16 bits executable run under OS/2 2.0, for a DOS executable
under OS/2 2.00 and for the DOS executable under DOS 5.00.  I
don't have a machine with OS/2 1.3 handy, so I didn't try that.

The first message from paranoia was about Radix: it says:

Radix = ****
Closest relative separation is 2.11758237E-22
Recalculating radix and precision
gets better closest separation is .54210E-19
mystery: recalculated radix is .200000E+1
FAILURE: (1-u1)-1/2 < 1/2 is false so this program may malfunction.
...

SERIOUS DEFECT: disagreements among values of X!, Y!, Z1
respectively .1084202E-18  .5421011E-19   .5421011E-19
are symptoms of inconsistencies introduced by extra-precise
evaluation of allegedly "optimized" arithmetic
subexpressions.  Possibly some part of this
test is inconsistent; PLEASE NOTIFY KARPINSKI !
....

Next, after milestone 30, I get 3 SERIOUS DEFECTS about lacking 
guard digits, and one FAILURE: multiplication gets too many last digits
wrong.

After Milestone 40, I get another FAILURE: incomplete carry-propagation
in addition.  Add/subtract appears to be chopped, and one FLAW.

Then, after milestone 90, I get a DEFECT: .300000000E+01^(1)=.3000000E+01
compares unequal to correct...

I got another DEFECT after milestone 130.

Finally, after milestone 160, it crashes with a -sqrt: domain error,
preceded by another SERIOUS DEFECT and a FAILURE: comparisons
are confused by overflow.

At that point, I cannot restart the test.

Under Watcom, (old, unpatched version), I get to after Milestone 130
when it crashes  (floating point overflow) when calculating
x^((X+1)/(x-1)) as x -> 1, vs. exp(2). 

Without any defect of failure or flow before that.  I'll try
again after I get the patches.

BTW, I also tried on an RS/6000, and I got one DEFECT, with and without
optimization, and on an HP 9000/710, where I got no problem at all
without optimization, and one defect and one failure with all
optimizations on.

Luc B