Oddly, sum and prod are considered to be numbers -- when POV-Ray is looking for
numbers:

#debug concat("sum = ",str(sum,0,3),"; prod = ",str(prod,0,3),"\n")


So far as I can tell, this is due to a discrepancy between
'backend/parser/reswords.h' and 'backend/parser/express.cpp'.  Specifically,
SUM_TOKEN and PROD_TOKEN both appear before FLOAT_FUNCT_TOKEN in the TOKEN_IDS
enum (reswords.h), so they get treated as float functions (when POV-Ray isn't
doing function compilation); however, neither SUM_TOKEN nor PROD_TOKEN is
handled in Parser::Parse_Num_Factor (express.cpp), so they fall through the
switch statement beginning on line 687.  The result is that whatever is sitting
in the memory location for Val gets returned as being the value of 'sum' or
'prod' (for me, this tends to be a denormalized number).

[Note that the source references are from the 3.7.0.beta.35a source...]




Also, I was curious why POV-Ray is only picky about argument delimiters (that
is, commas) some of the time.

For instance, POV-Ray is perfectly happy with this:

#macro A(b c)b+c#end
#declare a=0;
#declare b=A(1a);
#declare f=function{A(a.3)+A(A(1a)1)}
#debug str(b(0)3)
#debug"\n"
#debug str(pow(3!1)0(3))
#debug "\n"
#debug str(f(0
0a)0 3)
#debug "\n"
#debug vstr(3x"a"1!2+2)
#debug "\n"


However, it is not happy with this:

#declare f=function{pow(3!1)}


It isn't happy with this, either:

#macro A(b(c))b+c#end


Nor this:

#macro A(b c)b+c#end
#declare a=0;
#declare b=A(1A(1a));


Nor this:

#debug("a\n")



Why?




(For reference, I'm using the unofficial 64-bit Mac version of POV-Ray
3.7.0.beta.36 provided by the MegaPOV-Team; however, all of the oddities also
occur under a self-compiled (unofficial) version of POV-Ray 3.6.1.  I'm running
Mac OS X 10.6.3 on an Intel Core 2 Duo with 4 GB of memory.)


Bent

Post a reply to this message

Bent wrote:

> Also, I was curious why POV-Ray is only picky about argument delimiters (that
> is, commas) some of the time.

I suppose it's mostly a matter of organic growth.
Of course, your working code sample should be avoided
outside of short code competitions ;)

> However, it is not happy with this:
> 
> #declare f=function{pow(3!1)}

Functions are treated rather specially anyway.
Other things such as arrays also do not work
inside functions.

> It isn't happy with this, either:
> 
> #macro A(b(c))b+c#end

I'm not sure why you would expect this to work.
It's not as if parentheses are just something to
separate identifiers and be discarded.

> #debug("a\n")

That is as documented although I'd find a syntax
with parentheses more natural as well for #debug,
#fopen, #fclose, #warning and #error.

Post a reply to this message

Am 19.04.2010 23:34, schrieb Bent:

> Oddly, sum and prod are considered to be numbers -- when POV-Ray is looking for
> numbers:
>
> #debug concat("sum = ",str(sum,0,3),"; prod = ",str(prod,0,3),"\n")

Thatnks for pointing this out - and thanks for the thorough analysis; 
from what I see, you're perfectly right.


> Also, I was curious why POV-Ray is only picky about argument delimiters (that
> is, commas) some of the time.

Basically, the rules are simple: Commas are optional, always and 
everywhere (though in some cases omitting them may change the meaning, 
e.g. "1,-2" is two numeric exptessions while "1-2" is a single numeric 
expression) - *except in functions*, where commas are *mandatory*.

What happens when you leave them out depends:

> For instance, POV-Ray is perfectly happy with this:
>
> #macro A(b c)b+c#end
> #declare a=0;
> #declare b=A(1a);

