The reference manual (section 3.3.1.8.3, or 2.3.1.8.3 in the wiki) gives
the following as a legal function definition:

  #declare foo3 = function(k1, k2, z, y) { x + y * z + k1 * y + k2 }

The function body refers to x, even though x is not one of the declared
arguments.  But the function still works, somehow.  The following scene

----------[BEGIN SCENE]----------
#version max (3.5, min (3.8, version));
global_settings { assumed_gamma 1 }
#declare foo3 = function(k1, k2, z, y) { x + y * z + k1 * y + k2 }
#declare G = foo3 (1, 2, 3, 4);
#debug concat ("G = ", str (G, 0, 1), "\n")
-----------[END SCENE]-----------

yields the output:

G = 18.0

Manually working through the function yields
  x + y * z + k1 * y + k2
= x + 4 * 3 + 1 * 4 + 2
= x + 12 + 4 + 2
= x + 18

This suggests that POV-Ray pre-assigned 0 to x.  That this construction
is given as an example suggests that this is a significant feature
(however inadvisable to use), and not just a parser glitch.  Shouldn't
there be some explanation of this feature?

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> This suggests that POV-Ray pre-assigned 0 to x.  That this construction
> is given as an example suggests that this is a significant feature
> (however inadvisable to use), and not just a parser glitch.  Shouldn't
> there be some explanation of this feature?

https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_6_6

"All built-in vector identifiers never change value. They are defined as though
the following lines were at the start of every scene.

#declare x = <1, 0, 0>;
#declare y = <0, 1, 0>;
#declare z = <0, 0, 1>;
#declare t = <0, 0, 0, 1>;
#declare u = <1, 0>;
#declare v = <0, 1>;


It shouldn't be like you say. But by the trunk of the fifth elephant that it is.

B. Gimeno

Post a reply to this message

"B. Gimeno" <nomail@nomail> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
> > This suggests that POV-Ray pre-assigned 0 to x.  That this construction
> > is given as an example suggests that this is a significant feature
> > (however inadvisable to use), and not just a parser glitch.  Shouldn't
> > there be some explanation of this feature?
>
> https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_6_6
>
> "All built-in vector identifiers never change value. They are defined as though
> the following lines were at the start of every scene.
>
> #declare x = <1, 0, 0>;
> #declare y = <0, 1, 0>;
> #declare z = <0, 0, 1>;
> #declare t = <0, 0, 0, 1>;
> #declare u = <1, 0>;
> #declare v = <0, 1>;
>
>
> It shouldn't be like you say. But by the trunk of the fifth elephant that it is.
>
> B. Gimeno

Right, but those are if you're accessing those values from the regular parser.
When you access them from the _function parser / VM_, you get a different set of
values.  I made a post about this once - and of course I can't find it ATM.

AFAIK, if you use all of those identifiers in a function, they will all return
zero until you assign them a value by passing a value into the function call
using that variable name.

As Ricky says, it's certainly a useful "feature", but could probably use a good
post, some example code, or at some point, a more detailed explanation in the
documentation.

Post a reply to this message

On 9/30/21 1:27 PM, Bald Eagle wrote:
> AFAIK, if you use all of those identifiers in a function, they will all return
> zero until you assign them a value by passing a value into the function call
> using that variable name.

Excepting 't'. In the function body use of 't' where it is otherwise not 
defined results in:

File 'wham.inc' line 19:
Parse Error:
Expected 'operand', 't' found instead
Fatal error in parser: Cannot parse input.
Render failed

Aside: I've been playing with other stuff most of the day, but
we have too that function { pattern {} } mode where you don't - cannot - 
specify an argument list for the function. In that case I expect all the 
values are whatever was passed to 'pattern' for x|u,y|v,z. Should verify 
u and v set to x and y I guess, but expect that the case.

Bill P.

Post a reply to this message

On 2021-09-30 1:03 PM (-4), B. Gimeno wrote:
> 
> "All built-in vector identifiers never change value. They are defined as though
> the following lines were at the start of every scene.
> 
> #declare x = <1, 0, 0>;
> #declare y = <0, 1, 0>;
> #declare z = <0, 0, 1>;
> #declare t = <0, 0, 0, 1>;
> #declare u = <1, 0>;
> #declare v = <0, 1>;

This does not apply in the context of function parameters.  Function
parameters are not vector constants, but variable scalars.

In the foo3 example in particular, you can see that the pre-declared
value of x is not used: 0 does not equal <1, 0, 0>.

Post a reply to this message

On 2021-09-30 1:27 PM (-4), Bald Eagle wrote:
> 
> As Ricky says, it's certainly a useful "feature",

Hardly.  I think it's a horrible feature.

My point was that if it's significant enough to use in an example, then it

> [...] could probably use a good
> post, some example code, or at some point, a more detailed explanation in the
> documentation.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-09-30 1:27 PM (-4), Bald Eagle wrote:
> >
> > As Ricky says, it's certainly a useful "feature",
>
> Hardly.  I think it's a horrible feature.

