Scattered throughout the metamath library are template specializations of numeric metafunction classes like the following: template <> struct times_impl< integral_c_tag , metamath::double_c_tag
{ ... } The purpose of mpl::numeric_cast<> (or BOOST_MPL_AUX_NUMERIC_CAST) is to render such specializations unnecessary. I understand that if template instantiation overhead is a problem then the current situation is okay, but if we start implementing more numeric metatypes such as metamath::float_ and/or metamath::long_double_, then the net increase in code size will become an issue. Also included in the last update of my math sublibrary are files from the metamath library that I modified to make use of BOOST_MPL_AUX_NUMERIC_CAST: * In <boost/metamath/double/double.hpp> I modified double_c_tag so that it inherits from boost::mpl::int_<8> (an arbitrary constant higher than zero). * In <boost/metamath/double/integral_to_double.hpp> I added a template specialization of BOOST_MPL_AUX_NUMERIC_CAST that uses integral_to_double<>. * In the other files I deleted the redundant specializations. Let me know what you think. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 9/20/05, Cromwell Enage <sponage@yahoo.com> wrote:
Scattered throughout the metamath library are template specializations of numeric metafunction classes like the following:
template <> struct times_impl< integral_c_tag , metamath::double_c_tag
{ ... }
The purpose of mpl::numeric_cast<> (or BOOST_MPL_AUX_NUMERIC_CAST) is to render such
I didn't know about that. Thanks.
specializations unnecessary. I understand that if template instantiation overhead is a problem then the current situation is okay, but if we start implementing more numeric metatypes such as metamath::float_ and/or metamath::long_double_, then the net increase in code size will become an issue.
Also included in the last update of my math sublibrary are files from the metamath library that I modified to make use of BOOST_MPL_AUX_NUMERIC_CAST: * In <boost/metamath/double/double.hpp> I modified double_c_tag so that it inherits from boost::mpl::int_<8> (an arbitrary constant higher than zero). * In <boost/metamath/double/integral_to_double.hpp> I added a template specialization of BOOST_MPL_AUX_NUMERIC_CAST that uses integral_to_double<>. * In the other files I deleted the redundant specializations.
Let me know what you think.
Definitely an improvement. Perhaps it would be a good idea to move the entire metamath/double implementation to the mpl/math directory? Regards, Peder
Cromwell D. Enage
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- Peder Holt wrote:
Definitely an improvement.
Perhaps it would be a good idea to move the entire metamath/double implementation to the mpl/math directory?
Indeed. The question now is where main development should continue: the Sandbox CVS or the Boost Vault <http://boost-consulting.com/vault/>. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
--- Peder Holt wrote:
Definitely an improvement.
Perhaps it would be a good idea to move the entire metamath/double implementation to the mpl/math directory?
Agreed. The question now is where main development should continue: the Sandbox CVS or the Boost Vault <http://boost-consulting.com/vault/>. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 9/21/05, Cromwell Enage <sponage@yahoo.com> wrote:
--- Peder Holt wrote:
Definitely an improvement.
Perhaps it would be a good idea to move the entire metamath/double implementation to the mpl/math directory?
Agreed. The question now is where main development should continue: the Sandbox CVS or the Boost Vault <http://boost-consulting.com/vault/>.
In general, I prefer CVS when developing. Having frequent snapshots on the vault is a good thing, though. Do we have a good name for the project? metamath or mpl_math or something new? Regards, Peder
Cromwell D. Enage
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 9/21/05, Cromwell Enage <sponage@yahoo.com> wrote:
--- Peder Holt wrote:
Definitely an improvement.
Perhaps it would be a good idea to move the entire metamath/double implementation to the mpl/math directory?
Agreed. The question now is where main development should continue: the Sandbox CVS or the Boost Vault <http://boost-consulting.com/vault/>.
Btw. My initial motivation for developing the compile time double, was to be able to implement an expression library on top of it, supporting differentiation and simple equation solving. typedef times<sine<_1>,_1> fn; typedef differentiate<fn,_1> dfn; typedef apply<dfn,pi> number; I haven't been able to implement this without adding a function_tag typedef to all metafunctions. plus -> plus_tag sine -> sine_tag In addition, it would be great to have fusion-support inplace, allowing: BOOST_AUTO(fn,sin(_1)*_1); BOOST_AUTO(dfn,diff(fn,_1)); and in turn: double result=dfn(pi()); or typedef BOOST_TYPEOF(dfn) tdfn; typedef apply<tdfn,pi> number; The fundamental fusion support is something that could be part of the mpl_math library. Regards, Peder
Cromwell D. Enage
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- Peder Holt wrote:
Btw.
My initial motivation for developing the compile time double, was to be able to implement an expression library on top of it, supporting differentiation and simple equation solving.
typedef times<sine<_1>,_1> fn; typedef differentiate<fn,_1> dfn; typedef apply<dfn,pi> number;
I haven't been able to implement this without adding a function_tag typedef to all metafunctions. plus -> plus_tag sine -> sine_tag
Interesting. I tried to follow the guidelines for extending MPL lambda support to my trig functions but have yet to test them that way. I'll post the results of my endeavors in a different thread.
In addition, it would be great to have fusion-support inplace, allowing: BOOST_AUTO(fn,sin(_1)*_1); BOOST_AUTO(dfn,diff(fn,_1)); and in turn: double result=dfn(pi()); or typedef BOOST_TYPEOF(dfn) tdfn; typedef apply<tdfn,pi> number;
The fundamental fusion support is something that could be part of the mpl_math library.
Intriguing, but one thing at a time. Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
participants (2)
-
Cromwell Enage -
Peder Holt