I'm not that much into how functions work and should work, but this surely
must be a bug?

The following code:

#declare V = 0.1;
#declare Myfunction = function (V) {V*2}
sphere {x, V}

Gives the error:

"#declare V = 0.1;

#declare Myfunction = function (V <----ERROR

Parse Error: Expected 'parameter identifier', float function 'float
identifier' found instead


Returned from renderer with error status"

I'm using POV-Ray 3.5 beta 6
on a P150, 16MB RAM
Windows 95  4.00.450 B  IE 5 5.00.2919.6307

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

V does not represent your function, it's just a parameter. As it is now you
are telling povray to do:
#declare Myfunction (0.1) (0.1*2)
sphere {x, 0.1)
which isn't correct.

try something like this:

#declare Myfunction = function (V) {V*2}
sphere {x, Myfunction (0.1)}

--
Jonathan.

Post a reply to this message

"JRG" wrote:
> V does not represent your function, it's just a
> parameter. As it is now you are telling povray to do:
> #declare Myfunction (0.1) (0.1*2)

But shouldn't the parameters use a different name-space than things declared
outside of the functions, just like it works with macros?

This:

#declare V = 0.1;
#include "math.inc"

gives an error because a function in math.inc uses V as a parameter! We
can't have that, now can we?

> try something like this:
>
> #declare Myfunction = function (V) {V*2}
> sphere {x, Myfunction (0.1)}

No because that's not what I want. I want the function to leave alone my
declared floats and stop bothering them.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> But shouldn't the parameters use a different name-space than things declared
> outside of the functions, just like it works with macros?
> 

Since it's leagal to use declared variables in functions, this would lead
to at least a lot of confusion.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Ah aaah.... now I understand...
You want to give your float identifiers any name you want without bothering
that that name is already used somewhere (for example in math.inc) as a
function parameter. But why bother? Just use another identifier. Of course I
usually expect an uppercased identifier (such as R) to work in any
situation, but this could be just a minor problem in math.inc design.

--
Jonathan.

"Rune" <run### [at] mobilixnetdk> ha scritto nel messaggio
news:3bd9fd4e@news.povray.org...
> "JRG" wrote:
> > V does not represent your function, it's just a
> > parameter. As it is now you are telling povray to do:
> > #declare Myfunction (0.1) (0.1*2)
>
> But shouldn't the parameters use a different name-space than things
declared
> outside of the functions, just like it works with macros?
>
> This:
>
> #declare V = 0.1;
> #include "math.inc"
>
> gives an error because a function in math.inc uses V as a parameter! We
> can't have that, now can we?
>
> > try something like this:
> >
> > #declare Myfunction = function (V) {V*2}
> > sphere {x, Myfunction (0.1)}
>
> No because that's not what I want. I want the function to leave alone my
> declared floats and stop bothering them.
>
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
> POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
> POV-Ray Webring: http://webring.povray.co.uk
>
>

Post a reply to this message

In article <3bd9fd4e@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> But shouldn't the parameters use a different name-space than things declared
> outside of the functions, just like it works with macros?

No, because one is the scene level and the other the parser level.  The
parser values are inserted first by substituting every variable you
declared.  The resulting scene file (which is invisible to you) is the
passed on the the actual parser which only sees the 0.1 as it should because
the "V" has been substituted by "0.1" as you requested.

You mistake is part of the functions are no macros misunderstanding!


    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

"Christoph Hormann" wrote:
> Since it's leagal to use declared variables in functions,

When you *call* functions, not when you initiate them! At least it shouldn't
be since it makes no sense at all.

Take a macro:

#declare V = 0.1:
#macro MyMacro(V) V*2 #end
sphere {x, 0.1}

Here's there's no problem since the parameter in the macro doesn't conflict
with already declared variables. You can still call the macro with the
declared variable and *then* it will be used:

#declare B = MyMacro(V);

But with functions a conflict happens at the time of declaring the function
and that's all wrong.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"JRG" wrote:
> But why bother? Just use another identifier.

To use long cryptic parameter names and/or variable names just to avoid a
name conflicts is not an acceptable solution. You can never know if some
include file uses the same name you're using for your variables.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3bda83a9$1@news.povray.org> , "Rune" 
<run### [at] mobilixnetdk> wrote:

> When you *call* functions, not when you initiate them! At least it shouldn't
> be since it makes no sense at all.
>
> Take a macro:
>
> #declare V = 0.1:
> #macro MyMacro(V) V*2 #end
> sphere {x, 0.1}
>
> Here's there's no problem since the parameter in the macro doesn't conflict
> with already declared variables. You can still call the macro with the
> declared variable and *then* it will be used:
>
> #declare B = MyMacro(V);
>
> But with functions a conflict happens at the time of declaring the function
> and that's all wrong.

Repeat after we:

Functions are not macros.  Functions are not macros.  Functions are not
macros.  Functions are not macros.   Functions are not macros. ...

    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

"Thorsten Froehlich" wrote:
> The parser values are inserted first by substituting
> every variable you declared.

But it doesn't make sense to have parameters that are constant! And indeed
an error is generated as I reported! The *only* result of the way it woks
now is apparently that parameter names cannot use the same name as declared
variables and that's *very* inconvenient, as it's very common to use
one-letter names for both variables and for function parameters.

> You mistake is part of the functions are no macros misunderstanding!

But what's the logic behind how it works? It seems to be a big limitation
that have no positive effects at all...

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> > Since it's leagal to use declared variables in functions,
> 
> When you *call* functions, not when you initiate them! At least it shouldn't
> be since it makes no sense at all.
> 
> [...]

Surely also when you initiate them, and this makes a lot of sense.

I would find constructs like the following extremely irritating:

#declare V = 0.1;
#declare Myfunction = function (V, x) {V*x}
#declare Myfunction2 = function (x) {V*x}

I know macros work this way, but as Thorsten mentioned, they are something
completely different.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

"Christoph Hormann" wrote:
> Rune wrote:
> >
> > > Since it's leagal to use declared variables in functions,
> >
> > When you *call* functions, not when you initiate them! At least it
shouldn't
> > be since it makes no sense at all.
> >
> > [...]
>
> Surely also when you initiate them, and this makes a lot of sense.

You say it's legal an useful to use declared variables as parameters when
declaring a function. But I can't see how, as it just generates an error, as
I reported. Please post an example.

> I would find constructs like the following extremely irritating:
>
> #declare V = 0.1;
> #declare Myfunction = function (V, x) {V*x}

This should make V a parameter, unrelated to the variable V IMO.
Currently it generates an error. What's the use in that?
How do *you* think it should work?

> #declare Myfunction2 = function (x) {V*x}

This should use the variable V, and it does, so there's no problem here.

> I know macros work this way, but as Thorsten mentioned,
> they are something completely different.

I still don't see how the current behavior makes any sense!

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3bda9ead@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

>> I know macros work this way, but as Thorsten mentioned,
>> they are something completely different.
>
> I still don't see how the current behavior makes any sense!

Well, if you don't understand the reasoning so far, try to see it this way:

A # declared variable is just like a macro without any parameters (it really
is, also the docs don't and won't explain it that way).  So whenever POV-Ray
finds the string matching the #declared variable it will just replace it
with whatever the value of the #declared variable.

    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

"Thorsten Froehlich" wrote:
> Well, if you don't understand the reasoning so far,
> try to see it this way:

Thorsten, it's not that I don't understand how function parameters work,
what I don't understand is why they're designed to work that way.

