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

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

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

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

| Sooo....
| What's less than AND equal to 2? ;)

Good point.

Post a reply to this message

Warp <war### [at] tagpovrayorg> schrieb in im Newsbeitrag:
390209b1@news.povray.org...
> : 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.
Hmm ... so why not implement a complete algebra-system into POV ???
This would also make it easier to build these physical-modells some people
are always trying to ... ;-)

OK ... I know it would be hard ... Just a thougt ...

--

 ,',    Jan Walzer      \V/  http://wa.lzer.net     ,',
',','   student of      >|<  mailto:jan### [at] lzernet ',','
  '   ComputerScience   /A\  +49-177-7403863         '

Post a reply to this message

Jan Walzer <wal### [at] informatikuni-hallede> wrote:
: Hmm ... so why not implement a complete algebra-system into POV ???

  Speed.
  It would be prohibitely slow.

-- 
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