On Wed, 31 Aug 2005, Tim Jenness wrote:
> Can people please try compiling this fortran program on their systems?
> It's a short program that perturbs some orbital elements using slalib
> but it seems to be working right on the edge of numerical stability.
>
> * On my linux system it does run fine (status=0) *unless* I remove
> the D0 from variable E (then it fails with status=-5). So two
> runs, one with and one without the D0 would be great.
>
> * On my linux system linking against a libsla.a from March 7th it works
> fine even if the E parameter does not have D0. Although bizarrely,
> rebuilding from March CVS checkout doesn't help me now. I note that
> the SLA_EVP calculation changed between March and now.
>
> * On my mac it always fails with status=-5 (g77 and g95)
Same for Solaris and Tru64, all three values produce the same result, with
status=-5.
> So I'm not sure whether this is an issue for Pat or just a flaky operating
> system compiler combination...
Well if you believe it, Intel claims to be the more accurate floating
point representation, so that would tie in with this being a case of
the extra precision leading to an odd result. See the section "Current
IEEE 754 Implementations" in:
http://www.validlab.com/goldberg/addendum.html
to appreciate how such extra precision, and how it is used, could lead to
very different results. BTW, if I compile SLALIB with -ffloat-store (not
recommended as this is supposed give slower code) and run it under
Linux/g77 I do get the same results and status=-5.
Cheers,
Peter.
|