> The macro gets called 30000 times, and about 29965 of those times the
> calculated values get returned into the Cp array, but on 35 of those
> calls one of the calculated values doesn't get returned. The value in
> the control point array is whatever the array was preloaded with (in
> this case 0). So about 35 of the 30000 control points of the mesh are
> incorrectly positioned, producing ugly spikes in the surface.
>
> Changes to other parts of the scene (e.g. adding the debugging code that
> I used to determine what was going on) cause the errors to appear at
> different points of the surface.
>
> I've so far failed to reproduce the effect in a minimal scene.

Oh, wow. I've seen this exact same behavior recently in my POVCOMP WIP.
Passing variables by reference (and changing their values within the macro)
fails *very* occasionally for no apparent reason. Changing the code (even
just the number of tokens in code that's never actually executed) changes
the results. I was going to try to find the problem in the POV-Ray source,
but I'm not familiar enough with that part of the code to do it in a
reasonable amount of time. And as you said, it's incredibly difficult to
reproduce the effect on purpose, so I couldn't make a minimal scene to do a
bug report.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Wasn't it Slime who wrote:
>> The macro gets called 30000 times, and about 29965 of those times the
>> calculated values get returned into the Cp array, but on 35 of those
>> calls one of the calculated values doesn't get returned. The value in
>> the control point array is whatever the array was preloaded with (in
>> this case 0). So about 35 of the 30000 control points of the mesh are
>> incorrectly positioned, producing ugly spikes in the surface.
>>
>> Changes to other parts of the scene (e.g. adding the debugging code that
>> I used to determine what was going on) cause the errors to appear at
>> different points of the surface.
>>
>> I've so far failed to reproduce the effect in a minimal scene.
>
>Oh, wow. I've seen this exact same behavior recently in my POVCOMP WIP.
>Passing variables by reference (and changing their values within the macro)
>fails *very* occasionally for no apparent reason. Changing the code (even
>just the number of tokens in code that's never actually executed) changes
>the results. I was going to try to find the problem in the POV-Ray source,
>but I'm not familiar enough with that part of the code to do it in a
>reasonable amount of time. And as you said, it's incredibly difficult to
>reproduce the effect on purpose, so I couldn't make a minimal scene to do a
>bug report.

I've now produced a minimal scene. Under 3.5 the macro always returns
with X=1, but under 3.6 it returns with X=123 about one time in a
thousand.

POV 3.6.0.icl8.win32 under Windows 98SE on a Celeron II with 376Mb RAM.


#macro Wave (Xo)
  #declare Xo = 1;
#end

#declare N=0;
#while (N<10000)
  #declare X=123;
  Wave(X)
  #if (X != 1)
    #debug concat("N = ", str(N,0,0), " X = ",str(X,0,0),"\n")
  #end
  #declare N=N+1;
#end


-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

> I've now produced a minimal scene. Under 3.5 the macro always returns
> with X=1, but under 3.6 it returns with X=123 about one time in a
> thousand.

Nice. I didn't think such simple code would actually reproduce it.

The code produces the effect on my machine, running Windows XP, version
3.6.1.icl8.win32.

Anything else necessary to make this a complete bug report? =)

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Mike Williams wrote:
> 
> #macro Wave (Xo)
>   #declare Xo = 1;
> #end
> 
> #declare N=0;
> #while (N<10000)
>   #declare X=123;
>   Wave(X)
>   #if (X != 1)
>     #debug concat("N = ", str(N,0,0), " X = ",str(X,0,0),"\n")
>   #end
>   #declare N=N+1;
> #end

Interesting.  I don't use this kind of construction when coding scenes 
so i never came across this problem (it works without trouble when 
passing array identifiers BTW).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Mike Williams <nos### [at] econymdemoncouk> wrote:
> #macro Wave (Xo)
>   #declare Xo = 1;
> #end
>
> #declare N=0;
> #while (N<10000)
>   #declare X=123;
>   Wave(X)
>   #if (X != 1)
>     #debug concat("N = ", str(N,0,0), " X = ",str(X,0,0),"n")
>   #end
>   #declare N=N+1;
> #end

Hmm same thing here (Linux v.3.6.1 athlon-xp) I get bug's at:
2462,3347,4232,5117,6002,6887,7772,8657,9542 exactly 885 apart - peridic
thing.

Post a reply to this message

In article <41a558b9$1@news.povray.org> , "Slime" <fak### [at] emailaddress> 
wrote:

> just the number of tokens

The cause is an interaction of Parse_RValue's Temp_Count with a turnaround
of token_count in Get_Token.  If you change the last declare in the given
example to "#declare N=N+1-1+1;" you will see that the first such
coincidence occurs at N=72 with a period of 290.  If you break in the reset
of token_count in Get_Token you can follow the cause.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

This will be fixed in POV-Ray 3.6.2.

    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

> The cause is an interaction of Parse_RValue's Temp_Count with a turnaround
> of token_count in Get_Token.  If you change the last declare in the given
> example to "#declare N=N+1-1+1;" you will see that the first such
> coincidence occurs at N=72 with a period of 290.  If you break in the
reset
> of token_count in Get_Token you can follow the cause.

I don't quite follow you, but since you seem to understand the problem, do
you think there is any sort of workaround (aside from never relying on
passing variables by reference)?

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

In article <41a61527@news.povray.org> , "Slime" <fak### [at] emailaddress> wrote:

>> The cause is an interaction of Parse_RValue's Temp_Count with a turnaround of
>> token_count in Get_Token.  If you change the last declare in the given
>> example to "#declare N=N+1-1+1;" you will see that the first such coincidence
>> occurs at N=72 with a period of 290.  If you break in the reset of
>> token_count in Get_Token you can follow the cause.
>
> I don't quite follow you,

The problem is a lesson why today good books on good programming practice
will tell you to define constants once and use them by name rather than by
inserting the constant's value everywhere.  If that practice had been well
established when POV-Ray was initially written (or 3.0 ten years ago for
that matter), this problem could not have occurred.  In Parse_RValue
token_count is compared against two constants (-1 and 1000) inserted by
their value.  As it turns out (the code was never commented) the second
constant there needs to match the same constant in Get_Token...

> but since you seem to understand the problem, do
> you think there is any sort of workaround (aside from never relying on
> passing variables by reference)?

First of all, only references to vectors and scalars will be affected if and
only if a 5000th token parsed happens to be the last token of a macro call
argument list.  If this happens, then POV-Ray decides that the argument is
an expression and not a declared value and passes it by value, not
reference.

Now, anybody who knows what counts as a token and what does not in POV-Ray
can work around this (hint: the documentation tells).  Everybody else should
consider twice if passing by reference is really necessary.  In many cases
it is not at all anyway!  Those who want to do neither will have to wait for
POV-Ray 3.6.2 or use POV-Ray 3.5.  Sorry!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Wasn't it Slime who wrote:
>
>I don't quite follow you, but since you seem to understand the problem, do
>you think there is any sort of workaround (aside from never relying on
>passing variables by reference)?

You could load the variables with values that the macro is unlikely to
return, perform tests after the macro call to see if they're unchanged
and call the macro again. Because the problem occurs at widely separated
intervals, a second call will succeed. You need to think about whether
the macro has any side effects which shouldn't be duplicated.

E.g. in the original Tsutomo Higo scene we could write:

 #declare M = 0; #while (M<3)
   #declare Cp[T][L][M] = 12345;
 #declare M = M+1; #end
 Wave (Cp[T][L][0], Cp[T][L][1], Cp[T][L][2], T+Ncase, L)
 #if (Cp[T][L][0] = 12345 | Cp[T][L][1] = 12345 | Cp[T][L][2] = 12345)
   Wave (Cp[T][L][0], Cp[T][L][1], Cp[T][L][2], T+Ncase, L)
 #end

The Wave() macro doesn't have any side effects and can't ever validly
return the value 12345, so if one of the outputs is still 12345 we call
the macro again.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message