Re: Math coprocessors for gs?

[glyn@gsb013.cs.ualberta.ca (Reade Glyn Devin)]

In article <behrenss.748335191@hphalle6>, Soenke Behrens writes...
> 
> tracadas@athena.mit.edu (Philip W Tracadas) writes:
> 
> >I'm looking for a way to increase the precision (and to
> >some extent the speed) of my gs' calculations.  Is there
> >any such thing as a math coprocessor for the //'s?
> 
> Yes, the NumberCruncher. Uses an 68882, was made in FRG, and I don't
> know if it's still available. There's also the FPE, basically the same
> card, but I think it has bugs.

I would classify these more as inconsistencies with SANE than bugs;
to quote from the FPE manual:

  "The FPE returns results with the same accuracy but behaves differently
   for zero, denormalized numbers, infinities, and NANs" ... with round-
   to-integer, truncate-to-integer, and binary log (for 0 and infinity).

In other words, both (or neither of -- as you prefer) SANE and the FPE
are "correct"; they just use different conventions.

In practise, I have found that in their own ways the FPE coprocessor and
the Zip accelerator have greatly decreased my idle time ... I have never
noticed inconsistencies in calculations with the FPE that weren't
significantly less than the significant figures in my data (sorry 'bout
the double word, there).

Henrik has found some sync problems when writing to the FPE with assy; I
haven't had any trouble with Orca C in this respect.  (OTOH, someone
posted a bug report for the Orca C _library_ for the FPE a while back --
I don't have that info handy.)

--
        G. Devin Reade          glyn@cs.ualberta.ca        <-- preferred
                                glynr@ersys.edmonton.ab.ca