POV-Ray : Newsgroups : povray.beta-test : POV-Ray v3.8.0-alpha.9945627 Server Time
28 Mar 2024 08:42:21 EDT (-0400)
  POV-Ray v3.8.0-alpha.9945627 (Message 4 to 13 of 13)  
<<< Previous 3 Messages Goto Initial 10 Messages
From: jr
Subject: Re: POV-Ray v3.8.0-alpha.9945627
Date: 28 Nov 2018 17:10:01
Message: <web.5bff111db0fe7d71c98b24460@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 28.11.2018 um 20:57 schrieb jr:
> > the benchmark is four-tenths of a second slower than 9893777.  :-)
> Given the nature of the changes, I find even such a miniscule difference
> difficult to believe, and invoke measurement error.
                                   ^^^^^^^^^^^^^^^^^

  :-)


btw, how much parse time difference do you expect between this and the
x.tokenizer (compared to the previous)?


regards, jr.


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-alpha.9945627
Date: 28 Nov 2018 18:30:05
Message: <5bff24fd@news.povray.org>
Am 28.11.2018 um 23:05 schrieb jr:

> btw, how much parse time difference do you expect between this and the
> x.tokenizer (compared to the previous)?

I haven't found time to work on the tokenizer recently, so there's not 
much difference between x.tokenizer.9945666 and x.tokenizer.9844488, and 
I expect no measurable difference at all between those.

As for the difference between x.tokenizer.9945666 and alpha.9945627, 
that totally depends on the structure of the source code, and the 
architectural changes run too deep to make any quantitative predictions 
for any given scene. I had originally hoped for roughly similar parsing 
times at this stage while fearing slightly worse. So far it seems that 
the implementation is performing a tad beyond my hopes in most cases, 
while matching my fears (but for other reasons than I had anticipated) 
in a few other cases.

In other words, from experience so far I would expect most scenes to 
parse slightly faster, while some special cases may still parse slower.

I'd like to mention that I'm interested in hearing about any of the latter.


Post a reply to this message

From: jr
Subject: Re: POV-Ray v3.8.0-alpha.9945627
Date: 28 Nov 2018 19:35:00
Message: <web.5bff33c4b0fe7d71c98b24460@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 28.11.2018 um 23:05 schrieb jr:
>
> > btw, how much parse time difference do you expect between this and the
> > x.tokenizer (compared to the previous)?
>
> I haven't found time to work on the tokenizer recently, so there's not
> much difference between x.tokenizer.9945666 and x.tokenizer.9844488, and
> I expect no measurable difference at all between those.

ok.


> As for the difference between x.tokenizer.9945666 and alpha.9945627,
> ...
> In other words, from experience so far I would expect most scenes to
> parse slightly faster, while some special cases may still parse slower.
>
> I'd like to mention that I'm interested in hearing about any of the latter.

ok.  I'll install it and run some scenes over the coming week.


regards, jr.


Post a reply to this message

From: jr
Subject: Re: POV-Ray v3.8.0-alpha.9945627
Date: 4 Dec 2018 19:25:01
Message: <web.5c071a8eb0fe7d71e43b71790@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9945627

this version allows me to omit a comma in a dictionary, I'm guessing that's
unintended?

#declare X = dictionary {
  .v0 : array
  .v1 : 0,
  .v2 : 1
};

same for x.tokenizer.9945666.

regards, jr.


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-alpha.9945627
Date: 4 Dec 2018 23:24:21
Message: <5c0752f5$1@news.povray.org>
Am 05.12.2018 um 01:24 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9945627
> 
> this version allows me to omit a comma in a dictionary, I'm guessing that's
> unintended?
> 
> #declare X = dictionary {
>    .v0 : array
>    .v1 : 0,
>    .v2 : 1
> };
> 
> same for x.tokenizer.9945666.
> 
> regards, jr.

No, that's entirely intentional. Commas are always optional, provided 
that this doesn't lead to ambiguity.

For example, the following will NOT work:

     #declare Foo = <1,2,3>;
     #declare X = dictionary {
        .v0 : Foo
        .v1 : 0,
        .v2 : 1
     };

That's because `Foo` is a vector, so POV-Ray would misinterpret the `.` 
in `.v1` as belonging to `Foo`, and expect either `x`, `y`  or `z` to 
follow. Placing a comma after `Foo` indicates to POV-Ray that this 
expression is completed.


As another example, consider the following:

     #declare Foo = <1 2 3>;

This will declare a 3-dimensional vector. On the other hand, the 
following will declare a 2-dimensional vector:

     #declare Foo = <1 -2 3>;

That's because POV-Ray interprets `1 -2` as the expression `1-2`, i.e. 
the single value -1.


Post a reply to this message

