In article <3a092503@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> unfortunately i still have 2049 in p.p and 21988 in p.g to read :-(
> but only 6977 in p.b.i :-)

You are reading all the messages in the groups? Whew...


> but this small change could make 3.5 much faster in such use

It could, but POV 3.5 is feature-frozen now, so this improvement most 
likely won't make it in.


> at parse time?
> could you describe me how do you think you can racognize at parse
> that there was previous calling in subfunction?

No need to recognize previous calling, just make a table of the 
different function calls. When you add an entry, just make sure there 
isn't already one like it.


> yes it is possible but more complicated
> see:
> 
> R=function{"R"}
> func1=function{R*(R-1)}
> func2=function{func1*(func1-1)}
> func3=function{func2*(func2-1)}
> func4=function{func3+R}
> 
> at parse you must walk on tree of calling to find that there was 
> result for R I think it could be better to test during trace

Why? That way, it would just have to be done many times instead of once, 
with a slower result than the parse-time method. Just put the function 
calls in a hash table accessed by the name of the function and the 
variables passed ot it, no need for a tree. At render time, it can 
simply grab the right value from the table for functions that don't use 
constant parameters, or in the case of functions of variables, 
precompute the functions at the beginning of each evaluation and reuse 
those results for every call. This would work best for functions that 
use multiple calls to the same function, but should be able to work fine 
with the "nested" functions like your example.(func3 would only call 
func2 once, func2 would only call func1 once, etc...R would be called 2 
times, unless it can figure out that x, y, and z don't change from 
functin call to function call. Run-time checking like you suggest could 
be used in combination with parse-time checking to get rid of the extra 
call...since much of the work would be done at parse time, the run-time 
checking could have a lower overhead)


> perhaps it could be done as include in structure of function
> pointer to array of local variables
> than at parse alloc as many entries in this table as declared local
> variables
> and at expresion parse after fist calling of local variable
> call subfunction declared for local variable but after next calling
> call to entries in table - it avoids calling of unused locals
> 
> but this way you can't referenced to local variables in other functions

This is probably a good idea anyway, functions should be kept as simple 
as possible. I don't see how referencing local variables in other 
functions could ever be a good idea in these functions.


> but this way you cant referenced to local variables in other functions
> therefore there is also need for solution with remembered fast results
> for the same parameters

Why would you need to reference variables in other functions? What would 
that even mean? Variables should expire when the function is done.
Or are you talking about optimizing the variables so if two functions 
set a variable with the same expression it isn't recalculated?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message