[boost] Re: Re: Re: is_nan

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2003-07-26 16:49:01

"Gabriel Dos Reis" <gdr_at_[hidden]> escribió en el mensaje news:m3llulj9yh.fsf_at_uniton.integrable-solutions.net...
> "Fernando Cacciola" <fcacciola_at_[hidden]> writes:
>
> | >|
> | >| What don't you understand in the expression "isnan is a private function"?
> | >
> | >What being private has to do with being trapping or not?
> | >
> | Guillaume point is that this isnan(), being an implementation
> | detail, is known to never recieve a sNAN, so it does not has to
>
> No, that is not exactly what is beind discussed.  He is assuming isnan
> will not receive an sNaN.
>
He's not assumining it, he is stating it.
Or, put another way, interval_detail::isnan() receiving an sNAN can only ocurr as a result of invalid input, and even in the
presence of such input, the sNAN may not make it to isnan().

Is your point that the interval library should handle such invalid input? That's probably a good point but I think it goes way
further than making isnan() non-trapping. For that goal the whole library design must be reconsidered.
Personally, I wouldn't take on such a job, or perhaps, I'd do it at large, not on a per library basis.
If out there is a power user how really knows how to deal with sNAN properly enough as to require Boost.Interval to also deal
with it, she probably isn't using C++ on the first place.
Doing math on such a level requires too many tools not provided by the language and most numeric stuff is not properly
implemented anyway.

> | Your point I can't understand though.
> |
> | Are you saying that an isnan() could trigger a sNAN trap even if it
> | doesn't recieve a sNAN?
>
> No. I'm saying that his implementation of isnan will trigger a trap if
> the operand contains an sNaN -- as input.  And yes, no normal
> arithmeic operations would produce an sNaN.  But, airthmetic
> operations are not the only way to produce an interval.
>
Of course not, yet I think it is fair to require users not to produce an interval with an sNAN.
It isn't that difficult, is it?
In my experience, it is better to deal with sNAN at the application level.

If your point is that it is still possible to produce an interval with a sNAN for reasons so subtle that it couldn't be avoided
by a careful implementation of the user code, then the issue goes beyond isnan() and affects the interval library as a whole.

But I can't think of a reason why a user program couldn't handle sNAN by itslef making sure no such intervals are ever produced.

> I know the interval library is already accepted -- and yes I could
> have made comments earlier, but for several reasons I could not.
> However, I do think that it is still time to correct that sloppiness.
>
I agree that it usually still time to make simple and useful corrections.
It's just that I'm not sure this one is something to be corrected, at least not within isnan() alone.

Fernando Cacciola