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

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

hi,

clipka <ano### [at] anonymousorg> 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

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

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

> 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

hi,

clipka <ano### [at] anonymousorg> 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

On 7/25/21 4:33 AM, jr wrote:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> 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

hi,

William F Pokorny <ano### [at] anonymousorg> 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] tpov

#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] swiftlan>

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

On 7/28/21 11:38 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> 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