The above should be rather easy to understand. The last one may be the 
most surprising, but as everything starting with a "." or digit is 
considered a number token, and "a" is never part of such a token, 
POV-Ray decides that the "a" must start a new token.

> #declare f=function{A(a.3)+A(A(1a)1)}

While commas are /not/ optional in functions, you do have macro calls 
here, which get resolved even before the function parser ever gets to 
see them.

> #debug str(b(0)3)

This sould be simple again. Note that (0) is a valid numeric expression 
(which, not surprisingly, evaluates to 0).

> #debug"\n"
> #debug str(pow(3!1)0(3))

Again, "!1" is a valid numeric expression, evaluating to 0. As there's 
no binary operator between "3" and "!1", POV-Ray decides that they can't 
be a single expression.

> #debug "\n"
> #debug str(f(0
> 0a)0 3)

While functions are involved here, function /calls/ from normal SDL code 
are still within the domain of the SDL parser, allowing you to drop 
commas here.

> #debug "\n"
> #debug vstr(3x"a"1!2+2)

Ugly, but evaluates to the same as

#debug vstr(3,x,"a",1,!2+2)


> However, it is not happy with this:
>
> #declare f=function{pow(3!1)}

In this case, "pow" is not a macro, so this will all be handled by the 
function parser, which insists on having commas.

> It isn't happy with this, either:
>
> #macro A(b(c))b+c#end

Here, POV-Ray is /not/ unhappy about the missing comma, but rather about 
the parentheses around the identifier name. It will not accept the 
following either:

#macro A(b,(c)) b + c #end

> Nor this:
>
> #macro A(b c)b+c#end
> #declare a=0;
> #declare b=A(1A(1a));

I must confess that this is a puzzler to me as well; theoretically it 
should work, but it doesn't.

> Nor this:
>
> #debug("a\n")

This is simple again: #debug expects a single string without 
parentheses. With numerical values that wouldn't make a difference, as a 
parenthesized expression is a valid numerical expression as well, but 
string expressions cannot be parenthesized. For instance, the following 
is illegal as well:

#declare MyString = concat("a", ("b"), "c");

> Why?

To teach you a habit of /always/ using commas? ;-)

Post a reply to this message

"Bent" <ben### [at] gmailcom> wrote:

> ( ... I'm using the unofficial 64-bit Mac version of POV-Ray
> 3.7.0.beta.36 provided by the MegaPOV-Team; ... )
>
>
> Bent

Sorry for asking an off-topic question:

I just checked with the megapov site and can't locate the version you are
referring to.

Bent, where to get that version that you are using?

Post a reply to this message

"..... ...... ......" <nomail@nomail> schreef in bericht 
news:web.4bd1248f92d4875f4f801fa50@news.povray.org...
> "Bent" <ben### [at] gmailcom> wrote:
>
>> ( ... I'm using the unofficial 64-bit Mac version of POV-Ray
>> 3.7.0.beta.36 provided by the MegaPOV-Team; ... )
>>
>>
>> Bent
>
> Sorry for asking an off-topic question:
>
> I just checked with the megapov site and can't locate the version you are
> referring to.
>
> Bent, where to get that version that you are using?
>

I think that Bent means POV-Team instead of MegaPOV-Team... :-)

Thomas

Post a reply to this message

Thomas de Groot wrote:

> I think that Bent means POV-Team instead of MegaPOV-Team... :-)

In fact, the unofficial 3.7 beta 36 for Mac resides at

   http://megapov.inetart.net/beta/pv37_b36.zip

and

   http://megapov.inetart.net/beta/pv37_64_b36.zip

see

http://news.povray.org/povray.beta-test/thread/%3C1jfpa6h.yjps9j1ceaw8eN%25yvo.s@cancel_This_gmx.net%3E/

Post a reply to this message

Not being a Mac user myself, that explains it  :-)

Interesting to discover though, that this resides at the *official* megapov 
site...

Thomas

Post a reply to this message