--- Andy Little wrote:

Hi Cromwell,

Hey, Andy.

...

Registration of each metafunction occurs at the end of the header file in which the metafunction is declared, as per the "don't pay for what you don't use" policy.

Thats great and suits me, but I was wondering whether it might be better to really make this optional, either by looking for a macro BOOST_TYPEOF_PLEASE_REGISTER_MY_INCLUDED_TYPES (or whatever name) or by putting the typeof stuff in a separate include file.

Point is that on some compilers where there is no inbuilt typeof, then Boost.Typeof causes a big slow down in compile-performance. AFAIK this happens in VC8,

The macro route is probably better. though I

haven't tried this compiler myself so I'm only guessing.

You can #define BOOST_TYPEOF_COMPLIANT to force emulation mode, so you don't have to guess.

[..] I would question the name 'inverse' to replace 'reciprocal', because it needs a function to take the inverse of, whereas reciprocal is unequivocal:

FWIW I have attached some other related functions

Okay. It's probably better than 'multiplicative_inverse' as well. OTOH, we'd also break a long-standing tradition of using ambiguous names for certain mathematical functions. :) that might be

useful.

boost::mpl::math::is_positive<T>, to go with boost::mpl::math::is_negative<T> boost::mpl::math::is_rational_constant<T>, to go with boost::mpl::is_integral_constant<T> boost::mpl:rational_int<> boost::mpl:rational_long<>

Finally regarding the boost::mpl::math::power function, I was told once upon a time that the traditional way to do

is_positive<> is okay, as long as is_strictly_positive<> (which zero<> is not) goes with it. I'd like to know how your Physical Quantities library uses the other metafunctions, so I can see if there are more generic ways to facilitate such usage (e.g. for seamless interaction with double_c). this in mpl

would be to call it just 'pow' after the runtime version. FWIW

