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

Am 28.07.2021 um 15:16 schrieb William F Pokorny:

> 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:
> 

> 
> 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.

The `datetime` function with default values works as documented:

"The default for the STRING parameter format is %Y-%m-%d %H:%M:%SZ"


I'm not the author of that functionality, but according to my 
understanding, this is entirely intentional:

Since the information provided by "now" is based on UTC, and the 
`strftime` conversion specifiers are time zone agnostic(*), the printed 
date and time are also with respect to UTC.

In full compliance with ISO 8601, this is indicated by appending a 
literal uppercase `Z` right after the time, which is the official time 
zone designator for UTC.


(*)Except for `%Z` or `%z` of course.

Speaking of which: Appending either of those instead of "Z" would 
actually give a wrong time, unless you first convert `now` to local time.

Also, per ISO 8601 any time zone designator should be appended to the 
time without any intervening space.

Post a reply to this message

hi,

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

not so sure now whether 'povr' or 'povray' cause "a problem", see attached,
'povr' on right.  did a quick check with a Tk text and that confirms the 'povr'
output.

also, Tdg, while testing my macro (thanks, Thomas), found fonts where 'chr(32)'
display as exclamation marks; with both POV-Ray alpha and yr 'povr'.  have not
yet checked to find out why (have to install one or two of the fonts first).


regards, jr.

Post a reply to this message

Attachments:
Download 'tabu_cmp.png' (832 KB)

Preview of image 'tabu_cmp.png'

Am 29.07.2021 um 10:35 schrieb jr:

>>> 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.
> 
> not so sure now whether 'povr' or 'povray' cause "a problem", see attached,
> 'povr' on right.  did a quick check with a Tk text and that confirms the 'povr'
> output.

povr is based on those rolled-back alpha versions, right? Then color me 
unsurprised.

Did I ever, maybe in passing, mention that POV-Ray v3.7's behavior 
(which we strive to emulate in v3.8) regarding non-ASCII characters and 
fonts is seriously borked?


> also, Tdg, while testing my macro (thanks, Thomas), found fonts where 'chr(32)'
> display as exclamation marks; with both POV-Ray alpha and yr 'povr'.  have not
> yet checked to find out why (have to install one or two of the fonts first).

It is theoretically possible for fonts to provide a non-empty glyph for 
the ASCII "space" character. I guess this could go unnoticed in most 
programs, as they would typically use operating systems calls to render 
text, which in turn could conveivably give special treatment to ASCII 
"space" by simply inserting a gap according to the character's width.

I think POV-Ray does not currently do that, and instead treats "space" 
like any other character, i.e. it may or may not have a visible glyph.


But I think we're digressing a bit from the original thread...

Post a reply to this message

On 7/28/21 5:53 PM, clipka wrote:
> Am 28.07.2021 um 15:16 schrieb William F Pokorny:
> 
>> 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:
>>

>>
>> 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.
> 
> The `datetime` function with default values works as documented:
> 
> "The default for the STRING parameter format is %Y-%m-%d %H:%M:%SZ"
> 
> 
> I'm not the author of that functionality, but according to my 
> understanding, this is entirely intentional:
> 
> Since the information provided by "now" is based on UTC, and the 
> `strftime` conversion specifiers are time zone agnostic(*), the printed 
> date and time are also with respect to UTC.
> 
> In full compliance with ISO 8601, this is indicated by appending a 
> literal uppercase `Z` right after the time, which is the official time 
> zone designator for UTC.
> 
> 
> (*)Except for `%Z` or `%z` of course.
> 
> Speaking of which: Appending either of those instead of "Z" would 
> actually give a wrong time, unless you first convert `now` to local time.
> 
> Also, per ISO 8601 any time zone designator should be appended to the 
> time without any intervening space.

Supposing the SDL:

    #debug concat("",datetime(now),"\n")
    #debug concat("",datetime(-100000),"\n") // (*)

And the 'date' command on my Ubuntu 20.04 computer returning:

     Thu 29 Jul 2021 07:15:12 AM EDT

The v3.8 branch returns:

     2021-07-29 06:15:12Z  <-- Not current Zulu time... (**)
     1726-03-18 00:00:00Z

The povr branch returns:

     2021-07-29 06:15:13 -0400 <-- Not my current dst time. Offset wrong.
     2021-07-29 07:15:13 -0400 <-- This is correct.

Bill P.

(*) The -100000 days is somewhat arbitrary. Just needs to be earlier 
than the unix epoch time to trigger the dst aware mode.

(**) Using %Z would add EDT instead of EST (locally), which is also 
correct. Though any given reader must know what the local %Z dst is no 
matter where povray/datetime(now) was run or where they live
compared to the person who did run it.

Post a reply to this message