
Boost : 
From: Cromwell Enage (sponage_at_[hidden])
Date: 20050506 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://boostsandbox.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
nonfunctional 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk