 |
|
|
|
|
|
| |
| |
|
|
From: Jarek Cora
Subject: (X <= D) different than ((X<D) | (X=D)) ?
Date: 22 Apr 2000 06:10:02
Message: <39017a7a@news.povray.org>
|
|
|
| |
| |
|
|
Hi all,
Could someone please explain the following behavior of POV-Ray 3.1g:
Let's consider a simple while loop:
#local D = 2;
#local X = -D;
#while ((X < D) | (X = D))
#local X = X + 0.1;
#end
#debug concat("X = ",str(X,0,-1),"\n")
It produces the result X=2.10000, just as I expected.
However when I change the "while" condition to:
#while (X <= D)
the result is: X = 2.000
Why is that? I would expect that (X <= D) and ((X<D) | (X=D)) are
equivalent.
-- Jarek
Post a reply to this message
|
|
| |
| |
|
|
From: Bob Hughes
Subject: Re: (X <= D) different than ((X<D) | (X=D)) ?
Date: 22 Apr 2000 08:09:27
Message: <39019677@news.povray.org>
|
|
|
| |
| |
|
|
Not that I really know but <= might be considered as "less than AND equal to" whereas
the
OR is taken to be the case in the ((X < D) | (X = D)), so <= won't let it also be
equivalent although the | does.
Bob
"Jarek Cora" <jco### [at] poczta fm> wrote in message news:39017a7a@news.povray.org...
| Hi all,
| Could someone please explain the following behavior of POV-Ray 3.1g:
| Let's consider a simple while loop:
|
| #local D = 2;
| #local X = -D;
| #while ((X < D) | (X = D))
| #local X = X + 0.1;
| #end
| #debug concat("X = ",str(X,0,-1),"\n")
|
| It produces the result X=2.10000, just as I expected.
| However when I change the "while" condition to:
|
| #while (X <= D)
|
| the result is: X = 2.000
|
| Why is that? I would expect that (X <= D) and ((X<D) | (X=D)) are
| equivalent.
|
| -- Jarek
|
|
|
|
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes wrote:
>
> Not that I really know but <= might be considered as "less than AND equal to"
Sooo....
What's less than AND equal to 2? ;)
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, those conditions should be equivalent.
It seems to be a precision-related issue, since the correct result is achieved
by adding some very small value to D in the condition (X <= D). Also, when the
loop is shorter, e.g. D=1, the result is correct for X = X + 0.1
The second version works because for some reason the condition (X = D) evaluates
correctly. However, the conditions like (X != D) (X <= D) etc do not.
I tested this under official 3.1g (Windows & Linux) and Megapov 0.4g (Windows)
and due to the inconsistency regarding conditional operators, it looks like a
bug to me. Comments?
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: (X <= D) different than ((X<D) | (X=D)) ?
Date: 22 Apr 2000 11:54:10
Message: <3901cb22$1@news.povray.org>
|
|
|
| |
| |
|
|
In article <3901AA4C.28062CFA@peak.edu.ee> , Margus Ramst
<mar### [at] peakeduee> wrote:
> Yes, those conditions should be equivalent.
The are equivalent mathematically, but not in terms of floating-point
arithmetic.
> It seems to be a precision-related issue, since the correct result is achieved
> by adding some very small value to D in the condition (X <= D). Also, when the
> loop is shorter, e.g. D=1, the result is correct for X = X + 0.1
> The second version works because for some reason the condition (X = D)
> evaluates correctly. However, the conditions like (X != D) (X <= D) etc do
> not. I tested this under official 3.1g (Windows & Linux) and Megapov 0.4g
> (Windows) and due to the inconsistency regarding conditional operators, it
> looks like a bug to me. Comments?
Technically it is not a bug but a limit in floating-point precision. The
reason why the first one works is rather simple: POV-Ray already contains a
workaround for "is equal" comparisons as well as "is not equal" ones, but
not for smaller/greater (or equal) than ones. In reality POV-Ray fixes the
problem for the equal and not equal cases with this method:
condition: f1 = f2
POV-Ray: if (fabs(f1 - f2) > EPSILON) then false else true
condition: f1 != f2
POV-Ray: if (fabs(f1 - f2) > EPSILON) then true else false
The other comparison operators do not take EPSILON into account. So
practically POV-Ray should contain a workaround for these cases as well.
However, you can also do something like #while (X <= D+0.0001) and it will
work.
Further, the documentation should make clear that floating-point math is
_not_ precise. Especially in long operations the error will build up: There
are some more exact specs for this, but you can safely assume about one
digit per operation. Thus, the example above will accumulate a reasonable
error after its twenty iterations.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> Technically it is not a bug but a limit in floating-point precision.
I did suspect a precision problem. But the fact that some operators act
differently than others leads to some confusion. I think either they all should
take epsilon into account, or at least the difference should be documented.
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
From: Jarek Cora
Subject: Re: (X <= D) different than ((X<D) | (X=D)) ?
Date: 22 Apr 2000 13:42:46
Message: <3901e496@news.povray.org>
|
|
|
| |
| |
|
|
Thank you for the detailed explanation. Now it does make sense.
BTW, I agree with Margus that it would be a good idea to mention it in the
docs or some FAQ.
-- Jarek
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: (X <= D) different than ((X<D) | (X=D)) ?
Date: 22 Apr 2000 15:47:25
Message: <390201cd$1@news.povray.org>
|
|
|
| |
| |
|
|
In article <3901e496@news.povray.org> , "Jarek Cora" <jco### [at] pocztafm>
wrote:
> Thank you for the detailed explanation. Now it does make sense.
> BTW, I agree with Margus that it would be a good idea to mention it in the
> docs or some FAQ.
Thank you for reporting this problem!
I agree with you two. A problem report has been posted to
povray.bugreports.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: Further, the documentation should make clear that floating-point math is
: _not_ precise. Especially in long operations the error will build up
That's right. The key problem here is the value 0.1. It can't be accurately
represented in binary format.
We have the same problem with the decimal format with values like 1/3;
it can't be represented accurately.
It is NOT a bug. It's just a hardware limitation.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> That's right. The key problem here is the value 0.1. It can't be accurately
> represented in binary format.
> We have the same problem with the decimal format with values like 1/3;
> it can't be represented accurately.
>
> It is NOT a bug. It's just a hardware limitation.
>
Yes, but the problem here is incosistency. The epsilon value should be used to
handle such cases, but is not being used here.
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
