[mpl] Math sublibrary: new version.
--- 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
"Cromwell Enage" <sponage@yahoo.com> wrote
The following expressions are currently illegal:
rational<int_<1>,int_<0> > rational_c<long,9,-5>
disallowing negative denominator seems a little harsh. 1 / -2 is a valid mathematical expression. [snip]
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.
FWIW some comments on rational... 1) rational should have a value_type for similarity with integral_c. ( eg plus <Numerator,Denominator>::type::value_type; ) 2) Because gcd is not a primitive operation( because it can be expressed solely in terms of others); Is there a need fo the 'impl and '::apply rigmarole. I think not(Same for abs, is_negative etc.)Why is this amount of implementation complexity necessary in gcd?. 3) However OTOH numerator<T> and denominator<T> need to be applicable to integral_c too(Otherwise there is no advantage over use of member ::denomnator) , but is a primitive operation; Therefore the 'impl rigmarole should be applied. denominator <int_<X> >:: type == int_<1>, numerator <int_<X> >:: type == int_<X> or whatever. It should be possible to mix rational and integral parameters pretty easily. FWIW Ive enclosed my rendition of denominator (hopefully boostified) in this method . Thanks for working on it though ... ;-) regards Andy Little
--- Andy Little <andy@servocomm.freeserve.co.uk> wrote:
disallowing negative denominator seems a little harsh. 1 / -2 is a valid mathematical expression.
Very well. I'll move this restriction to mixed_number<>.
FWIW some comments on rational...
1) rational should have a value_type for similarity with integral_c. ( eg plus <Numerator,Denominator>::type::value_type; )
So, what should value_type be when either Numerator or Denominator are big_integral<>?
2) Because gcd is not a primitive operation( because it can be expressed solely in terms of others); Is there a need fo the 'impl and '::apply rigmarole. I think not(Same for abs, is_negative etc.)Why is this amount of implementation complexity necessary in gcd?.
There may be an implementation of gcd<> that is more efficient even if it works solely on big_integral<> numbers. Or there may not, but for now, I shouldn't rule out anything that promises to make big_integral<> operations less expensive.
3) However OTOH numerator<T> and denominator<T> need to be applicable to integral_c too(Otherwise there is no advantage over use of member ::denomnator) , but is a primitive operation; Therefore the 'impl rigmarole should be applied. denominator <int_<X> >:: type == int_<1>, numerator <int_<X> >:: type == int_<X> or whatever. It should be possible to mix rational and integral parameters pretty easily. FWIW Ive enclosed my rendition of denominator (hopefully boostified) in this method .
I hadn't thought of this, yet. I'll do it, but I'll only specialize for integral_c_tag and big_integral_tag; the default implementation will look for the corresponding member type. Same for whole_part<>, rational_part<>, real_part<>, and imaginary_part<>.
Thanks for working on it though ... ;-)
Not a problem, whenever I have time. :) Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
"Cromwell Enage" wrote
--- Andy Little wrote:
disallowing negative denominator seems a little harsh. 1 / -2 is a valid mathematical expression.
Very well. I'll move this restriction to mixed_number<>.
FWIW some comments on rational...
1) rational should have a value_type for similarity with integral_c. ( eg plus <Numerator,Denominator>::type::value_type; )
So, what should value_type be when either Numerator or Denominator are big_integral<>?
err... whatever the underlying type is. presumably long or long long? But I see the problem. In hindsight .. I guess I can live without it.
2) Because gcd is not a primitive operation( because it can be expressed solely in terms of others); Is there a need fo the 'impl and '::apply rigmarole. I think not(Same for abs, is_negative etc.)Why is this amount of implementation complexity necessary in gcd?.
There may be an implementation of gcd<> that is more efficient even if it works solely on big_integral<> numbers.
Surely it would make sense to specialise this for big_int. Or there may not, but for now, I shouldn't
rule out anything that promises to make big_integral<> operations less expensive.
But these operations will now be unneccessarily expensive for small_int types. Your version of gcd looks is obviously optimised for big_integral. However my requirements on rational would be for a large number of smallint types. I hope you will take this into account in the design and favour the implementation more towards small_int types as well.
parameters pretty easily. FWIW Ive enclosed my rendition of denominator (hopefully boostified) in this method .
I hadn't thought of this, yet. I'll do it, but I'll only specialize for integral_c_tag and big_integral_tag; the default implementation will look for the corresponding member type. Same for whole_part<>, rational_part<>, real_part<>, and imaginary_part<>.
OK maybe that would be quicker, and give better error messages. But you will need a tag dispatch mechanism anyway wont you?, to avoid a large number of specialisations.
Thanks for working on it though ... ;-)
Not a problem, whenever I have time. :)
Cheers Andy Little
participants (2)
-
Andy Little -
Cromwell Enage