Re^2: [OT] C++ mystery.

It looks like it's just ensuring that the return value is coerced into a double

But every variable in the entire subroutine is already a double?

I don't know anything about doubledouble, so perhaps it's using an extended floating point type (like long double)?

No. The doubledouble class provides greater precision by using pairs of doubles (hi & lo) to hold different parts of the higher precision value.

This routine adds two doubledoubles together, by extracting any 'carry' from the lo+lo and adding it into the hi+hi calculation.

I'm beginning (after reading a dozen or so papers and banging my head till it hurts) to understand how it achieves that; but the one bit that has me baffled is:

why does it need to cast the subtraction of one double from another double; to a double, before adding it to another double?

That; along with a couple of the other calculations don't appear to make any difference to the outcome no matter what values I've tried.

Normally, I might just conclude they were artifacts of time; or minor over-engineering; but the routine is attributed (copyrighted) by W. Kahan

And is (apparently) an implementation of the Kahan summation algorithm.

So, I'm loathed to simplify; but I'm bugged that I cannot find any reason why they are there :(

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Comment on Re^2: [OT] C++ mystery.

Replies are listed 'Best First'.
Re^3: [OT] C++ mystery. by Anonymous Monk on Jun 19, 2015 at 19:48 UTC
to that point, why... `z.hi = H + e z.lo = e + H - z.hi z.lo = e + H - ( H + e ) z.lo = e - e` [download] ...my math may be rusty ;) ...	[reply] [d/l]
Re^4: [OT] C++ mystery. by BrowserUk (Patriarch) on Jun 19, 2015 at 20:35 UTC
The basic process at work here is the following You've got two numbers of widely differing scale: `printf "%.17e\n", 1.00000000000000040e+000;; 1.00000000000000040e+000 printf "%.17e\n", 5.00000000000100030e-016;; 5.00000000000100030e-016` [download] If you just add those together, you obviously loose some precision from the smaller number due to hardware limitation: `printf "%.17e\n", $S = 1.00000000000000040e+000 + 5.00000000000100030e +-016;; 1.00000000000000090e+000` [download] So, doubledouble uses a second double to store that lost precision. But to do so,it needs to 'recover' the loss. By subtracting the two numbers in turn, from their sum (numerically ought to be zero); but due to the machine limitations, a delta falls out and the lost precision is recovered: `printf "%.17e\n", $S = 1.00000000000000040e+000 + 5.00000000000100030e +-016;; 1.00000000000000090e+000 printf "%.17e\n", $e = ( $S = 1.00000000000000040e+000 + 5.00000000000 +100030e-016 ) - 1.00000000000000040e+000;; 4.44089209850062620e-016 printf "%.17e\n", ( $e = ( $S = 1.00000000000000040e+000 + 5.000000000 +00100030e-016 ) - 1.00000000000000040e+000 ) - 5.00000000000100030e-0 +16;; -5.59107901500374110e-017` [download] That last value is the lost precision that needs to be stored in the second double. Of course, it doesn't end there. There might already be values in those other (low) doubles; and they need to be added together along with the spillage from the hi order doubles above. But that calculation itself can result in what might be termed 'overflow' or 'carry-over'; and that needs to be added back into the high order part of the result. But that ... Hopefully, you get the picture. The sequences of additions and subtractions in that sub are meant to ensure that borrows from the high order doubles and carries from the low order doubles are sorted out and merged; with the result that you end up with 105/6 bits of precision. It -- the C++ -- appears to work; plenty of people have used it -- but I want to port (parts of) it to C; and that's caused me to look closely at it. And there is weirdness afoot. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply] [d/l] [select]
Re^4: [OT] C++ mystery. by bitingduck (Chaplain) on Jun 20, 2015 at 00:46 UTC
So maybe to keep the compiler from optimizing the result to zero at compile time?	[reply]
Re^5: [OT] C++ mystery. by BrowserUk (Patriarch) on Jun 20, 2015 at 01:15 UTC
According to this and (for me) this, that should either not happen; or at least be controllable. But then, that may not have been the case for which compiler the code was originally (or subsequently) targeted at; so it's a good thought. Thank you. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply]
Re^6: [OT] C++ mystery. by bitingduck (Chaplain) on Jun 20, 2015 at 03:39 UTC
Re^7: [OT] C++ mystery. by BrowserUk (Patriarch) on Jun 20, 2015 at 13:45 UTC


Syntactic Confectionery Delight
	PerlMonks