I know macros and functions are different things, but I think the parameters
in functions should work the same way as the parameters in macros. As I
said, the current implementation is a great limitation that has no
advantages at all! All it means is that you have to make sure that the names
of the parameters in your functions never are the same as any declared
variable identifiers. That gets very difficult when working with include
files containing functions made by other people. Are we really supposed to
never use function parameters with names identical to variable identifiers?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3bdab763@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Thorsten, it's not that I don't understand how function parameters work,
> what I don't understand is why they're designed to work that way.

Because POV-Ray directives are designed to work this way.  They sit "on top"
of your scene.  Contrary to macros functions are _part_of_the_scene_ and as
such are and have to be handled different from macros.

Would you expect the scene below to work as well? - It would be a
consequence of what you are asking for (as I explained above) and obviously
does not make sense!

    #declare foo = function(a,b,c)
    {
        #while(a > 0)
            (b - a) *
            #declare a = a - 1;
        #end
        c
    }


____________________________________________________
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

"Thorsten Froehlich" wrote:
> Would you expect the scene below to work as well?

I don't ask for a change of the part between the {...} brackets, all I ask
is that the function parameters are made local to the function so they don't
conflict with existing variables.

Consider this code:

#declare A = 0.1;
#declare foo = function(A) {A*2}

Now when the parser reaches function(A) it "calls" the already declared
variable A and then generates an error.

Then consider this code:

#declare foo = function(C) {C*2}
#declare D = C;

Here C has not been already declared and thus the function can use C as a
parameter. That must mean that C is somehow being #declared by the function
when the function is parsed. But after the function has been declared the
variable C is not available anymore, as can be seen when attempting to
render the line #declare D = C;. That must mean that C is local to the
function.

All I'm asking is that functions *always* create local variables for the
parameters, no matter if existing variables exist that have the same name as
the function parameters. Wouldn't that be more logical? And would't it be
possible to implement?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3bdad6fb@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> All I'm asking is that functions *always* create local variables for the
> parameters, no matter if existing variables exist that have the same name as
> the function parameters. Wouldn't that be more logical? And would't it be
> possible to implement?

