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

Tor Olav Kristensen <tor### [at] toberemovedgmailcom> wrote:
> > #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.

  OTOH, how should it behave?

  Macro parameters are passed "by reference". This means that you can
do this:

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

and it will modify the original identifier given as parameter.

  You want #local to not to modify the original identifier. So basically
you want #local to make a local copy of the identifier and modify only that.
But then all kinds of problematic situations may arise, for instance:

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

  Should the #declare modify the local copy or the original identifier?

  More importantly: There are two A's now, the original and the local copy.
Which 'A' should be used in the right-hand-side of the '=' of the #declare,
the local copy or the original variable? If the #local only modifies a copy,
then this "local A" will have a different value than the original identifier.

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

I meant just for POV SDL, passing values by parameter is the
norm in some languages, and passing values around in global
variables is considered bad form in most languages.

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

Yeah, an identifier associates the variable name with a location
in memory which contains a value.  In POV a macro can be
passed an identifier, so that associates the parameter name
with the identifier name and location in memory.

Most programming languages don't have different versions
of variable assignment, the scope of a variable is usually
determined by the location it was created.

Post a reply to this message