[multiprecision] OK to merge to Trunk?
Folks, Unless there are any objections, I'd like to merge the multiprecision library to SVN Trunk pretty soon. Here are the main changes since the review, which have mostly concentrated on the interface changes: * Non-expression template operators further optimized with rvalue reference support. * Many functions made `constexp`. * Differentiate between explicit and implicit conversions in the number constructor. * Removed "mp_" prefix from types. * Allowed mixed precision arithmetic. * Changed ExpressionTemplates parameter to class `number` to use enumerated values rather than true/false. * Changed ExpressionTemplate parameter default value to use a traits class so that the default value depends on the backend used. * Added support for fused-multiply-add/subtract with GMP support. * Tweaked expression template unpacking to use fewer temporaries when the LHS also appears in the RHS. * Refactored `cpp_int_backend` based on review comments with new template parameter structure. * Added additional template parameter to `mpfr_float_backend` to allow stack-based allocation. * Added section on mixed precision arithmetic, and added support for operations yielding a higher precision result than either of the arguments. * Added overloads of integer-specific functions for built in integer types. Things requested in review, but not yet done: * We can reuse temporaries in multiple subtrees (temporary caching). Low priority for now. * cpp_dec_float should round to nearest. Chris currently has no time for this, and it's really hard to do *right*. * A 2's complement fixed precision int that uses exactly N bits and no more. Refactoring of cpp_int should make this easier to add as an option in future. There are also documentation updates pending (mostly relating to the new improved performance results), and more tests I want to add/run, bit basically I need to get things widely tested to move forward now. Release schedule wise, I think it'll be hard to get things ready for the next release, but the release after that really should be on the cards. So basically now is the last chance for folks to complain before the interface gets ossified ;-) As ever current code is in the sandbox under /big_number/ and docs can be viewed online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/ht... Regards, John.
On 11/13/2012 9:53 AM, John Maddock wrote:
Folks,
Unless there are any objections, I'd like to merge the multiprecision library to SVN Trunk pretty soon.
Here are the main changes since the review, which have mostly concentrated on the interface changes: <snip>
I haven't been following the details closely, but as long as the library didn't need a secondary mini-review, I don't think anybody has cause to object to an accepted library being committed to trunk. Fire when ready. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, Nov 13, 2012 at 10:16 AM, Eric Niebler <eric@boostpro.com> wrote:
On 11/13/2012 9:53 AM, John Maddock wrote:
Folks,
Unless there are any objections, I'd like to merge the multiprecision library to SVN Trunk pretty soon.
Here are the main changes since the review, which have mostly concentrated on the interface changes: <snip>
I haven't been following the details closely, but as long as the library didn't need a secondary mini-review, I don't think anybody has cause to object to an accepted library being committed to trunk. Fire when ready.
No mini-review was required upon acceptance, so I agree with Eric. I'll try to skim through the docs, John; in particular, I'm curious how you addressed mixed-type operations. - Jeff
On Tuesday, November 13, 2012 05:53:26 PM John Maddock wrote:
Folks,
Unless there are any objections, I'd like to merge the multiprecision library to SVN Trunk pretty soon.
Where are you planning to put the library? I think it clearly addresses numeric problems so I would say it should go into boost/numeric/multiprecision? Mario
Here are the main changes since the review, which have mostly concentrated on the interface changes:
* Non-expression template operators further optimized with rvalue reference support. * Many functions made `constexp`. * Differentiate between explicit and implicit conversions in the number constructor. * Removed "mp_" prefix from types. * Allowed mixed precision arithmetic. * Changed ExpressionTemplates parameter to class `number` to use enumerated values rather than true/false. * Changed ExpressionTemplate parameter default value to use a traits class so that the default value depends on the backend used. * Added support for fused-multiply-add/subtract with GMP support. * Tweaked expression template unpacking to use fewer temporaries when the LHS also appears in the RHS. * Refactored `cpp_int_backend` based on review comments with new template parameter structure. * Added additional template parameter to `mpfr_float_backend` to allow stack-based allocation. * Added section on mixed precision arithmetic, and added support for operations yielding a higher precision result than either of the arguments. * Added overloads of integer-specific functions for built in integer types.
Things requested in review, but not yet done:
* We can reuse temporaries in multiple subtrees (temporary caching). Low priority for now. * cpp_dec_float should round to nearest. Chris currently has no time for this, and it's really hard to do *right*. * A 2's complement fixed precision int that uses exactly N bits and no more. Refactoring of cpp_int should make this easier to add as an option in future.
There are also documentation updates pending (mostly relating to the new improved performance results), and more tests I want to add/run, bit basically I need to get things widely tested to move forward now.
Release schedule wise, I think it'll be hard to get things ready for the next release, but the release after that really should be on the cards.
So basically now is the last chance for folks to complain before the interface gets ossified ;-)
As ever current code is in the sandbox under /big_number/ and docs can be viewed online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/ht ml/index.html
Regards, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Unless there are any objections, I'd like to merge the multiprecision library to SVN Trunk pretty soon.
Where are you planning to put the library?
boost/multiprecision libs/multiprecision
I think it clearly addresses numeric problems so I would say it should go into boost/numeric/multiprecision?
That would require a lot of refactoring (again) to change all the paths, so I'm not that keen unless there are strong views on this. John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Wednesday, November 14, 2012 4:37 PM To: boost@lists.boost.org Subject: Re: [boost] [multiprecision] OK to merge to Trunk?
Unless there are any objections, I'd like to merge the multiprecision library to SVN Trunk pretty soon.
Where are you planning to put the library?
boost/multiprecision libs/multiprecision
I think it clearly addresses numeric problems so I would say it should go into boost/numeric/multiprecision?
That would require a lot of refactoring (again) to change all the paths, so I'm not that keen unless there are strong views on this.
A change wasn't agreed at review. I don't think there is any compelling reason to change location. But there is a compelling reason to get the code out ;-) My 0.02 euros. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Nov 14, 2012, at 9:11 AM, Mario Mulansky <mario.mulansky@gmx.net> wrote:
On Tuesday, November 13, 2012 05:53:26 PM John Maddock wrote:
Folks,
Unless there are any objections, I'd like to merge the multiprecision library to SVN Trunk pretty soon.
Where are you planning to put the library? I think it clearly addresses numeric problems so I would say it should go into boost/numeric/
It is a numeric library, but most Boost libraries stand alone. There are other numeric libraries not already in that directory(refer to the Math and Numerics category on the Libraries page), so precedent is against you.
Here are the main changes since the review, which have mostly concentrated on the interface changes:
[snip everything else] Please don't overquote. ___ Rob
Where are you planning to put the library? I think it clearly addresses numeric problems so I would say it should go into boost/numeric/
It is a numeric library, but most Boost libraries stand alone. There are other numeric libraries not already in that directory(refer to the Math and Numerics category on the Libraries page), so precedent is against you.
Just a couple of more random thoughts: 1) I think sub-libraries work best when they're related mini-libraries: utility is a good example. 2) Personally I find extra long include paths a pain, especially if boost/mylib is already subdivided. So I would prefer larger standalone lib's to go directly in boost/mylib and smaller mini-libs either under the banner of an existing lib, or under a subcategory such as boost/utility. Of course uBlas breaks that by being a large lib that could/should stand alone, but is under the /boost/numeric sub-category. So <shrug> I guess! John.
On Thursday, November 15, 2012 11:56:27 am John Maddock wrote:
Where are you planning to put the library? I think it clearly addresses numeric problems so I would say it should go into boost/numeric/
It is a numeric library, but most Boost libraries stand alone. There are other numeric libraries not already in that directory(refer to the Math and Numerics category on the Libraries page), so precedent is against you.
Just a couple of more random thoughts:
1) I think sub-libraries work best when they're related mini-libraries: utility is a good example. 2) Personally I find extra long include paths a pain, especially if boost/mylib is already subdivided.
So I would prefer larger standalone lib's to go directly in boost/mylib and smaller mini-libs either under the banner of an existing lib, or under a subcategory such as boost/utility.
Ok following this argument we should release odeint also directly in boost/odeint and not (as is now) boost/numeric/odeint. It doesnt matter too much to me, although some consistency would be nice, I think?
Of course uBlas breaks that by being a large lib that could/should stand alone, but is under the /boost/numeric sub-category.
Yes I think ublas made us using boost/numeric/odeint. Mario
On Thu, Nov 15, 2012 at 3:16 PM, Mario Mulansky <mario.mulansky@gmx.net> wrote:
1) I think sub-libraries work best when they're related mini-libraries: utility is a good example. 2) Personally I find extra long include paths a pain, especially if boost/mylib is already subdivided.
So I would prefer larger standalone lib's to go directly in boost/mylib and smaller mini-libs either under the banner of an existing lib, or under a subcategory such as boost/utility.
Ok following this argument we should release odeint also directly in boost/odeint and not (as is now) boost/numeric/odeint. It doesnt matter too much to me, although some consistency would be nice, I think?
Simplicity is nice too. What's gained from boost/numeric/odeint? boost/odeint is shorter and simpler. -- Olaf
On Thursday, November 15, 2012 03:20:19 pm Olaf van der Spek wrote:
On Thu, Nov 15, 2012 at 3:16 PM, Mario Mulansky <mario.mulansky@gmx.net> wrote:
1) I think sub-libraries work best when they're related mini-libraries: utility is a good example. 2) Personally I find extra long include paths a pain, especially if boost/mylib is already subdivided.
So I would prefer larger standalone lib's to go directly in boost/mylib and smaller mini-libs either under the banner of an existing lib, or under a subcategory such as boost/utility.
Ok following this argument we should release odeint also directly in boost/odeint and not (as is now) boost/numeric/odeint. It doesnt matter too much to me, although some consistency would be nice, I think?
Simplicity is nice too. What's gained from boost/numeric/odeint? boost/odeint is shorter and simpler.
I agree. Our initial thought was that libraries with similar purposes should be put together, based on the observation that ublas is in boost/numeric. It appears now that this is indeed an exception and the general approach is rather to put libraries directly in the top directory. Maybe we will change that for the release of odeint, this would break existing code but in a very easily fixable way, I suppose.
participants (7)
-
Eric Niebler -
Jeffrey Lee Hellrung, Jr. -
John Maddock -
Mario Mulansky -
Olaf van der Spek -
Paul A. Bristow -
Rob Stewart