You still did not understand which means I am not able to explain it well
enough :-(

What you are assuming is that function variables have a scope within the
parser like #declared variables have.  But they do not have any scope at
all!  They are not part of the parser and its #declared variables.  If they
had a scope in the context of the parser as you expect them to have (because
otherwise the #declared values could not be "hidden" inside functions) the
example I gave would be valid, but it is not and cannot be valid without
changing the fundamentals of what functions are (it would make them to
macros).  Let me try a different example (based on some other discussion
that took place in this groups recently).  It shows a problem the change you
are asking for would create (unless it would be made illegal).  I hope it
illustrates the problem of adding function parameters to any parser level
scope:

#declare foo = function(a,b,c)
{
    a +
    #declare b = 5;
    c + b // What is 'b' now assuming either model of operation???
}

Currently the answer is:  'b' will be substituted by '5'

You ask for:  It should either remain 'b' or be an error.  Neither makes
              sense to me.  I hope neither makes sense to you and it
              explains the problem with adding a scope for function
              parameters to the parser.

____________________________________________________
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

"Thorsten Froehlich" wrote:
> You still did not understand which means I am not able
> to explain it well enough :-(

I still don't understand I'm afraid. In this one-line example:

#declare foo = function(C) {C*2}

C is not defined before the function. C *is* defined inside the function
{...} brackets. C is not defined after the function brackets. If that
doesn't mean that C is local to the function, then what does it mean?

> #declare foo = function(a,b,c)
> {
>     a +
>     #declare b = 5;
>     c + b // What is 'b' now assuming either model of operation???
> }
>
> Currently the answer is:  'b' will be substituted by '5'

That's what I want too. Only if B is declared *before* the function it
shouldn't affect the function, like here:

> #declare b = 5;
> #declare foo = function(a,b,c)
> {
>     a + c + b // What is 'b' now assuming either model of operation???
> }
> #declare q = foo(7,8,9)

In this example an error occurs, but I would like the b in the function to
be substituted with the b parameter fed to the function when it is invoked
(ie. 8), not the b variable declared before the function.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

I think I see the problem here. The code

  #declare V = 0.1;
  #declare Myfunction = function (V) {V*2}
  sphere {x, V}

is internally transformed into something like

  #declare Myfunction = function (0.1) {0.1*2}
  sphere {x, 0.1}

But why can't the parser transform it into something like this instead?

  #declare Myfunction = function (Myfunction_V) {Myfunction_V*2}
  sphere {x, 0.1}

Post a reply to this message

"Anders K." wrote:
> But why can't the parser transform it into something
> like this instead?
>
>   #declare Myfunction = function (Myfunction_V) {Myfunction_V*2}
>   sphere {x, 0.1}

Yeah, that's what I mean too.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3bdae970@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> "Thorsten Froehlich" wrote:
>> You still did not understand which means I am not able
>> to explain it well enough :-(
>
> I still don't understand I'm afraid. In this one-line example:
>
> #declare foo = function(C) {C*2}
>
> C is not defined before the function. C *is* defined inside the function
> {...} brackets. C is not defined after the function brackets. If that
> doesn't mean that C is local to the function, then what does it mean?

Sorry, if you still ask this question than I failed and I am unable to
explain it better.  Sorry!


    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

Rune <run### [at] mobilixnetdk> wrote:
: #declare foo = function(C) {C*2}

: C is not defined before the function. C *is* defined inside the function
: {...} brackets.

  Nope, it isn't. Not from the point of view of the parser. It is not an
identifier which the parser sees.
  That 'C' has become a variable in the function evaluation engine, which is
a completely different beast than the parser. The parser doesn't know anything
about functions, and the function handler doesn't know anything about the
parser. The parser has no notion of a variable/identifier called 'C'.
  In the same way if you had declared an identifier called 'D', then the
*parser* sees and recognizes that 'D', but the function handler is completely
unaware of it (the parser can give the function the value of 'D', but the
function handler doesn't see 'D' in any way).

  Think about the function definition (what is inside { and }) as a string
which is just raw data to the parser unless it contains something the
parser recognizes (eg. a previously declared identifier).

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

"Thorsten Froehlich" wrote:
> Sorry, if you still ask this question than I failed
> and I am unable to explain it better.  Sorry!

Anyway, if it can't be fixed, I presume that means that all functions in
include files have to use very special names for the parameters to minimize
the risc that the user has variables with identical names.

For example these functions from math.inc:

#declare sind = function (V) {sin(radians(V))}
#declare adj_range2 = function (V, Mn, Mx, OMn, OMx) {((V - Mn)/(Mx -
Mn))*(OMx - OMn) + OMn}

must be changed to something like:

#declare sind = function (__V) {sin(radians(__V))}
#declare adj_range2 = function (__V, __Mn, __Mx, __OMn, __OMx) {((__V -
__Mn)/(__Mx - __Mn))*(__OMx - __OMn) + __OMn}

Is that really so?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3bdb16aa@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> must be changed to something like:
>
> #declare sind = function (__V) {sin(radians(__V))}
> #declare adj_range2 = function (__V, __Mn, __Mx, __OMn, __OMx) {((__V -
> __Mn)/(__Mx - __Mn))*(__OMx - __OMn) + __OMn}
>
> Is that really so?

I think the naming you have is nearly failsafe.  You could also check if the
variables used in math.inc have been declared and then simply output to
#error (which may or may not be 'fixed' for beta 7).

    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

"Warp" wrote:
>   Think about the function definition (what is inside
> { and }) as a string which is just raw data to the parser
> unless it contains something the parser recognizes (eg. a
> previously declared identifier).

Ok. Could you say that the parser has "first rights" to see the code, and
only afterwards the function engine gets to see the code? Thus, if something
is named similar to both a variable and a parameter, it's the variable that
counts?

Is that correctly understood?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message