[Ann] Proposed Boost.TR1 library: first complete version now available.
As some of you already know, I've been working on producing a Boost implementation of the Technical Report on C++ Library Extensions, the first full version is now available from: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=tr1 The documentation can also be viewed online at: http://freespace.virgin.net/boost.regex/tr1/doc/html/tr1.html For those new to the TR, the following are supported in this release: Reference Wrappers Smart Pointers Class template result_of. Function template mem_fn. Function Object Binders. Polymorphic function wrappers. Type Traits. Random Number Generators and Distributions. Tuples. Tuple Interface to std::pair. Fixed Size Array. Hash Function Objects. Regular Expressions. Complex Number Algorithm Overloads. Complex Number Additional Algorithms. The following are not yet supported, but will be as soon as hash-tables make it into Boost: Unordered Associative Set (Hash Table). Unordered Associative Map (Hash Table). The following do not currently have Boost-licence compatible implementations and are not supported: Mathematical Special Functions. C99 Math Functions. Finally, note that I may split the complex number stuff out into a separate submission (I'll post another message about this). As ever, comments are most welcome. John.
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:007501c537a0$690bc040$51eb1b52@fuji...
As some of you already know, I've been working on producing a Boost implementation of the Technical Report on C++ Library Extensions, the first full version is now available from: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=tr1
The documentation can also be viewed online at: http://freespace.virgin.net/boost.regex/tr1/doc/html/tr1.html
Nice! Boost developers of TR1 components should read John's docs to be sure he has got it right for their component , and to note what will have to be changed in his docs when a TR1 incompatibility is fixed. It would probably be a courtesy to John to notify him of such a change, so he doesn't have to monitor changes to every Boost TR1 library. --Beman
"Beman Dawes" <bdawes@acm.org> writes:
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:007501c537a0$690bc040$51eb1b52@fuji...
As some of you already know, I've been working on producing a Boost implementation of the Technical Report on C++ Library Extensions, the first full version is now available from: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=tr1
The documentation can also be viewed online at: http://freespace.virgin.net/boost.regex/tr1/doc/html/tr1.html
Nice!
Not just nice; this is totally awesome! Good job, John! -- Dave Abrahams Boost Consulting www.boost-consulting.com
As some of you already know, I've been working on producing a Boost implementation of the Technical Report on C++ Library Extensions, the first full version is now available from:
John, this is great stuff! What's your timeline for migrating from boost-sandbox to the main repository? Regards, Christopher Currie
John, this is great stuff! What's your timeline for migrating from boost-sandbox to the main repository?
To be honest I haven't given it much thought, I was planning on asking for a review quite soon, but I want to finish off a rewrite of the type traits docs in time for 1.33 if I can. In any case given the 1.33 schedule, I don't think there's any way this can be reviewed and added in time for that release (unless anyone thinks otherwise, or the release is badly delayed or something). I also need to sort out with Hubert Holin, what I'm going to do with the new complex number code (add it to his special functions library, or something else). Thanks for the interest, John.
Somewhere in the E.U., le 13/04/2005 Bonjour In article <015d01c53f47$b005b880$b3560252@fuji>, "John Maddock" <john@johnmaddock.co.uk> wrote:
John, this is great stuff! What's your timeline for migrating from boost-sandbox to the main repository?
To be honest I haven't given it much thought, I was planning on asking for a review quite soon, but I want to finish off a rewrite of the type traits docs in time for 1.33 if I can.
In any case given the 1.33 schedule, I don't think there's any way this can be reviewed and added in time for that release (unless anyone thinks otherwise, or the release is badly delayed or something).
I also need to sort out with Hubert Holin, what I'm going to do with the new complex number code (add it to his special functions library, or something else).
I believe integration is the simplest route. How would you want to proceed? I can update the code documentation fairly rapidly, but the "background" (mathematical) part may take some time, especially if I try to produce explanatory figures. At any rate, if we are to feature-freeze in 48 hours, the former may just be possible but certainly not the later. I believe text explaining that some of the functions in the "Special Functions" library are actually part of the TR1 should not prove to be too confusing, and relevant passages of the TR1 could perhaps point to the "Special Functions" library documentation for additional information (not instead of the information you already provide). The body of code you produced is far greater (in more ways than one ;-) ) than what I have done, so perhaps it would be simpler if you merged my code into yours rather than the other way around. One sticking point perhaps would be that of the namespace these things live in, as I believe my implementations should be moved to ::std::tr1 as well, as per 8.16.4 of the TR1, and this raises the possibility of name conflicts. The sinus cardinal and hyperbolic sinus cardinal should preferably stay in ::boost::math, as they have not been introduced into the TR1, and quaternions and octonions depend upon them (though I could update that as well, of course). If I get around to adding valarray support for some of these functions, they would live in ::boost::math as well.
Thanks for the interest,
John.
Merci Hubert
I also need to sort out with Hubert Holin, what I'm going to do with the new complex number code (add it to his special functions library, or something else).
I believe integration is the simplest route. How would you want to proceed?
I can update the code documentation fairly rapidly, but the "background" (mathematical) part may take some time, especially if I try to produce explanatory figures. At any rate, if we are to feature-freeze in 48 hours, the former may just be possible but certainly not the later. I believe text explaining that some of the functions in the "Special Functions" library are actually part of the TR1 should not prove to be too confusing, and relevant passages of the TR1 could perhaps point to the "Special Functions" library documentation for additional information (not instead of the information you already provide).
Yes, the idea is that the TR1 docs just point to the relevent Boost docs. I'm not sure how much theoretical background is needed for these, I like your graphs for the real number versions very much, but I've never seen complex number graphs that really work well for me: the mathworld site makes a brave attempt to illustrate these, but IMO it doesn't convey that much information to me.
The body of code you produced is far greater (in more ways than one ;-) ) than what I have done, so perhaps it would be simpler if you merged my code into yours rather than the other way around. One sticking point perhaps would be that of the namespace these things live in, as I believe my implementations should be moved to ::std::tr1 as well, as per 8.16.4 of the TR1, and this raises the possibility of name conflicts. The sinus cardinal and hyperbolic sinus cardinal should preferably stay in ::boost::math, as they have not been introduced into the TR1, and quaternions and octonions depend upon them (though I could update that as well, of course). If I get around to adding valarray support for some of these functions, they would live in ::boost::math as well.
I think it should all be in boost::math, and then pulled into std::tr1 with using declarations (like the rest of the proposed TR1 implementation), and I don't think we can refactor all this in time for the 1.33 release if it sticks to schedule. So... right now I've got some existing docs to update in time for 1.33, how about I prepare a patch for the match lib after that and we can take it from there? Regards, John.
Somewhere in the E.U., le 15/04/2005 Bonjour In article <020701c540e4$ef150320$17120952@fuji>, "John Maddock" <john@johnmaddock.co.uk> wrote:
I also need to sort out with Hubert Holin, what I'm going to do with the new complex number code (add it to his special functions library, or something else).
I believe integration is the simplest route. How would you want to proceed?
I can update the code documentation fairly rapidly, but the "background" (mathematical) part may take some time, especially if I try to produce explanatory figures. At any rate, if we are to feature-freeze in 48 hours, the former may just be possible but certainly not the later. I believe text explaining that some of the functions in the "Special Functions" library are actually part of the TR1 should not prove to be too confusing, and relevant passages of the TR1 could perhaps point to the "Special Functions" library documentation for additional information (not instead of the information you already provide).
Yes, the idea is that the TR1 docs just point to the relevent Boost docs. I'm not sure how much theoretical background is needed for these, I like your graphs for the real number versions very much, but I've never seen complex number graphs that really work well for me: the mathworld site makes a brave attempt to illustrate these, but IMO it doesn't convey that much information to me.
OK, I'll try to see if I can come up with something more inspiring :-) .
The body of code you produced is far greater (in more ways than one ;-) ) than what I have done, so perhaps it would be simpler if you merged my code into yours rather than the other way around. One sticking point perhaps would be that of the namespace these things live in, as I believe my implementations should be moved to ::std::tr1 as well, as per 8.16.4 of the TR1, and this raises the possibility of name conflicts. The sinus cardinal and hyperbolic sinus cardinal should preferably stay in ::boost::math, as they have not been introduced into the TR1, and quaternions and octonions depend upon them (though I could update that as well, of course). If I get around to adding valarray support for some of these functions, they would live in ::boost::math as well.
I think it should all be in boost::math, and then pulled into std::tr1 with using declarations (like the rest of the proposed TR1 implementation), and I don't think we can refactor all this in time for the 1.33 release if it
Yes, we should assume the release will be on schedule, so time is too short.
sticks to schedule. So... right now I've got some existing docs to update in time for 1.33, how about I prepare a patch for the match lib after that and we can take it from there?
Sounds fine with me. In the mean time, I'll also try to deal with the "long double" deficiency already identified that some platforms suffer from, though that only affects the tests, not the library proper (I don't know if that will make it for 1.33).
Regards,
John.
Merci Hubert
Sounds fine with me. In the mean time, I'll also try to deal with the "long double" deficiency already identified that some platforms suffer from, though that only affects the tests, not the library proper (I don't know if that will make it for 1.33).
According to http://docs.sun.com/app/docs/doc/816-5173/6mbb8adu7?a=view the long double math functions on solaris should be pretty accurate, so I guess this could be a problem with the overloads declared in <cmath>, rather than the platform headers? Just guessing, you'd need to see the preprocessed source to be sure. John.
Somewhere in the E.U., le 19/04/2005 Bonjour In article <004e01c541d0$d6436070$cf200d52@fuji>, "John Maddock" <john@johnmaddock.co.uk> wrote:
Sounds fine with me. In the mean time, I'll also try to deal with the "long double" deficiency already identified that some platforms suffer from, though that only affects the tests, not the library proper (I don't know if that will make it for 1.33).
According to http://docs.sun.com/app/docs/doc/816-5173/6mbb8adu7?a=view the long double math functions on solaris should be pretty accurate, so I guess this could be a problem with the overloads declared in <cmath>, rather than the platform headers?
Just guessing, you'd need to see the preprocessed source to be sure.
John.
Yes, it is possible. Unfortunately, I do not have access to that platform. I found out about the problem while investigating a regression, and asking M. Caleb Epstein who ran the tests on that platform. Either that platform does not have tailored "long double" versions of some special functions, or they are not visible to the C++ compiler (note that numeric_limits is indeed correct for "long double" on that platform). Do we have some template metamagic to see if a given function signature is available? I had intended to test computation accuracy for some select values and compare with epsilon for that type (could still use it to check for QOI anyway...). Merci Hubert
Hubert Holin wrote:
Do we have some template metamagic to see if a given function signature is available? I had intended to test computation accuracy for some select values and compare with epsilon for that type (could still use it to check for QOI anyway...).
You can see my crude attempt at this at: http://lists.boost.org/boost/2005/04/23883.php http://lists.boost.org/boost/2005/04/23921.php I use the return type of the function to tell which overload was called. It's a bit odd on Solaris though, as both GCC and the Sun compiler seem to have the standard overloads, but my tests fail on GCC which suggests that the GCC long double overload doesn't have the full accuracy. Anyway, the following might be what you want. But I think some config macros, with good test cases, would be better. #include "boost/type_traits/detail/yes_no_type.hpp" #include <cmath> boost::type_traits::no_type is_long_double(double); boost::type_traits::yes_type is_long_double(long double); const bool has_long_double_frexp = sizeof(is_long_double(std::frexp((long double) 0.0, 1))) == sizeof(boost::type_traits::yes_type);
Somewhere in the E.U., le 21/04/2005 Bonjour In article <d43gnq$t9f$1@sea.gmane.org>, Daniel James <daniel@calamity.org.uk> wrote:
Hubert Holin wrote:
Do we have some template metamagic to see if a given function signature is available? I had intended to test computation accuracy for some select values and compare with epsilon for that type (could still use it to check for QOI anyway...).
You can see my crude attempt at this at:
http://lists.boost.org/boost/2005/04/23883.php http://lists.boost.org/boost/2005/04/23921.php
I use the return type of the function to tell which overload was called. It's a bit odd on Solaris though, as both GCC and the Sun compiler seem to have the standard overloads, but my tests fail on GCC which suggests that the GCC long double overload doesn't have the full accuracy.
Anyway, the following might be what you want. But I think some config macros, with good test cases, would be better.
#include "boost/type_traits/detail/yes_no_type.hpp" #include <cmath>
boost::type_traits::no_type is_long_double(double); boost::type_traits::yes_type is_long_double(long double);
const bool has_long_double_frexp = sizeof(is_long_double(std::frexp((long double) 0.0, 1))) == sizeof(boost::type_traits::yes_type);
Well, it looks like testing for the signature (using your code or presumably something from the upcoming for review function type library) will not preclude testing for actual accuracy... Though one can wonder at this stage if we are still dealing with QOI or a broken library. Merci Hubert
Well, it looks like testing for the signature (using your code or presumably something from the upcoming for review function type library) will not preclude testing for actual accuracy... Though one can wonder at this stage if we are still dealing with QOI or a broken library.
Looks like it might be a broken implementation: looking at the output from config_info at http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/out... it seems that _RWSTD_NO_OVERLOAD_C_POW is defined, and the Rogue Waves headers say: /* If your 'C' library does not provide overloads for the pow function * (i.e. pow(float,float), and pow(long double, long double) if appropriate), * then uncommment the following. */ /* #define _RWSTD_NO_OVERLOAD_C_POW 1 */ So I guess at least one API is broken. John.
"John Maddock" <john@johnmaddock.co.uk> writes: John, this is way cool.
Finally, note that I may split the complex number stuff out into a separate submission (I'll post another message about this). ^^^^^^^^^^
So is your intention to have this stuff undergo formal review and become part of Boost? If so, is there implementation duplication, or does it somehow use common headers and source files? -- Dave Abrahams Boost Consulting www.boost-consulting.com
So is your intention to have this stuff undergo formal review and become part of Boost? If so, is there implementation duplication, or does it somehow use common headers and source files?
I'm quite happy to have a separate review for this, but at present Hubert seems to think it's basically an extension of his special functions library (most of the algorithms are complex number versions of his hyperbolic special functions), so I'm preparing patches against that: all this new code will then end up in namespace boost::math, and the TR1 library (when it comes up for review) will just make use of that code rather than duplicating it. John.
"John Maddock" <john@johnmaddock.co.uk> writes:
So is your intention to have this stuff undergo formal review and become part of Boost? If so, is there implementation duplication, or does it somehow use common headers and source files?
I'm quite happy to have a separate review for this, but at present Hubert seems to think it's basically an extension of his special functions library
?? I'm asking about all of your Boost.TR1, including shared_ptr etc., not just the math part.
(most of the algorithms are complex number versions of his hyperbolic special functions), so I'm preparing patches against that: all this new code will then end up in namespace boost::math, and the TR1 library (when it comes up for review) will just make use of that code rather than duplicating it.
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams Boost Consulting www.boost-consulting.com
I'm asking about all of your Boost.TR1, including shared_ptr etc., not just the math part.
There is no duplication of code, it's described here: http://freespace.virgin.net/boost.regex/tr1/doc/html/tr1/implementation.html But basically: "When Boost.TR1 is configured to make use of your standard library's native TR1 implementation, then it doesn't do very much: it just includes the appropriate header. When Boost.TR1 is using the Boost implementation of a particular component, then it includes the appropriate Boost header(s) and imports the necessary declarations in namespace std::tr1 with using declarations. Note that only those declarations that are part of the standard are imported: the implementation is deliberately quite strict about not including any Boost-specific extensions in namespace std::tr1, in order to catch any portability errors in user code. If you really need to use Boost-specific extensions then you should include the Boost headers directly and use the declarations in namespace boost:: instead. Note that this style of implementation is not completely standards-conforming, in particular it is not possible to add user-defined template specializations of TR1 components into namespace std::tr1. There are also one or two Boost libraries that are not yet fully standards conforming, any such non-conformities are documented in the section called "TR1 By Subject". Hopefully, occurrences of non-standard behavior should be extremely rare in practice however." Clear now ? John.
"John Maddock" <john@johnmaddock.co.uk> writes:
I'm asking about all of your Boost.TR1, including shared_ptr etc., not just the math part.
There is no duplication of code, it's described here: http://freespace.virgin.net/boost.regex/tr1/doc/html/tr1/implementation.html
Clear now ?
Yes, that part is, but it was only one of my questions. The bigger one is:
So is your intention to have this stuff undergo formal review and become part of Boost?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
"John Maddock" <john@johnmaddock.co.uk> writes:
So is your intention to have this stuff undergo formal review and become part of Boost?
YES.
Cccooooolll! -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (6)
-
Beman Dawes -
Christopher Currie -
Daniel James -
David Abrahams -
Hubert Holin -
John Maddock