Hallo,

I have a problem concerning the use of array indices inside
a function.
Let me explain what I'm trying to do and what the problem is:

I have a 3D-grid with density values in a 3D-array called
Cube and must use this as density inside a media statement.
Beside a interpolation between these grid points,
ultimately POV-ray needs something like

   #declare F_DensPoint = function(x,y,z)
   { Cube[int((x-X0)/StepX)]
         [int((y-Y0)/StepY)]
         [int((z-Z0)/StepZ)] }

   (X0,Y0,Z0 is the origin of the density grid and
    StepX, StepY and StepZ are the grid distances)

to get values from the 3D-array.
If you use this function you get the error massage:
'Float expected but vector or color expression found'

This has clearly something to do with the array indices
control of the parser, because

  #declare F_Ix = function(x,y,z)
  { int((x-X0)/StepX) }

does NOT give an error message and returns a float and not a
vector.
I thought I found a workaround with

  #declare F_Ix = function(x,y,z){ int((x - X0)/StepX) }
  #declare F_Iy = function(x,y,z){ int((y - Y0)/StepY) }
  #declare F_Iz = function(x,y,z){ int((z - Z0)/StepZ) }

  #declare F_Cube =
  function(x,y,z,NX,NY,NZ) { Cube[NX][NY][NZ] }
  #declare F_DensPoint = function(x,y,z)
  { F_Cube(x,y,z, F_Ix(x,y,z), F_Iy(x,y,z), F_Iz(x,y,z)) }

but this gives the error message

'Expected 'numeric expression', undeclared identifier 'NX'
found instead'.

*#@!@^& .. the parser doesn't accept function parameters
as array indices!

I've tried several other possibilities, but that doesn't
work because you have to pass over x,y,z somewhere and the
parser stops when it finds this vector. You can use
functions as indices, but they may not contain x,y,z in the
parameter section and that is essential to find the correct
indices in the array.

My question is:
  Is there a way to circumvent this problem
  or if not
  is it possible to raise one of the blockages of the parser.

I've been working for months to develop interpolation
functions with matrices and they work perfectly, but now I
stumble over a not expected problem that blocks everything.

...help please...

Jaap Frank

Post a reply to this message

Jaap Frank wrote:
> 
> [...]
> 
> My question is:
>   Is there a way to circumvent this problem

No, arrays are a parse time language element in POV-Ray and can not be
used in (render time) user defined functions.  This is a very common
misunderstanding about user defined functions.  Although they look similar
in syntax to the normal script they are completely different.  An 'sqrt()'
in a function for example has nothing to do with an 'sqrt()' elsewhere in
SDL.

Christoph

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

Post a reply to this message

On Fri, 2 May 2003 14:15:13 +0200, "Jaap Frank" <jjf### [at] xs4allnl> wrote:
> I have a 3D-grid with density values in a 3D-array called
> Cube and must use this as density inside a media statement.

I assume using density file format is not possible in your case ?
Perhaps maps are the solution you are looking for. I mean array:

#local A=array[2][2];
#local A[0][0]=0;
#local A[0][1]=.1;
#local A[1][0]=.2;
#local A[1][1]=.3;

can be expressed as

#local C=array[2];
#local C[0]=pigment{
  gradient y
  pigment_map{
    [0 color rgb A[0][0]]
    [1 color rgb A[0][1]]
  }
}
#local C[1]=pigment{
  gradient y
  pigment_map{
    [0 color rgb A[1][0]]
    [1 color rgb A[1][1]]
  }
}
#local P=pigment{
  gradient x
  pigment_map{
    [0 C[0]]
    [1 C[0]]
  }
}

and then
A[0,0]=P(0,0,0)
A[0,1]=P(0,1,0)
A[1,0]=P(1,0,0)
A[1,1]=P(1,1,0)

Of course this can be easy extended into 3 dimensions and coded with smart loops
but I would leave it for you because you are using 'advanced' group for post :-)

AVX

Post a reply to this message

On Fri, 02 May 2003 14:42:08 +0200, ABX <abx### [at] abxartpl> wrote:
>    [0 C[0]]
>    [1 C[0]]

   [0 C[0]]
   [1 C[1]]

ABX

Post a reply to this message

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

-- 
merge{#local i=-11;#while(i<11)#local
i=i+.1;sphere{<i*(i*i*(.05-i*i*(4e-7*i*i+3e-4))-3)10*sin(i)30>.5}#end
pigment{rgbt 1}interior{media{emission x}}hollow}//  Mark Weyer

Post a reply to this message

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. Maps are also
limited in size IIRC, but their number in scenes is not so limited I think.
Moreover evaluation of function even if done with JIT compiler seems not as fast
as precompiled code of map evaluation. But measurement and comparison could be
interesting and (who knows?) perhaps surprised.

