[boost] [mpl] Math sublibrary: new version.

From: Cromwell Enage (sponage_at_[hidden])
Date: 2005-05-06 10:53:57

--- Dan Perry wrote:
> I need some sort of compile time float type that
> supports multiplication and division.  I found your
> comments on the gmane.comp.lib.boost.devel newsgroup
> via google but I can't access your mpl_math.zip
> file.  Could you send me your source?  Thanks.

The file has a new home.  Go to
<http://boost-sandbox.sourceforge.net/vault/>, look
under the subdirectory "expaler", and download from
there.

Major issues:
1.  The big_integral<> numeric "metatype" is still a
compiler resource hog.  If I could use list<> instead
of vector<>, I may be able to make it more efficient. 
To do so, I would need to know how to iterate through
two lists "concurrently" instead of one list at a
time.  Aleksey Gurtovoy, any pointers?
2.  The most recently added numeric metafunctions,
which are square_root<>, exponent<>, sine<>, cosine<>,
arctangent<>, hypersine<>, and hypercosine<>, are
either insufficiently tested or not tested at all.
3.  The numeric_caster_rt facility probably needs a
more appropriate name.  It is untested with wrt
boost::rational as the ResultType.  It is also
non-functional wrt complex_number<>, at least until I
figure out how to use std::complex.
4.  Documentation should be available in the next
version.  For now, the source code, examples, and test
programs will have to suffice.

Andy Little wrote:
> Why not call this one mixed_number?

Okay, your suggested name changes have been applied. 
Also, except for big_integral<>, the NumberSign
parameter is now removed.  Examples:

  rational<int_<11>,integral_c<long,16> >
  rational_c<long,-9,5>
  mixed_number<long_<2>,int_<54>,integral_c<int,100> >
  mixed_number_c<int,0,-2,5>

The following expressions are currently illegal:

  rational<int_<1>,int_<0> >
  rational_c<long,9,-5>
  mixed_number<long_<3>,int_<-1>,integral_c<int,2> >
  mixed_number_c<int,0,6,5>

I'm currently debating with myself about whether to
make aux::rational2mixed_number<> part of the public
interface; and if so, whether to rename it to
something more legible; or if not, whether
mixed_number<> and mixed_number_c<> should take
default parameters.

> IMO the rational Concept should hold independent of
> the exact parameters.  The types used for the
> parameters are a trade off between using small_ints
> and having a relatively quick compile with the
> possibility of everflow, as against big_integers
with
> long compile (and posibly run) times.

Actually only the relationship between the concept and
the implementation models was dependent on the
parameter "metatypes".  But I know what you meant, so
don't worry about it.

> However in a large number of cases a rational has
> known bounds, so an inbuilt int has ample range.

Yeah.  It's when you try things like the square_root<>
example program (included in the zip file) that the
inbuilt range becomes not enough.

> I am wondering if the more lazy implementation
> possible by moving away from integral constant
> expansion might improve matters.  OTOH perhaps it
> will make matters worse.  (I am no expert on 'lazy'
> programming...but it must have some benefit?)

I'll try to implement some lazy versions of both
big_integral<> and the new numeric metafunctions in
the next version.

> It is merely one among several possible compile time
> types that Might be useful as parameters.  Other
> possibilities are the aforementioned big_int and a
> complex, should One not try to make the thing
generic
> as possible?  I dont think anything is lost by it.
> Even if the helper functions like gcd and abs are
not
> useful for this they may come in useful somewhere
> else.

I've reimplemented rational<> so that it accepts any
numeric constants M and N for which modulus<M,N> is a
valid expression.  That should improve its genericity.

                              Cromwell D. Enage

                
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail