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
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: | 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?
| -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
| -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_limitsfloat::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?
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
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 float. | | In fact, since it is not specified by the C++ standard, isnan comes from | the C headers and is supposed to be found in math.h. | | Right.. I was actually thinking on the C header but wrote it incorrectly. | I meant cfloat. 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
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 | fenv.h C header file. fenv.h 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
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
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
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 fenv.h 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