ABX

Post a reply to this message

> Jaap Frank wrote:
> >   Is there a way to circumvent this problem
>
> No, arrays are a parse time language element in POV-Ray and can not be
> used in (render time) user defined functions.  This is a very common
> misunderstanding about user defined functions.  Although they look similar
> in syntax to the normal script they are completely different.  An 'sqrt()'
> in a function for example has nothing to do with an 'sqrt()' elsewhere in
> SDL.

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.
I suppose you mean that POV-ray needs to know what the array indices are
at parse time and that it is not possible to fill in the correct indices on the
fly
during rendering.

I remember -it was in the seventies that I coded in machine language on a
Z80 processor (I know it's ancient, but I doubt that the principal is changed)
- that this can be done on the fly using indirect referencing a variable where
the indirect address gives the offset in the variable field. Maybe this was a
speciality of this processor, because I've heard that the famous 8086
processor that came later was not so advanced compared to this processor.
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.

But never the less, thanks for your reaction,

Jaap Frank

Post a reply to this message

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.

ABX

Post a reply to this message

Jaap Frank wrote:
> 
> 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.
> I suppose you mean that POV-ray needs to know what the array indices are
> at parse time and that it is not possible to fill in the correct indices on the
> fly
> during rendering.

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

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

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote in message
news:v1p4bvcfgdeb7a2jvf79p7k1b2e9vkv9nr@4ax.com...
> I assume using density file format is not possible in your case ?
> Perhaps maps are the solution you are looking for. I mean array:
>
> #local A=array[2][2];
> #local A[0][0]=0;
> #local A[0][1]=.1;
> #local A[1][0]=.2;
> #local A[1][1]=.3;
>
> can be expressed as
>
> #local C=array[2];
> #local C[0]=pigment{
>   gradient y
>   pigment_map{
>     [0 color rgb A[0][0]]
>     [1 color rgb A[0][1]]
>   }
> }
> #local C[1]=pigment{
>   gradient y
>   pigment_map{
>     [0 color rgb A[1][0]]
>     [1 color rgb A[1][1]]
>   }
> }
> #local P=pigment{
>   gradient x
>   pigment_map{
>     [0 C[0]]
>     [1 C[0]]
>   }
> }
>
> and then
> A[0,0]=P(0,0,0)
> A[0,1]=P(0,1,0)
> A[1,0]=P(1,0,0)
> A[1,1]=P(1,1,0)
>
> Of course this can be easy extended into 3 dimensions and coded with smart loops
> but I would leave it for you because you are using 'advanced' group for post :-)

I always have some difficulty with understanding someone elses code, but I
think this is a way to interpolate between the grid points.
If this is what you mean with this code, then that is not my problem, because I
have a solution for that already.
Your code gives a linear interpolation, but I need a interpolation using
A0 + A1*x + A2*x^2 + A3*x^3 + A4*x^4 + ... = y
for the densities in the array vary a lot because these are the electron
densities around tens of atoms inside a molecule. (The density values vary
from 1.0*10^-20 to 1 within a few grid points)
I've developed functions that uses matrix calculation in order to solve
a N unknowns in N equations problem for me and they work fine.
You can choose the power of the polynomal as high as you wish ( or
as much patient as you have, because the parse time of the functions
grow with N-factorial, but power N=4 needs about a second).
My problem is that only during the rendering the indices for the various
grid points are known and POV-ray don't accept that.

