Hello. First of all, i serched with google on this site without seeing 
any mention to my problem. So, apologies if i am repeating.

I have something wrong in the following code, but i cannot see it. It 
pretends to be a minimun sample, and its only purpose is to show the 
problem. It occurs in a bigger file that i'm working on. At first, i 
tried to isolate the error there, but it was impossible to me (i am not 
a programmer :). Finally i could find what seems to be wrong.

//pov version: 3.6.1c.icl8.win32
//-------------------------------------------------------------
default{ pigment{rgb <1,1,0>} }

//this is ok, for control purposes
#macro Wave_Ctrl(N,Fr,A,Fs,L)
   #local C=0;
   #while(C < N)
     sphere{z*L*C/N+y*A*sin(2*pi*Fr*C/N+Fs) 0.05 pigment{red 1}}
     #local C= C+1;
   #end
#end
//Here starts the problem
//let's say i need some macros with parameters passed both, per value 
//and reference
#macro WavePt(pZ,pY)
   DoCalc(pZ,pY,cC,+cN) sphere{z*pZ+y*pY 0.05 }
#end

#macro DoCalc(pZ,pY,I,N) //function arbitrarily choosen
   #local pY= y*cA*sin(2*pi*cFr*I/N+cFs);
   #local pZ= z*L*I/N;
#end
//
#macro WrongWave(cN,Fr,A,Fs,L)
   #local cA= A; #local cFr= Fr; #local cFs= Fs;
   #local cC=0; #local pY=0*y; #local pZ=0*z;
   #while(cC < cN) WavePt(pY,pZ) #local cC= cC+1; #end
#end

#declare cN= 500;
#declare Freq= 5; #declare Amp= 0.5; #declare Phase=0; #declare L=10;

//#debug "doesn't matter what\n" //(1)
#declare Ctrl= no;
#local I=0; #local T= 50; #local cRt= 360/T;
#while(I < T)
   union{
     #if(!Ctrl)
       WrongWave(cN,Freq,Amp,Phase,L)
     #else
       Wave_Ctrl(cN,Freq,Amp,Phase,L)
     #end
     rotate y*cRt*I
   }
   #local I=I+1;
#end

The problem: while in the Wave_Ctrl() macro all the spheres are placed 
correctly, in the WrongWave() one, that it's supposed to do the same, 
some spheres are out of place. At first i thought in a rounding error, 
but as i never have faced one, i don't know what it looks like :/.

But if it is a rounding error, why Wave_Ctrl is rendering properly? and 
Why typing a debug line affects the resulting image (with WrongWave())? 
Uncomment the line (1) and probably the wrong placed spheres will 
change. Anyway, here i am not adding  or performing further operations 
with the resulting calculations, the counter is integer...

Maybe the sample seems a bit silly, but this problem ruins a scene where 
the objects has been calculated previously in size and position.

Thank you very much in advance

Martin

Post a reply to this message

Martin wrote:
...
> #macro DoCalc(pZ,pY,I,N) //function arbitrarily choosen
>   #local pY= y*cA*sin(2*pi*cFr*I/N+cFs);
>   #local pZ= z*L*I/N;
> #end
...

Note that this macro should (AFAIK) have no effect in any scene.

If it has, then that might be a bug in the POV-Ray version you
are using.

(You are just setting 2 local variables that are "lost" right
afterwards when the macro is exited.)

-- 
Tor Olav
http://subcube.com

Post a reply to this message

>> #macro DoCalc(pZ,pY,I,N) //function arbitrarily choosen
>>   #local pY= y*cA*sin(2*pi*cFr*I/N+cFs);
>>   #local pZ= z*L*I/N;
>> #end
> ...
>
> Note that this macro should (AFAIK) have no effect in any scene.
>
> If it has, then that might be a bug in the POV-Ray version you
> are using.
>
> (You are just setting 2 local variables that are "lost" right
> afterwards when the macro is exited.)

That isn't exactly right, pY and pZ are being returned by
parameter.

Unfortunately in 3.6 passing values by parameter is buggy,
it's fixed in the 3.7 beta, but in general you probably shouldn't
rely on values being returned correctly via parameter.

Typically you can either globally #declare a value to return,
or return a value by subsitution like this...

#macro DoCalcY(pZ,pY,I,N)
   #local result = y*cA*sin(2*pi*cFr*I/N+cFs);
   (result)
#end

#macro DoCalcZ(pZ,pY,I,N)
   #local result = z*L*I/N;
   (result)
#end

And call the calculations...

#local pY = DoCalcY(pZ,pY,I,N);
#local pZ = DoCalcZ(pZ,pY,I,N);

Post a reply to this message

Tim Attwood wrote:
>>> #macro DoCalc(pZ,pY,I,N) //function arbitrarily choosen
>>>   #local pY= y*cA*sin(2*pi*cFr*I/N+cFs);
>>>   #local pZ= z*L*I/N;
>>> #end
>> ...
>>
>> Note that this macro should (AFAIK) have no effect in any scene.
>>
>> If it has, then that might be a bug in the POV-Ray version you
>> are using.
>>
>> (You are just setting 2 local variables that are "lost" right
>> afterwards when the macro is exited.)
> 
> That isn't exactly right, pY and pZ are being returned by
> parameter.

