![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 25 Jul 2021 17:27:37
Message: <60fdd749$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 25.07.2021 um 23:23 schrieb clipka:
> For ISO/IEC 9899:1999, that forms the main basis for C++, I only have
That was supposed to read "... the main basis for C++11". Which is the
minimum language revision required to build POV-Ray v3.8.
(In POV-Ray v3.7, which requires C++99 as the minimum language version,
the earlier C89 standard would apply, which is even more limited.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 25 Jul 2021 18:00:58
Message: <60fddf1a$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
It might be worth weaving the following information into the
documentation of our "datetime" function:
-------------------------
Which codes are supported depends on the platform POV-Ray is compiled
an/or running on.
In POV-Ray v3.7, the following codes can be expexted to work reliably:
a,A,b,B,c,d,H,I,j,m,M,p,S,U,w,W,x,X,y,Y,Z,%
In POV-Ray v3.8, the following additional codes can be expexted to work
reliably:
a,A,b,B,c,C,d,D,e,F,g,G,h,H,I,j,m,M,n,p,r,R,S,t,T,u,U,V,w,W,x,X,y,Y,z,Z,%
-------------------------
(Side note: The C99/C++11 standards define additional two-letter codes
starting with E or O; while those should also work in POV-Ray v3.8,
their result _will_ differ between systems, depending on the language
settings of the computer.
(Also, note to self and fellow developers: It may be worth adding a
check in POV-Ray itself, to verify whether the formatting string
submitted is actually portable across platforms, and warn if it isn't.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
clipka <ano### [at] anonymous org> wrote:
I thank you for the (detailed) clarification re status of "%s" (and yr time). I
dug up a PDF (N1256, Committee Draft 7.9.2007) and was shocked (sort of) to find
no mention of "%s".
and also a big thank you for writing "..in POV-Ray, `now` already is a numeric
value..", this has cleared up a complete misunderstanding. the documentation
says 'now' is a "keyword" and only illustrates its use in a 'datetime()' call.
I had not realised that 'now' can be used outside 'datetime()'. :-) so the
demo scene TdG mentioned simply needs a (fairly) reliable unique seed for the
RNG, whenever it's rendered. made a couple of quick tests with 'now', and am
thinking of using something like the following to replace the
'datetime(now,"%s")', and would appreciate comment(s):
#declare seed_ = mod((now-int(now))*1e16,1e9);
> It might be worth weaving the following information into the
> documentation of our "datetime" function:
and perhaps improve description of 'now'.
regards, jr.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Cousin Ricky
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 26 Jul 2021 10:54:21
Message: <60fecc9d$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 2021-07-26 4:34 AM (-4), jr wrote:
>
> and perhaps improve description of 'now'.
The 'now' keyword is documented in the float built-in variables section
of the 3.8 reference manual (as it should be), but unlike most of the
other variables in that section, the word 'now' is not its own header,
so it is easy to miss. (The same is true of the 'version' keyword.)
The documentation of 'datetime' could use a cross reference to the 'now'
description.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 26 Jul 2021 14:46:34
Message: <60ff030a$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 26.07.2021 um 10:34 schrieb jr:
> demo scene TdG mentioned simply needs a (fairly) reliable unique seed for the
> RNG, whenever it's rendered. made a couple of quick tests with 'now', and am
> thinking of using something like the following to replace the
> 'datetime(now,"%s")', and would appreciate comment(s):
>
> #declare seed_ = mod((now-int(now))*1e16,1e9);
- Variable name should use uppercase as the first letter. Just saying.
- No need for `mod`, as the seeding via `#declare MyRNG = seed(seed_);`
already effectively does a `mod` operation with a modulus of 2^32 (ca. 4e9).
- Taking the time of day, rather than the running total, is a smart move
I probably wouldn't have thought of, and had me thinking thrice to
figure out whether it even has any advantage. (My preliminary
conclusion: I think it does.)
- Multiplying with 1e16 seems excessive. The value is given in days, and
has a precision of microseconds at best; 8.64e10 would be the ideal
factor in that case. Some systems may even provide timers as slow as one
tick mer millisecond, in which case there would be little point in using
a factor larger than 8.64e6.
There might be some point in multiplying with a very large number and
then applying `mod`, so that seeds quickly diverge. But that doesn't
work when the multiplying factor is a multiple of the modulus - you'd
ideally want coprime values for that, otherwise you're not shuffling
around information, you're just ditching digits.
This should be easy to accomplish by using any odd (in the literal
sense) multiplier, while ditching your own mod and relying on the
inbuilt mod 2^32 operation. I have a hunch that numbers with a
well-balanced number of binary ones and zeros would be ideal.
The following might do nicely:
#declare seed_ = (now-int(now))*(1e9+1);
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Alain Martel
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 27 Jul 2021 10:40:25
Message: <61001ad9$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Am 26.07.2021 um 10:34 schrieb jr:
>
>> demo scene TdG mentioned simply needs a (fairly) reliable unique seed
>> for the
>> and am
>> thinking of using something like the following to replace the
>> 'datetime(now,"%s")', and would appreciate comment(s):
>>
>> #declare seed_ = mod((now-int(now))*1e16,1e9);
>
> - Variable name should use uppercase as the first letter. Just saying.
>
> - No need for `mod`, as the seeding via `#declare MyRNG = seed(seed_);`
> already effectively does a `mod` operation with a modulus of 2^32 (ca.
> 4e9).
>
> - Taking the time of day, rather than the running total, is a smart move
> I probably wouldn't have thought of, and had me thinking thrice to
> figure out whether it even has any advantage. (My preliminary
> conclusion: I think it does.)
>
> - Multiplying with 1e16 seems excessive. The value is given in days, and
> has a precision of microseconds at best; 8.64e10 would be the ideal
> factor in that case. Some systems may even provide timers as slow as one
> tick mer millisecond, in which case there would be little point in using
>
>
> There might be some point in multiplying with a very large number and
> then applying `mod`, so that seeds quickly diverge. But that doesn't
> work when the multiplying factor is a multiple of the modulus - you'd
> ideally want coprime values for that, otherwise you're not shuffling
> around information, you're just ditching digits.
>
> This should be easy to accomplish by using any odd (in the literal
> sense) multiplier, while ditching your own mod and relying on the
> inbuilt mod 2^32 operation. I have a hunch that numbers with a
> well-balanced number of binary ones and zeros would be ideal.
>
> The following might do nicely:
>
When I want coprimes, I often plug in pi in the mix, or use two values
that differ by 1. It could be something like :
#declare Seed_ = mod(now*pi*100000000, 87654321);
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
clipka <ano### [at] anonymous org> wrote:
> Am 26.07.2021 um 10:34 schrieb jr:
>> #declare seed_ = mod((now-int(now))*1e16,1e9);
>
> - Variable name should use uppercase as the first letter. Just saying.
:-) I can live with camelcase like 'fooBarBaz' but..
> - No need for `mod`, as the seeding via `#declare MyRNG = seed(seed_);`
> already effectively does a `mod` operation with a modulus of 2^32 (ca. 4e9).
>
> - Taking the time of day, rather than the running total, is a smart move
> I probably wouldn't have thought of, and had me thinking thrice to
> figure out whether it even has any advantage. (My preliminary
> conclusion: I think it does.)
>
> - Multiplying with 1e16 seems excessive. The value is given in days, and
> has a precision of microseconds at best; 8.64e10 would be the ideal
> factor in that case. Some systems may even provide timers as slow as one
> tick mer millisecond, in which case there would be little point in using
> a factor larger than 8.64e6.
>
> There might be some point in multiplying with a very large number and
> then applying `mod`, so that seeds quickly diverge. But that doesn't
> work when the multiplying factor is a multiple of the modulus - you'd
> ideally want coprime values for that, otherwise you're not shuffling
> around information, you're just ditching digits.
I guess that ("ditching digits") was the idea. take away the "constant" part,
shift the decimal point by 16 positions (I was looking at 'now' with
'str(now,0,16)', and all positions are in use/change), then "truncate".
> ...
> The following might do nicely:
>
> #declare seed_ = (now-int(now))*(1e9+1);
it does (and I'll be using that). output is more like using "%s", ie
incrementing, than with the "diverging" 'mod()'.
AM: yes, 'pi', neat, though not for this project. thanks.
regards, jr.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 28 Jul 2021 09:16:08
Message: <61015898$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 7/25/21 4:33 AM, jr wrote:
> hi,
>
> Thomas de Groot <tho### [at] degroot org> wrote:
>
> (thanks, could not post this as I have no MS Windows machine)
>
>
>> #declare seed_ = val(datetime(now,"%s"));
>
> just to confirm, this works on all Linux systems I have access to, incl a Debian
> VM with (oldest) POV-Ray-3.7.0.8.
>
Just to toss it out there, for as long as I've used datetime(now) as in:
#version 3.8;
#debug concat("v3.8 default -> ",datetime(now),"\n")
I've gotten back:
v3.8 default -> 2021-07-28 08:11:16Z
because the default format strings has a 'Z' on the end where I suspect
' %Z' was intended. In the povr branch I changed to ' %z' as I think the
time offset more general.
v3.8 (povr) default -> 2021-07-28 08:15:15 -0400
Bill P.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
William F Pokorny <ano### [at] anonymous org> wrote:
> Just to toss it out there, for as long as I've used datetime(now) as in:
>
> #version 3.8;
> #debug concat("v3.8 default -> ",datetime(now),"\n")
>
> I've gotten back:
>
> v3.8 default -> 2021-07-28 08:11:16Z
>
> because the default format strings has a 'Z' on the end where I suspect
> ' %Z' was intended. In the povr branch I changed to ' %z' as I think the
> time offset more general.
>
> v3.8 (povr) default -> 2021-07-28 08:15:15 -0400
is this new? because does not work for me, see below. also, while on 'povr', I
ran into trouble viewing font glyphs >= chr(256). (and thanks for raising the
"constant rounding" thing)
regards, jr.
jr@swift:6:wfp$ c### [at] t pov
#version 3.8;
global_settings {assumed_gamma 1}
box {0,1}
#declare s_ = datetime(now);
#debug concat("datetime v3.8 default: '",s_,"'.\n")
jr@swift:7:wfp$ povr t.pov -gr -gs -d -f
Persistence of Vision(tm) Ray Tracer (see --license)
Copyright 1991-2021 Persistence of Vision Raytracer Pty. Ltd.
Version 3.8.0-x.povr_1984d6ea.unofficial
(g++ 5.5.0 @ x86_64-slackware-linux-gnu)
This is an unofficial version compiled by: <jr### [at] swift lan>
Dynamic optimizations:
CPU detected: Intel,SSE2,AVX,AVX2,FMA3
Noise generator: avx2fma3-intel (hand-optimized by Intel)
==== [Parsing...] ==========================================================
datetime v3.8 default: '2021-07-28 15:31:42Z'.
==== [Rendering...] ========================================================
POV-Ray finished
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 28 Jul 2021 15:34:17
Message: <6101b139@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 7/28/21 11:38 AM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymous org> wrote:
...
>> because the default format strings has a 'Z' on the end where I suspect
>> ' %Z' was intended. In the povr branch I changed to ' %z' as I think the
>> time offset more general.
>>
>> v3.8 (povr) default -> 2021-07-28 08:15:15 -0400
>
> is this new? because does not work for me, see below.
Relatively, I guess. Looks like I updated this with a commit on:
Date: Fri Jun 11 06:18:44 2021 -0400
where I changed datetime() to optionally generate a time accounting for
the local daylight savings time datetime(-100000) after getting myself
tangled up due the generated datetime() string not aligning to my local
-dst adjusted - computer time. Only %z %Z appear to be dst aware with
datetime() otherwise.
So... The Z to ' %z' is an update not yet published.
> also, while on 'povr', I
> ran into trouble viewing font glyphs >= chr(256).
True my text{} isn't POV-Ray's exactly... Is this something unique to
the povr branch? Off the top of my head, this likely normal unless using
a unicode string specifications.
---
Aside:
In povr, I'm leaning in a direction of eliminating the text{} object...
Or, at least, not further updating it.
Christoph has been playing with freetype and making the text{} internals
prisms as you know. I'm thinking perhaps all characters/glyphs should
just be include-able objects only where we'd use SDL macros to do all
the placements for a string -- get POV-Ray, at the core, completely out
of the text formatting game and push that sort of thing into SDL.
If you look at the text oriented macros shipped today - like
Circle_Text(), for example, they are actually doing a lot of work to
pull apart text{} strings character by character. When I do isosurface
stuff with text{} strings, I often do the same to get to single
'characters' for better performance. Effectively, pulling text{} objects
apart - or internally doing this - for most work is a painfully
backwards way to approach things in my opinion.
Bill P.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |