Chris Huff wrote:

> ... 
> You don't need a macro for this, a plain old function will do fine.
> 
> #declare Heaviside = function {if(x - y, 1, 0)}
> // x=the value, y=the jump threshold, z=nothing
> ...

Agreed. But I think the best solution to Libellule problem should be
something like

#macro Heaviside(jump)
  if(x - jump, 1, 0)
#end

isosurface{function{y - Heaviside(actual_jump)}
  contained_by{box -<1, 1, 1> <1, 1, 1>}
  accuracy .01
  max_gradient 21
}

where actual_jump is a constant float.

In this way, if you need more than one step function with jumps at
distinct places in the same isosurface, this would be the optimal
implementation. I tried this code but got an error message

error: float factor expected but macro identifier found instead.

So macro substitution doesn't work inside function{...}. I thought that
at parse time, this macro substitution would take effect.

Is that a MegaPov misbehavior or is this intended for some reason?

Regards, Alberto.

Post a reply to this message

In article <39A2B900.9BC7401A@usb.ve>, jac### [at] usbve wrote:

> So macro substitution doesn't work inside function{...}. I thought that
> at parse time, this macro substitution would take effect.
> 
> Is that a MegaPov misbehavior or is this intended for some reason?

This is the reason I wrote it as a function. :-)
No, macros don't work within functions, neither do #if, #switch, or 
#while. How should the internals of the macro work? Macros can have 
local variables and can do different things for each time they are 
called. The only way I can see to do it would be to have the macro be 
evaluated once, at parse time, but this would make it appear to the user 
that the macro is called from within the function, when it is really 
called to make part of the function.

I think the best way to do things would be to extend functions to have 
variable numbers of parameters(so you could just have 1 parameter, or 5, 
instead of always having 3), allow functions to be called like macros 
from within the scene file, and to extend the function language with 
loops, variables, and conditionals(there is already an if() function, 
but a slightly different syntax could be useful).

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

> I think the best way to do things would be to extend functions to have
> variable numbers of parameters(so you could just have 1 parameter, or 5,
> instead of always having 3), allow functions to be called like macros
> from within the scene file, and to extend the function language with
> loops, variables, and conditionals(there is already an if() function,
> but a slightly different syntax could be useful).

Being able to call finctions would be great, and would also suppress the
need for texture or pigment evaluation...
About the "if" function, it could also be possible to have something
like the well-known cryptic a?b:c syntax.
Adding local variables and loops would probably make things quite
different. Could you elaborate on a possible syntax? Did you think about
some lisp-like or RPN (a la PostScript) method?

-- 

      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

In article <39A30BD5.5E049847@club-internet.fr>, Francois Dispot 
<woz### [at] club-internetfr> wrote:

> Being able to call finctions would be great, and would also suppress the
> need for texture or pigment evaluation...

Do you mean using eval_pattern() or eval_pigment() to extract the value? 
This makes it possible to evaluate functions in the current version, but 
would break with variable numbers of parameters.


> About the "if" function, it could also be possible to have something
> like the well-known cryptic a?b:c syntax.

Why? Like you said, it is cryptic. I personally avoid it like goto or 
the plague. :-)


> Adding local variables and loops would probably make things quite
> different. Could you elaborate on a possible syntax? Did you think about
> some lisp-like or RPN (a la PostScript) method?

The syntax would be very similar to ordinary POV, and in ways more 
similar to C...I don't know what Lisp is like, and definitely not RPN(if 
you mean Reverse Polish Notation, I don't know PostScript either). Just 
something like this:

#declare MyFunc =
function (V, Oct, A){
    var Ctr = 0;
    var O = 0;
    var Result = 0;

    if(Oct <= 0)
        O = 1;
    else
        O = Oct;
    endif// or maybe use {} blocks
    
    while(Ctr < O)
        Result += sin(O*V);
        newVal += 1;
    endwhile

    Result/O
    // or
    return A*(Result/O);
};

#declare Value = MyFunc(clock, 4, 1.4);

I really am not sure about the return syntax...the first one would 
maintain compatibility with existing functions, but might make the 
parser harder to write(and it looks funny if you are used to programming 
in C). Maybe the return value should be the first expression not 
preceded by an expression which is using it, and not followed by =, +=, 
-=, --, or ++. So if the parser encounters an equation is just sitting 
there alone, not being used as input to if(), while(), or anything, or a 
variable which is not being modified, it would be used as the return 
value.
And maybe it should use #if(), #while(), etc. for consistency with the 
rest of the language.

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

> You don't need a macro for this, a plain old function will do fine.
>
> #declare Heaviside = function {if(x - y, 1, 0)}
> // x=the value, y=the jump threshold, z=nothing

I was wondering about the macro, that would make it more general, but,
as has been demonstrated, they cannot be used inside functions :-)

Thanks to all, I got exactly what I needed, one-stop shopping :-))

Post a reply to this message

On Tue, 22 Aug 2000 21:53:40 -0500, Chris Huff wrote:
>Maybe the return value should be the first expression not 
>preceded by an expression which is using it, and not followed by =, +=, 
>-=, --, or ++. So if the parser encounters an equation is just sitting 
>there alone, not being used as input to if(), while(), or anything, or a 
>variable which is not being modified, it would be used as the return 
>value.

Perl uses the value of the last evaluated expression as the return value.
Could that work?

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> Perl uses the value of the last evaluated expression as the return value.
> Could that work?

It might, I think...does it just return at the end of the function with 
the value of the last expression, or is there an equivalent to the 
"return" statement in C?
It could be useful to have any "orphan" expression force a return with 
the value of that expression if it is reached, that would allow multiple 
exit points. Or maybe that isn't a good idea...I have found it sometimes 
makes cleaner code, but I have also heard it isn't good programming 
style. And constantly checking every expression for the returning 
conditions might slow things down, but maybe a "return" statement could 
be inserted at parse-time so the checking doesn't have to be done at 
run-time...

-- 
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" <chr### [at] maccom> wrote in message
news:chrishuff-73EA9B.08380023082000@news.povray.org...
> In article <slr### [at] fwicom>, ron### [at] povrayorg
> wrote:
>
> > Perl uses the value of the last evaluated expression as the return
value.
> > Could that work?
>
> It might, I think...does it just return at the end of the function with
> the value of the last expression, or is there an equivalent to the
> "return" statement in C?

Both - it will return the last evaluated expression or you can use "return
$foo", so

sub foobar{
    $foo = 1;
    return $foo;
}

is the same as

sub foobar{
    $foo = 1;
}

Post a reply to this message

On Wed, 23 Aug 2000 08:38:00 -0500, Chris Huff wrote:
>In article <slr### [at] fwicom>, ron### [at] povrayorg 
>wrote:
>
>> Perl uses the value of the last evaluated expression as the return value.
>> Could that work?
>
>It might, I think...does it just return at the end of the function with 
>the value of the last expression, or is there an equivalent to the 
>"return" statement in C?

Yes.

That is, it does both.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> Yes.
> 
> That is, it does both.

This sounds like a good compromise. :-)
Now, just have to figure out how to write it...I don't understand much 
of the isosurface code at all, hopefully the function stuff will be 
separated out and cleaned up in 3.5.

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