rigorously predictable random numbers

rigorously predictable random numbers

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

#!/usr/bin/zsh

echo $RANDOM
var=$( echo $RANDOM )
echo $var

... I run that and get:



3 /aWorking/Zsh/Source/Wk 1 % . test1
23008
3809

3 /aWorking/Zsh/Source/Wk 1 % . test1
3809
768

3 /aWorking/Zsh/Source/Wk 1 % . test1
768
11071

3 /aWorking/Zsh/Source/Wk 1 % . test1
11071
26432

3 /aWorking/Zsh/Source/Wk 1 % . test1
26432
19059

3 /aWorking/Zsh/Source/Wk 1 % . test1
19059
14427

... the result of the first $RANDOM is always exactly the result of the 
second $RANDOM in the previous call to the script.  This might not be as 
unexpected in a function where at least it's the same shell, but a 
script, seems to me, should always have a virginal notion of $RANDOM, 
no?  Yet it remembers the previous result from another shell.  I have 
the vaguest fragment of memory that we discussed this on the list once 
before.


[-- Attachment #2: Type: text/html, Size: 1411 bytes --]

Re: rigorously predictable random numbers

[Lawrence Velázquez]

On Thu, May 2, 2024, at 9:23 PM, Ray Andrews wrote:
> ... the result of the first $RANDOM is always exactly the result of the 
> second $RANDOM in the previous call to the script.

As zshparam(1) says:

	The values of RANDOM form an intentionally-repeatable
	pseudo-random sequence; subshells that reference RANDOM
	will result in identical pseudo-random values unless the
	value of RANDOM is referenced or seeded in the parent shell
	in between subshell invocations.

Referencing RANDOM advances the sequence, but doing so in $(...)
-- or any other subshell -- causes that progress to be discarded
upon returning to the parent shell, and the next reference to
RANDOM will "rewind" to the first value seen in that subshell.

	% typeset -p RANDOM
	typeset -i10 RANDOM=9493
	% (repeat 3; do typeset -p RANDOM; done)
	typeset -i10 RANDOM=5570
	typeset -i10 RANDOM=30244
	typeset -i10 RANDOM=21515
	% typeset -p RANDOM
	typeset -i10 RANDOM=5570


> This might not be 
> as unexpected in a function where at least it's the same shell, but a 
> script, seems to me, should always have a virginal notion of $RANDOM, 
> no?  Yet it remembers the previous result from another shell.

There are no other shells, other than the $(...) subshells.  You
are using the "." command, which sources the given script in the
current shell.


> I have 
> the vaguest fragment of memory that we discussed this on the list once 
> before.

https://www.zsh.org/mla/workers/2015/msg00549.html
https://www.zsh.org/mla/workers/2017/msg00586.html
https://www.zsh.org/mla/users/2017/msg00618.html
https://www.zsh.org/mla/workers/2019/msg00887.html
https://www.zsh.org/mla/workers/2023/msg00012.html
https://www.zsh.org/mla/workers/2023/msg00208.html
https://www.zsh.org/mla/users/2023/msg00475.html


-- 
vq

Re: rigorously predictable random numbers

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]



On 2024-05-02 20:09, Lawrence Velázquez wrote:
> 	The values of RANDOM form an intentionally-repeatable
> 	pseudo-random sequence; subshells that reference RANDOM
> 	will result in identical pseudo-random values unless the
> 	value of RANDOM is referenced or seeded in the parent shell
> 	in between subshell invocations.
Ok then at least this is intentional.  How does one obtain a genuinely 
random number then?  TBH, for my particular needs right now the standard 
behavior is perfect, but as a matter of principle I'd like to know how 
to get 'real' random numbers.  There will be a way.

