QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnThis looks relevantThe "Guard Digits" is an efficient solution. The pioneers must have had a great time coming up with these solutions.Although "Guard Digits" ensure lower round-off errors in the result of any given dyadic operation, they don't solve the problem of non-associativity in longer chains of operations. To reduce the effects of the original problem, one would have to implement "guard digits" in the CPU registers (e.g., use 65-bit registers in the CPU) and ensure that the programmer/compiler/runtime never moved the intermediate values of a long computation from the register out to RAM (which strips the "guard digits" away in order to fit the value in the 64-bit memory location.

QuoteOriginally posted by: outrunSomewhat related -especially for precision in finance- is that decimal numbers nearly made it to C++11. That would guarantee 0.3 * 10 to be 3.I love the exponentiation by squaring. I wanted to explain it to my son a couple of moths ago but that was a bit too early.That would have been great, I had to provide figures for Finance and Accounting departments. We then realised tat they needed exact precision at the penny level on the figures given to them.

QuoteOriginally posted by: outrunQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnThis looks relevantThe "Guard Digits" is an efficient solution. The pioneers must have had a great time coming up with these solutions.Although "Guard Digits" ensure lower round-off errors in the result of any given dyadic operation, they don't solve the problem of non-associativity in longer chains of operations. To reduce the effects of the original problem, one would have to implement "guard digits" in the CPU registers (e.g., use 65-bit registers in the CPU) and ensure that the programmer/compiler/runtime never moved the intermediate values of a long computation from the register out to RAM (which strips the "guard digits" away in order to fit the value in the 64-bit memory location.Cuch has some recurring interest in this..The "boost interval" library keeps track of *intervals*. So if you say x=1/3 and with one bit floating point precision if with say that the associated interval is [0.25, 0.5). If you next do y=x*x then y will be the interval [0.0625, 0.25). It implements all operators and instead of mapping floats->float it maps intervals->intervalIndeed! And interval math violates associatively even more so than regular floating point math because the calculation of the lower bound of the interval ALWAYS uses round-down math and the calculation of the upper bound of the interval ALWAYS uses round-up math. Thus the interval for (((((((((x*x)*x)*x)*x)*x)*x)*x)*x)*x) will be several ULS larger than that for (((x*x)*(x*x))*((x*x)*(x*x))).

QuoteOriginally posted by: outrunSomewhat related -especially for precision in finance- is that decimal numbers nearly made it to C++11. That would guarantee 0.3 * 10 to be 3.Perhaps types in Boost.Multiprecision can be of help:http://www.boost.org/libs/multiprecision/

QuoteOriginally posted by: outrunQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: outrunQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnThis looks relevantThe "Guard Digits" is an efficient solution. The pioneers must have had a great time coming up with these solutions.Although "Guard Digits" ensure lower round-off errors in the result of any given dyadic operation, they don't solve the problem of non-associativity in longer chains of operations. To reduce the effects of the original problem, one would have to implement "guard digits" in the CPU registers (e.g., use 65-bit registers in the CPU) and ensure that the programmer/compiler/runtime never moved the intermediate values of a long computation from the register out to RAM (which strips the "guard digits" away in order to fit the value in the 64-bit memory location.Cuch has some recurring interest in this..The "boost interval" library keeps track of *intervals*. So if you say x=1/3 and with one bit floating point precision if with say that the associated interval is [0.25, 0.5). If you next do y=x*x then y will be the interval [0.0625, 0.25). It implements all operators and instead of mapping floats->float it maps intervals->intervalIndeed! And interval math violates associatively even more so than regular floating point math because the calculation of the lower bound of the interval ALWAYS uses round-down math and the calculation of the upper bound of the interval ALWAYS uses round-up math. Thus the interval for (((((((((x*x)*x)*x)*x)*x)*x)*x)*x)*x) will be several ULS larger than that for (((x*x)*(x*x))*((x*x)*(x*x))).This is interesting:x^10 is very different than a*b*c*..*j with a=b=c=...=j = x in the first case we know that x is inside some interval *but* that all values that get multiplied together are identical -the uncertainty is completely dependent-in the second case we know that a and b are in the same interval, but they need not be the same, -the uncertainty is independent- hence the extra expansion of uncertainty.I'm sure that boost interval knows this: it will give a tighter interval for pow(x,10) than for x*x*x*x*.. I'll bet you a Kwak on it.I agree that the interval should be tighter, but not for the reason you suggest.Unless the interval of x spans 0, x*x*x*x...*x*x is not different than a*b*c*..*j with a=b=c=...=j = x due to the way intervals interact with the multiplication operator. Whether the value within the interval is positively correlated or independent won't change the extrema of the multiplication of the two intervals. (Negative correlation between two multiplied intervals or multiplied intervals that span zero are a different matter.)That said, pow(x,10) should have a tighter interval unless they implement pow() as a linear chain of multiplications, which is unlikely. Any implementation of pow() that reduces the number of chained operations will reduce the creeping expansion of the interval due to round-down/round-up errors in every step of the interval math.QuoteOriginally posted by: outrun(or you could use the high precision library instead, much easier...)Exactly! And that's synonymous with using (and maintaining) guard digits across multiple operations.

QuoteOriginally posted by: PolterQuoteOriginally posted by: outrunSomewhat related -especially for precision in finance- is that decimal numbers nearly made it to C++11. That would guarantee 0.3 * 10 to be 3.Perhaps types in Boost.Multiprecision can be of help:http://www.boost.org/libs/multiprecision/Sounds good. Is it easy to integrate this into an existing program with doubles all over the place?

QuoteOriginally posted by: outrunQuoteOriginally posted by: Traden4AlphaI agree that the interval should be tighter, but not for the reason you suggest.Unless the interval of x spans 0, x*x*x*x...*x*x is not different than a*b*c*..*j with a=b=c=...=j = x due to the way intervals interact with the multiplication operator. Whether the value within the interval is positively correlated or independent won't change the extrema of the multiplication of the two intervals.AI! Indeed!I was thinking in stdev terms, not in ranges Indeed! And that's one of the differences between L-2 and L-∞ norms.

Here is some Boost Interval code you can play with (BTW afaik Boost pow is _still_ not work). It's a great pity because interval arithmetic is the good way to go in some cases.

Sure; it's the policy that is not defined in Interval.

QuoteOriginally posted by: CuchulainnHere is some Boost Interval code you can play with (BTW afaik Boost pow is _still_ not work). It's a great pity because interval arithmetic is the good way to go in some cases.http://liveworkspace.org/code/4EteOj$0h ... ml#include <boost/multiprecision/gmp.hpp>typedef boost::multiprecision::mpf_float ScalarType;typedef boost::numeric::interval<ScalarType> Range;long N = 87;[9.6e-67203814131540119,1.36515e+67209790456936]