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