A horribly useful feature then.  :D

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Aside: I've been playing with other stuff most of the day, but
> we have too that function { pattern {} } mode where you don't - cannot -
> specify an argument list for the function. In that case I expect all the
> values are whatever was passed to 'pattern' for x|u,y|v,z. Should verify
> u and v set to x and y I guess, but expect that the case.

Ah, yeah.
I've had to wrangle a lot with those too.
I'm forever trying to do things like:
#declare F0 = function {pattern {bozo}}

and then do something like F0 (x+1, y/2, z)

or F0 = function {pattern {bozo} / <2, 1, 1>}


Functions are certainly challenging in the current implementation.  It takes a
while to get used to what you can and cannot do, and there are a lot of "tricks"
to getting the syntax and expressions worked out to accomplish what one wants.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I'm forever trying to do things like:
> #declare F0 = function {pattern {bozo}}
>
> and then do something like F0 (x+1, y/2, z)
>
> or F0 = function {pattern {bozo} / <2, 1, 1>}
>

Using v3.8.0 beta 1 in Windows, the following is interesting... or maybe
strange?

#declare F0 = function {pattern {bozo}}
...throws a fatal error just by itself, "Expected 'Rvalue to declare', pattern
found instead"

But...
#declare F0 = function {pigment {bozo}}
...works fine.

I had assumed that they were the same basic kind of entity (except for a
grayscale version when using 'pattern'.)

But more on-topic: Given a pigment instead, your 1st example does run, if a
function wrapper is included (plus an optional color_map, simply to make the
results more visually understandable). AND with only a single argument(?) pulled
out of the function, using a dot operator. For example, I can do some crazy
things with it...

pigment{
function{F0 (max(x,.5),pow(y,1.3),sqrt(z)).red}
color_map {[0,rgb 0][1,rgb <1,0,0>]}
}

Or .x for the function instead of .red

Post a reply to this message

On 10/1/21 3:13 PM, Kenneth wrote:
> #declare F0 = function {pattern {bozo}}
> ...throws a fatal error just by itself, "Expected 'Rvalue to declare', pattern
> found instead"

Hmm. Do others on windows see this sort of fail?

The code parses for me with v3.7 and v3.8.

---
What I had in mind when asking myself whether u & v were also set with 
function{pattern{}} was the function{pattern{function{}}} usage. It's 
what one does to enable all the pattern modifiers for the the pattern 
wrapped function(a). The answer is the u and v values are indeed set to 
the x and y values passed through the pattern mechanism.

// povr parse test
#declare Fn00 = function {
     pattern { function { f_boom(x,y,z,u,v,0) }
         // turbulence, warps... - can applied
     }
}
#declare V00  = Fn00(1,2,3);
//---

Returns:

f_boom
1(x) -> 1,
2(y) -> 2,
3(z) -> 3,
4(0) -> 1,  // u
5(1) -> 2,  // v
6(2) -> 0

(a) - This is easier to do in the povr branch due the raw_wave and 
function_interval pattern modifiers.

---
Posting too the following v3.7..v4.0 generic code to highlight a couple 
other function {pattern | pigment} traps / concerns.

// povray +mv3.8 +iThisParseTest.inc
#declare F0 = function {pattern {bozo}}
#declare F1 = function {pigment {bozo}}
#declare F2 = function {pigment {bozo
         color_map {[0,rgbft 0][1,rgbft 1]}
     }}
#declare F3 = function { F0(x+1,y/2,z) }
//#declare V0 = F0(x+1,y/2,z);
// Parse Error: Float expected but vector or color expression found.
#declare V1 = F1(1,2,3);
#declare V2 = F2(1,2,3);
#declare V3 = F3(1,2,3);
#debug concat("\nV1 = ",vstr(5,V1,",",1,3),"\n")
#debug concat("V2 = ",vstr(5,V2,",",1,3),"\nV3 = ",str(V3,1,3),"\n\n")

#error "Parse Test. Stop early"
//---

v3.7/v.38 returns:
------------------
V1 = 0.000,1.000,0.000,0.000,0.000 (*)
V2 = 0.421,0.421,0.421,0.421,0.421 (***)
V3 = 0.489

The povr branch returns:
------------------------
V1 = 0.421,0.421,0.421,0.000,0.000 (**)
V2 = 0.421,0.421,0.421,0.421,0.421 (***)
V3 = 0.489

(*) - POV-Ray proper has unique default color maps for each continuous 
pattern. Be sure to always specify the color map you want!
(**) - The povr branch defaults to rgb [0..1] color maps for all 
continuous patterns.
(***) - The function{pigment{}} mechanism uses a full 5D color vector 
which, in all current versions of POV-Ray of which I'm aware, use only 
single float channels; Making this mechanism to pass around values more 
problematic - especially for isosurface / parametric function use. The 
function{pattern{}} mechanism returns a double float and it's faster 
than using function{pigment{}}.

Bill P.

Post a reply to this message