From: jr
Subject: Re: POV-Ray v3.8.0-alpha.9945627
Date: 5 Dec 2018 11:25:02
Message: <web.5c07fb1cb0fe7d71e43b71790@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 05.12.2018 um 01:24 schrieb jr:
> > ... unintended?
> >
> No, that's entirely intentional. Commas are always optional, provided
> that this doesn't lead to ambiguity.

I have the feeling I knew but then forgot.  :-(


> This will declare a 3-dimensional vector. On the other hand, the
> following will declare a 2-dimensional vector:
>
>      #declare Foo = <1 -2 3>;
>
> That's because POV-Ray interprets `1 -2` as the expression `1-2`, i.e.
> the single value -1.

heh, a real trap for the unwary.


while on punctuation,  following your reply to ingo on brackets etc (facepalm
moment :-)) I re-read the declaring arrays section (3.3.1.10.1), and noticed in
the table titled "Additional usage examples are as follows" the use of
semicolons after the #undefs.  the documentation (3.3.2.2.4) offers no
explanation.

so when I added semicolons to my recent 'queues.inc' ([*]  I know it's not the
same since I'm not removing dictionary keys, just .. experimenting), I found
that of the four (near) identical uses, two throw an error while the other
two work unchanged.

the error is:  Parse Error: Expected 'numeric expression', ; found instead

occurring in the get/pop macros but working in the destroys.

the respective line numbers, referring to the file posted: 41 + 102 are ok, 57 +
115 cause "trouble".


regards, jr.

[*] http://news.povray.org/web.5be1d482cfca02966427f7f90%40news.povray.org


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-alpha.9945627
Date: 5 Dec 2018 13:44:23
Message: <5c081c87$1@news.povray.org>
Am 05.12.2018 um 17:23 schrieb jr:

> while on punctuation,  following your reply to ingo on brackets etc (facepalm
> moment :-)) I re-read the declaring arrays section (3.3.1.10.1), and noticed in
> the table titled "Additional usage examples are as follows" the use of
> semicolons after the #undefs.  the documentation (3.3.2.2.4) offers no
> explanation.

The examples are wrong - my bad. As a C++ programmer I tend to add 
semicolons where POV-Ray expects none. If semicolons work at the end of 
`#undef` in some cases, that's only by coincidence.

(http://wiki.povray.org/content/Reference:Array#Declaring_Arrays)


Post a reply to this message

From: dick balaska
Subject: Re: POV-Ray v3.8.0-alpha.9945627
Date: 5 Dec 2018 22:37:06
Message: <5c089962$1@news.povray.org>
On 12/4/18 11:24 PM, clipka wrote:

> 
> Commas are always optional, provided that this doesn't lead to ambiguity.
> 

*gurgle* man I hate that.  I get it, but these little odd nuances make
it near impossible for someone else to write a parser.  SDL is a rough
enough language as it is...


-- 
dik
Rendered 1024 of 921600 pixels (0%)


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-alpha.9945627
Date: 6 Dec 2018 06:55:21
Message: <5c090e29$1@news.povray.org>
Am 06.12.2018 um 04:37 schrieb dick balaska:
> On 12/4/18 11:24 PM, clipka wrote:
> 
>>
>> Commas are always optional, provided that this doesn't lead to ambiguity.
>>
> 
> *gurgle* man I hate that.  I get it, but these little odd nuances make
> it near impossible for someone else to write a parser.  SDL is a rough
> enough language as it is...

You're telling me.


Post a reply to this message

From: jr
Subject: Re: POV-Ray v3.8.0-alpha.9945627
Date: 6 Dec 2018 08:05:01
Message: <web.5c091d9fb0fe7d71e43b71790@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 06.12.2018 um 04:37 schrieb dick balaska:
> > On 12/4/18 11:24 PM, clipka wrote:

(in earlier message)
> > while on punctuation,,  ...
> The examples are wrong - my bad. As a C++ programmer ...

cheers.


> >> Commas are always optional, provided that this doesn't lead to ambiguity.
> >>
> >
> > *gurgle* man I hate that.  I get it, but these little odd nuances make
> > it near impossible for someone else to write a parser.  SDL is a rough
> > enough language as it is...
>
> You're telling me.

can you not use this opportunity to "shape" the future?  eg if you said from
version 3.9 or 3.10 the parser -- too lenient now -- will get "tightened", like
no more #declare without terminating semicolon, or even force ("nudge" ;-))
people into using commas consistently.  with the '#declare deprecated' you
already have a mechanism, no?

personally I'd like to see a '#pragma' keyword that would, among other things,
allow disabling certain parser warnings like "no object in scene", perhaps:
  #pragma disable_warning_*

or an enhanced #debug?  a real bugbear since I frequently have "scenes" that
only calculate or try something, ie without cameras, lights, and objects.

regards, jr.


Post a reply to this message

<<< Previous 3 Messages Goto Initial 10 Messages

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