No one told me. I just thought using full names was more readable (and educational, too; I didn't know "asin" stood for "arcus sine" until Peder Holt used that name). Cromwell D. Enage __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/

"Cromwell Enage" wrote

I've added <boost/mpl/math/rational_/rational.hpp>, which contains the minimal amount you need to use only boost::mpl::integral_c et. al. and boost::mpl::math::rational. The <boost/mpl/math/rational.hpp> header is reserved for those who need the kitchen sink.

That seems like an odd way to do things. I would expect the main header for rational to just contain the interface for rational itself. Isnt it normally beneficial to try to limit per header dependencies? What is the rationale behind adding double and big_integral in there too? [...]

...

Anyway changing the gcd algorithm to a recursive one wrapping boost::math::static_gcd (attached) in "boost/math/commn_factor.hpp" cures the above problem of compiler running out of keys and similar issues for me.

I've reimplemented the integral_c_tag specialization of boost::mpl::math::gcd so that it's wrapped around an MPL-ized version of boost::math::static_gcd. Performance should be close to what you're looking for.

That looks a lot better. (Once I've waded through the macros). I'm not sure if you use rational with mpl integral constants in your double implementation, but if you do that mod should help compile times a there too.

...

As previously mentioned I also reckon that it would be best to make typeof registration separate.

I thought you said "optional". Anyway, typeof registration is now disabled by default; you must now define the macro BOOST_MPL_CFG_REGISTER_WITH_TYPEOF to enable it.

For each type, typeof registration is quite a heavyweight process, so I want to only register those types that I Really need to. Currently this is not the case so I get for example mpl::math::zero, mpl::math::denominator, etc etc, etc, etc and the kitchen sink registered for me though I dont need registration for the vast majority of these types, also bearing in mind that space in the Typeof vector is limited, so I dont think registering everything is a practical way to do it. It must be possible for me the user to be able to register each type separately (only if it becomes necessary.) Of coures the problem comes then because mpl works in terms of concepts rather than type-names, so I might get a int_, a integral_c, or a long_. , a rational or a simplified_rational. I dont really know a clean solution to the problem of what to register if I use mpl, (maybe 'per concept registration would be OK) but I dont think registering everything at one go is a good solution. Throwing the baby out with the bathwater. Having come up against compile times/debris problems in mpl as applied specifically to the pqs library ( mostly due to mpl::vector), In pqs_3_0_1, as an alternative style to the mpl way, I am currently thinking in terms of how to use the minimum variety of types, parameters and functions etc. This line of thinking means for instance that I would have a (custom for the pqs library) rational<1,2> , note not rational_c<int,1,2> or rational<int_<1>,long_<2> >. and also no conversion via the tag system between rational and int_ for instance. I can use boost::is_same rather than mpl::equal_to for comparison, which represents another reduction in complexity as well as a reduction in potential number of types created automatically. Similarly result of an operation on two rationals will be a rational, so that I can use boost::is_same for comparison of types comprised of rationals, have a definite 'type' interface and a known documentable type as result of operations and reduce the number of types requiring Typeof registration. IOW I have decided to abandon use of mpl entirely in the next version of pqs library and see if that helps specifically with the compiler out of keys issue (which I am still getting currently when using headers with a lot of physical_quantity types) and the compile time issue. These are greater problems in pqs than some other uses of mpl because the idea is to be able to use these types to 'seamlessly' replace bult-in types such as double and int. That means absolutely minimal effect on compilation time and of course minimal use of compiler resources too. regards Andy Little

"Cromwell Enage" wrote

In the meantime, the main problem we've run into here is one of granularity. With integral_c and friends, you can just

#include <boost/mpl/integral_c.hpp> #include <boost/mpl/plus.hpp> ... typedef plus<integral_c<long,1>,integral_c<short,2>

...

three;

Not so with these other numeric constants. You can't

#include <boost/mpl/math/rational.hpp> #include <boost/mpl/plus.hpp>

without

#include <boost/mpl/math/rational_/plus.hpp>

The convention of headers used with integral_constants is already invalid because of the use of the mpl::math namespace, therefore I dont see using a different design as a problem.

One of the two files must include this one. It's not going to be plus, so it has to be rational. Furthermore, for the moment, I can't be sure which operations will or will not be used...so I have to #include them all.

Once the convention of each boost::math's types files having its own directory is set I would be quite happy with: #include <boost/mpl/math/rational.hpp> #include <boost/mpl/math/rational_/plus.hpp> BTW What is the purpose of '_' suffix. on the directory name?

To achieve the finer level of granularity you seek, then, I need a safe way to #include certain files if and only if other files are #included, e.g.

#include <boost/mpl/math/rational.hpp> #include <boost/mpl/plus.hpp>

implies

#include <boost/mpl/math/rational_/plus.hpp>

I'll look into it when I get the chance.

As stated above, just tell the user to get used to the convention of #include <boost/mpl/math/rational_/plus.hpp>

...

I'm not sure if you use rational with mpl integral constants in your double implementation, but if you do that mod should help compile times a there too.

It's not *my* double implementation, it's Peder Holt's, and the metadata are already stored int BOOST_STATIC_CONSTANTs.

Ok... Apologies to Peder Holt for misattribuing it. [..]

If you can ensure that the *only* syntax you use for any operation (numeric or otherwise) is

typedef typename some_op<...>::type some_constant;

and not

typedef some_op<...> some_constant;

then maybe #defining a macro BOOST_MPL_CFG_TYPEOF_NO_REGISTER_FUNCTIONS will suffice.

In pqs the typeof interface is comprised of a limited number of types and certainly not mpl operations . I would expect to have the granularity primarily at the level of each type in the librarys interface. That means a separate register_X_with_typeof.hpp header for each type. The messy problem of exactly what type to register in mpl I now think needs to be left to the user, because the mpl library author cant know how the user will use the library. BTW while on the issue of result type of operations The member ::type of rational being a simplified_rational sticks out as being really odd. and with no precedent in the integral_constants. As an example of how odd it strikes me ... If this logic was applied to intgral_constants then the result type of mpl::plus<int_<X>,int_<Y> > would be added_int<Z>. OTOH I would expect the format to be either something like: template <typename N, typename D> struct rational{ typedef N numerator; // available for reflection, but no operations on these here typedef D denominator; //... typedef rational type; // rational is a unary_metafunction }; // then use (tediously) template <typename Rational> struct simplify_rational{ typedef typename apply_simplification_impl<Rational>::type type; // type is a rational<X,Y> where eg '5' /'10' --> '1'./ '2 'etc }; IOW simplification should be an interface operation to simplify a rational rather than a distinct user type resulting from the operation. Or alternatively and more practical IMO because simplification is be required before and after any operation anyway (to prevent overflow) it would relieve the tedium to just do the simplification in place. template <typename N, typename D> struct rational{ impl: typedef detail::simplify_rational_impl<N,D> > impl; public: typedef typename impl::numerator numerator ; typedef typename impl::denominator denominator ; typedef rational<numerator, denominator> type ; // simplification in place }; IOW I dont see any advantage to making the member ::type of a rational other than a rational.

...

[snip future plans w/o MPL]

Try to eliminate the use of mpl::vector first, since it's the biggest slowdown for you. See if you can replace it with Boost.Preprocessor constructs. This method worked well for me when I gave big_integral an overhaul.

OK thanks for the tip. regards Andy Little

"Andy Little" <andy@servocomm.freeserve.co.uk> wrote

For each type, typeof registration is quite a heavyweight process,

so I want to only register those types that I Really need to. Currently this is not

so I get for example mpl::math::zero, mpl::math::denominator, etc etc, etc, etc and the kitchen sink registered for me though I dont need registration for

Why is it heavyweight? Registering a type is just creating a couple of template specializations -- that's it. the case the

vast majority of these types, also bearing in mind that space in the Typeof vector is limited,

What do you mean by the "space in the typeof vector"? How is it related to the number of registered types?

so I dont think registering everything is a practical way to do it.

What do you mean by everything? I would recommend registering types and templates that can be present in the types used by your users.

It must be possible for me the user to be able to register each type separately (only if it becomes necessary.) Of coures the problem comes then because mpl works in terms of concepts rather than type-names, so I might get a int_, a integral_c, or a long_. , a rational or a simplified_rational. I dont really know a clean solution to the problem of what to register if I use mpl, (maybe 'per concept registration would be OK) but I dont think registering everything at one go is a good solution.

I would register your own types/templates leaving mpl types/templates to either mpl authors or users. Then again, you could wear an mpl hat and register its types, but I don't think this should become a part of your library. Regards, Arkadiy

"Andy Little" <andy@servocomm.freeserve.co.uk> wrote

I always understood typeof useage to be quite heavyweight, so I was quite worried about the large number of types automatically registered in last version of boost::mpl::math library.

Well, when the types are registered, the specializations are created by preprocessor, and so, theoretically, it may consume some noticable time. However, I don't believe it should be a problem... When a type is actually being deduced, there are two parts that consume compile time: 1) The type needs to be encoded and decoded. The time necessary for this operation is linearly proportional to the complexity of the type (the size of encoding vector). The factor is about 10 template instantiations per node (or something like this -- I estimated this in the past, and things changed since then). 2) The expression needs to be passed to the template function so that the compiler deduce the type. This is done BOOST_TYPEOF_LIMIT_SIZE times per BOOST_TYPEOF invocation. Of these two, the first one is most significant. On my 1.5 GHz PC, with BOOST_TYPEOF_LIMIT_SIZE=50, vc71 can compile 10 BOOST_TYPEOF's of fundamental types in under one second. However, it may take about 2 sec to compile BOOST_TYPEOF of one more complicated, e.g., Spirit expression of about 45 nodes. The inclusion of typeof.hpp takes 2 to 3 seconds. The time is spent registering fundamental types, pointers, functions, etc.

Bearing in mind that I have been getting a compiler out of keys error message recently in even small tests, which as you will understand basically renders my library a useless resource hog, I am now trying to be extremely careful to add as little unnecessary clutter in headers as possible. That includes not wishing to register unneccesary types with Typeof if at all possible.

You may want to consider the strategy we used with the STL types -- for each STL header we defined a corresponding typeof header which included the STL header and registered the types. Then, depending on whether the typeof functionality is needed, the user can do either: #include <vector> or #include <boost/typeof/std/vector.hpp> Regards, Arkadiy

"Victor A. Wagner Jr." <vawjr@rudbek.com> wrote

Arkadiy Vertleyb wrote:

...

You may want to consider the strategy we used with the STL types -- for each STL header we defined a corresponding typeof header which included the STL header and registered the types.

Then, depending on whether the typeof functionality is needed, the user can do either:

#include <vector>

or

#include <boost/typeof/std/vector.hpp>

if its name were vector instead of vector.hpp I could switch between them simply by telling my compiler to look in boost/typeof/std before the standard locatons for includes.

I am afraid, since the std header is #included by the typeof header, this would not achieve the desired effect, since the line: #include <vector> in the typeof header would reffer, again, to the typeof header.

btw, shouldn't that be #include "boost/typeof/std/vector.hpp" instead?

Should it? Isn't this equivalent in this particular context? Regards, Arkadiy

--- Arkadiy Vertleyb wrote:

"Cromwell Enage" wrote

...

* The BOOST_MPL_AUX_TYPEOF_REGISTER_TYPE_C macro, defined in <boost/mpl/aux_/typeof/register_type_c.hpp>

Hmmm, I am kind of surprised it is working...

In retrospect, I should be defining BOOST_TYPEOF_COMPLIANT during testing. I'm now getting errors too; GCC reports BOOST_PP_SEQ_ENUM_III lacking an input. *sigh* Back to the drawing board... Cromwell D. Enage __________________________________________ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

I think you may want to use (BOOST_PP_)REPEAT in conjunction with SEQ_ELEM and SEQ_SIZE instead of SEQ_FOR_EACH. Since REPEAT is automatically re-entrant, it may be less

use it, and you don't depend on what typeof has inside (OTOH, I am thinking of adopting the same strategy, so that

--- Arkadiy Vertleyb wrote: trouble to people don't

have re-entrancy problems when using typeof).

Also note another issue that I mentioned --

ID (I gave the example in my previous post). I will add the needed macro soon, but if you want to proceed before

copy it from the example somewhere in your code, and

Understood. providing explicit this, just then you'll

just remove it once it's in typeof.

I'll wait for the macro. Cromwell D. Enage __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/

I think you may want to use (BOOST_PP_)REPEAT in conjunction with SEQ_ELEM and SEQ_SIZE instead of SEQ_FOR_EACH. Since REPEAT is automatically re-entrant, it may be less

--- Arkadiy Vertleyb wrote: trouble to

use it, and you don't depend on what typeof has inside.

I'm also studying file iteration so I can see if that helps me out.

(OTOH, I am thinking of adopting the same strategy, so that people don't have re-entrancy problems when using typeof.)

Please do adopt this strategy. Currently this kind of code doesn't work: BOOST_TYPEOF_REGISTER_TYPE( boost::mpl::math::string_c_to_double , BOOST_MPL_PP_ARG_SEQ(unsigned char, 40) ) BOOST_MPL_PP_ARG_SEQ uses BOOST_PP_REPEAT to create a sequence of N elements containing the specified primitive integral type.

Added in CVS:

BOOST_TYPEOF_REGISTER_TYPE_EXPLICIT_ID(Name, Id) BOOST_TYPEOF_REGISTER_TEMPLATE_EXPLICIT_ID(Name, Params, Id)

I'll make use of them when I get the chance. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com