Re: [boost] Re: Re: is_nan
"Fernando Cacciola" <[EMAIL PROTECTED]> 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. | 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. 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. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_nan
>| >| 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 account for that situation. Just as you won't put bounds check in an internal function accessing an internal array with a fixed known size. 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? That is, can a reasonable implementation of it be so wrong as to _generate_ a sNAN? Or are you arguing that the interval library should contend for possible sNAN as input? If the former, I'm sure we are all interested in knowing how can that happen. If the later, I agree with Guillaume that this is a design decision that is already made, and I don't see a compelling reason for changing it. Most likely, if the user inputs sNAN to the interval library, a trap will be triggered way before isnan() is called. An interval library _could_ be designed to cope with sNAN, but this is not the case here and I don't see a real benefit for adding such complexity. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_nan - how to flag missing values?
"Paul A. Bristow" <[EMAIL PROTECTED]> writes: | Thanks but this still leaves me feeling that there is a need for a | 'Standard and Portable' way of indicating 'missing value', sorry if I sounded negative, that wasn't the intent. I would to make sure we all undertsand and agree on what is going on. By "standard and Portable", we need to specifiy exactly what that means. On some plateform, the notion of special values like NaN just does not make sens -- either a floating point always object represents a value. So on those plateforms, we won't have the notion of "missing value". Clearly such plateform don't have things like NaNs. | but perhaps this will remain one of the many unmet needs. Choosing a | bit pattern(s) for 'missing value'etc doesn't seem easily portable | from your other posts on detecting NaNs in general. this is an area where practice varies from one community to another; unfortuenatly. But, from time to time, some architwectures manuals seem to recommand some practices. | Does we have to | have processor specific macros to implement an bool | is_missing(double)? Yes, I think that we would need some target-specific macros to implement notions that missing values (I would prefer singular values). | Can one be sure that the bit pattern chosen for | the 'missing value' NaN won't be produced from a computational | mishap? That is why I would suggest conducting some analysis to see how much practice varies. | Is there a reason why it should it be a quiet or signalling NaN? If we were to stay in the real of C99, I would say it should be a qNaN -- because C99 does not support yet sNaNs. On the other hand the only traditional use of sNaN was for unitialized objets. | Leaves me a bit :-( Floating point arithmetic really is a minefield :-( -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: is_nan - how to flag missing values?
Thanks but this still leaves me feeling that there is a need for a 'Standard and
Portable' way of indicating 'missing value', but perhaps this will remain one of
the many unmet needs. Choosing a bit pattern(s) for 'missing value'etc doesn't
seem easily portable from your other posts on detecting NaNs in general. Does
we have to have processor specific macros to implement an bool
is_missing(double)? Can one be sure that the bit pattern chosen for the 'missing
value' NaN won't be produced from a computational mishap? Is there a reason why
it should it be a quiet or signalling NaN?
Leaves me a bit :-(
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Dos Reis
| Sent: Wednesday, July 16, 2003 10:46 PM
| To: Boost mailing list
| Subject: Re: [boost] Re: Re: is_nan - how to flag missing values?
|
|
| "Paul A. Bristow" <[EMAIL PROTECTED]> writes:
|
| | | Signalling NaNs are used to indicate missing initialization values.
| |
| | This is OK for catching missing initialization by mistake - but not
| | for OK for deliberately missing because there really is no value
| | (measurement missing).
|
| There is not just one qNaN (nor just one sNaN). There is a range for
| NaNs. And most of the systems I worked with, the pattern bits in a
| NaN is used to communicate the reason of being of the NaN. For
| example, it may output sNaN("missing-value").
|
| Note: C99 provides a pseudo-standard way to produce NaNs, through the
| functions
|
| double nan(const char*);
| float nanf(const char*);
| long double nanl(const char*);
|
| |
| | In this case, for example calculating the mean, you want to test if
| the value is
| | present/valid 'is_not_missing' before you add it to the sum and
| increment the
| | count.
| |
| | Testing !is_nan is possible solution but I'm not sure it is ideal.
|
| Indeed, it is no good.
|
| | Suggestions?
|
| I would first make a summary of the usage of the bit patterns for NaNs
| and decide on one and document it.
| ___
| Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_nan - how to flag missing values?
"Paul A. Bristow" <[EMAIL PROTECTED]> writes:
| | Signalling NaNs are used to indicate missing initialization values.
|
| This is OK for catching missing initialization by mistake - but not
| for OK for deliberately missing because there really is no value
| (measurement missing).
There is not just one qNaN (nor just one sNaN). There is a range for
NaNs. And most of the systems I worked with, the pattern bits in a
NaN is used to communicate the reason of being of the NaN. For
example, it may output sNaN("missing-value").
Note: C99 provides a pseudo-standard way to produce NaNs, through the
functions
double nan(const char*);
float nanf(const char*);
long double nanl(const char*);
|
| In this case, for example calculating the mean, you want to test if the value is
| present/valid 'is_not_missing' before you add it to the sum and increment the
| count.
|
| Testing !is_nan is possible solution but I'm not sure it is ideal.
Indeed, it is no good.
| Suggestions?
I would first make a summary of the usage of the bit patterns for NaNs
and decide on one and document it.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: is_nan
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Dos Reis | Sent: Sunday, July 13, 2003 9:22 AM | To: Boost mailing list | Subject: Re: [boost] Re: Re: is_nan | | | And can anyone help with allowing one to easily customise the | display of NaNs?(and infs, max, min...?) | | I believe that a new (derived) num_put facet is the way | | to do this. | Does anyone have an actual implementation of this to contribute too? | | I'm willing to volunteer but I'm not sure I really understand the | question. Can you elaborate a little bit? | | -- Gaby If you 'show' a qNaN (or indeed an sNaN) with MSVC, you get cout << "The quiet NaN for type float is: " << numeric_limits::quiet_NaN( ) << endl; Output: The quiet NaN for type float is: 1.#QNAN But suppose you want to display another message instead, perhaps to output data for input by some other system that recognizes all qNaNs as, say, "NaN", so the output would be The quiet NaN for type float is: NaN AND would be portable for all platforms, of course. Similarly for infs, max, min - if you get floating point inf, max or min as a result of a calculation, it should be shown as special to the reader? Paul PS IMHO This is more important than it may appear because it, with the lack of a Standard isnan test, is preventing real-life use of NaNs. Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: is_nan - how to flag missing values?
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Dos Reis | Sent: Sunday, July 13, 2003 9:22 AM | To: Boost mailing list | Subject: Re: [boost] Re: Re: is_nan | | | "Paul A. Bristow" <[EMAIL PROTECTED]> writes: | | There is also a single IEEE FP pattern called 'indeterminate' or | what Intel call | | 'NotAVal" (0x1fffe000...) which might become useful as a Portable Standard | | "missing value" marker if portably supported? | I won't take that road. Well if not then can you suggest a potentially Portable and Standard way to indicate 'missing values' in arrays etc of floating point values. I'm not sure that a qNaN is the best way to do this - it seems better suited to the result of compuational mishaps. | Signalling NaNs are used to indicate missing initialization values. This is OK for catching missing initialization by mistake - but not for OK for deliberately missing because there really is no value (measurement missing). In this case, for example calculating the mean, you want to test if the value is present/valid 'is_not_missing' before you add it to the sum and increment the count. Testing !is_nan is possible solution but I'm not sure it is ideal. Suggestions? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_nan
"Paul A. Bristow" <[EMAIL PROTECTED]> writes: | I think this would be excellent (and overdue). It needs to support double and | long double (and facilitate UDTs too if possible). | | There is also the matter of signalling and quiet NaN. Although signalling NaN | may cause an hardware exception if enabled, I suspect it is more useful if isnan | returns ture for both types of NaN. Agreed. It is no question that isnan should distinguish between Quiet NaNs and Signalling NaNs. They are all NaNs. | At least we should make this clear. I | think this is what MSVC 7.1 does but the documentation is thin. | | There is also a single IEEE FP pattern called 'indeterminate' or what Intel call | 'NotAVal" (ox1fffe000...) which might become useful as a Portable Standard | "missing value" marker if portably supported? I won't take that road. Signalling NaNs are used to indicate missing initialization values. | And can anyone help with allowing one to easily customise the display of NaNs? | (and infs, max, min...?) I believe that a new (derived) num_put facet is the way | to do this. Does anyone have an actual implementation of this to contribute | too? I'm willing to volunteer but I'm not sure I really understand the question. Can you elaborate a little bit? -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_nan
Guillaume Melquiond <[EMAIL PROTECTED]> writes: | On Sat, 5 Jul 2003, Fernando Cacciola wrote: | | > Thanks to Gabriel we may have an is_nan() right now. | > Is there anything else that the interval library uses which might be better | > packed as a compiler-platform specific routine? | | All the hardware rounding mode selection stuff. It's equivalent to the | C header file. is not the way I would like to see better support for floating point types and access to executing environment in C++. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_nan
"Fernando Cacciola" <[EMAIL PROTECTED]> writes: [...] | > > Most compilers provide a non standard extension for this purpose. | > > For instance, Borland uses _isnan. | > > In general, these extensions are found on . | > | > In fact, since it is not specified by the C++ standard, isnan comes from | > the C headers and is supposed to be found in . | > | Right.. I was actually thinking on the C header but wrote it incorrectly. | I meant . I would like to point out that a correct implementation of isnan would 1) use a reference to its parameter 2) rely on compiler extension. (I'll try to get built-in support for isnan in GCC). -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: is_nan
I think this would be excellent (and overdue). It needs to support double and long double (and facilitate UDTs too if possible). There is also the matter of signalling and quiet NaN. Although signalling NaN may cause an hardware exception if enabled, I suspect it is more useful if isnan returns ture for both types of NaN. At least we should make this clear. I think this is what MSVC 7.1 does but the documentation is thin. There is also a single IEEE FP pattern called 'indeterminate' or what Intel call 'NotAVal" (ox1fffe000...) which might become useful as a Portable Standard "missing value" marker if portably supported? And can anyone help with allowing one to easily customise the display of NaNs? (and infs, max, min...?) I believe that a new (derived) num_put facet is the way to do this. Does anyone have an actual implementation of this to contribute too? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Joel de Guzman | Sent: Monday, July 07, 2003 5:15 PM | To: Boost mailing list | Subject: Re: [boost] Re: Re: is_nan | | | Fernando Cacciola <[EMAIL PROTECTED]> wrote: | > Fernando Cacciola <[EMAIL PROTECTED]> wrote in message | > news:[EMAIL PROTECTED] | >> | >> Thanks to Gabriel we may have an is_nan() right now. | >> | > Oops! | > It was Joel de Guzman who offered his is_nan() implementation. | > | > Sorry Joel :-) | | No problem. I thought Gaby also offered an implementation ahead of me. | So you guys are interested then? It would really be nice to have a | common boost implementation. I'll put it in the sandbox tomorrow. | | -- | Joel de Guzman | joel at boost-consulting.com | http://www.boost-consulting.com | http://spirit.sf.net | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_nan
Fernando Cacciola <[EMAIL PROTECTED]> wrote: > Fernando Cacciola <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> >> Thanks to Gabriel we may have an is_nan() right now. >> > Oops! > It was Joel de Guzman who offered his is_nan() implementation. > > Sorry Joel :-) No problem. I thought Gaby also offered an implementation ahead of me. So you guys are interested then? It would really be nice to have a common boost implementation. I'll put it in the sandbox tomorrow. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_nan
Fernando Cacciola <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Thanks to Gabriel we may have an is_nan() right now. > Oops! It was Joel de Guzman who offered his is_nan() implementation. Sorry Joel :-) Fernando ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_nan
On Sat, 5 Jul 2003, Fernando Cacciola wrote: > Thanks to Gabriel we may have an is_nan() right now. > Is there anything else that the interval library uses which might be better > packed as a compiler-platform specific routine? All the hardware rounding mode selection stuff. It's equivalent to the C header file. In the interval library, it's handled by at least 9 files (all the boost/numeric/interval/detail/*_rounding_control.hpp headers for example) and some new files may be added each time a new compiler-platform support is needed. Guillaume ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_nan
"Joel de Guzman" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > Fernando Cacciola <[EMAIL PROTECTED]> wrote: > > Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in > > >> Yes. It is an incorrect (unfortunately popular) > >> implementation. > >> > > Right. We should say that more often. It is incorrect > > however popular. > > > > Most compilers provide a non standard extension for this > > purpose. > > For instance, Borland uses _isnan. > > In general, these extensions are found on . > > The best approach, IMO, is to have a boost::is_nan() with > > compiler specific implementations. > > Hi, > > We have an is_nan(float) implementation (for quiet NaNs of course) > that does just that. Right now, it supports most compilers on Win32 but it > should be straight-forward to support others. Right now, it is tested on: > > g++2.95.3 (MinGW) > g++3.1 (MinGW) > Borland 5.5.1 > Comeau 4.24 (Win32) > Microsoft Visual C++ 6 > Microsoft Visual C++ 7 > Microsoft Visual C++ 7.1 > Metrowerks CodeWarrior 7.2 > > The default implementation assumes IEEE754 floating point. It takes advantage > of the fact that IEEE754 has a well defined binary layout for quiet NaNs. Platform > specific implementations forward the call to the correct platform header when > available. The code does not rely on the availability of numeric_limits. > > I hope this can be used as the basis of a standardized boost::is_nan utility. > Thoughts? > It works for me Checking directly for the bit patterns is the way it has been done for years in the Windows platform. As long as this implementation is correctly dispatched from the user function I see no problem. BTW, it just poped my mine: could SFINAE be arranged to detect the existence of a global non-member function? We could write an implementation that dispatches to _isnan(), __isnan(), an so on if available. (though this would break the ODR on the other hand) Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_nan
--
Fernando Cacciola
fernando_cacciola-at-movi-dot-com-dot-ar
"Guillaume Melquiond" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
> On Fri, 4 Jul 2003, Fernando Cacciola wrote:
>
> > Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > > "jvd" <[EMAIL PROTECTED]> writes:
> > >
> > > | Dear boosters,
> > > |
> > > | seems like this code
> > > |
> > > | template< typename T >
> > > | bool is_nan( const T& v )
> > > | {
> > > | return std::numeric_limits::has_quiet_NaN && (v != v);
> > > | }
> > > |
> > > | does not work correctly on some machines.
> > >
> > > Yes. It is an incorrect (unfortunately popular) implementation.
> > >
> > Right. We should say that more often. It is incorrect however popular.
>
> Yes, it is incorrect for C++. But it's something we can hope to see one
> day. For example, in the LIA-1 annex I about C langage bindings, it is
> written that != is a binding for IEEE-754 ?<> operator (unordered
> compare). In the C9X annex F.8.3 about relational operators, it is written
> that the optimization "x != x -> false" is not allowed since "The
> statement x != x is true if x is a NaN". And so on.
>
Yes of course... but we will have to wait until the LIA-1 bindings
make into C++.
But not too long I hope.
> > Most compilers provide a non standard extension for this purpose.
> > For instance, Borland uses _isnan.
> > In general, these extensions are found on .
>
> In fact, since it is not specified by the C++ standard, isnan comes from
> the C headers and is supposed to be found in .
>
Right.. I was actually thinking on the C header but wrote it incorrectly.
I meant .
> > The best approach, IMO, is to have a boost::is_nan() with compiler specific
> > implementations.
>
> Yes, and there also were discussions on this mailing-list about a
> header. But unless somebody finds the time to tackle this
> whole problem...
>
Thanks to Gabriel we may have an is_nan() right now.
Is there anything else that the interval library uses which might be better
packed as a compiler-platform specific routine?
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
