Boost logo

Boost :

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
> file. Could you send me your source? Thanks.

The file has a new home. Go to
<>, look
under the subdirectory "expaler", and download from

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> >
  mixed_number<long_<2>,int_<54>,integral_c<int,100> >

The following expressions are currently illegal:

  rational<int_<1>,int_<0> >
  mixed_number<long_<3>,int_<-1>,integral_c<int,2> >

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
> 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
> as possible? I dont think anything is lost by it.
> Even if the helper functions like gcd and abs are
> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at