> There are no other shells, other than the $(...) subshells.  You
> are using the "." command, which sources the given script in the
> current shell.
Yes, pardon.  I get it mixed up with $( ) and with piping.
> https://www.zsh.org/mla/workers/2015/msg00549.html
> https://www.zsh.org/mla/workers/2017/msg00586.html
> https://www.zsh.org/mla/users/2017/msg00618.html
> https://www.zsh.org/mla/workers/2019/msg00887.html
> https://www.zsh.org/mla/workers/2023/msg00012.html
> https://www.zsh.org/mla/workers/2023/msg00208.html
> https://www.zsh.org/mla/users/2023/msg00475.html
>
How do you do that?  It would save a lot of repetition if I could 
research the archives myself.    Such a resource, but inaccessible -- 
tho you seem to know how.  It bothers me to ask a question that I know 
has been asked before.





[-- Attachment #2: Type: text/html, Size: 3125 bytes --]

Re: rigorously predictable random numbers

[Roman Perepelitsa]

On Fri, May 3, 2024 at 5:48 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> How does one obtain a genuinely random number then?

There are several ways. I use this:
https://gist.github.com/romkatv/a6cede40714ec77d4da73605c5ddb36a

  # Returns a random 32-bit number.
  # If /dev/urandom is cryptographically secure, so is srand32.
  #
  # If zsh is compiled with 64-bit number support, the result
  # is non-negative. Otherwise it may be negative and the value
  # is governed by the rules of unsigned-to-signed conversion in C.
  #
  # Examples:
  #
  #   % print -r -- $(( srand32() ))
  #   263510467
  #
  #   % local -i x='srand32()'
  #   % typeset -p x
  #   typeset -i x=858148951
  #
  # Performance: ~30us per call.
  #
  #   % time ( repeat 1000000 srand32 )
  #   user=19.95s system=6.95s cpu=99% total=26.934
  #
  #   % uname -srm
  #   Linux 5.4.0-58-generic x86_64
  #
  #   % grep 'model name' /proc/cpuinfo | head -1
  #   model name      : AMD Ryzen 7 3700X 8-Core Processor
  function srand32() {
    emulate -L zsh -o no_multi_byte
    local bytes
    while (( $#bytes < 4 )); do
      sysread -s$((4-$#bytes)) 'bytes[$#bytes+1]' </dev/urandom || return
    done
    local b1=$bytes[1] b2=$bytes[2] b3=$bytes[3] b4=$bytes[4]
    return '#b1 << 24 | #b2 << 16 | #b3 << 8 | #b4'
  }
  functions -M srand32 0 0

Roman

Re: rigorously predictable random numbers

[Lawrence Velázquez]

On Thu, May 2, 2024, at 11:48 PM, Ray Andrews wrote:
> On 2024-05-02 20:09, Lawrence Velázquez wrote:
>> https://www.zsh.org/mla/workers/2015/msg00549.html
>> https://www.zsh.org/mla/workers/2017/msg00586.html
>> https://www.zsh.org/mla/users/2017/msg00618.html
>> https://www.zsh.org/mla/workers/2019/msg00887.html
>> https://www.zsh.org/mla/workers/2023/msg00012.html
>> https://www.zsh.org/mla/workers/2023/msg00208.html
>> https://www.zsh.org/mla/users/2023/msg00475.html
>> 
> How do you do that?  It would save a lot of repetition if I could 
> research the archives myself.    Such a resource, but inaccessible -- 
> tho you seem to know how.

I just search a folder in my email account.  I've saved almost every
message from the lists since I joined on [checks] December 9, 2013.

-- 
vq

Re: rigorously predictable random numbers

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]



On 2024-05-02 22:40, Lawrence Velázquez wrote:
> I just search a folder in my email account.  I've saved almost every
> message from the lists since I joined on [checks] December 9, 2013.
>
Just a while back seems to me there was some thoughts as to making the 
archives searchable.  IMHO that would be most useful.  I know there's 
many times I'd like to dredge up stuff that's been covered previously.  
I remember it was covered but not the details.

[-- Attachment #2: Type: text/html, Size: 910 bytes --]

Re: rigorously predictable random numbers

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]



On 2024-05-02 21:58, Roman Perepelitsa wrote:
> # Examples:
>    #
>    #   % print -r -- $(( srand32() ))
>    #   263510467
>

1 /aWorking/Zsh/Source/Wk 2 % print -r -- $(( srand32() ))
srand32:4: command not found: sysread
4


... how the devil?  It's a builtin.


[-- Attachment #2: Type: text/html, Size: 768 bytes --]

Re: rigorously predictable random numbers

[Clinton Bunch]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

On 5/2/2024 22:48, Ray Andrews wrote:
>
>
> On 2024-05-02 20:09, Lawrence Velázquez wrote:
>> 	The values of RANDOM form an intentionally-repeatable
>> 	pseudo-random sequence; subshells that reference RANDOM
>> 	will result in identical pseudo-random values unless the
>> 	value of RANDOM is referenced or seeded in the parent shell
>> 	in between subshell invocations.
> Ok then at least this is intentional.  How does one obtain a genuinely 
> random number then?  TBH, for my particular needs right now the 
> standard behavior is perfect, but as a matter of principle I'd like to 
> know how to get 'real' random numbers.  There will be a way.
'real' random numbers are not possible on a computer, but 'good enough' 
random numbers are available in /dev/random character device file.  I 
have also written the zsh/random module that uses system calls to access 
the same kernel 'random' pool, but it has yet to be accepted for 
addition to the next release.  It provides the SRANDOM parameter (32-bit 
unsigned) similar to modern bash, a zrand_float() math function for 
numbers between 0 and 1, and zrand_int(upper,lower,inclusive) to return 
an integer between two values (32-bit integer max)


[-- Attachment #2: Type: text/html, Size: 1980 bytes --]

Re: rigorously predictable random numbers

[Ray Andrews]

On 2024-05-03 06:36, Clinton Bunch wrote:
> 'real' random numbers are not possible on a computer, 
Understood, thus the air-quotes.

> but 'good enough' random numbers are available in /dev/random 
> character device file.  I have also written the zsh/random module that 
> uses system calls to access the same kernel 'random' pool, but it has 
> yet to be accepted for addition to the next release. It provides the 
> SRANDOM parameter (32-bit unsigned) similar to modern bash, a 
> zrand_float() math function for numbers between 0 and 1, and 
> zrand_int(upper,lower,inclusive) to return an integer between two 
> values (32-bit integer max)
Sounds luxuriously complete.  I noted in those links that Lawrence 
posted that every one of them considered the existing behavior to be 
'obviously' wrong.  And it is 'obviously' wrong intuitively whatever 
it's merits may be.  A predictable random number isn't.  Besides, if 
bash can offer a 'real' random number then that's established practice 
so we should too.

Re: rigorously predictable random numbers

[Lawrence Velázquez]

On Fri, May 3, 2024, at 9:58 AM, Ray Andrews wrote:
> I noted in those links that Lawrence 
> posted that every one of them considered the existing behavior to be 
> 'obviously' wrong.  And it is 'obviously' wrong intuitively whatever 
> it's merits may be.  A predictable random number isn't.

This is just a consequence of the name "RANDOM", which unfortunately
implies a property that the parameter doesn't quite have.  There is
nothing "'obviously' wrong" with repeatable pseudorandom sequences.

Also, seven discussions over ten years doesn't exactly scream
"everyone is super confused by this".

> Besides, if 
> bash can offer a 'real' random number then that's established practice 
> so we should too.

Copying bash's "established practice" is not a reason to do anything.
Bash has plenty of misfeatures and poor design decisions that should
not be imitated.  If we choose to ship Clinton's module, it will
be because it is useful, not because of any perceived need to catch
up to another shell.

-- 
vq

Re: rigorously predictable random numbers

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

On Fri, May 3, 2024 at 4:43 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> Also, seven discussions over ten years doesn't exactly scream
> "everyone is super confused by this".

No, but it might be enough to qualify for the "F" in "AQ".

> https://www.zsh.org/mla/users/2023/msg00475.html

That one isn't really the same Q, though.

[-- Attachment #2: random-faq.txt --]
[-- Type: text/plain, Size: 1811 bytes --]

diff --git a/Etc/FAQ.yo b/Etc/FAQ.yo
index 4e11637ea..2c83fe7fa 100644
--- a/Etc/FAQ.yo
+++ b/Etc/FAQ.yo
@@ -137,6 +137,7 @@ Chapter 3:  How to get various things to work
 3.28. How do I edit the input buffer in $EDITOR?
 3.29. Why does `which' output for missing commands go to stdout?
 3.30. Why doesn't the expansion mytt(*.{tex,aux,pdf}) do what I expect?
+3.31. Why does mytt($RANDOM) return the same number more than once?
 
 Chapter 4:  The mysteries of completion
 4.1. What is completion?
@@ -2219,6 +2220,37 @@ sect(Why doesn't the expansion mytt(*.{tex,aux,pdf}) do what I expect?)
   This is harder for the user to remember but easier for the shell to
   parse!
 
+sect(Why does mytt($RANDOM) return the same number more than once?)
+
+  As tt(zshparam(1)) says:
+  verb(
+      The values of RANDOM form an intentionally-repeatable
+      pseudo-random sequence; subshells that reference RANDOM
+      will result in identical pseudo-random values unless the
+      value of RANDOM is referenced or seeded in the parent shell
+      in between subshell invocations.
+  )
+
+  You can use a function, including an anonymous function, to always
+  evaluate mytt($RANDOM) in the parent shell.  This example illustrates
+  the difference:
+  verb(
+    for i in {1..10}; do
+      echo subshell: $(echo $RANDOM) $RANDOM
+      () { echo parent: $(echo $1) $2 } $RANDOM $RANDOM;
+    done
+  )
+
+  Remember that for a pipe like mytt(A | B), zsh runs A in a subshell
+  and B in the current shell.  This means that, for example:
+  verb(
+    for i in {1..10}; do
+      echo $RANDOM | tee
+    done
+  )
+  also repeats the same value, because mytt($RANDOM) is evaluated in
+  the subshell and the parent sequence is left unchanged.
+
 chapter(The mysteries of completion)
 
 sect(What is completion?)

Re: rigorously predictable random numbers

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]



On 2024-05-03 16:42, Lawrence Velázquez wrote:
> This is just a consequence of the name "RANDOM", which unfortunately
> implies a property that the parameter doesn't quite have.  There is
> nothing "'obviously' wrong" with repeatable pseudorandom sequences.
Indeed.  As I said, the current behavior suits my current need 
perfectly.  Still I'd say that a 'real' random number should be 
available.  One can't have too many resources.
> Also, seven discussions over ten years doesn't exactly scream
> "everyone is super confused by this".
Not exactly a crisis, still I think I'm not alone in being surprised by 
the current behavior.
> Copying bash's "established practice" is not a reason to do anything.
But I have noticed a strong deference to tradition and consensus, so it 
at least does not hurt that bash has 'real' random numbers.
> Bash has plenty of misfeatures and poor design decisions that should
> not be imitated.  If we choose to ship Clinton's module, it will
> be because it is useful, not because of any perceived need to catch
> up to another shell.
I'd not put it that way.  Of course it would have to be a genuine 
improvement. 'Catching up' is not a mentality I think any of us have.  
It seems to be near universally agreed that zsh is by far the more 
advanced shell. Still a precedent exists.  It is to be noted casually, 
that's all.



[-- Attachment #2: Type: text/html, Size: 2577 bytes --]

Re: rigorously predictable random numbers

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]



On 2024-05-03 17:28, Bart Schaefer wrote:
> No, but it might be enough to qualify for the "F" in "AQ".
>
+3.31. Why does mytt($RANDOM) return the same number more than once?
  
What I like is that even acknowledging that the question is out there goes half way to answering it.  The question first awakens you to the fact that zsh is aware that what 'you' think 'RANDOM' means might not be what the shell delivers.  That's half the battle right there.  De-confused, one then seeks a method of producing 'real' random numbers.
   

[-- Attachment #2: Type: text/html, Size: 1018 bytes --]

Re: rigorously predictable random numbers

[Lawrence Velázquez]

On Fri, May 3, 2024, at 8:28 PM, Bart Schaefer wrote:
> On Fri, May 3, 2024 at 4:43 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>> https://www.zsh.org/mla/users/2023/msg00475.html
>
> That one isn't really the same Q, though.

Hm, I guess I didn't read it closely enough.  Is the difference
that that one is really about the consequences of pipeline stages
forking earlier than they used to?

-- 
vq

Re: rigorously predictable random numbers

[Bart Schaefer]

On Sat, May 4, 2024 at 11:18 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> On Fri, May 3, 2024, at 8:28 PM, Bart Schaefer wrote:
> > On Fri, May 3, 2024 at 4:43 PM Lawrence Velázquez <larryv@zsh.org> wrote:
> >> https://www.zsh.org/mla/users/2023/msg00475.html
> >
> > That one isn't really the same Q, though.
>
> Hm, I guess I didn't read it closely enough.  Is the difference
> that that one is really about the consequences of pipeline stages
> forking earlier than they used to?

It's about parameters that used to be expanded after forking, instead
being expanded before forking.

Re: rigorously predictable random numbers

[Kannan Varadhan]

Hi folks:

This was an interesting pointer.  I am puzzled about some of the 
zsh-isms here and the logic, so

some questions:

>      while (( $#bytes < 4 )); do
>        sysread -s$((4-$#bytes)) 'bytes[$#bytes+1]' </dev/urandom || return
>      done

It looks like we want 4 individual byes (the sysread promises anywhere 
from 1 to size of buffer specified, max 8192 (in zshmodules(1)) but may 
return after only reading 1B.    So why not only say `-s1` instead of 
the more involved `-s$((4-$#bytes))`?

>      local b1=$bytes[1] b2=$bytes[2] b3=$bytes[3] b4=$bytes[4]
>      return '#b1 << 24 | #b2 << 16 | #b3 << 8 | #b4'
Now these two lines have me very confused.   Why copy to a scalar 
parameters and what does referring to them as '#b1', #b2', ... mean.   I 
have not seen these before and cant figure out where in the zsh 
documentation this is explained.


Thanks


Kannan


On 5/2/24 21:58, Roman Perepelitsa wrote:
> On Fri, May 3, 2024 at 5:48 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> How does one obtain a genuinely random number then?
> There are several ways. I use this:
> https://gist.github.com/romkatv/a6cede40714ec77d4da73605c5ddb36a
>
>    # Returns a random 32-bit number.
>    # If /dev/urandom is cryptographically secure, so is srand32.
>    #
>    # If zsh is compiled with 64-bit number support, the result
>    # is non-negative. Otherwise it may be negative and the value
>    # is governed by the rules of unsigned-to-signed conversion in C.
>    #
>    # Examples:
>    #
>    #   % print -r -- $(( srand32() ))
>    #   263510467
>    #
>    #   % local -i x='srand32()'
>    #   % typeset -p x
>    #   typeset -i x=858148951
>    #
>    # Performance: ~30us per call.
>    #
>    #   % time ( repeat 1000000 srand32 )
>    #   user=19.95s system=6.95s cpu=99% total=26.934
>    #
>    #   % uname -srm
>    #   Linux 5.4.0-58-generic x86_64
>    #
>    #   % grep 'model name' /proc/cpuinfo | head -1
>    #   model name      : AMD Ryzen 7 3700X 8-Core Processor
>    function srand32() {
>      emulate -L zsh -o no_multi_byte
>      local bytes
>      while (( $#bytes < 4 )); do
>        sysread -s$((4-$#bytes)) 'bytes[$#bytes+1]' </dev/urandom || return
>      done
>      local b1=$bytes[1] b2=$bytes[2] b3=$bytes[3] b4=$bytes[4]
>      return '#b1 << 24 | #b2 << 16 | #b3 << 8 | #b4'
>    }
>    functions -M srand32 0 0
>
> Roman
>

Re: rigorously predictable random numbers

[Roman Perepelitsa]

On Mon, May 20, 2024 at 7:41 PM Kannan Varadhan <kvaradhan3@gmail.com> wrote:
>
> Hi folks:
>
> This was an interesting pointer.  I am puzzled about some of the
> zsh-isms here and the logic, so
>
> some questions:
>
> >      while (( $#bytes < 4 )); do
> >        sysread -s$((4-$#bytes)) 'bytes[$#bytes+1]' </dev/urandom || return
> >      done
>
> It looks like we want 4 individual byes (the sysread promises anywhere
> from 1 to size of buffer specified, max 8192 (in zshmodules(1)) but may
> return after only reading 1B.    So why not only say `-s1` instead of
> the more involved `-s$((4-$#bytes))`?

Reading 1 byte at a time is slower than reading 4 bytes at once.

> >      local b1=$bytes[1] b2=$bytes[2] b3=$bytes[3] b4=$bytes[4]
> >      return '#b1 << 24 | #b2 << 16 | #b3 << 8 | #b4'
>
> Why copy to a scalar parameters

My goal was to implement the contract described in the comments. This
is how I managed to do it. Your asking "why" appears to imply that you
have another implementation in mind that is more natural to you. If
so, can you post it?

> what does referring to them as '#b1', #b2', ... mean.

These are the numeric values of the bytes held in b1..b4.

    % x='A'
    % print -r -- $(( #x ))
    65

Roman.

Re: rigorously predictable random numbers

[Kannan Varadhan]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]


On 5/20/24 11:01, Roman Perepelitsa wrote:
> On Mon, May 20, 2024 at 7:41 PM Kannan Varadhan<kvaradhan3@gmail.com>  wrote:
>> Hi folks:
>>
>> This was an interesting pointer.  I am puzzled about some of the
>> zsh-isms here and the logic, so
>>
>> some questions:
>>
>>>       while (( $#bytes < 4 )); do
>>>         sysread -s$((4-$#bytes)) 'bytes[$#bytes+1]' </dev/urandom || return
>>>       done
>> It looks like we want 4 individual byes (the sysread promises anywhere
>> from 1 to size of buffer specified, max 8192 (in zshmodules(1)) but may
>> return after only reading 1B.    So why not only say `-s1` instead of
>> the more involved `-s$((4-$#bytes))`?
> Reading 1 byte at a time is slower than reading 4 bytes at once.

ok but the loop seems to read 4, then 3, 2, and 1B in each iteration, or 
did I miss something?

>>>       local b1=$bytes[1] b2=$bytes[2] b3=$bytes[3] b4=$bytes[4]
>>>       return '#b1 << 24 | #b2 << 16 | #b3 << 8 | #b4'
>> Why copy to a scalar parameters
> My goal was to implement the contract described in the comments. This
> is how I managed to do it. Your asking "why" appears to imply that you
> have another implementation in mind that is more natural to you. If
> so, can you post it?

i dont have an alternate implementation.  I was trying to use 
'#bytes[1]' directly and that did not work.

>> what does referring to them as '#b1', #b2', ... mean.
> These are the numeric values of the bytes held in b1..b4.
>
>      % x='A'
>      % print -r -- $(( #x ))
>      65


Interesting,


Kannan

[-- Attachment #2: Type: text/html, Size: 3174 bytes --]

Re: rigorously predictable random numbers

[Roman Perepelitsa]

On Mon, May 20, 2024 at 9:14 PM Kannan Varadhan <kvaradhan3@gmail.com> wrote:
>
> ok but the loop seems to read 4, then 3, 2, and 1B in each
> iteration, or did I miss something?

You can add something like 'print reading' in that loop to see how
many times sysread is invoked.

> i dont have an alternate implementation.  I was trying to use '#bytes[1]' directly and that did not work.

That's "why" then.

Roman.

Re: rigorously predictable random numbers

[Bart Schaefer]

On Mon, May 20, 2024 at 12:14 PM Kannan Varadhan <kvaradhan3@gmail.com> wrote:
>
>> On 5/20/24 11:01, Roman Perepelitsa wrote:
>
>>> what does referring to them as '#b1', #b2', ... mean.
>
>> These are the numeric values of the bytes held in b1..b4.
>>
>>     % x='A'
>>     % print -r -- $(( #x ))
>>     65
>
> Interesting

This is documented in the "Arithmetic Evaluation" section of the
manual, about 3/4 of the way through:

An expression of the form '##X' where X is any character sequence such
as 'a', '^A', or '\M-\C-x' gives the value of this character and an
expression of the form '#NAME' gives the value of the first character of
the contents of the parameter NAME.  Character values are according to
the character set used in the current locale; for multibyte character
handling the option MULTIBYTE must be set.  Note that this form is
different from '$#NAME', a standard parameter substitution which gives
the length of the parameter NAME.  '#\' is accepted instead of '##', but
its use is deprecated.

Re: rigorously predictable random numbers

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

On Mon, May 20, 2024 at 6:57 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> This is documented in the "Arithmetic Evaluation" section of the
> manual, about 3/4 of the way through:
>
> An expression of the form '##X' where X is any character sequence such
> as 'a', '^A', or '\M-\C-x' gives the value of this character and an
> expression of the form '#NAME' gives the value of the first character of
> the contents of the parameter NAME.  Character values are according to
> the character set used in the current locale; for multibyte character
> handling the option MULTIBYTE must be set.  Note that this form is
> different from '$#NAME', a standard parameter substitution which gives
> the length of the parameter NAME.  '#\' is accepted instead of '##', but
> its use is deprecated.
>

Note that the *## *form does work fine in conjunction with parameter
expansion:

$ msg=hello
$ for (( i=1; i <= $#msg; ++i )); do echo $(( ##$msg[i] )); done
104
101
108
108
111

But that's not particularly efficient.

-- 
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 1989 bytes --]

Re: rigorously predictable random numbers

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

On Mon, May 20, 2024 at 12:14 PM Kannan Varadhan <kvaradhan3@gmail.com>
wrote:

> On 5/20/24 11:01, Roman Perepelitsa wrote:
>
> On Mon, May 20, 2024 at 7:41 PM Kannan Varadhan <kvaradhan3@gmail.com> <kvaradhan3@gmail.com> wrote:
>
>      while (( $#bytes < 4 )); do
>        sysread -s$((4-$#bytes)) 'bytes[$#bytes+1]' </dev/urandom || return
>      done
>
> Reading 1 byte at a time is slower than reading 4 bytes at once.
>
> ok but the loop seems to read 4, then 3, 2, and 1B in each iteration, or
> did I miss something?
>

To clarify this, it has to do with the way sysread assigns to the parameter
'bytes[$#bytes+1]'.

On the first iteration, $#bytes == 0, so this is 'bytes[1]'.  Assignment to
a subscripted parameter reference replaces the element at the subscript
position (or positions, if a range is given, which is not allowed for
associative arrays) with the assigned value.  Thus all bytes returned from
/dev/urandom in the first read are inserted in place of position 1 in the
string bytes.  There's nothing at position 1 yet in this case, so that
becomes the entire value of $bytes.  If fewer than 4 bytes were returned --
say, 2 -- then at the next iteration we sysread into bytes[3], which is
past the end of the existing 2-byte value, so has the effect of appending
the next series of bytes and lengthening the string.

Upshot:  The loop attempts to read the exact number of (remaining) bytes
necessary to fill a four-byte string, and repeatedly appends if and only if
it doesn't yet have all four.

[-- Attachment #2: Type: text/html, Size: 2328 bytes --]