How can it be wrong when his macro is not returning anything ?
(Note that he is using #local instead of #declare.)

I have re-read these to sections of the documentation;

   "2.2.2.2 The #declare and #local Directives"
   "2.2.2.8 User Defined Macros"

- without finding anything that about changing contents of
passed parameters within macros by using #local.

The 2 manual sections:

   http://www.povray.org/documentation/view/3.6.1/237/
   http://www.povray.org/documentation/view/3.6.1/243/

> Unfortunately in 3.6 passing values by parameter is buggy,
> it's fixed in the 3.7 beta, but in general you probably shouldn't
> rely on values being returned correctly via parameter.
...

Yes I know. Sometimes I have to use v3.5 to render my code.
(But I have never been able to make a simple scene file that
clearly demonstrates the problem.)

-- 
Tor Olav
http://subcube.com

Post a reply to this message

> How can it be wrong when his macro is not returning anything ?
> (Note that he is using #local instead of #declare.)

2.2.2.8.5 explains it a bit, if an identifier is passed to a
macro then that identifier is in scope and #local will
modify that identifier's value.

The return-by-parameter bug is more apparent in loops,
sometimes the modified value of a parameter isn't returned,
but that's less than 1% of the time, and it's fixed in 3.7 :-)

Try this test code to convince yourself that #local in
a macro can modify a parameter value.

#macro TEST(A)
   #local A = A + 1;
#end

#declare B = 1;

TEST(B)

text { // the answer is 2
   ttf "timrom.ttf",
   concat("B = ", str(B,0,0)), 0.1,0
   pigment {rgb <0,1,0>}
   finish {ambient 1}
   translate <-1,-0.2,2>
}

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> text { // the answer is 2
>    ttf "timrom.ttf",
>    concat("B = ", str(B,0,0)), 0.1,0
>    pigment {rgb <0,1,0>}
>    finish {ambient 1}
>    translate <-1,-0.2,2>
> }

  Wouldn't usually #debug be used for that? Easier.

-- 
                                                          - Warp

Post a reply to this message

> Unfortunately in 3.6 passing values by parameter is buggy,
> it's fixed in the 3.7 beta, but in general you probably shouldn't
> rely on values being returned correctly via parameter.
> 
Just for curiosity sake, do you mean in general programming, or only in 
SDL (and why)?

At the end, i read that a parameter (in programming) is just a variable 
stored in the stack (and recovered later).

Post a reply to this message

>> Unfortunately in 3.6 passing values by parameter is buggy,
>> it's fixed in the 3.7 beta, but in general you probably shouldn't
>> rely on values being returned correctly via parameter.
>>
> Just for curiosity sake, do you mean in general programming, or only in 
> SDL (and why)?
> 
> At the end, i read that a parameter (in programming) is just a variable 
> stored in the stack (and recovered later).

That depends on the programming language. In C, you'd have to pass a 
pointer.

void change_param(int* foo) {
     *foo=42;
}
...
int bar = 1;
change_param(&bar);

Post a reply to this message

Warp wrote:
> Tim Attwood <tim### [at] comcastnet> wrote:
>> text { // the answer is 2
>>    ttf "timrom.ttf",
>>    concat("B = ", str(B,0,0)), 0.1,0
>>    pigment {rgb <0,1,0>}
>>    finish {ambient 1}
>>    translate <-1,-0.2,2>
>> }
> 
>   Wouldn't usually #debug be used for that? Easier.

That wouldn't be *shiny*!

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Tim Attwood wrote:
>> How can it be wrong when his macro is not returning anything ?
>> (Note that he is using #local instead of #declare.)
> 
> 2.2.2.8.5 explains it a bit, if an identifier is passed to a
> macro then that identifier is in scope and #local will
> modify that identifier's value.
> 
> The return-by-parameter bug is more apparent in loops,
> sometimes the modified value of a parameter isn't returned,
> but that's less than 1% of the time, and it's fixed in 3.7 :-)
> 
> Try this test code to convince yourself that #local in
> a macro can modify a parameter value.
> 
> #macro TEST(A)
>    #local A = A + 1;
> #end
> 
> #declare B = 1;
> 
> TEST(B)
...

Your code above may work, but was it meant to work that way ?
I.e. Is the behaviour above a bug - or is it a feature ?
:)

To me it is illogical that a #local statement should be
able to change _anything_ outside its scope.

Do you have any references to documentation, discussions
(or source code) that _clearly_ shows that one may use a
#local assignment to return a value by a parameter passed
to a macro ?

Section 2.2.2.8.5 in the manual shows #declare used to
change a given parameter in a macro.

-- 
Tor Olav
http://subcube.com

Post a reply to this message