POV-Ray : Newsgroups : povray.bugreports : Bug in functions (3.7) Server Time
5 May 2024 13:58:37 EDT (-0400)
  Bug in functions (3.7) (Message 1 to 8 of 8)  
From: SharkD
Subject: Bug in functions (3.7)
Date: 9 Nov 2008 00:00:01
Message: <web.49166d8b922dfb254dffc32d0@news.povray.org>
Sorry if this bug has been mentioned before.

This works:

#local Temp_function = function { f_sphere(x + 1, y + 1, z + 1, 1) }

But this doesn't:

#local Temp_var = <1,1,1,>;
#local Temp_function = function { f_sphere(x + Temp_var.x, y + Temp_var.y, z +
Temp_var.z, 1) }


Post a reply to this message

From: Kenneth
Subject: Re: Bug in functions (3.7)
Date: 9 Nov 2008 08:40:01
Message: <web.4916e71f3371f17d78dcad930@news.povray.org>
"SharkD" <nomail@nomail> wrote:
> Sorry if this bug has been mentioned before.
>
> This works:
>
> #local Temp_function = function { f_sphere(x + 1, y + 1, z + 1, 1) }
>
> But this doesn't:
>
> #local Temp_var = <1,1,1,>;
> #local Temp_function = function { f_sphere(x + Temp_var.x, y + Temp_var.y, z +
> Temp_var.z, 1) }

You probably meant
#local Temp_var = <1,1,1>;

Actually, this doesn't work in 3.6.1c either, I've found. I'm just guessing
here, but I think it has to do with x and Temp_var.x being different kinds of
entities, which apparently can't be mixed together. Temp_var.x is a vector
quantity, whereas x (in a function) is...something else. :-)

BTW, using the function keyword (or not) has different, 'opposite' results,
depending on if x or Temp_var.x is used when making the function.  Kind of hard
to describe but here are some examples:
Given your original function...
#local Temp_function = function { f_sphere(x + 1, y + 1, z + 1, 1) }

This works (that is, it runs without a fatal error):
#local Temp_function_2 = function{Temp_function(x,y,z)}

but this doesn't...
#local Temp_function_2 = Temp_function(x,y,z);

Yet this works (though it probably doesn't mean much)...
#local Temp_var = <1,1,1>;
#local Temp_function_3 = Temp_function(Temp_var.x,Temp_var.y,Temp_var.z);

but this doesn't...
#local Temp_function_3 =
function{Temp_function(Temp_var.x,Temp_var.y,Temp_var.z)}

I'm sure there are reasons for this, but that's beyond me.

Ken W.


Post a reply to this message

From: Christian Froeschlin
Subject: Re: Bug in functions (3.7)
Date: 9 Nov 2008 09:51:51
Message: <4916f907$1@news.povray.org>
Kenneth wrote:

> #local Temp_function_2 = function{Temp_function(x,y,z)}

Thats defining Temp_function_2 to be a function
which just happen to pass its default arguments
x,y,z to Temp_function.

> #local Temp_function_2 = Temp_function(x,y,z);

That attempts to evaluate Temp_function outside a function
context, where x,y,z are not function arguments, but built-in
vectors (coordinate axes).

But not even passing <1,0,0> as

#local Temp_function_2 = Temp_function(x);

works, because the parser wants individual values here.

This actually does something:

#local Temp_function_2 = Temp_function(x.x,x.y,x.z);

;)

> Yet this works (though it probably doesn't mean much)...
> #local Temp_var = <1,1,1>;
> #local Temp_function_3 = Temp_function(Temp_var.x,Temp_var.y,Temp_var.z);

Temp_function_3 is the scalar value returned by Temp_function(1,1,1)

> but this doesn't...
> #local Temp_function_3 =
> function{Temp_function(Temp_var.x,Temp_var.y,Temp_var.z)}

I suppose this is just a limitation in the function parser.
There doesn't seem to be support for vectors in the syntax
for user-defined functions, except for special vector
functions created using transform and spline.


Post a reply to this message

From: SharkD
Subject: Re: Bug in functions (3.7)
Date: 10 Nov 2008 04:25:01
Message: <web.4917fd303371f17d14cef4880@news.povray.org>
Christian Froeschlin <chr### [at] chrfrde> wrote:
> > but this doesn't...
> > #local Temp_function_3 =
> > function{Temp_function(Temp_var.x,Temp_var.y,Temp_var.z)}
>
> I suppose this is just a limitation in the function parser.
> There doesn't seem to be support for vectors in the syntax
> for user-defined functions, except for special vector
> functions created using transform and spline.

Yes, this parser limitation is what I wanted to point out.


Post a reply to this message

From: SharkD
Subject: Re: Bug in functions (3.7)
Date: 10 Nov 2008 04:25:02
Message: <web.4917fddd3371f17d14cef4880@news.povray.org>
Christian Froeschlin <chr### [at] chrfrde> wrote:
> Kenneth wrote:
>
> > #local Temp_function_2 = function{Temp_function(x,y,z)}
>
> Thats defining Temp_function_2 to be a function
> which just happen to pass its default arguments
> x,y,z to Temp_function.

I thought this was the way to make an exact copy of a function? If I am wrong,
what is the proper way to do it?


Post a reply to this message

From: Christian Froeschlin
Subject: Re: Bug in functions (3.7)
Date: 10 Nov 2008 06:36:47
Message: <49181ccf$1@news.povray.org>
SharkD wrote:

> Christian Froeschlin <chr### [at] chrfrde> wrote:
> 
>>Kenneth wrote:
>>
>>
>>>#local Temp_function_2 = function{Temp_function(x,y,z)}
>>
>>Thats defining Temp_function_2 to be a function
>>which just happen to pass its default arguments
>>x,y,z to Temp_function.

> I thought this was the way to make an exact copy of a function? If I am wrong,
> what is the proper way to do it?

The syntax doesn't seem to distinguish between those cases.
As the result returned by the function is the same in both
cases, its more a question of internal optimization.

BTW, I thought I would be able to spot a difference with

#local f_A = function {0}
#local f_B = function {f_A(x,y,z)}
#debug str(f_B(0,0,0),2,0)
#undef f_A
#local f_A = function {1}
#debug str(f_B(0,0,0),2,0)

but it seems that dependant functions are always copied
(or possibly kept alive using some reference counting?),
as the output for both debug statements is consistently
equal, even if f_B is a composite expression such as
#local f_B = function {f_A(x,y,z)+1}.


Post a reply to this message

From: Kenneth
Subject: Re: Bug in functions (3.7)
Date: 11 Nov 2008 16:40:00
Message: <web.4919fb7d3371f17d78dcad930@news.povray.org>
Christian Froeschlin <chr### [at] chrfrde> wrote:

> This actually does something:
>
> #local Temp_function_2 = Temp_function(x.x,x.y,x.z);
>
> ;)
>

Weird! Yet interesting. That's a permutation I hadn't thought of.

KW


Post a reply to this message

From: SharkD
Subject: Re: Bug in functions (3.7)
Date: 12 Nov 2008 11:05:00
Message: <web.491afea43371f17d8980caa70@news.povray.org>
Here's another bug.

This works:

#declare fn_C = function { clock }

This doesn't:

#declare fn_C = function { frame_number }


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.