I wonder if this is optimized if functions evaluator:

select(
  x*Ey+y*Ex-R1*Ex,
  select(
    z+3*x.
    x*Ey+y*Ex-R1*Ex,
    123
  ),
 17
)

Note expression "x*Ey+y*Ex-R1*Ex" appear twice. How many times is it
calculated ?

ABX

Post a reply to this message

> Note expression "x*Ey+y*Ex-R1*Ex" appear twice. How many times is it
> calculated ?

Twice. The function compiler cannot optimise common subexpressions and it is
unlikely this feature will be added to it in time for a 3.5 release because
it is very complex and would require another intermediate code
representation layer.  The (current) function compiler has no layer suitable
for general optimisations because it performs similfications and elimination
of constants in the expression tree.  That tree is then turned into function
VM instructions, which is nearly trivial because no complex language
constructs (which would benefit from such further optimisation as well) are
supported by the compiler.

    Thorsten

Post a reply to this message

On Fri, 15 Mar 2002 12:33:16 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> > Note expression "x*Ey+y*Ex-R1*Ex" appear twice. How many times is it
> > calculated ?
>
> Twice. The function compiler cannot optimise common subexpressions and it is
> unlikely this feature will be added to it in time for a 3.5 release because
> it is very complex and would require another intermediate code
> representation layer. 

Then it is feature request for 4.5 since 4 will by much more complex task
around rewriting.

> The (current) function compiler has no layer suitable
> for general optimisations because it performs similfications and elimination
> of constants in the expression tree.  That tree is then turned into function
> VM instructions, which is nearly trivial because no complex language
> constructs (which would benefit from such further optimisation as well) are
> supported by the compiler.

As I remember text output of function parser - there were some kind of float
variables/registers/stack entries. I though that every such float has
dictionary feature (similiar to dictionary used gif coding) where every float
has preprocessed string (without whitespaces) with syntax used to build this
expression. So when new expression is calculated then it is verified with
dictionary and use reference to ready float. But my imagination was probably
far from implementation so forget it.

ABX

Post a reply to this message

Skiba <abx### [at] babilonorg>  wrote:

> As I remember text output of function parser - there were some kind of float
> variables/registers/stack entries. I though that every such float has
> dictionary feature (similiar to dictionary used gif coding) where every float
> has preprocessed string (without whitespaces) with syntax used to build this
> expression. So when new expression is calculated then it is verified with
> dictionary and use reference to ready float. But my imagination was probably
> far from implementation so forget it.

Sadly, it isn't that simple.  The internal representation is a tree so finding
a subexpression would require to compare every possible subtree of the
function with every other possible subtree.  This task gets very complex
quickly.  That is why there is usually an intermediate representation more
suitable for this "kind of pattern matching" in advanced compilers.

    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

> Twice. The function compiler cannot optimise common subexpressions and it
is
> unlikely this feature will be added to it in time for a 3.5 release
because
> it is very complex and would require another intermediate code
> representation layer.  The (current) function compiler has no layer
suitable
> for general optimisations because it performs similfications and
elimination
> of constants in the expression tree.  That tree is then turned into
function
> VM instructions, which is nearly trivial because no complex language
> constructs (which would benefit from such further optimisation as well)
are
> supported by the compiler.

Hmm. I can see how this would be difficult to do automatically, but is there
any chance that 3.5 or a future version could support something where the
user is able to manually select parts of the function that will appear
later? For instance, if I said something like

function{
    f_noise3d(
        x/sqrt(x^2+y^2+z^2),
        y/sqrt(x^2+y^2+z^2),
        z/sqrt(x^2+y^2+z^2)
    )
}

then it has to evaluate that one peice three times. I can plainly see that
this will slow it down. So it would be cool if I could say something like

function{
    f_noise3d(
        x/(remember(1): sqrt(x^2+y^2+z^2)),
        y/(recall:1),
        z/(recall:1)
    )
}

Where the 1 indicates that the remembered item labeled "1" should be
recalled. The syntax I made up here is ugly, but is there any chance of this
functionality appearing in the future?

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

Post a reply to this message

What you want is simple: Support for defining variables inside functions.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

>   What you want is simple: Support for defining variables inside functions.

All we miss then yet is only iteration/recursion inside of these functions, and
they're turing-complete ...

(I know, the language itself is already, but function themselfes are not, are they ?)

Post a reply to this message

Jan Walzer <jan### [at] lzernet> wrote:
> All we miss then yet is only iteration/recursion inside of these functions, and
they're turing-complete ...

  Imagine the mandelbrot pattern defined as a function... Or any other
fractal whatsoever.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

But it would be quite a high risk, to get a stack overflow ...

As I understood, functions are more deeper embedded in POVRay, than macros ...

so there probably would be a need for extra checkings, to make functions, not to block
the whole system ...

Imagine a function that looks up, because of a infinite-loop, that gets computet first
time at 50% of an Image ... (this image
rendered at 2pps) ...

how will you tell, that it's the function, dooing an infinite loop, and not "only the
image with a bit of
media/refraction/any-other-slow-feature" ?

I think it would be _very_ powerful, but it would lead to even more headaches than we
have already ...

I think you all know what I mean ... <looking into p.b-t> ....

Post a reply to this message

Jan Walzer <jan### [at] lzernet> wrote:
> But it would be quite a high risk, to get a stack overflow ...

  It would just give a "max recursion depth limit reached" error. Nothing
fancy.
  Of course this limit should be something usable, eg. at least hundreds or
better some thousands.
  Naturally if some type of iterative loop is implemented, then recursion
will not be needed.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message