POV-Ray : Newsgroups : povray.documentation.inbuilt : Mysterious function argument Server Time 7 Dec 2021 10:13:31 EST (-0500)
 Mysterious function argument (Message 1 to 10 of 20)
 From: Cousin Ricky Subject: Mysterious function argument Date: 30 Sep 2021 09:39:42 Message: <6155be1e\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#6155be1e%241%40news.povray.org",
"dateCreated": "2021-09-30T13:39:42+00:00",
"datePublished": "2021-09-30T13:39:42+00:00",
"author": {
"@type": "Person",
"name": "Cousin Ricky"
}
}
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?
```
 From: B  Gimeno Subject: Re: Mysterious function argument Date: 30 Sep 2021 13:05:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.6155edcc3ec630374f038c688484ae3a%40news.povray.org",
"dateCreated": "2021-09-30T17:05:00+00:00",
"datePublished": "2021-09-30T17:05:00+00:00",
"author": {
"@type": "Person",
"name": "B  Gimeno"
}
}
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
```
 From: Bald Eagle Subject: Re: Mysterious function argument Date: 30 Sep 2021 13:30:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.6155f3783ec630371f9dae3025979125%40news.povray.org",
"dateCreated": "2021-09-30T17:30:00+00:00",
"datePublished": "2021-09-30T17:30:00+00:00",
"author": {
"@type": "Person",
"name": "Bald Eagle"
}
}
"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

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.
```
 From: William F Pokorny Subject: Re: Mysterious function argument Date: 30 Sep 2021 13:46:26 Message: <6155f7f2\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#6155f7f2%241%40news.povray.org",
"dateCreated": "2021-09-30T17:46:26+00:00",
"datePublished": "2021-09-30T17:46:26+00:00",
"author": {
"@type": "Person",
"name": "William F Pokorny"
}
}
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:
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.
```
 From: Cousin Ricky Subject: Re: Mysterious function argument Date: 30 Sep 2021 17:44:43 Message: <61562fcb\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#61562fcb%241%40news.povray.org",
"dateCreated": "2021-09-30T21:44:43+00:00",
"datePublished": "2021-09-30T21:44:43+00:00",
"author": {
"@type": "Person",
"name": "Cousin Ricky"
}
}
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>.
```
 From: Cousin Ricky Subject: Re: Mysterious function argument Date: 30 Sep 2021 17:50:55 Message: <6156313f\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#6156313f%241%40news.povray.org",
"dateCreated": "2021-09-30T21:50:55+00:00",
"datePublished": "2021-09-30T21:50:55+00:00",
"author": {
"@type": "Person",
"name": "Cousin Ricky"
}
}
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.
```
 From: Bald Eagle Subject: Re: Mysterious function argument Date: 30 Sep 2021 18:00:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.615633573ec630371f9dae3025979125%40news.povray.org",
"dateCreated": "2021-09-30T22:00:00+00:00",
"datePublished": "2021-09-30T22:00:00+00:00",
"author": {
"@type": "Person",
"name": "Bald Eagle"
}
}
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
```
 From: Bald Eagle Subject: Re: Mysterious function argument Date: 30 Sep 2021 18:30:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.61563a193ec630371f9dae3025979125%40news.povray.org",
"dateCreated": "2021-09-30T22:30:00+00:00",
"datePublished": "2021-09-30T22:30:00+00:00",
"author": {
"@type": "Person",
"name": "Bald Eagle"
}
}
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.
```
 From: Kenneth Subject: Re: Mysterious function argument Date: 1 Oct 2021 15:15:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.61575dc63ec630374cef624e6e066e29%40news.povray.org",
"dateCreated": "2021-10-01T19:15:00+00:00",
"datePublished": "2021-10-01T19:15:00+00:00",
"author": {
"@type": "Person",
"name": "Kenneth"
}
}
"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

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
```
 From: William F Pokorny Subject: Re: Mysterious function argument Date: 2 Oct 2021 09:02:32 Message: <61585868\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#61585868%241%40news.povray.org",
"dateCreated": "2021-10-02T13:02:32+00:00",
"datePublished": "2021-10-02T13:02:32+00:00",
"author": {
"@type": "Person",
"name": "William F Pokorny"
}
}
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

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