What should we do about the accuracy of double_ operations? The implementation of plus,minus,times and divide mimics the behaviour of the runtime equivalent, double. This means that the mantissa is trunkated from 61 to 52 bit for every fundamental operation. The result of this, is that complex functions such as sine and exponential will differ from their runtime counterpart, unless a specialization is made for double_. The problem would disappear if we allow calculations with double_ to be more accurate than calculations with double. Is this a problem? Regards Peder
Peder Holt <peder.holt@gmail.com> writes:
What should we do about the accuracy of double_ operations?
The implementation of plus,minus,times and divide mimics the behaviour of the runtime equivalent, double.
On which implementation of C++?
This means that the mantissa is trunkated from 61 to 52 bit for every fundamental operation. The result of this, is that complex functions such as sine and exponential will differ from their runtime counterpart, unless a specialization is made for double_. The problem would disappear if we allow calculations with double_ to be more accurate than calculations with double. Is this a problem?
It doesn't sound like your correspondence with runtime results can possibly be portable anyway, can it? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 9/24/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
What should we do about the accuracy of double_ operations?
The implementation of plus,minus,times and divide mimics the behaviour of the runtime equivalent, double.
On which implementation of C++?
Hmm. Good question :) VC8.0 beta and VC7.1
This means that the mantissa is trunkated from 61 to 52 bit for every fundamental operation. The result of this, is that complex functions such as sine and exponential will differ from their runtime counterpart, unless a specialization is made for double_. The problem would disappear if we allow calculations with double_ to be more accurate than calculations with double. Is this a problem?
It doesn't sound like your correspondence with runtime results can possibly be portable anyway, can it?
I haven't studied the results from other compilers, but from reading other posts on the issue, it seems that you are right, floating point operations are implementation defined anyway, so I'll stick to keeping the 61 bits. 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> wrote in message news:4c1c5632050924115073d9251c@mail.gmail.com...
What should we do about the accuracy of double_ operations?
The implementation of plus,minus,times and divide mimics the behaviour of the runtime equivalent, double. This means that the mantissa is trunkated from 61 to 52 bit for every fundamental operation. The result of this, is that complex functions such as sine and exponential will differ from their runtime counterpart, unless a specialization is made for double_. The problem would disappear if we allow calculations with double_ to be more accurate than calculations with double. Is this a problem?
There is neverending discussion on comp.lang.c++.mod regarding differences between runtime floats on various platforms. IMO this is an ideal opportunity to create a platform independent floating point type, IOW one with an exact length of mantissa and exponent specified and with a consistent policy on rounding etc. I think this is how it is done in Java though the only link I can find is:http://www.concentric.net/~Ttwang/tech/javafloat.htm Other question is ... What sort of rounding do you use? Also ... I'm assuming it is simple enough to program the length of mantissa and exponent?. By making them length adjustable you would be able to regain platform dependence via typedefs where required. thus providing the best of both worlds. regards Andy Little
On 9/25/05, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
"Peder Holt" <peder.holt@gmail.com> wrote in message news:4c1c5632050924115073d9251c@mail.gmail.com...
What should we do about the accuracy of double_ operations?
The implementation of plus,minus,times and divide mimics the behaviour of the runtime equivalent, double. This means that the mantissa is trunkated from 61 to 52 bit for every fundamental operation. The result of this, is that complex functions such as sine and exponential will differ from their runtime counterpart, unless a specialization is made for double_. The problem would disappear if we allow calculations with double_ to be more accurate than calculations with double. Is this a problem?
There is neverending discussion on comp.lang.c++.mod regarding differences between runtime floats on various platforms. IMO this is an ideal opportunity to create a platform independent floating point type, IOW one with an exact length of mantissa and exponent specified and with a consistent policy on rounding etc. I think this is how it is done in Java though the only link I can find is:http://www.concentric.net/~Ttwang/tech/javafloat.htm Other question is ... What sort of rounding do you use?
For multiplication and division operations: If the 53'rd bit is 1, add 1 to the 52'nd bit. For addition/subtraction Ignore extra bits, cutoff after the 52'nd bit. This mimics the behaviour of the VC compilers.
Also ... I'm assuming it is simple enough to program the length of mantissa and exponent?.
To a certain extent... I use two 32 bit integer types to represent the mantissa, and two bits are lost to overflow control. The last bit is the hidden 1 that preceeds the mantissa in the double representation. It is possible to add more integers to represent the mantissa, but it would involve some work to get it right. Certainly doable, though. The exponent is much simpler, as I currently only use 11 bit out of 16 (potentially 32)
By making them length adjustable you would be able to regain platform dependence via typedefs where required. thus providing the best of both worlds.
Not a bad idea :) Probably best to start with the run-time adjustable floating point, then extend it to compile-time. Regards, Peder
regards Andy Little
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 9/25/05, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
There is neverending discussion on comp.lang.c++.mod regarding differences between runtime floats on various platforms. IMO this is an ideal opportunity to create a platform independent floating point type, IOW one with an exact length of mantissa and exponent specified and with a consistent policy on rounding etc. I think this is how it is done in Java though the only link I can find is:http://www.concentric.net/~Ttwang/tech/javafloat.htm Other question is ... What sort of rounding do you use?
For multiplication and division operations: If the 53'rd bit is 1, add 1 to the 52'nd bit. For addition/subtraction Ignore extra bits, cutoff after the 52'nd bit.
This mimics the behaviour of the VC compilers.
Note that not even this will help you, if you allow for optimizations. Just consider the evaluation of the following two expressions: x=b*c; y=a*b*c; Using common subexpression elimination, the compiler might rewrite this as x=b*c; y=a*x; The second line is now equivalent to a*(b*c), while before it was (a*b)*c, and hence the numbers could differ in the last bit(s), because of different rounding. Note that in the past this has actually prevented the Java compiler from performing such optimizations, because such roundoff discrepancies were not allowed! I am aware that at compile time you might just ignore such optimizations, but the result might still differ from the runtime result, because of possible runtime optimizations. Since, hence, now perfect agreement with runtime values will ever be possible unless optimization is completely turned off anyways, one should either, not put too much weight on equivalence to runtime computation, or just forget about compile time computations at all. Matthias
participants (4)
-
Andy Little -
David Abrahams -
Matthias Troyer -
Peder Holt