mainThe GNU Bourne-Again SHell - Support: sr #110843, Successive $RANDOM invocations are...

 
 

sr #110843: Successive $RANDOM invocations are not independent

Submitter:  Roshan Padaki <roshan>
Submitted:  Sun 26 Feb 2023 04:23:34 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  2 - Minor Status:  Wont Do
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 27 Feb 2023 09:13:41 PM UTC, comment #3: 

I think I'd get more bug reports if $RANDOM generated two identical numbers in succession. People expect the period of the generator to be more than 1.

There were similar complaints about subshells returning the same random numbers (that is, the following would display the same number three times:

RANDOM=42
(echo $RANDOM)
(echo $RANDOM)
(echo $RANDOM)

) before I added subshell reseeding along with this code back in bash-2.0.

Chet Ramey <chet>
Group administrator
Mon 27 Feb 2023 08:53:14 PM UTC, comment #2: 

comment #1:

> When do you ever want two successive references of $RANDOM to be the same?


I ran into this when doing a quick-and-dirty generation of test inputs for a small computation I was writing. It turns out that testing `./integral 0.$RANDOM 0.$RANDOM` would never hit the "diagonal case" `./integral 0.X 0.X`. Yes, if I was properly testing this, I would explicitly test the diagonal case and not rely on `$RANDOM`. Still, I think it's very reasonable to expect `$RANDOM` to behave exactly the way the docs claim it behaves.


I agree with your point that the cases where this comes into play are very niche. If this is too niche to warrant changing the implementation or mentioning this quirk in the docs, then this issue can be dropped.

Roshan Padaki <roshan>
Mon 27 Feb 2023 08:32:18 PM UTC, comment #1: 

When do you ever want two successive references of $RANDOM to be the same?

Chet Ramey <chet>
Group administrator
Sun 26 Feb 2023 04:23:34 AM UTC, original submission:  

Configuration Information [Automatically generated, do not change]:
Machine: aarch64
OS: linux-musl
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux 6427fde013c0 5.15.49-linuxkit #1 SMP PREEMPT Tue Sep 13 07:51:32 UTC 2022 aarch64 Linux
Machine Type: aarch64-unknown-linux-musl

Bash Version: 5.2
Patch Level: 15
Release Status: release

Description:
This is either an implementation bug or a docs bug. The documentation for `$RANDOM` says:

> Each time this parameter is referenced, it expands to a random integer between 0 and 32767.
> Assigning a value to this variable seeds the random number generator.
> If RANDOM is unset, it loses its special properties, even if it is subsequently reset.

However, there is an undocumented behavior -- consecutive results from `$RANDOM` are never equal. This is caused by the implementation of get_random_number() in variables.c, where we have:

do
  rv = brand ();
while (rv == last_random_value);


Repeat-By:
One might expect the following command to terminate, but it never does.

while true
do
  A=$RANDOM
  B=$RANDOM
  [[ $A -eq $B ]] && break
done

When taking `$RANDOM mod N` or performing other computations, the effect of this dependence is much smaller but still measurable.

Fix:
Either the do-while loop in the implementation of variables.c :: get_random_number() should be removed, or the documentation should be updated to reflect this behavior.

Roshan Padaki <roshan>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by chet (Posted a comment)
  • -email is unavailable- added by roshan (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-02-27 chet StatusNeed Info Wont Do
    2023-02-27 chet StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-3cd0.
    Corresponding source code