Is there any interest in a compile-time meta-version of double? Syntax: //Definition typedef META_DOUBLE(3.1415926535897932384626433) pi; //Or META_DOUBLE(3.1415926535897932384626433) pi_; //Mathematical operations typedef math::meta::add<pi,pi>::type pi2; //Evaluation: assert(META_DOUBLE_EVAL(pi2)==3.1415926535897932384626433*2); This implementation uses two ints to represent the decimals, and a short to represent the exponent. It has been tested on VC7.1,VC8.0 beta and GCC3.2 Regards, Peder
I can say for everyone else, but I am very interested, but IFAIK there is a current development in this area on mpl, but I can be wrong, but yor code looks promissing. how well does it integrate with other mpl stuff? On 6/8/05, Peder Holt <peder.holt@gmail.com> wrote:
Is there any interest in a compile-time meta-version of double?
Syntax:
//Definition typedef META_DOUBLE(3.1415926535897932384626433) pi; //Or META_DOUBLE(3.1415926535897932384626433) pi_;
//Mathematical operations typedef math::meta::add<pi,pi>::type pi2;
//Evaluation: assert(META_DOUBLE_EVAL(pi2)==3.1415926535897932384626433*2);
This implementation uses two ints to represent the decimals, and a short to represent the exponent.
It has been tested on VC7.1,VC8.0 beta and GCC3.2
Regards, Peder
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 6/8/05, Sérgio Vale e Pace <svpace.forum@gmail.com> wrote:
I can say for everyone else, but I am very interested, but IFAIK there is a current development in this area on mpl, but I can be wrong, but yor code looks promissing. how well does it integrate with other mpl stuff?
Haven't done any work to integrate it with the rest of mpl, but It should be fairly straight forward.
On 6/8/05, Peder Holt <peder.holt@gmail.com> wrote:
Is there any interest in a compile-time meta-version of double?
Syntax:
//Definition typedef META_DOUBLE(3.1415926535897932384626433) pi; //Or META_DOUBLE(3.1415926535897932384626433) pi_;
//Mathematical operations typedef math::meta::add<pi,pi>::type pi2;
//Evaluation: assert(META_DOUBLE_EVAL(pi2)==3.1415926535897932384626433*2);
This implementation uses two ints to represent the decimals, and a short to represent the exponent.
It has been tested on VC7.1,VC8.0 beta and GCC3.2
Regards, Peder
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- Sérgio Vale e Pace wrote:
I can't say for everyone else, but I am very interested, but AFAIK there is a current development in this area on mpl, but I can be wrong,
No, you are correct, I just haven't gotten around to decimals yet.
but yor code looks promising. how well does it integrate with other mpl stuff?
I would like to know as well. I second the request to have it uploaded to <http://boost-sandbox.sourceforge.net/vault/>
On 6/8/05, Peder Holt wrote:
Is there any interest in a compile-time meta-version of double?
Most definitely.
Syntax:
//Definition typedef META_DOUBLE(3.1415926535897932384626433) pi; //Or META_DOUBLE(3.1415926535897932384626433) pi_;
Yes, very compact.
//Mathematical operations typedef math::meta::add<pi,pi>::type pi2;
You can specialize the MPL plus metafunction so that it works on your double metatype. Or I can do that for you :)
//Evaluation:
assert(META_DOUBLE_EVAL(pi2)== 3.1415926535897932384626433*2);
This implementation uses two ints to represent the decimals, and a short to represent the exponent.
Like I said, please upload to the sandbox vault so that we can examine the implementation. Cromwell D. Enage __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs
On 6/8/05, Cromwell Enage <sponage@yahoo.com> wrote:
--- Sérgio Vale e Pace wrote:
I can't say for everyone else, but I am very interested, but AFAIK there is a current development in this area on mpl, but I can be wrong,
No, you are correct, I just haven't gotten around to decimals yet.
but yor code looks promising. how well does it integrate with other mpl stuff?
I would like to know as well. I second the request to have it uploaded to <http://boost-sandbox.sourceforge.net/vault/>
On 6/8/05, Peder Holt wrote:
Is there any interest in a compile-time meta-version of double?
Most definitely.
Syntax:
//Definition typedef META_DOUBLE(3.1415926535897932384626433) pi; //Or META_DOUBLE(3.1415926535897932384626433) pi_;
Yes, very compact.
//Mathematical operations typedef math::meta::add<pi,pi>::type pi2;
You can specialize the MPL plus metafunction so that it works on your double metatype. Or I can do that for you :)
I'll get right to it. Sounds like an interesting challenge :)
//Evaluation:
assert(META_DOUBLE_EVAL(pi2)== 3.1415926535897932384626433*2);
This implementation uses two ints to represent the decimals, and a short to represent the exponent.
Like I said, please upload to the sandbox vault so that we can examine the implementation.
It's there: meta_double.hpp
Cromwell D. Enage
__________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 6/8/05, Cromwell Enage <sponage@yahoo.com> wrote:
--- Sérgio Vale e Pace wrote:
I can't say for everyone else, but I am very interested, but AFAIK there is a current development in this area on mpl, but I can be wrong,
No, you are correct, I just haven't gotten around to decimals yet.
but yor code looks promising. how well does it integrate with other mpl stuff?
I would like to know as well. I second the request to have it uploaded to <http://boost-sandbox.sourceforge.net/vault/>
On 6/8/05, Peder Holt wrote:
Is there any interest in a compile-time meta-version of double?
Most definitely.
Syntax:
//Definition typedef META_DOUBLE(3.1415926535897932384626433) pi; //Or META_DOUBLE(3.1415926535897932384626433) pi_;
Yes, very compact.
//Mathematical operations typedef math::meta::add<pi,pi>::type pi2;
You can specialize the MPL plus metafunction so that it works on your double metatype. Or I can do that for you :)
I have mpl-enabled double_ for plus and less, and uploaded this to the vault. I think I can handle the rest of the fundamental operators, but what I really need help on is: Is it possible to make compile-time versions of the basic mathematical functions? sin,cos,sqrt etc. If you have an idea of how to approach this (given the existence of the basic mpl meta-operators) I would really be interested. Regards, Peder
//Evaluation:
assert(META_DOUBLE_EVAL(pi2)== 3.1415926535897932384626433*2);
This implementation uses two ints to represent the decimals, and a short to represent the exponent.
Like I said, please upload to the sandbox vault so that we can examine the implementation.
Cromwell D. Enage
__________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt <peder.holt@gmail.com> writes:
Is there any interest in a compile-time meta-version of double?
Syntax:
//Definition typedef META_DOUBLE(3.1415926535897932384626433) pi; //Or META_DOUBLE(3.1415926535897932384626433) pi_;
Whoa, that's nice syntax! I'm still trying to guess how you do it. Does the PP treat 3.14 as three tokens?
//Mathematical operations typedef math::meta::add<pi,pi>::type pi2;
//Evaluation: assert(META_DOUBLE_EVAL(pi2)==3.1415926535897932384626433*2);
Really, even with FP rounding errors? I guess multiplying by 2 is fairly safe...
This implementation uses two ints to represent the decimals, and a short to represent the exponent.
I don't understand why you'd choose int for one and short for the other when they have the same range requirements: both int and short are required to be at least 16 bits and neither short nor int is required to be more than 16 bits. Can you explain that? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 6/8/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
Is there any interest in a compile-time meta-version of double?
Syntax:
//Definition typedef META_DOUBLE(3.1415926535897932384626433) pi; //Or META_DOUBLE(3.1415926535897932384626433) pi_;
Whoa, that's nice syntax!
Thanks :)
I'm still trying to guess how you do it. Does the PP treat 3.14 as three tokens?
Currently, I use a naive approach, that does not handle rounding errors correctly for exponents. It goes something like this: #define REMOVE_EXP256(number) number*(number>1e256?1e-256:1.) #define REMOVE_EXP128(number) \ REMOVE_EXP256(number)*(REMOVE_EXP256(number)>1e128?1e-128:1.) etc etc to #define REMOVE_EXP1(number)\ REMOVE_EXP2(number)*(REMOVE_EXP2(number)>1e1?1e-1:1.) And similar for negative exponents. After removing the exponent (normalising the number) I convert the number to int: #define BOOST_META_NORMALISED_DOUBLE_TO_INTA(value) (value<0?-1:1)*int((value)*1e8) #define BOOST_META_NORMALISED_DOUBLE_TO_INTB(value) (value<0?-1:1)*int(((value)*1e8-int((value)*1e8))*1e8) As mentioned, since double is 2-based, the above approach gives round-off errors since it is 10-based. Replacing the above with a 2-based exponent seems to solve this problem
//Mathematical operations typedef math::meta::add<pi,pi>::type pi2;
//Evaluation: assert(META_DOUBLE_EVAL(pi2)==3.1415926535897932384626433*2);
Really, even with FP rounding errors? I guess multiplying by 2 is fairly safe...
I think so, with the 2-based exponent I currently use.
This implementation uses two ints to represent the decimals, and a short to represent the exponent.
I don't understand why you'd choose int for one and short for the other when they have the same range requirements: both int and short are required to be at least 16 bits and neither short nor int is required to be more than 16 bits. Can you explain that?
Should have used long in stead of int. This has been fixed. Correction from above: I use 64 bits to represent the mantissa + sign and 16 bits to represent the exponent Regards, Peder
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt <peder.holt@gmail.com> writes:
On 6/8/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
Currently, I use a naive approach, that does not handle rounding errors correctly for exponents.
It goes something like this:
#define REMOVE_EXP256(number) number*(number>1e256?1e-256:1.) #define REMOVE_EXP128(number) \ REMOVE_EXP256(number)*(REMOVE_EXP256(number)>1e128?1e-128:1.) etc etc to #define REMOVE_EXP1(number)\ REMOVE_EXP2(number)*(REMOVE_EXP2(number)>1e1?1e-1:1.)
And similar for negative exponents.
After removing the exponent (normalising the number) I convert the number to int:
#define BOOST_META_NORMALISED_DOUBLE_TO_INTA(value) (value<0?-1:1)*int((value)*1e8)
#define BOOST_META_NORMALISED_DOUBLE_TO_INTB(value) (value<0?-1:1)*int(((value)*1e8-int((value)*1e8))*1e8)
As mentioned, since double is 2-based, the above approach gives round-off errors since it is 10-based.
Replacing the above with a 2-based exponent seems to solve this problem
Maybe I'm missing something obvious, but I don't see how any of this leads to compile-time constants. On a conforming compiler, a calculation involving floating-point is not a compile-time constant. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 6/8/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
On 6/8/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
Currently, I use a naive approach, that does not handle rounding errors correctly for exponents.
It goes something like this:
#define REMOVE_EXP256(number) number*(number>1e256?1e-256:1.) #define REMOVE_EXP128(number) \ REMOVE_EXP256(number)*(REMOVE_EXP256(number)>1e128?1e-128:1.) etc etc to #define REMOVE_EXP1(number)\ REMOVE_EXP2(number)*(REMOVE_EXP2(number)>1e1?1e-1:1.)
And similar for negative exponents.
After removing the exponent (normalising the number) I convert the number to int:
#define BOOST_META_NORMALISED_DOUBLE_TO_INTA(value) (value<0?-1:1)*int((value)*1e8)
#define BOOST_META_NORMALISED_DOUBLE_TO_INTB(value) (value<0?-1:1)*int(((value)*1e8-int((value)*1e8))*1e8)
As mentioned, since double is 2-based, the above approach gives round-off errors since it is 10-based.
Replacing the above with a 2-based exponent seems to solve this problem
Maybe I'm missing something obvious, but I don't see how any of this leads to compile-time constants. On a conforming compiler, a calculation involving floating-point is not a compile-time constant.
In that case VC7.1,VC8.0 beta and GCC3.2 got it wrong somewhere :) (1.0<2.0) yields a compile-time bool, long(2.0) yield a compile-time long. On the above compilers, that is. Regards, Peder
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt <peder.holt@gmail.com> writes:
On 6/8/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
Maybe I'm missing something obvious, but I don't see how any of this leads to compile-time constants. On a conforming compiler, a calculation involving floating-point is not a compile-time constant.
In that case VC7.1,VC8.0 beta and GCC3.2 got it wrong somewhere :)
That's a known extension in vc7.1. The head of the VC++ team himself told me about it (his favorite unintentional extension, I think), and told me it was gone in vc8.x, I'm pretty sure. I'm surprised to hear that it works for you there. Can't speak for GCC.
(1.0<2.0) yields a compile-time bool, long(2.0) yield a compile-time long. On the above compilers, that is.
Throw a test at comeau online. If it works there, I'll be amazed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Peder Holt <peder.holt@gmail.com> writes:
(1.0<2.0) yields a compile-time bool, long(2.0) yield a compile-time long. On the above compilers, that is.
Throw a test at comeau online. If it works there, I'll be amazed.
long(2.0) must work. 1.0 < 2.0 may not. 5.19/1.
On 6/8/05, Peter Dimov <pdimov@mmltd.net> wrote:
David Abrahams wrote:
Peder Holt <peder.holt@gmail.com> writes:
(1.0<2.0) yields a compile-time bool, long(2.0) yield a compile-time long. On the above compilers, that is.
Throw a test at comeau online. If it works there, I'll be amazed.
long(2.0) must work. 1.0 < 2.0 may not. 5.19/1. given: template<long I> struct test{}; In strict mode, test<long(2.0)> compiled, test<long(1.0<2.0)> did not.
In relaxed mode, a simple META_DOUBLE test-case compiled without warnings. Regards, Peder
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Jun 08, 2005 at 05:20:26PM -0400, David Abrahams wrote:
Peder Holt <peder.holt@gmail.com> writes:
On 6/8/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
Maybe I'm missing something obvious, but I don't see how any of this leads to compile-time constants. On a conforming compiler, a calculation involving floating-point is not a compile-time constant.
In that case VC7.1,VC8.0 beta and GCC3.2 got it wrong somewhere :)
That's a known extension in vc7.1. The head of the VC++ team himself told me about it (his favorite unintentional extension, I think), and told me it was gone in vc8.x, I'm pretty sure. I'm surprised to hear that it works for you there. Can't speak for GCC.
This was an undocumented extension that has been deprecated in GCC 4 c.f. http://gcc.gnu.org/ml/gcc/2005-01/msg01744.html and the last two items here: http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Deprecated-Features.html#Depreca... jon -- "We're doomed!" - C3PO
On 6/9/05, Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
On Wed, Jun 08, 2005 at 05:20:26PM -0400, David Abrahams wrote:
Peder Holt <peder.holt@gmail.com> writes:
On 6/8/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
Maybe I'm missing something obvious, but I don't see how any of this leads to compile-time constants. On a conforming compiler, a calculation involving floating-point is not a compile-time constant.
In that case VC7.1,VC8.0 beta and GCC3.2 got it wrong somewhere :)
That's a known extension in vc7.1. The head of the VC++ team himself told me about it (his favorite unintentional extension, I think), and told me it was gone in vc8.x, I'm pretty sure. I'm surprised to hear that it works for you there. Can't speak for GCC.
This was an undocumented extension that has been deprecated in GCC 4
c.f. http://gcc.gnu.org/ml/gcc/2005-01/msg01744.html and the last two items here: http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Deprecated-Features.html#Depreca...
Oh, well. Anyway, I have now uploaded a version of this to the vault: metamath.zip that is mpl-compliant and supports comparison and arithmetics with the same accuracy as normal double arithmetics. Does not support NaN. Regards, Peder
jon
-- "We're doomed!" - C3PO _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt <peder.holt@gmail.com> writes:
c.f. http://gcc.gnu.org/ml/gcc/2005-01/msg01744.html and the last two items here: http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Deprecated-Features.html#Depreca...
Oh, well. Anyway, I have now uploaded a version of this to the vault: metamath.zip that is mpl-compliant and supports comparison and arithmetics with the same accuracy as normal double arithmetics. Does not support NaN.
Does it get around the comparison problem somehow? I think the results when a floating point value is converted to an integral that can't represent it are undefined (or something similar) but at least most compilers won't stop you. You might try to do some awful thing like transforming a < b into long(b - a) > 0 -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 6/10/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
c.f. http://gcc.gnu.org/ml/gcc/2005-01/msg01744.html and the last two items here: http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Deprecated-Features.html#Depreca...
Oh, well. Anyway, I have now uploaded a version of this to the vault: metamath.zip that is mpl-compliant and supports comparison and arithmetics with the same accuracy as normal double arithmetics. Does not support NaN.
Does it get around the comparison problem somehow?
I think the results when a floating point value is converted to an integral that can't represent it are undefined (or something similar) but at least most compilers won't stop you. You might try to do some awful thing like transforming
a < b
into
long(b - a) > 0
I am not quite sure I understand the problem correctly. What I do is the following: BOOST_STATIC_CONSTANT(bool,value=(BOOST_DOUBLE_EVAL(N1)<BOOST_DOUBLE_EVAL(N2))); So the comparison is not a very big problem. If you absolutely don't want to evaluate the double expression, you would have to do something like: if N1::exp < N2::exp then true if N1::exp > N2::exp then false if N1::decimals1 < N2::decimals then true if N1::decimals1 > N2::decimals then false if N1::decimals2 < N2::decimals then true if N1::decimals2 > N2::decimals then false false Same goes for addition and subtraction, and arguably also multiplication. I am not sure how to avoid double-evaluation in division, but it is probably possible. But, on the other hand, if you are talking about tolerances, I have not implemented any support for a rounding-error tolerant version of compare, I just mimic the behaviour of double. Regards, Peder.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt <peder.holt@gmail.com> writes:
On 6/10/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
c.f. http://gcc.gnu.org/ml/gcc/2005-01/msg01744.html and the last two items here: http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Deprecated-Features.html#Depreca...
Oh, well. Anyway, I have now uploaded a version of this to the vault: metamath.zip that is mpl-compliant and supports comparison and arithmetics with the same accuracy as normal double arithmetics. Does not support NaN.
Does it get around the comparison problem somehow?
I think the results when a floating point value is converted to an integral that can't represent it are undefined (or something similar) but at least most compilers won't stop you. You might try to do some awful thing like transforming
a < b
into
long(b - a) > 0
I am not quite sure I understand the problem correctly.
The problem is that a < b is not a compile-time constant when a and b are floating. If you use such comparisons internally to your library, it is nonportable.
What I do is the following: BOOST_STATIC_CONSTANT(bool,value=(BOOST_DOUBLE_EVAL(N1)<BOOST_DOUBLE_EVAL(N2)));
So the comparison is not a very big problem.
I don't know what BOOST_DOUBLE_EVAL does, so that is opaque to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 6/11/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
On 6/10/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
c.f. http://gcc.gnu.org/ml/gcc/2005-01/msg01744.html and the last two items here: http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Deprecated-Features.html#Depreca...
Oh, well. Anyway, I have now uploaded a version of this to the vault: metamath.zip that is mpl-compliant and supports comparison and arithmetics with the same accuracy as normal double arithmetics. Does not support NaN.
Does it get around the comparison problem somehow?
I think the results when a floating point value is converted to an integral that can't represent it are undefined (or something similar) but at least most compilers won't stop you. You might try to do some awful thing like transforming
a < b
into
long(b - a) > 0
I am not quite sure I understand the problem correctly.
The problem is that a < b is not a compile-time constant when a and b are floating. If you use such comparisons internally to your library, it is nonportable.
Ahh, but you have the same problem with a-b, or indeed with any operation. The only thing that compiles with comeau online in strict mode, is long(a), where a is a double literal, and this doesn't do much good. The building up of a double is nonportable, and I haven't tried to tackle this problem. So far, the only compilers I have tried that did not accept operators on doubles to form compile time constants, is Comeau in strict mode and Digital Mars. Borland, VC [6.5 ,8beta], GCC [?, 4.0.0> on the other hand, accepts the syntax. It is probably possible to create a less elegant way to construct a double_, not involving non-standard functionality. Once a double_ is formed, it is possible to do (most of) the arithmetics on integral constants, as described in previous mail. Regards, Peder
What I do is the following: BOOST_STATIC_CONSTANT(bool,value=(BOOST_DOUBLE_EVAL(N1)<BOOST_DOUBLE_EVAL(N2)));
So the comparison is not a very big problem.
I don't know what BOOST_DOUBLE_EVAL does, so that is opaque to me.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt <peder.holt@gmail.com> writes:
On 6/11/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
On 6/10/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
c.f. http://gcc.gnu.org/ml/gcc/2005-01/msg01744.html and the last two items here: http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Deprecated-Features.html#Depreca...
Oh, well. Anyway, I have now uploaded a version of this to the vault: metamath.zip that is mpl-compliant and supports comparison and arithmetics with the same accuracy as normal double arithmetics. Does not support NaN.
Does it get around the comparison problem somehow?
I think the results when a floating point value is converted to an integral that can't represent it are undefined (or something similar) but at least most compilers won't stop you. You might try to do some awful thing like transforming
a < b
into
long(b - a) > 0
I am not quite sure I understand the problem correctly.
The problem is that a < b is not a compile-time constant when a and b are floating. If you use such comparisons internally to your library, it is nonportable.
Ahh, but you have the same problem with a-b, or indeed with any operation.
Is that right? I guess I thought there was a loophole if you ultimately convert it to int.
The only thing that compiles with comeau online in strict mode, is long(a), where a is a double literal, and this doesn't do much good.
Not much, no.
The building up of a double is nonportable, and I haven't tried to tackle this problem. So far, the only compilers I have tried that did not accept operators on doubles to form compile time constants, is Comeau in strict mode and Digital Mars.
Borland, VC [6.5 ,8beta], GCC [?, 4.0.0> on the other hand, accepts the syntax.
It is probably possible to create a less elegant way to construct a double_, not involving non-standard functionality.
I think you need to at least provide the option, for people who want to write portable code. It doesn't have to be all that ugly, you know. Do you need more than 32 bits after the decimal point? double< 3,1415927 ,E<+6> > -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 6/12/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
On 6/11/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
On 6/10/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
> c.f. http://gcc.gnu.org/ml/gcc/2005-01/msg01744.html > and the last two items here: > http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Deprecated-Features.html#Depreca...
Oh, well. Anyway, I have now uploaded a version of this to the vault: metamath.zip that is mpl-compliant and supports comparison and arithmetics with the same accuracy as normal double arithmetics. Does not support NaN.
Does it get around the comparison problem somehow?
I think the results when a floating point value is converted to an integral that can't represent it are undefined (or something similar) but at least most compilers won't stop you. You might try to do some awful thing like transforming
a < b
into
long(b - a) > 0
I am not quite sure I understand the problem correctly.
The problem is that a < b is not a compile-time constant when a and b are floating. If you use such comparisons internally to your library, it is nonportable.
Ahh, but you have the same problem with a-b, or indeed with any operation.
Is that right? I guess I thought there was a loophole if you ultimately convert it to int.
The only thing that compiles with comeau online in strict mode, is long(a), where a is a double literal, and this doesn't do much good.
Not much, no.
The building up of a double is nonportable, and I haven't tried to tackle this problem. So far, the only compilers I have tried that did not accept operators on doubles to form compile time constants, is Comeau in strict mode and Digital Mars.
Borland, VC [6.5 ,8beta], GCC [?, 4.0.0> on the other hand, accepts the syntax.
It is probably possible to create a less elegant way to construct a double_, not involving non-standard functionality.
I think you need to at least provide the option, for people who want to write portable code.
Definitely. I'll try to change the operators (times,plus etc.) to use integral operations only.
It doesn't have to be all that ugly, you know. Do you need more than 32 bits after the decimal point?
double< 3,1415927 ,E<+6> >
Not bad. The double type does have 16 decimals precision. Is it an option to use long long for the decimal part? I discovered that using base 2 exponent in stead of base 10 exponent gives you the same accuracy as with a regular double expression. Is this an absolute requirement, or is an approximation to double sufficient? Regards, Peder
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt <peder.holt@gmail.com> writes: <snip> [Please try to limit the amount of quoted text in your postings]
I think you need to at least provide the option, for people who want to write portable code.
Definitely. I'll try to change the operators (times,plus etc.) to use integral operations only.
It doesn't have to be all that ugly, you know. Do you need more than 32 bits after the decimal point?
double< 3,1415927 ,E<+6> >
Not bad. The double type does have 16 decimals precision. Is it an option to use long long for the decimal part?
Only on compilers that support it. Again, that's a non-C++98 extension.
I discovered that using base 2 exponent in stead of base 10 exponent
I don't understand what you mean her. Where is this exponent used? Does the user specify the exponent in base 2 (probably not)? YOu must mean in the representation?
gives you the same accuracy as with a regular double expression.
Is this an absolute requirement, ^^^^
a base 2 exponent or the same accuracy as a double?
or is an approximation to double sufficient?
I don't know. Better ask your target audience! I'd guess they don't want an approximation, but I'm only guessing. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 6/12/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
<snip>
[Please try to limit the amount of quoted text in your postings]
Ok :)
double< 3,1415927 ,E<+6> >
One more problem: It is not possible to write e.g. the number 3.00011 in the above notation: double_<3,00011> First of all, 00011 is interpreted as 9. Second, there is no way to distinguish this from: double_<3,9> (as I know of) The alternatives would then be: double_<31415927,E<-7> > (which is basically the same as what Andy does in his physical quantities library) DOUBLE(3,00011,E<0>) where 1 is temporarily prepended to 0001 to preserve the preceding zeros. Alternatively: double_<3,DECIMALS(0001)> that has a default value for the exponent.
Not bad. The double type does have 16 decimals precision. Is it an option to use long long for the decimal part?
Only on compilers that support it. Again, that's a non-C++98 extension.
I discovered that using base 2 exponent in stead of base 10 exponent
I don't understand what you mean her. Where is this exponent used? Does the user specify the exponent in base 2 (probably not)? YOu must mean in the representation?
I mean the representation. I just need to find the correct transformation between the E<N> notation and the 2^M notation.
gives you the same accuracy as with a regular double expression.
Is this an absolute requirement, ^^^^
a base 2 exponent or the same accuracy as a double?
this == same accuracy as double
or is an approximation to double sufficient?
I don't know. Better ask your target audience! I'd guess they don't want an approximation, but I'm only guessing.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt <peder.holt@gmail.com> writes:
On 6/12/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
<snip>
[Please try to limit the amount of quoted text in your postings]
Ok :)
double< 3,1415927 ,E<+6> >
One more problem: It is not possible to write e.g. the number 3.00011 in the above notation: double_<3,00011> First of all, 00011 is interpreted as 9. Second, there is no way to distinguish this from: double_<3,9> (as I know of)
Right... I knew about that problem and somehow it disappeared for me as I wrote out the example :(
The alternatives would then be: double_<31415927,E<-7> > (which is basically the same as what Andy does in his physical quantities library)
DOUBLE(3,00011,E<0>) where 1 is temporarily prepended to 0001 to preserve the preceding zeros.
That's not a bad concept, although "the andy method" also looks pretty nice to me, and avoids the macro.
I discovered that using base 2 exponent in stead of base 10 exponent
I don't understand what you mean her. Where is this exponent used? Does the user specify the exponent in base 2 (probably not)? YOu must mean in the representation?
I mean the representation.
Ah, well that's what the machine's FPU does too.
I just need to find the correct transformation between the E<N> notation and the 2^M notation.
Yup. I'm sure you can find well-researched information about that somewhere. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
I don't understand why you'd choose int for one and short for the other when they have the same range requirements: both int and short are required to be at least 16 bits and neither short nor int is required to be more than 16 bits. Can you explain that?
AFAIK, the only thing you can say about the size of int is that it must handle the INT_MIN to INT_MAX range on a given platform and the only thing you can say about short is that it is no bigger than int and at least one byte. Have I missed something that requires both to be at least 16 bits? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
I don't understand why you'd choose int for one and short for the other when they have the same range requirements: both int and short are required to be at least 16 bits and neither short nor int is required to be more than 16 bits. Can you explain that?
AFAIK, the only thing you can say about the size of int is that it must handle the INT_MIN to INT_MAX range on a given platform and the only thing you can say about short is that it is no bigger than int and at least one byte.
Have I missed something that requires both to be at least 16 bits?
Yes. -- Dave Abrahams Boost Consulting www.boost-consulting.com
I wonder how this can be implemented. How could you separate the decimal part and the exponent part from the double literal like 3.14159 Would you upload the code to boost-sandbox vault?:) Peder Holt wrote:
Is there any interest in a compile-time meta-version of double?
Syntax:
//Definition typedef META_DOUBLE(3.1415926535897932384626433) pi; //Or META_DOUBLE(3.1415926535897932384626433) pi_;
//Mathematical operations typedef math::meta::add<pi,pi>::type pi2;
//Evaluation: assert(META_DOUBLE_EVAL(pi2)==3.1415926535897932384626433*2);
This implementation uses two ints to represent the decimals, and a short to represent the exponent.
It has been tested on VC7.1,VC8.0 beta and GCC3.2
Regards, Peder
On 6/8/05, Allen <yaozhen@ustc.edu> wrote:
I wonder how this can be implemented. How could you separate the decimal part and the exponent part from the double literal like 3.14159
Would you upload the code to boost-sandbox vault?:)
Have done: http://boost-sandbox.sourceforge.net/vault/ meta_double.hpp
Peder Holt wrote:
Is there any interest in a compile-time meta-version of double?
Syntax:
//Definition typedef META_DOUBLE(3.1415926535897932384626433) pi; //Or META_DOUBLE(3.1415926535897932384626433) pi_;
//Mathematical operations typedef math::meta::add<pi,pi>::type pi2;
//Evaluation: assert(META_DOUBLE_EVAL(pi2)==3.1415926535897932384626433*2);
This implementation uses two ints to represent the decimals, and a short to represent the exponent.
It has been tested on VC7.1,VC8.0 beta and GCC3.2
Regards, Peder
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (8)
-
Allen -
Cromwell Enage -
David Abrahams -
Jonathan Wakely -
Peder Holt -
Peter Dimov -
Rob Stewart -
Sérgio Vale e Pace