"Mark Weyer" <wey### [at] informatikuni-freiburgde> wrote in message
news:3EB### [at] informatikuni-freiburgde...
> > ultimately POV-ray needs something like
> >
> >    #declare F = function(x)
> >    { Cube[int((x-X0)/StepX)]  }
>
> I might get killed for proposing something so inefficient, but:
> (I only treat one-dimensional array, the rest (including optimization
> correction of errors, introduction of interpolation,...) I leave to you)
>
> #declare F = function(x)
> {
>    #local I=1;
>    #while (I<Max)
>
>      select (x-X0-I*StepX, Cube[I-1],
>
>      #local I=I+1;
>    #end
>
>    Cube[Max-1]
>
>    #local I=1;
>    #while (I<Max)
>
>      )
>
>      #local I=I+1:
>    #end
> }

Although it will need about 40 selects in a row, it may be a solution.
I will need probably about 25 of them, so I hope it is not to much
for POV-ray.

Thank you for this possibility!

Jaap Frank

Post a reply to this message

> If you take this literally then this means you can't use arrays inside
functions,
> but I know that you can use them because my interpolation functions are
> full with them, but they all have fixed indices.


What happens there is that, since the indices are fixed, POV-Ray can
evaluate the array index during parse time, and simply puts the respective
value into the function, rather than the array reference itself.

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

Post a reply to this message

You could probably replace the loops with some sort of recursion to give
this an O(log(n)) running time by doing binary search.

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

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote in message
news:9l85bv8ci4arkvhob3qlc99fpcdvfr4b1j@4ax.com...
> On Fri, 2 May 2003 18:46:31 +0200, "Jaap Frank" <jjf### [at] xs4allnl> wrote:
> > I suppose that the modern processors have this possibility too, but that the
> > way the arrays are reached in memory, this is already in use and we need
> > now indirect indirect referencing or something like that to do this.
>
> It seems you have mistaken something. POV-Ray Scene Description Language is not
> low-level language. It does not base on architecture of processor (even if there
> was 'architecture' topic in last POV related image contest :-). The design
> describes what functions can do. AFAIK current design does not include run-time
> operations on arrays just like it does not allow vectors, strings or objects
> there.
>
I know what you mean, but what I meant is that I think that in principal it should
be
possible to do this with the program,  if it takes this possibility into account.
The program should be changed then of coarse. Maybe there are reasons that
forbid this. I have tried to read the C-program, but it is to complex to follow
for me.

Jaap Frank

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3EB2A83A.72DC7B31@gmx.de...
>
> No, functions really don't support arrays.  They just support float
> constants which can be array elements.  This is an important thing to
> understand when working with functions.  Thinking 'it needs to know what
> the indices are at parse time' leads into the wrong direction.
>
> Christoph

Oops, I get answers when I'm typing an answer for another answer...

It was not clear for me what you mean with
   "No, functions really don't support arrays.",
but the answer of  Slime just below this answer of you made it clear
to me.
What I need should be a special function that can reach an array
during render time and the 'function system' of POV-ray don't have this
possibility at the moment. Is this by the way very difficult to implement?

Jaap Frank

Post a reply to this message

"Slime" <slm### [at] slimelandcom> wrote in message news:3eb2b047$1@news.povray.org...
> > If you take this literally then this means you can't use arrays inside
> functions,
> > but I know that you can use them because my interpolation functions are
> > full with them, but they all have fixed indices.
>
>
> What happens there is that, since the indices are fixed, POV-Ray can
> evaluate the array index during parse time, and simply puts the respective
> value into the function, rather than the array reference itself.

Thank you for this explanation, for I now understand the answer of Chris
about 'not supporting arrays'.

Jaap Frank

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote in message
news:plu4bv0oq60qq73fv6d6fj75gbbidtvh4d@4ax.com...
> On Fri, 02 May 2003 15:51:59 +0200, Mark Weyer
> <wey### [at] informatikuni-freiburgde> wrote:
> > I might get killed for proposing something so inefficient
>
> Inefficent indeed. First of all there is a limited number of tokens to be used
> in one function. You can split function into subfunctions but number of
> constants used in functions is also limited in whole scene.

From the manual:
  The maximum number of function blocks per scene is 1048575.
  The maximum number of operators per function is about 200000. Individual limits
    will be different depending on the types of operators used in the function.
  The maximum depth for nesting functions is 1024.
  The maximum number of constants in all functions 1048575.

Although I will need lots of functions to complete my project, I doubt that I will
reach these limits. Maybe I can get into problems with the depth of nesting.

Jaap Frank

Post a reply to this message

"Slime" <slm### [at] slimelandcom> wrote in message news:3eb2b0ec$1@news.povray.org...
> You could probably replace the loops with some sort of recursion to give
> this an O(log(n)) running time by doing binary search.
>
>  - Slime
> [ http://www.slimeland.com/ ]
>
Do you mean that it's possible to do recursion with functions?
I've never thought about that. That's interesting.
You can then use only a couple of functions with a select in it.
I must try that!

Jaap Frank

Post a reply to this message

> Do you mean that it's possible to do recursion with functions?
> I've never thought about that. That's interesting.
> You can then use only a couple of functions with a select in it.
> I must try that!


Yes, but I was referring to recursion with SDL macros, since in the end you
can't mix array indices and function variables anyway.

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

Post a reply to this message

"Jaap Frank" <jjf### [at] xs4allnl> wrote in message news:3eb2b001$1@news.povray.org...
>
> I will need probably about 25 of them, so I hope it is not to much
> for POV-ray.
>
Correction: I will need about 40 * 40 of them!  It's a 3D Cube.
ABX is probably right. This may become to much after all.

Jaap Frank

Post a reply to this message