 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
started at p.u.p
Chris Huff wrote in message ...
>> and I want ask if there is optimized calling with the same arguments
?
>This type of optimization has been discussed a while ago, I think the
>discussion started in povray.general and spread to .programming...
unfortunately i still have 2049 in p.p and 21988 in p.g to read :-(
but only 6977 in p.b.i :-)
>Unfortunately, nobody has ever done anything about it.
than I should start, I think it could be veeeery useful
in my plant isosurface (see "is over iso vers. of plant" at p.b.i)
>There don't seem
>to be any people who understand the isosurface code well enough and
have
>the time to implement this.
I have looked at sources
and I think that there is not to much to do
>Or maybe, like me, they are simply waiting
>for 3.5 to come out
but this small change could make 3.5 much faster in such use
>> to avoid slower render time for simple isosurface
>> this feature should be switched inside isosurface
>> (i.e. keyword "fast_results")
>
>This could be done at parse time so it wouldn't slow down even the
>simplest functions, so this option would be unnecessary.
at parse time?
could you describe me how do you think you can racognize at parse
that there was previous calling in subfunction ?
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
>Another possibly useful feature would be the ability to use variables
in
>the function, for example:
>function {
> A = sqr(x+y*Func(x,y,z));
> Func2(A, A+2, x+A/2)
>}
yes, it could be very usefull
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
>And of course, functions allowing different numbers of parameters...
this could be done like above but first with reserved entries
in described table for params, for example:
Function=function {
/* additional parameters with default values */
add_params[4] {2,7,0,0.1}
/* local variable after keyword "local" finnished with ";" */
local A = add_params[0]^2 + add_params[1];
local B = sin(add_params[2]+add_params[3]);
local C = A + B;
/* old function stuff */
C^2+7/A+4*B
}
example of possible calls:
Function
Function(x,y,z)
Function(x,y,z,14,.1)
Function(x,y,z,14,.1,10,0)
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
I try make such patch but ...
khem... khem...
is there any free C compiler for windows or dos
which I can download to start ....
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wlodzimierz ABX Skiba wrote in message <3a092503@news.povray.org>...
>is there any free C compiler for windows or dos
>which I can download to start ....
of course I found it
but is there any person who has compiled megapov
or even pure pov dos with djgpp ?
I have downloaded sources for dos from povray.org and
djgpp from delorie.com/djgpp
I have installed both rather properly
follow instruction I have started with make
compilation and linking process outputs only warning
that main() is void insted of int
povray.exe created
but after run of prepared povray.exe it crash with General
Protection Fault in command prompt window (i've using nt 4 serv)
in documentat cmpl_djg.doc I always see povray 3.0 insted of
povray 3.1 but I think this is not important if sources are from
povray 3.1 - all *.o files for all *.c are created
anybody tried this ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wlodzimierz ABX Skiba wrote:
[...]
>
> of course I found it
> but is there any person who has compiled megapov
> or even pure pov dos with djgpp ?
> I have downloaded sources for dos from povray.org and
> djgpp from delorie.com/djgpp
I tried quite a lot to compile the unix source with cygwin
(http://sources.redhat.com/cygwin/) but i did not succeed. I don't know about
the DOS version and djgpp though.
Christoph
--
Christoph Hormann <chr### [at] gmx de>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote in message
<3A0ABE7D.DA3D8C00@schunter.etc.tu-bs.de>...
> Wlodzimierz ABX Skiba wrote:
> > of course I found it
> > but is there any person who has compiled megapov
> > or even pure pov dos with djgpp ?
> > I have downloaded sources for dos from povray.org and
> > djgpp from delorie.com/djgpp
>
> I tried quite a lot to compile the unix source with cygwin
> (http://sources.redhat.com/cygwin/) but i did not succeed. I don't
know about
> the DOS version and djgpp though.
well, finally it works - I undefined FANCY TEXT and FANCY VIDEO
form config.h and pure povray is compiled okay
some warning are reported but compiled version works
when rendering of chees finish I'll start with port megapov 06a to it
or meybe somebody can save my time ? :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wlodzimierz ABX Skiba wrote in message <3a0ac8e7@news.povray.org>...
>well, finally it works - I undefined FANCY TEXT and FANCY VIDEO
>from config.h and pure povray is compiled okay
>some warning are reported but compiled version works
>when rendering of chees finish I'll start with port megapov 06a to it
hmm, strange error
all modules from mp06a compiled ok
but during linking process errors reported
super.o(.text+0xf50):super.c: multiple definition of
'Create_Superellipsoid'
super.o(.text+0xf50):super.c: first defined here
super.o(.text+0x101c):super.c: multiple definition of
'Compute_Superellipsoid_BBox'
super.o(.text+0x101c):super.c: first defined here
have you any idea ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote in message ...
>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...
yeap, it's good lesson
now I have 55% of whole news.povray.org in my little head ;-)
>> 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.
I know, I know
but it will be faster if I only implement technic from mp6 I think
I don't want waste time for looking at randering ;-)
> [interesting stuff about my previous idea]
During download of djgpp and teaching it I thought about
my previous idea with remebered results.
It is completly not necessary if thera are locals in function.
Since three days I look at sources
and yesterdey I start with coding.
I plan support such syntax:
#declare Func=function{expression_using_x_y_z}
this is for old scripts to support not changed pov-files
this is i.e. for such old calls:
Func,Func(x,y,z),Func(4*sin(x),Func(x,y+1.z+2),2^z)
#declare Func=function(name1,name2,name3,name4)
#declare Func=function(name1,name2,name3=value,name4=value)
this is for extended new syntax - you can pass as many parameters
as you want with default values or not
first parameters with no defaults, than with defaults
it is possible to put all with defaults and all without
possible calls depends of how many defaults is declared, i.e.:
Func(x,y,z)
- possible: Func(4*x,y+7,z+8), Func(Func(x,y,z),Func(x,x,x),0)
- impossible: Func, Func(x,y), Func(x,y,z,a)
Func(x,a,mad=7,any=vlength(P1,P2))
- possible: Func(7,9,10,12), Func(x,y,z), Func(x,sin(y))
- impossible: Func, Func(x)
In both, new and old syntax, I plan add support for locals:
Func=function{
local a=expression;
local b=expression;
a+b-sin(a)
}
Perhaps, if it will be possible I will add
- recursion: Func=function(a,b){a+b+Func(a+1,b-1)}
- registration to use function also during parsing
any comments ?
>Christopher James Huff
thanks for help
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a0d4d1c@news.povray.org>, "Wlodzimierz ABX Skiba"
<abx### [at] abxartpl> wrote:
...snip stuff about function parameters...
This looks good. Isosurfaces could automatically add the x, y, and z
variables so old functions are supported without extra work. What I mean
is that x, y, and z become available to the function declaration in
isosurfaces, allowing you to use them in calls to other functions. This
would also help in allowing functions to be used in other places where
x, y, and z don't make much sense.
> Perhaps, if it will be possible I will add
> - recursion: Func=function(a,b){a+b+Func(a+1,b-1)}
This shouldn't be too hard, since it is apparently possible to trick the
parser into allowing this already.
> - registration to use function also during parsing
By this, do you mean something like this?
#declare SineWave = function(v) {sqr(sin(v))}
#declare Val = SineWave(clock*5);
In other words, allowing the function to be called in ordinary scene
code...this should be pretty easy, I have been trying to figure it out.
BTW, if you ever figure out what TmpFunc and tempfunc are for, tell
me...as far as I can tell, they don't do anything.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote in message ...
>> Perhaps, if it will be possible I will add
>> - recursion: Func=function(a,b){a+b+Func(a+1,b-1)}
>
>This shouldn't be too hard, since it is apparently possible to trick
the
>parser into allowing this already.
what about checking parameters count ?
I think that there should be also some max_recursion_level
perhaps in global_settings
>> - registration to use function also during parsing
>
>By this, do you mean something like this?
>#declare SineWave = function(v) {sqr(sin(v))}
>#declare Val = SineWave(clock*5);
>
>In other words, allowing the function to be called in ordinary scene
>code...
yes
>this should be pretty easy
I hope
>BTW, if you ever figure out what TmpFunc and tempfunc are for, tell
>me...as far as I can tell, they don't do anything.
ok.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a0d736f@news.povray.org>, "Wlodzimierz ABX Skiba"
<abx### [at] abxartpl> wrote:
> > This shouldn't be too hard, since it is apparently possible to trick
> > the parser into allowing this already.
> what about checking parameters count ?
I'm not sure what you mean.
> I think that there should be also some max_recursion_level
> perhaps in global_settings
Probably a good idea, infinite recursion is going to be the most common
error with recursive functions and hard coded limits are simply annoying
when you run into them.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
