As we can't use arrays inside functions I tried something else. A spline 
is an array, kind of and works in functions. So some test code, that 
works. There's one little thing I don't realy understand. I have to undef 
the 'i' used in SPL or rename it or the one in N. Otherwise I get: 

line xxx: Parse Error: Local variable name expected!

---%<------%<------%<---
#declare arrSPL = array[5]{
  <0,0>,
  <1,0>,
  <2,0>,
  <3,0>,
  <4,0>
}  
  
#declare SPL = spline{
  #for(i,0,dimension_size(arrSPL,1)-1)
    i, arrSPL[i],
  #end
}
#debug concat(str(SPL(4).x,5,5),"\n")
#undef arrSPL
#undef i      // <--------- !!

#declare Ar = function{
  spline{SPL}
}
#debug concat(str(Ar(4).x,5,5),"\n")
#undef SPL

#declare N = function(D){sum(i, 0, D, Ar(i).x)};
#declare NAR = N(4);
#debug concat(str(NAR,5,5),"\n")
---%<------%<------%<---

Ingo

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:
There's one little thing I don't realy understand. I have to undef
> the 'i' used in SPL or rename it or the one in N. Otherwise I get:
>
> line xxx: Parse Error: Local variable name expected!

Is it because you are essentially declaring an identifier for a scalar, and the
sum function wants to use a "function variable identifier", but there is a name
clash?

> ---%<------%<------%<---

These are very cool ASCII scissors   :D


I did a fair amount of work using a spline and another similar method to
implement Jerome's Pythagorean tiling in the source code as a function in SDL.
It was challenging, but I learned a lot and came up with something "new"  :)

Post a reply to this message

On 2021-04-14 1:50 PM (-4), ingo wrote:
> As we can't use arrays inside functions I tried something else. A spline 
> is an array, kind of and works in functions. So some test code, that 
> works. There's one little thing I don't realy understand. I have to undef 
> the 'i' used in SPL or rename it or the one in N. Otherwise I get: 
> 
> line xxx: Parse Error: Local variable name expected!
> 
> ---%<------%<------%<---
> #declare arrSPL = array[5]{
>   <0,0>,
>   <1,0>,
>   <2,0>,
>   <3,0>,
>   <4,0>
> }  
>   
> #declare SPL = spline{
>   #for(i,0,dimension_size(arrSPL,1)-1)
>     i, arrSPL[i],
>   #end
> }
> #debug concat(str(SPL(4).x,5,5),"\n")
> #undef arrSPL
> #undef i      // <--------- !!
> 
> #declare Ar = function{
>   spline{SPL}
> }
> #debug concat(str(Ar(4).x,5,5),"\n")
> #undef SPL
> 
> #declare N = function(D){sum(i, 0, D, Ar(i).x)};
> #declare NAR = N(4);
> #debug concat(str(NAR,5,5),"\n")
> ---%<------%<------%<---

You've just been burned by POV-Ray's scope leakage, a design flaw IMO.
It has nothing to do with you having used i to define the spline.  *Any*
identifier name local to a function definition will fail if the name had
been previously used--even if it was declared in an include file that
you did not write.  You will also get a parse error if you #declare D at
the top of your scene file.

I make it a practice never to use a name in a function that is used
elsewhere in the scene.  Since this means avoiding names declared in
include files written by other people, I have to get creative with
identifier names.

Note that you did not need to #undef arrSPL or SPL.  The scene runs fine
without those 2 #undefs.

Post a reply to this message

in news:607769cc@news.povray.org Cousin Ricky wrote:

> 
> You've just been burned by POV-Ray's scope leakage, [...]  You will also 
get a parse
> error if you #declare D at the top of your scene file.

Ah. The #declare D is one I've encoutered often and a reason for me to put 
functions in include files as much as possible.

I am aware that the first i lives on after the end of the for loop. It can 
be usefull to do some trickery with.

> I make it a practice never to use a name in a function that is used
> elsewhere in the scene.  [...]

Pseudo namespace are usefull. For many include files I prepend everything 
with the same few letters once they turn into something final. Like arrSPL 
lives in my personal "arr.inc". I saw jr. does the same with fore_ and qq

> Note that you did not need to #undef arrSPL or SPL.  The scene runs
> fine without those 2 #undefs.
> 

I know. In test scenes I keep "stuff" around so I don't forget what I did.

Thanks,

Ingo

Post a reply to this message

in news:web.6077665a848889811f9dae3025979125@news.povray.org Bald Eagle 
wrote:

>> ---%<------%<------%<---
> 
> These are very cool ASCII scissors   :D
> 

usenet habits from the days of old :)

Ingo

Post a reply to this message

Op 15/04/2021 om 00:02 schreef Bald Eagle:
> ingo <ing### [at] tagpovrayorg> wrote:
>> ---%<------%<------%<---
> 
> These are very cool ASCII scissors   :D
> 

or an angry emoticon:  %<   %-<   /%-<   >%-<

-- 
Thomas

Post a reply to this message

On 15.04.2021 00:16, Cousin Ricky wrote:
 > You've just been burned by POV-Ray's scope leakage, a design flaw IMO.

It isn't a design flaw as the declare is a preprocessor directive, so it 
all happens at well defined times during parsing and there are no leaks 
of variables. It is common to languages with preprocessors, in 
particular C/C++. I agree that it is annoying though.

Thorsten

Post a reply to this message

On 2021-04-15 1:59 AM (-4), ingo wrote:
> 
> Pseudo namespace are usefull. For many include files I prepend everything 
> with the same few letters once they turn into something final. Like arrSPL 
> lives in my personal "arr.inc". I saw jr. does the same with fore_ and qq

This is a good idea with languages that have no namespace operator, such
as POV-Ray SDL.  It is a requirement for compliance level 3 for include
files in the Object Collection, and I've made that a practice in all of
my include files.

Post a reply to this message