Further the dimensions of the arrays (I've about ten different molecules)
are in the order of  40 by 40 by 40 grid points.
If you mean that it is possible to expend your solution to 40 points inside
these maps, then I've to accept a linear interpolation, for my solution
obviously can't be used. I will try this.

Thanks for your reaction,

Jaap Frank

Post a reply to this message

"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

ABX <abx### [at] abxartpl> wrote in
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.
> Maps are also limited in size IIRC, but their number in scenes is not
> so limited I think. Moreover evaluation of function even if done with
> JIT compiler seems not as fast as precompiled code of map evaluation.
> But measurement and comparison could be interesting and (who knows?)
> perhaps surprised. 


I have not done the test you describe here, but I
have done another related test.

A couple of months ago I made the macro below just
to test if evaluation of such an "array" function
could be faster than the look-up of a array item
in "ordinary" arrays.

IIRC the evaluation at parse time of this macro
generated function was actually slower  =(

On my todo list was also to test if "abuse" of
spline functions will give any speed increase.
(I.e. storing points in them and only pass para-
meter values to the functions that will
reference those points directly.)


Tor Olav


#macro Coord2DFunction(Points, v0)

  #local SizeU = dimension_size(Points, 1);
  #local SizeV = dimension_size(Points, 2);

  function(u, v) {
    #local U = 0;
    #while (U < SizeU)
      #local V = 0;
      #while (V < SizeV)
        #local Value = vdot(Points[U][V], v0);
        +select(u - U, 0, 1, 0)*select(v - V, 0, 1, 0)*Value
        #local V = V + 1;
      #end // while
      #local U = U + 1;
    #end // while
  }

#end // macro Coord2DFunction


Example usage:

#declare SomePoints =
  array[5][4] {
    { < 0,  0,  2>, < 1, 0,  0>, < 2,  0,  1>, < 3,  0,  2> },
    { < 0,  1, -2>, < 1, 1, -2>, < 2,  1, -4>, < 3,  1, -4> },
    { < 0,  2,  1>, < 1, 2, -3>, < 2,  2, -1>, < 3,  2,  4> },
    { < 0,  3,  0>, < 1, 3,  0>, < 2,  3,  0>, < 3,  3, -4> },
    { < 0,  4, -3>, < 1, 4,  3>, < 2,  4, -3>, < 3,  4, -2> }
  }

#declare xFn = Coord2DFunction(SomePoints, x)
#declare yFn = Coord2DFunction(SomePoints, y)
#declare zFn = Coord2DFunction(SomePoints, z)

sphere { <xFn(2, 3), yFn(2, 3), zFn(2, 3)>, 0.1 }


This should give the same result as:

sphere { SomePoints[2][3], 0.1 }

or:

sphere { <3, 2, 4>, 0.1 }

Post a reply to this message

In article <3eb2b23c@news.povray.org> , "Jaap Frank" <jjf### [at] xs4allnl> wrote:

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

No, because the arrays only exist during parse time, while functions persist
until the end of the render.  Of course it can be done with various hacks
and changes or a million other ways, but that is not the point of anybody
here:  The point is that it is not implemented for reasons that have nothing
to do with the practical inability to implement it, which seems to be what
you keep thinking is the problem.

    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

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3eb67edc@news.povray.org...
> In article <3eb2b23c@news.povray.org> , "Jaap Frank" <jjf### [at] xs4allnl> wrote:
>
> No, because the arrays only exist during parse time, while functions persist
> until the end of the render.  Of course it can be done with various hacks
> and changes or a million other ways, but that is not the point of anybody
> here:  The point is that it is not implemented for reasons that have nothing
> to do with the practical inability to implement it, which seems to be what
> you keep thinking is the problem.

No offence Thorsten, but there are things that may be obviously for you or
the other programmers, but were not for me. I couldn't know that during the
render the array references are gone. If you think that the array references
are still there, then it seems not too difficult to reach them during rendering.
I suppose that one of the reasons is, is to free up memory for other tasks.

Because I need a high order interpolation and I don't want to throw away
months of work, I've decided to build a binary tree of function that contain
all the array values. I estimate that it will come to around 40 thousand
rather small functions.

Because of this discussion I've a couple of questions and a thought:

1. If a function(x,y,z) {} is used for a media inside a media_container,
   are the x,y and z then relative to the container or absolute in the scene?
   I have the impression that they are relative to the container that you
   declare. Is that correct? I can't find any hint about this in the manual.

2. If you 'undefine' a function or variable, is the memory then available
   for new functions or variables. (This could be handy if you reach your
   memory limit.) I suppose it is, but is it?

3. If more people would like to have arrays inside functions, then I've
   thought about the following function:

            function(index) { choose(index, item, [[item], ..] ) }

  with:   item = float | function
            index = which one do you want of this row
  If functions are allowed, then more dimensional arrays are possible.

   I hope that this can be made with the function building system of
   POV-ray. If so, I hope that someone is willing to implement this.
   I can't do it myself.

Thank you for your explanation. I've learned something new again.

Jaap Frank

Post a reply to this message

In article <3eb6acc2$1@news.povray.org> , "Jaap Frank" <jjf### [at] xs4allnl> 
wrote:

> No offence Thorsten, but there are things that may be obviously for you or
> the other programmers, but were not for me. I couldn't know that during the
> render the array references are gone. If you think that the array references
> are still there, then it seems not too difficult to reach them during
rendering.
> I suppose that one of the reasons is, is to free up memory for other tasks.

Well, that is not the problem I had with your direction.  The problem is
that you first made an observation that something didn't work as you
expected.  So you asked.  You got several answers.  Without any obvious
reason you then jumped to conclusions about some low level details that
where not even mentioned or suggested to exist by anybody.  This in turn
resulted in a long discussion about, well, nothing.  This doesn't really
help in finding out what you really want or need, which would be essential
to help you.  So, after reading this long thread, I still don't know what
you want to do, but only what conclusions you jumped to that are either
absolutely random or you simply didn't think before writing.  I find that
rather annoying in an advanced users group ;-)

Anyway, enough of that and back to the point:

> 1. If a function(x,y,z) {} is used for a media inside a media_container,
>    are the x,y and z then relative to the container or absolute in the scene?
>    I have the impression that they are relative to the container that you
>    declare. Is that correct? I can't find any hint about this in the manual.

Of course.  It wouldn't make any sense otherwise because it would make
applying existing transformations to patterns impossible, wouldn't it?

> 2. If you 'undefine' a function or variable, is the memory then available
>    for new functions or variables. (This could be handy if you reach your
>    memory limit.) I suppose it is, but is it?

Of course.  Just like with any other thing you undefine.  Nevertheless, if
you use the function anywhere, it has to be kept in memory even if you
undefine it for obvious reasons.

> 3. If more people would like to have arrays inside functions, then I've
>    thought about the following function:

The problem with array is not about a syntax.  It it simply that arrays are
a parse-time structure nobody ever anticipated a need for to stay around
after parsing prior to 3.5.  So it is simply a feature request, not
something about finding a good syntax for accessing arrays or any other
problem.

>    I hope that this can be made with the function building system of
>    POV-ray. If so, I hope that someone is willing to implement this.
>    I can't do it myself.

It is not about willing to implement it.  It is about doing so being
pointless in POV-Ray 3.5 as it is too much work to be worthwhile.

    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

In article <3eb6acc2$1@news.povray.org> , "Jaap Frank" <jjf### [at] xs4allnl> 
wrote:

> Because I need a high order interpolation and I don't want to throw away
> months of work, I've decided to build a binary tree of function that contain
> all the array values. I estimate that it will come to around 40 thousand
> rather small functions.

Write the numbers to a PPM image.  Use multiple pixels, i.e. four pixels to
store numbers.  Then write a single function to build a number out of it
from a pattern.  Load the image as pattern and apply the function.  Now you
have an array, and it will be really fast and consume very little memory!

    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

Thorsten Froehlich wrote:
> 
> > Because I need a high order interpolation and I don't want to throw away
> > months of work, I've decided to build a binary tree of function that contain
> > all the array values. I estimate that it will come to around 40 thousand
> > rather small functions.
> 
> Write the numbers to a PPM image.  Use multiple pixels, i.e. four pixels to
> store numbers.  Then write a single function to build a number out of it
> from a pattern.  Load the image as pattern and apply the function.  Now you
> have an array, and it will be really fast and consume very little memory!

Since the whole thing seems to be about 3D arrays it will probably be more
convenient to use df3 density files.  I know - they are binary in official
POV but Ryoichi Suzuki's density_file extension patch adds support for
ascii files:

http://staff.aist.go.jp/r-suzuki/e/povray/iso/df_body.htm

Christoph

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

Post a reply to this message

In article <3EB6BBC7.9F35BA4A@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Since the whole thing seems to be about 3D arrays it will probably be more
> convenient to use df3 density files.

Why?  A one dimensional array is used to represent arrays of any dimension
in every computer system anyway.

    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

Thorsten Froehlich wrote:
> 
> > Since the whole thing seems to be about 3D arrays it will probably be more
> > convenient to use df3 density files.
> 
> Why?  A one dimensional array is used to represent arrays of any dimension
> in every computer system anyway.

Well, you see it from the theoretical point of view, i from the practical
side... :-)

