|
From: | Daniel J Sebald |
Subject: | Re: A problem with range objects and floating point numbers |
Date: | Thu, 25 Sep 2014 10:50:51 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 09/25/2014 01:16 AM, Markus wrote:
Am 2014-09-25 07:54, schrieb Oliver Heimlich:Am 24.09.2014 20:06, schrieb Daniel J Sebald:On 09/24/2014 12:29 PM, Oliver Heimlich wrote:
[snip]
This is because x/x==1 with any x. I do not have to emphasize that both πs are equal.octave-cli:3> ((50*pi)/pi) == 50.0 ans = 1 octave-cli:4> ((pi*pi)/pi) == pi ans = 1Both 50 and the π constant are binary floating point numbers, so the results may be exact. Additionally, the π constant's very last binary digits are zero, so there is some protection against errors. Try the following: octave:1> x = pi + eps * 2; octave:2> x * 50 / 50 == x ans = 0oh boy octave:9> 0.1 + 0.2 == 0.3 ans = 0 octave:10> 0.1 + 0.2 - 0.2 == 0.1 ans = 0 octave:11> fprintf("%.24f == %.24f\n", 0.1 + 0.2, 0.3) 0.300000000000000044408921 == 0.299999999999999988897770 So, no surprise here. You should read this http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html And for the sake of completeness .... # Matlab0.1 + 0.2 == 0.3ans = 00.1 + 0.2 -0.2 == 0.1ans = 0
OK, true. I suppose that explains why the range-generating algorithm accumulates errors when adding the step size so often.
However, the original algorithm I was pondering is comprised of division. Given [A:s:B], if 1) A is integer, and 2) A/s is integer then [A:s:B] can be implemented as [A/s:1:floor(B/s)] * s where the range operation is integer-based.Will that eliminate the accumulation of addition errors that Jo pointed out? Is changing the problem into one of multiplication rather addition when possible a good idea? Or is the problem only manifesting somewhere else?
Dan
[Prev in Thread] | Current Thread | [Next in Thread] |