https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9945627

Post a reply to this message

hi,

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

the benchmark is four-tenths of a second slower than 9893777.  :-)


regards, jr.

Post a reply to this message

Am 28.11.2018 um 20:57 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9945627
> 
> 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.

Post a reply to this message

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

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

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

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

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

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

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