I'm trying to add G to POV-Ray, specifically I'm trying to make G 
functions callable through the POV function mechanism. However, the 
number of parameters (and return type) isn't known until a function is 
linked to a G function, and the code seems to take this from the trap 
table where it is defined at compile time. What's the best way to do 
this?

I could add multiple entries in POVFPU_TrapSTable for different numbers 
of parameters. That'd limit the number of parameters, and mean lots of 
entries for one function (16 entries for a max of 15 parameters). I 
can't just modify it at run time, different G functions will use the 
same trap entry. I'm a bit reluctant to modify more than necessary just 
to add my code.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> I'm trying to add G to POV-Ray, specifically I'm trying to make G
> functions callable through the POV function mechanism.

Which G functions are you talking about?

    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 <3dbbb805@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> > I'm trying to add G to POV-Ray, specifically I'm trying to make G
> > functions callable through the POV function mechanism.
> Which G functions are you talking about?

Maybe you haven't seen my posts about it...it's a simple langage with 
support for vectors.
The return value is apparently taken from the function itself, but the 
parameters are taken from the trap table, and I'd like to use one trap 
entry to interface to G functions, otherwise I'd need an entry for every 
supported number of parameters.
Actually, it looks like the trap table's parameter count is only used to 
initialize the functions parameter count, in FNCode::Compile()...I 
should be able to modify it for individual instances with no trouble, 
right? Doesn't look like the code is designed for this, but I don't see 
any reason for it to fail.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg>,
 Christopher James Huff <chr### [at] maccom> wrote:

> Actually, it looks like the trap table's parameter count is only used to 
> initialize the functions parameter count, in FNCode::Compile()...I 
> should be able to modify it for individual instances with no trouble, 
> right? Doesn't look like the code is designed for this, but I don't see 
> any reason for it to fail.

That seems to work...I used two entries, one in POVFPU_TrapSTable for 
vector returning functions, and one in POVFPU_TrapTable for scalar 
functions. After some more testing, I'll release the patch.
BTW, how do POV functions handle vectors? It looks like they are seen as 
3 double values...can it handle parameter list of mixed vectors and 
scalars?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> Maybe you haven't seen my posts about it...it's a simple langage with
> support for vectors.

No, where would they be?  The G functions i know are apparently something
completely different from those you know...

> Actually, it looks like the trap table's parameter count is only used to
> initialize the functions parameter count, in FNCode::Compile()...I
> should be able to modify it for individual instances with no trouble,
> right? Doesn't look like the code is designed for this, but I don't see
> any reason for it to fail.

You should not really mess with tables of constant values.  It is
initialised there in order to determine how many parameters a function
takes, more information is not necessary.  However, I see no clean way to
determine how many values got passed to the functions and then take
appropriate action.  If you desire such functionality, you should really not
add it with such an ugly hack.

> BTW, how do POV functions handle vectors? It looks like they are seen as
> 3 double values...can it handle parameter list of mixed vectors and
> scalars?

Vectors are not allowed as function parameters, so...

    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 <3dbc1972@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> No, where would they be?  The G functions i know are apparently something
> completely different from those you know...

The "It's alive" thread in .general, and the "Re: Proposal for 4.0 core 
control" thread in .programming. The language is called "G" for now, 
because it is mainly for graphics and I needed a name. I've heard of 
S-expressions, but not G-functions.


> You should not really mess with tables of constant values.  It is
> initialised there in order to determine how many parameters a function
> takes, more information is not necessary. 

The problem isn't the amount of information, but when it is known. The 
POV VM doesn't know how many parameters a G function has until it is 
told, it can't be hard coded at compile time.


> However, I see no clean way to determine how many values got passed 
> to the functions and then take appropriate action.  If you desire 
> such functionality, you should really not add it with such an ugly 
> hack.

It doesn't need to count values passed to the function. It just needs to 
take the parameter count from a different source, because it can vary 
for individual declarations.
Modifying the trap table seems to work fine, it looks like the code only 
uses that value to set the parameter_cnt value in the function, then 
relies on that value. I don't like it either, but it's the only way I 
can see to do it without modifying large chunks of the POV VM code, 
which I am reluctant to do.


> Vectors are not allowed as function parameters, so...

Right...my memory was getting mixed up with thinking about the transform 
functions. My code will see triples of scalar parameters as single 
vector parameters where a vector parameter is needed.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> The "It's alive" thread in .general, and the "Re: Proposal for 4.0 core
> control" thread in .programming. The language is called "G" for now,
> because it is mainly for graphics and I needed a name. I've heard of
> S-expressions, but not G-functions.

Here are a few:

<http://mathworld.wolfram.com/BarnesG-Function.html>
<http://mathworld.wolfram.com/MeijersG-Function.html>
<http://mathworld.wolfram.com/Ramanujang-andG-Functions.html>
<http://scienceworld.wolfram.com/physics/F-andG-Functions.html>

____________________________________________________
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 <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> The problem isn't the amount of information, but when it is known. The
> POV VM doesn't know how many parameters a G function has until it is
> told, it can't be hard coded at compile time.

But then it won't work.  The number of parameters on the stack has to be
known at compile-time or the generated code *will* fail if the parameters
are non-trivial expressions.

    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 <3dbc2ebd@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> But then it won't work.  The number of parameters on the stack has to be
> known at compile-time or the generated code *will* fail if the parameters
> are non-trivial expressions.

I think you misunderstood, I'm talking about POV-source compile time, 
not POV-function compile time. The number of parameters is figured out 
at function declaration time, as it is for user defined functions.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

>> But then it won't work.  The number of parameters on the stack has to be
>> known at compile-time or the generated code *will* fail if the parameters
>> are non-trivial expressions.
>
> I think you misunderstood, I'm talking about POV-source compile time,
> not POV-function compile time. The number of parameters is figured out
> at function declaration time, as it is for user defined functions.

Oh, yes, I misunderstood.  Then it will kind of work, of course.

    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