Random number diff from cmd line vs double click

[sst]

Hmm, I have let it run for a couple of minutes at a time and output thousands of results and have not gotten a duplicate when adding.

Just reran a test using addition with the seed coming from the thousandths seconds from WMIC. Ran for 6 minutes and got 4148 unique GUID strings. No duplicates.

Code: Select all

@echo off
setlocal EnableDelayedExpansion

set "RandomSeq=21213,21941,17920,10457,19086,5729,12553,29660,2929,6968,17472,27711,18025,20260,1593,26714,31301,28749,19661,30131,4415,18317,26301,27669,30665,29733,2199,14050,4234,8110,222,18601"

echo RandomSeq=%RandomSeq%
for %%s in (1363,1923) do (
    echo,
    <nul set /p "=seed=%%s result: "
    for %%n in (%RandomSeq%) do (
        set /a "hex=(%%n + %%s) %% 16"
        <nul set /p "=!hex!,"
    )
)
echo,

Output:

RandomSeq=21213,21941,17920,10457,19086,5729,12553,29660,2929,6968,17472,27711,18025,20260,1593,26714,31301,28749,19661,30131,4415,18317,26301,27669,30665,29733,2199,14050,4234,8110,222,18601

seed=1363 result: 0,8,3,12,1,4,12,15,4,11,3,2,12,7,12,13,8,0,0,6,2,0,0,8,12,8,10,5,13,1,1,12,
seed=1923 result: 0,8,3,12,1,4,12,15,4,11,3,2,12,7,12,13,8,0,0,6,2,0,0,8,12,8,10,5,13,1,1,12,

One random sequence two different seeds same result.

It is strange for me how you didn't observe the duplicates as running the two consecutive new cmd instances will most certainty produce the same random sequence it just needs the matching seeds.

[Aacini]

Accordingly to this Raymond Chen's article, the method cmd.exe uses to seed the random number generator of %RANDOM% variable only depends on the time when cmd.exe is started, with one-second resolution. This means that the execution of any command not related to %RANDOM% variable, like ping, have no effect on the sequence of generated random numbers and that there is no way to modify the seed used in %RANDOM% variable, excepting start cmd.exe at very different times.

I always have used a very simple method to randomize the sequence of random numbers that consists in generate a number of %RANDOM% numbers equal to the centiseconds given by %TIME% variable, that is:

Code: Select all

rem Randomize:
for /L %%i in (0,1,%time:~-2%) do set /A "!random!"

I used the next code for test this method:

Code: Select all

@echo off
setlocal EnableDelayedExpansion

rem Randomize:
for /L %%i in (0,1,%time:~-2%) do set /A "!random!"

set "hex=0123456789ABCDEF"
set "result="
for /L %%n in (1,1,32) do (
    set /A "i=!random! %% 16"
    for %%i in (!i!) do set "result=!result!!hex:~%%i,1!" 
)
echo %result%

And I tested this code in the following ways at the command prompt:

Code: Select all

(for /L %i in (1,1,50) do @for /F %a in ('test.bat') do @echo %a) | sort

(for /L %i in (1,1,50) do @for /F %a in ('call test.bat') do @echo %a) | sort

(for /L %i in (1,1,50) do @for /F %a in ('cmd /C test.bat') do @echo %a) | sort

(for /L %i in (1,1,50) do @cmd /C test.bat) | sort

I got not even a single 32-digits hexadecimal number duplicated...

Antonio

[sst]

I got not even a single 32-digits hexadecimal number duplicated...

I used the same method as yours which I had posted in previous replays to this thread, And as I said, it has a problem of producing sequences which have obvious patterns in them. sorting will just hides the pattern.
On My i7 6700 PC the first 30 unsorted samples of the script's output will look like this. I used 30 outputs for the pattern to be easily detectable by eye.

Code: Select all

> for /L %i in (1,1,30) do @cmd /C test.bat

Code: Select all

05E92823391DF4A9645121267AF9BED9
92823391DF4A9645121267AF9BED9815
3391DF4A9645121267AF9BED9815F0D7
1DF4A9645121267AF9BED9815F0D7717
A9645121267AF9BED9815F0D77174094
45121267AF9BED9815F0D77174094D4B
1267AF9BED9815F0D77174094D4BCAC2
55F3F1EC493706F4A956581C4593153B
F1EC493706F4A956581C4593153BFF77
4255F3F1EC493706F4A956581C459315
706F4A956581C4593153BFF77E369FEB
F4A956581C4593153BFF77E369FEBDAB
956581C4593153BFF77E369FEBDAB04C
81C4593153BFF77E369FEBDAB04CB544
4593153BFF77E369FEBDAB04CB5449DE
3153BFF77E369FEBDAB04CB5449DE079
3BFF77E369FEBDAB04CB5449DE07914D
77E369FEBDAB04CB5449DE07914D9DB4
369FEBDAB04CB5449DE07914D9DB40A0
FEBDAB04CB5449DE07914D9DB40A0D79
DAB04CB5449DE07914D9DB40A0D79F75
4CB5449DE07914D9DB40A0D79F75C81D
5449DE07914D9DB40A0D79F75C81D24C
9DE07914D9DB40A0D79F75C81D24C85B
07914D9DB40A0D79F75C81D24C85B568
4D9DB40A0D79F75C81D24C85B56852FB
DB40A0D79F75C81D24C85B56852FBFBE
0A0D79F75C81D24C85B56852FBFBE11B
79F75C81D24C85B56852FBFBE11B04D6
75C81D24C85B56852FBFBE11B04D6A7B

This is because the delta time between two invocations of cmd is almost a fixed number so the amount of shifting in sequence is fixed and produces a visible pattern. on slower computers the pattern may get harder to be detected by eye or can disappear altogether if it is too slow.

I used this to simulate a slower computer (at prompt)

Code: Select all

> set slow=call
> set slowfactor=40
> for /L %i in (1,1,%slowfactor%) do @call set slow=%%slow%% call
> for /L %i in (1,1,50) do @%slow% cmd /C test.bat

Here (viewtopic.php?f=3&t=5506#p57352) I have described a method to use the least significant digit of the centiseconds part to amplify and vary the amount of shifting in the first random sequences.

Apart from all, with this method in it's current form, producing unique sequences is not guaranteed, on a fast enough computer the delta time reaches zero. Using wmic to take advantage of milliseconds resolution can reduce the risk but does not remove theoretical potential for failure. I think combining this with Squashman's method yields more reliable results.