Christoph

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

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3eb6b345@news.povray.org...
> In article <3eb6acc2$1@news.povray.org> , "Jaap Frank" <jjf### [at] xs4allnl>
> wrote:
>
> > Because I need a high order interpolation and I don't want to throw away
> > months of work, I've decided to build a binary tree of function that contain
> > all the array values. I estimate that it will come to around 40 thousand
> > rather small functions.
>
> Write the numbers to a PPM image.  Use multiple pixels, i.e. four pixels to
> store numbers.   Then write a single function to build a number out of it
> from a pattern.

This is the best solution I've got! Thanks a lot Thorsten.

>  Load the image as pattern and apply the function.  Now you
> have an array, and it will be really fast and consume very little memory!
>
 I only have to figure out how to do this. I don't see it at the moment, but I
don't give up easily.

Jaap Frank

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3EB6C119.CDCD35AA@gmx.de...
>
>
> Thorsten Froehlich wrote:
> >
> > > Since the whole thing seems to be about 3D arrays it will probably be more
> > > convenient to use df3 density files.
> >
> > Why?  A one dimensional array is used to represent arrays of any dimension
> > in every computer system anyway.
>
> Well, you see it from the theoretical point of view, i from the practical
> side... :-)
>
> Christoph

This seems a good solution too Christoph. I've downloaded the patch and give it a
try.
Tri-cubic may be enough for the interpolation. I can always fall back at Thorstens
solution, although I've to figure out how to extract one value out off a
PPM-image.

Thanks for this solution!

Jaap Frank

Post a reply to this message