[floating point utilities] Review request
This is a request for a formal review of the Floating Point Utilities library. The library contains the following: 1. Floating point number classfication functions: fpclassify, isfinite, isinf, isnan, isnormal (Follows TR1) 2. Sign bit functions: signbit, copysign, changesign (Follows TR1) 3. Facets that format and parse infinity and NaN according to the C99 standard. (These can be used for portable handling of infinity and NaN in text streams.) The library is available in the vault in the folder Math-Numerics. --Johan Råde
Johan R?de wrote:
3. Facets that format and parse infinity and NaN according to the C99 standard. (These can be used for portable handling of infinity and NaN in text streams.)
Are lower-level functions available to use them in optimized lexical_cast? -- Alexander Nasonov http://nasonov.blogspot.com No man is so foolish but he may sometimes give another good counsel, and no man so wise that he may not easily err if he takes no other counsel than his own. He that is taught only by himself has a fool for a master. -- Hunter S. Thompson -- This quote is generated by: /usr/pkg/bin/curl -L http://tinyurl.com/veusy \ | sed -e 's/^document\.write(.//' -e 's/.);$/ --/' \ -e 's/<[^>]*>//g' -e 's/^More quotes from //' \ | fmt | tee ~/.signature-quote
Alexander Nasonov wrote:
Johan R?de wrote:
3. Facets that format and parse infinity and NaN according to the C99 standard. (These can be used for portable handling of infinity and NaN in text streams.)
Are lower-level functions available to use them in optimized lexical_cast?
No. What lower level functions are needed for optimized lexical cast?
Johan R?de wrote:
Are lower-level functions available to use them in optimized lexical_cast?
No.
What lower level functions are needed for optimized lexical cast?
something like array<char,N> from_double(double value, char decimal_point, /* other args */); where N - max length including '\0'. double to_double(char const* str, /* other args */) throw(bad_lexical_cast); -- Alexander Nasonov http://nasonov.blogspot.com True patriotism hates injustice in its own land more than anywhere else. -- Clarence Darrow -- This quote is generated by: /usr/pkg/bin/curl -L http://tinyurl.com/veusy \ | sed -e 's/^document\.write(.//' -e 's/.);$/ --/' \ -e 's/<[^>]*>//g' -e 's/^More quotes from //' \ | fmt | tee ~/.signature-quote
Alexander Nasonov wrote:
Johan R?de wrote:
Are lower-level functions available to use them in optimized lexical_cast?
No.
What lower level functions are needed for optimized lexical cast?
something like
array<char,N> from_double(double value, char decimal_point, /* other args */);
where N - max length including '\0'.
double to_double(char const* str, /* other args */) throw(bad_lexical_cast);
What exactly is "optimized lexical cast"? Is it a new implementation of lexical_cast that does not use streams? Will it be part of 1.34? Are there any docs? --Johan
Johan R?de wrote:
What exactly is "optimized lexical cast"? Is it a new implementation of lexical_cast that does not use streams? Yes, some combinations of types don't use streams.
Will it be part of 1.34? No.
Are there any docs? Official boost documentation is not changed because there no changes in interface. See my acticle in Overload 74: http://accu.org/var/uploads/journals/overload74.pdf
-- Alexander Nasonov http://nasonov.blogspot.com No good film is too long and no bad film is short enough. -- Roger Ebert -- This quote is generated by: /usr/pkg/bin/curl -L http://tinyurl.com/veusy \ | sed -e 's/^document\.write(.//' -e 's/.);$/ --/' \ -e 's/<[^>]*>//g' -e 's/^More quotes from //' \ | fmt | tee ~/.signature-quote
While porting the proposed Boost.Units (currently mcs::units) library to some (mainly older) platforms, we have run into problems with <cmath> functions being unavailable. For example, gcc 3.4.4 on Cygwin does not implement nexttoward, llrint, llround (possibly others). Given that the proposed fp utilities library already gives portable implementations of some TR1 functions in <cmath>, is it possible to extend support to provide a TR1 support for all functions aside from the special functions that John and Paul are working on providing? Matthias
Matthias Schabel wrote:
While porting the proposed Boost.Units (currently mcs::units) library to some (mainly older) platforms, we have run into problems with <cmath> functions being unavailable. For example, gcc 3.4.4 on Cygwin does not implement nexttoward, llrint, llround (possibly others). Given that the proposed fp utilities library already gives portable implementations of some TR1 functions in <cmath>, is it possible to extend support to provide a TR1 support for all functions aside from the special functions that John and Paul are working on providing?
Matthias _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
llrint: I don't see how to do a platform independent implementation. The function rounds to the nearest integer, using the current rounding direction. You get the current rounding direction using fegetround. It would be very hard to do a platform independent implementation of fegetround. I think it will be very hard to do platform independent implementations of any of the fe... functions in <cmath>. You probably need assembler to implement them at all. Does the Boost.Units library really need these functions? nextafter, nextbefore, nexttoward: Doable. To get the next floating point number after a given floating point number you copy the bits into an integer, add 1, and copy them back. You also need to do some special handling of 1: 0 2: std::numeric_limis<T>::min (if there are no denormals) 3: std::numeric_limits<max>::max 4: infinity 5: NaN If there is a need for this, I might do it, but not during the next two months. -- Johan Råde
llrint:
Does the Boost.Units library really need these functions?
Not necessarily _need_ - we're just trying to implement all of the TR1 functions for which quantity argument make sense. That means that we don't have to worry about the special functions, but do have to worry about the ones mentioned here... Even just wrapping the platform-dependent parts in a boost function would be fine, AFAICS...
nextafter, nextbefore, nexttoward:
Doable.
To get the next floating point number after a given floating point number you copy the bits into an integer, add 1, and copy them back. You also need to do some special handling of
1: 0 2: std::numeric_limis<T>::min (if there are no denormals) 3: std::numeric_limits<max>::max 4: infinity 5: NaN
If there is a need for this, I might do it, but not during the next two months.
From my standpoint, it would strengthen the fp utils proposal if it was relatively comprehensive - I'd be happy to test these out if that would help. Matthias
Matthias Schabel wrote:
From my standpoint, it would strengthen the fp utils proposal if it was relatively comprehensive - I'd be happy to test these out if that would help.
My goal has never been to do something comprehensive; only to do something useful. -- Johan
participants (3)
-
Alexander Nasonov -
Johan Råde -
Matthias Schabel