Re: [boost] Stream input and output of NaN and infinity

From: Damien Fisher (damienf_at_[hidden])
Date: 2006-05-16 01:21:52

On 5/16/06, Robert Ramey <ramey_at_[hidden]> wrote:
>
> David Abrahams wrote:
>
> > Not only break, but break unfixably.  There are important numerical
> > applications where large collections of individual floating values
> > (e.g. vectors and matrices) have to be computed in parallel, and one
> > or more NaNs in the result do not render the whole calculation
> > useless.
>
> I suppose that's possible. I'm not familiar with such applications.
> It sounds to me that they would be implemented in special hardware
> and sort of out of the C++ mainstream.

[Sorry to jump into the thread so late...but I just can't resist.]

It really seems to me that you are objecting to a numerical model which has
worked well for decades in numerous domains and into which much effort has
been expended.

The IEEE

> Besides all that, eliminating NaNs from the serialization problem
> > space is really impossible.  Even if we struck them from the C++
> > language, someone would effectively recreate them using
> > optional<float> or the equivalent.
>
> Actually that would be an improvement in that the "union" would
> be explicit, visible and modifiable.  In fact I could see the utility
> right now of a "safe_float" which would look something like
>
> #ifndef NDEBUG
> BOOST_STRONG_TYPE(float, safe_float)
> safe_float operator/(safe_float x, safe_float y){
>     if(y < epsilon) // machine dependent epsilon
>         throw overflow_exception
>     return x / y;
> }
> ...
> #else
> #define safe_float float
> #endif
>
> >> I would argue that such code is already broken anyway - it just
> >> looks like its working.
>
> > Really, you still think so?
>
> My view on this is in another post.
>
> > If so, I'd like to know how you measure "brokenness."
>
> A program which produces an undefined result is "broke"
>
> BTW - as far as the serialization system is concerned I
> never had a problem with the idea of recovering the exact
> kind of "undefined" data.  Its just that there's no way to
> do it with archives which might be ported from one machine
> to another as there is no guarentee that the reading
> machine has the same set of of undefined results as the
> source machine.  Its even worse, there is way to write
> portable code which will generate any specific one
> of the "undefined" types.  One might hack something
> together that would recover some undefined type
> but it wouldn't be guarenteed to the the same original
> type of undefined type.  So the whole effort would be
> for naught.
>
> There was a discussion of this
> on the list a while ago and this was the conclusion.  It
> was in the course of this discussion that I reached the
> conclusions I've stated here.
>
> Robert Ramey
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>