This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: make check error (IEEE ...?)


Brian Gough wrote:
> 
> Assume the least possible. i.e. the model for ordinary numbers, +/-{0,
> [DBL_MIN, DBL_MAX]}

Perhaps it would be better if I said that I'm not so worried
about what to assume. The question is really what variation
could/should we try to encapsulate. I don't want to build
things haphazardly into the implmentation. It would be
better to figure out what functionality is needed and
introduce a layer there, which could be adjusted at
configure time.

Of course, this all should have been done on day one...


> Full IEEE support is hard to find.  Subsets are the norm. Conformance
> depends on both the compiler and the fpu (classic example, compiler
> optimisation x==x, where x=NaN). Conformance is always "claimed" by
> the manufacturer, but there is no independent test (c.f. FDIV bug).
> Programs that "depend on" (i.e. rely on) a lot of IEEE features are
> not very portable, and are almost impossible to debug when things go
> wrong.

I'm sure that is the sad truth.


> You could use the
> GSL_POSINF GSL_NEGINF GSL_NAN macros for +/-Inf,NaN return values.

Yes. That is a separate issue though. Those
cases just need to be chased down in the impl.


> top-level rounding function would be useful for isolating the extended
> precision issue into a single function.  This could then use the
> appropriate assember instruction to round, rather than "volatile", or
> be a no-op on platforms that do not have extended precision.

Yes, exactly. What I have in mind is encapsulating as much of
this as needed. This includes some of the direct functionality
like rounding, as well as some other issues, such as what
happens when you multiply two numbers, where one or both
of the inputs and/or the result may be special values.

We just need to know these things. Has anybody
out there done this already? It need not be a
complete layer (which may not even be possible),
but at least something which detects some
features or problems and configures/builds
an appropriate layer.

Does anybody know the status of arithmetic support
in C9x (or whatever it is called now)? There is supposed
to be something new there. Although we probably cannot
rely on it, it would good to see what they had
decided was feasible.


-- 
G. Jungman

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]