Hi, all! Sorry I've been out for so long. I've been reading N2691 for the past couple of days. I just noticed section 20.3, called "compile-time rational arithmetic", and I'm wondering how stable that specification is. I'm also wondering whether or not anyone else has been working on an implementation. A Google search turned up a "Summer of Code" project labeled 'ontl', but the ratio source code is not part of the download or its SVN distribution. In the meantime, my questions are: * Should I resume work on MPL.Math? Should I make a different branch, still part of MPL? Or should I fork a separate Boost project altogether? * If I resume work, should I make the implementation more standards-conformant? Cheers, Cromwell D. Enage
On Wed, Nov 12, 2008 at 5:02 PM, Cromwell Enage <sponage@yahoo.com> wrote:
Hi, all! Sorry I've been out for so long.
I've been reading N2691 for the past couple of days.
The latest WP is N2798. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf
I just noticed section 20.3, called "compile-time rational arithmetic", and I'm wondering how stable that specification is.
20.3 in N2798 is very stable, since except for the diff markup it is the same as the Committee Draft that is currently being reviewed by national bodies, and there are no outstanding issues in the LWG active issues list.
I'm also wondering whether or not anyone else has been working on an implementation.
See the <boost/ratio.hpp> header that is part of the Chrono library added to the sandbox yesterday. Checkout http://svn.boost.org/svn/boost/sandbox/chrono with Subversion.
A Google search turned up a "Summer of Code" project labeled 'ontl', but the ratio source code is not part of the download or its SVN distribution.
In the meantime, my questions are: * Should I resume work on MPL.Math? Should I make a different branch, still part of MPL? Or should I fork a separate Boost project altogether? * If I resume work, should I make the implementation more standards-conformant?
Sorry, I'm not familiar with the MPL.Math work you are referring to. Perhaps look at the Chrono <boost/ratio.hpp> header and see if it affects your thinking. --Beman
20.3 in N2798 is very stable, since except for the diff markup it is the same as the Committee Draft that is currently being reviewed by national bodies, and there are no outstanding issues in the LWG active issues list.
Why the ugly (and pointless) ratio_multiply? Shouldn't there just be a standard template for multiplication? This can then be specialized as needed for any types that can be multiplied at compile time, which facilitates code such as used in the Boost.Units library where the result type of multiplication of two units takes into account the possibility that the type of the product of two other types is different. As far as I can tell, all having a special set of arithmetic operators of ratios does is necessitate the use of another layer of indirection. Maybe I'm missing some clear benefit? I think what Cromwell is talking about is coming up with extensions to MPL to do compile-time mathematical operations, which would be neat. Steven came up with a basic compile-time linear solver for Boost.Units, but it would be extremely cool to have this functionality abstracted out into a more general library... Matthias
--- On Thu, 11/13/08, Matthias Schabel <boost@schabel-family.org> wrote:
I think what Cromwell is talking about is coming up with extensions to MPL to do compile-time mathematical operations, which would be neat.
That is the job of MPL.Math, yes. A currently undocumented implementation exists in the BoostPro Computing Vault. Hopefully I still have an account in the Sandbox SVN so I can move my stuff there.
Steven came up with a basic compile-time linear solver for Boost.Units, but it would be extremely cool to have this functionality abstracted out into a more general library...
Neat! I'll need to study this linear solver. It'll give me something to chew on while I'm whipping up the documentation. We should continue this discussion in a separate thread. I'll start a new one in the next few minutes. Cheers, Cromwell D. Enage
--- On Thu, 11/13/08, Beman Dawes <bdawes@acm.org> wrote:
The latest WP is N2798. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf
Got it.
I just noticed section 20.3, called "compile-time rational arithmetic", and I'm wondering how stable that specification is.
20.3 in N2798 is very stable, since except for the diff markup it is the same as the Committee Draft that is currently being reviewed by national bodies, and there are no outstanding issues in the LWG active issues list.
Hmmm. I see that the ratio class template is neither required nor implemented as a nullary metafunction, as std::integral_constant is. (There is no "typedef ratio<N,D> type;" statement.) Is there any particular reason? I ask because this may cause problems if I try to have the ratio interact with other MPL metafunctions.
I'm also wondering whether or not anyone else has been working on an implementation.
See the <boost/ratio.hpp> header that is part of the Chrono library added to the sandbox yesterday.
Checkout http://svn.boost.org/svn/boost/sandbox/chrono with Subversion.
Got it.
In the meantime, my questions are: * Should I resume work on MPL.Math? Should I make a different branch, still part of MPL? Or should I fork a separate Boost project altogether? * If I resume work, should I make the implementation more standards-conformant?
Sorry, I'm not familiar with the MPL.Math work you are referring to.
My bad, I should have clarified. It's a generalized compile-time math library, available from the BoostPro Computing Vault, inside the Template Metaprogramming folder. It needs documentation, though.
Perhaps look at the Chrono <boost/ratio.hpp> header and see if it affects your thinking.
Okay, the last two options are out. :) I'll see what I can do about getting MPL.Math to play nice with boost::ratio, but as I said before, that missing type definition may cause problems. Cheers, Cromwell D. Enage
On Thu, Nov 13, 2008 at 3:18 PM, Cromwell Enage <sponage@yahoo.com> wrote:
--- On Thu, 11/13/08, Beman Dawes <bdawes@acm.org> wrote:
The latest WP is N2798. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf
Got it.
I just noticed section 20.3, called "compile-time rational arithmetic", and I'm wondering how stable that specification is.
20.3 in N2798 is very stable, since except for the diff markup it is the same as the Committee Draft that is currently being reviewed by national bodies, and there are no outstanding issues in the LWG active issues list.
Hmmm. I see that the ratio class template is neither required nor implemented as a nullary metafunction, as std::integral_constant is. (There is no "typedef ratio<N,D> type;" statement.) Is there any particular reason? I ask because this may cause problems if I try to have the ratio interact with other MPL metafunctions.
Howard would have to comment on that; I've pinged him to make him aware of this thread. The Boost implementation can add extensions, and we can submit a comment on the CD. If it is as simple as a typedef, it stands a good chance of being accepted. If you write it up, with a proposed resolution, I'll submit it. --Beman
On Nov 13, 2008, at 3:55 PM, Beman Dawes wrote:
On Thu, Nov 13, 2008 at 3:18 PM, Cromwell Enage <sponage@yahoo.com> wrote:
--- On Thu, 11/13/08, Beman Dawes <bdawes@acm.org> wrote:
The latest WP is N2798. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf
Got it.
I just noticed section 20.3, called "compile-time rational arithmetic", and I'm wondering how stable that specification is.
20.3 in N2798 is very stable, since except for the diff markup it is the same as the Committee Draft that is currently being reviewed by national bodies, and there are no outstanding issues in the LWG active issues list.
Hmmm. I see that the ratio class template is neither required nor implemented as a nullary metafunction, as std::integral_constant is. (There is no "typedef ratio<N,D> type;" statement.) Is there any particular reason? I ask because this may cause problems if I try to have the ratio interact with other MPL metafunctions.
Howard would have to comment on that; I've pinged him to make him aware of this thread.
The Boost implementation can add extensions, and we can submit a comment on the CD. If it is as simple as a typedef, it stands a good chance of being accepted. If you write it up, with a proposed resolution, I'll submit it.
My only comment so far is that these look like good suggestions. A defect report should show a motivating code sample for best chances. -Howard
--- On Thu, 11/13/08, Howard Hinnant wrote:
On Nov 13, 2008, at 3:55 PM, Beman Dawes wrote:
Howard would have to comment on that; I've pinged him to make him aware of this thread.
The Boost implementation can add extensions, and we can submit a comment on the CD. If it is as simple as a typedef, it stands a good chance of being accepted. If you write it up, with a proposed resolution, I'll submit it.
My only comment so far is that these look like good suggestions. A defect report should show a motivating code sample for best chances.
-Howard
Sections: 20.4.1 [Class template ratio], 20.4.2 [Arithmetic on ratio types] Discussion: Let's say that client code needs to use a unary metafunction named absolute_ratio in the following type definitions, to be evaluated lazily. // Usage. typedef std::ratio<-1,2> negative_one_half; typedef absolute_ratio<negative_one_half> one_half; typedef absolute_ratio< std::ratio_multiplies< one_half , negative_one_half > > one_fourth; // End usage. Assuming that a (partial) specialization of boost::mpl::negate exists for std::ratio, a programmer should be able to define absolute_ratio this way. template <typename R> struct absolute_ratio : boost::mpl::eval_if< R::type::num < 0 , boost::mpl::negate<R> , R > { }; The expression R::type::num is necessary because the std::ratio_multiplies metafunction is not required to inherit from std::ratio. However, the expression will not compile when it sees that std::ratio is not a metafunction. Proposed resolution: Add the nullary metafunction type definition to the ratio class template. namespace std { template <intmax_t N, intmax_t D = 1> class ratio { public: typedef ratio<N,D> type; static const intmax_t num; static const intmax_t den; }; } We should also require that each of the arithmetic metafunctions inherit from std::ratio if we want to allow the following usage (note the change from R::type::num to R::num). template <typename R> struct absolute_ratio : boost::mpl::eval_if< R::num < 0 , boost::mpl::negate<R> , R > { }; Cheers, Cromwell D. Enage
--- On Fri, 11/14/08, Cromwell Enage wrote:
Sections: 20.4.1 [Class template ratio], 20.4.2 [Arithmetic on ratio types]
Also 20.4.3 [Comparison of ratio types] [snip rest of report]
We should also require that each of the arithmetic metafunctions inherit from std::ratio if we want to allow the following usage (note the change from R::type::num to R::num).
template <typename R> struct absolute_ratio : boost::mpl::eval_if< R::num < 0 , boost::mpl::negate<R> , R > { };
For the sake of completeness, if the arithmetic metafunctions are to inherit from std::ratio, so should the comparison metafunctions. Cheers, Cromwell D. Enage
--- On Fri, 11/14/08, Cromwell Enage wrote:
For the sake of completeness, if the arithmetic metafunctions are to inherit from std::ratio, so should the comparison metafunctions.
Belay that last. The comparison metafunctions return integral_constants, so inheritance isn't necessary. I should go to sleep now. Cheers, Cromwell D. Enage
participants (4)
-
Beman Dawes -
Cromwell Enage -
Howard Hinnant -
Matthias Schabel