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

Chris Huff wrote in message ...
> > > 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.

you said about trick,
you mean this from p.u-p ?
what about overdefined declaration
with different number of parameters ?
this could cause unexpected error
(or expected by me in source code)
I think it should be possible without trick

ABX

Post a reply to this message

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

> >In other words, allowing the function to be called in ordinary scene
> >code...
> 
> yes
> 
> >this should be pretty easy
> 
> I hope

I am thinking something like this, in the Parse_Num_Factor() function in 
express.c:

#include "isosrf.h"

...

    CASE(FUNC_ID_TOKEN)
    {
        DBL result = 0;
        int i=0;
        VECTOR Point;
        FUNCTION * TFunc = NULL;

        Load_Function(TFunc, ((FUNCTION *)Token.Data)->func_name);/*?*/
        
        GET(LEFT_PAREN_TOKEN)
        Parse_Vector(Point);
        GET(RIGHT_PAREN_TOKEN)
        if(TFunc != NULL)
            result = (TFunc->iso_func)(TFunc, Point);
        
        for(i=0; i < *Terms; i++)
            Express[i] = Val;
    }
    END_CASE

I don't know if this will work(it compiles, but it hasn't been tested), 
and I have no idea what Load_Function() does...but it's a start.

-- 
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 ...
>I don't know if this will work(it compiles, but it hasn't been tested),
>and I have no idea what Load_Function() does...but it's a start.


I will check your idea, thanks

ABX

Post a reply to this message

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

> you said about trick,
> you mean this from p.u-p ?

The "trick" was something like:
#declare Func = function {1}
#declare Func = function {if(z, Func(x, y, z-1), moof)}


> what about overdefined declaration
> with different number of parameters ?
> this could cause unexpected error
> (or expected by me in source code)

If a function calls itself with the wrong number of parameters, it 
certainly should produce an error...just like any other function call.


> I think it should be possible without trick

Definitely. What I meant was that since it is already possible, it 
shouldn't be very difficult to make it work without that 
double-declaration trick. Maybe just creating a "dummy" function with 
the same name and parameters just before parsing the body of the 
function would work...

This:
#declare Func = function(r) {Func(r-1)}

Would do this:
1: Parse function parameter list
2: Create dummy function: Func = function(r){0}
3: Parse body of function: Func = function(r){Func(r-1)}

-- 
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 <3a0d736f@news.povray.org>, "Wlodzimierz ABX Skiba"
><abx### [at] abxartpl> wrote:
>> 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.


It should include an option to allow unlimited recursion for those who know
what they are doing.

Mark

Post a reply to this message

In article <3a0f905a@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> It should include an option to allow unlimited recursion for those 
> who know what they are doing.

Umm, unlimited recursion would take an unlimited amount of time and 
memory, it's better to let a function hit a limit and produce a parse or 
render time error. Even those who know what they are doing would never 
use this option...there is no reason I can see to let this "safety net" 
be removed.

It would be nice if you could adjust the max nesting level of macros too.

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