Random number diff from cmd line vs double click

[Matt Williamson]

I was helping a user on SO yesterday when we stumbled upon a strange occurrence with random numbers. Using the following code we want to create a random number between 11 and 21 and again between 0 and 59. When I was testing it, I ran it from a cmd prompt about 20 times and all was fine. But if that script is ran by double clicking on it, the first random number is always the same and it appears to be related to the system clock in some way because during our testing, we found that the random number went up by 1 after the hour on the system clock changed.

Code: Select all

@echo off
setlocal enabledelayedexpansion

call :rand 11 21 ret
call :rand 0 59 ret2
if %ret2% LSS 10 set ret2=0%ret2%
%ret%:%ret2%:00
pause
exit /b

:rand
setlocal
SET /A RAND_NUM=%RANDOM% * (%2 - %1 + 1) / 32768 + %1
endlocal & set %~3=%RAND_NUM%
exit /b

Does anyone have any idea what is going on here?

[dbenham]

The answer is actually quite simple

The random number generator is initiated with a seed value every time a CMD.EXE session is launched. The seed number is derived from the system clock, and it only changes once per second. The delta is very small from one second to the next. Your formula to compress the random number into a value between 11 and 21 causes all CMD sessions launched within the same hour to give the same initial value.

The random number generator will always yield the identical sequence of numbers if given the same seed number. So every session launched within the same second will yield the exact same sequence. Your sessions that are launched within the same hour, but during different seconds, will yield the same initial "random" number between 11 and 21, but the following sequences will vary.

The following math formula will yield different initial values between 11 and 21 every second instead of every hour:

Code: Select all

set /a rand_num=%random% %% 11 + 11

I posted some good examples at http://stackoverflow.com/a/19697361/1012053 that demonstrate how the batch random number generator works.


Dave Benham

[Matt Williamson]

Very interesting. So, I can just call the :rand function with a dummy return with any values to re-seed the generator and get the correct output when opening new cmd sessions?

Code: Select all

   @echo off
   setlocal enabledelayedexpansion

   call :rand 1 1 dummy
   call :rand 11 21 ret
   call :rand 0 59 ret2
   if %ret2% LSS 10 set ret2=0%ret2%
   echo %ret%:%ret2%:00
   pause
   exit /b

   :rand
   setlocal
   SET /A RAND_NUM=%RANDOM% * (%2 - %1 + 1) / 32768 + %1
   endlocal & set %~3=%RAND_NUM%
   exit /b

[dbenham]

Very interesting. So, I can just call the :rand function with a dummy return with any values to re-seed the generator and get the correct output when opening new cmd sessions?

No, the random number generator is only seeded when the CMD session is launched, and the seed is derived from the system clock. Multiple CMD sessions launched within the same second will always generate the exact same sequence of random numbers.

There is no native method to re-seed the generator, and you cannot control the initial seed value. Well, I suppose you could alter the system clock, but that seems a bit extreme.

Given a specific initial seed value (system clock second), the CMD session will always generate the same sequence of "random" numbers. It does not matter if those numbers are generated all within a single call to one script, or by multiple calls to multiple scripts. From the perspective of the CMD session, the sequence will be identical for sessions that started at the same time.

Bear in mind that pipes and FOR /F commands execute their commands within implict new CMD sessions. So if you have a script that executes commands via pipes or FOR /F multiple times within the same second, then the random number sequence within those commands will be identical.


Dave Benham

[Aacini]

You may generate your own random numbers via a Random Number Generator, some of which are very simple; for example:

Code: Select all

@echo off

rem Generate random numbers via a Linear Feedback Shift Register(LFSR):
rem http://en.wikipedia.org/wiki/Linear_feedback_shift_register

rem Fibonacci LFSR with taps: 16 14 13 11; feedback polynomial: x^16 + x^14 + x^13 + x^11 + 1

if not defined lfsr for /f "tokens=3,4 delims=:." %%a in ("%time%") do set lfsr=3%%a%%b
set /A "bit  = ( (lfsr >> 0) ^ (lfsr >> 2) ^ (lfsr >> 3) ^ (lfsr >> 5) ) & 1"
set /A "lfsr =   (lfsr >> 1) | (bit << 15)"
echo %lfsr%
exit /B

Output example:

Code: Select all

C:\> cmd /C "RandomLFSR & RandomLFSR & RandomLFSR & RandomLFSR & RandomLFSR"
50294
25147
45341
55438
27719

C:\> cmd /C "RandomLFSR & RandomLFSR & RandomLFSR & RandomLFSR & RandomLFSR"
17604
41570
53553
26776
46156

C:\> cmd /C "RandomLFSR & RandomLFSR & RandomLFSR & RandomLFSR & RandomLFSR"
50426
25213
12606
39071
52303

Previous method generate random numbers between 1 and 65535.

Antonio

[Magialisk]

Back in my cryptography threads I wrote my own random number generator because the trouble with %random% is that it cannot be directly seeded. Sure, people like Dave have gone to great lengths to explain how %random% derives it's seed based on the system clock, etc. but if you can't force it to use a specific seed value it's of no use for predictable number stream generation.

In any case, here's the link to my random function, or at least the version of it that existed back then: viewtopic.php?p=27666#p27666. I know for sure I "macro-ized" it since then, but I don't have that code handy and I don't know what else I might have done to it to improve it. I know at least one old version of my random function had issues occasionally spitting out negative numbers as well, so you might want to beware of that in case it's this version Also I feel I have to repeat that even while I used this function in my threads for demonstrating cryptographic purposes, this is *NOT* in any way a cryptographically secure PRNG.

As far as usage, it's intended to be used with two (optional) parameters, a range and a seed value. The range is formatted as a min and max value separated by a hyphen, ie "0-100", within the bounds of 0-32767. The seed is any integer, and as stated previously in this thread, given the same seed the random number will always turn out the same. If 'rand 0-10 12345' spits out a 7, it will always spit out a 7, no matter how many times you call it or what time of day If you don't care about seeding it, leave that parameter out and the function defaults to using %random%.

In addition to spitting out the random number, if an input seed is provided, the function also returns the next seed in the generation sequence, so you can use it to generate long streams of repeatable random numbers. You'll find plenty of usage examples in that cryptography thread if the seeding concept is of interest to you.

[Matt Williamson]

You may generate your own random numbers via a Random Number Generator, some of which are very simple; for example:

Code: Select all

@echo off

rem Generate random numbers via a Linear Feedback Shift Register(LFSR):
rem http://en.wikipedia.org/wiki/Linear_feedback_shift_register

rem Fibonacci LFSR with taps: 16 14 13 11; feedback polynomial: x^16 + x^14 + x^13 + x^11 + 1

if not defined lfsr for /f "tokens=3,4 delims=:." %%a in ("%time%") do set lfsr=3%%a%%b
set /A "bit  = ( (lfsr >> 0) ^ (lfsr >> 2) ^ (lfsr >> 3) ^ (lfsr >> 5) ) & 1"
set /A "lfsr =   (lfsr >> 1) | (bit << 15)"
echo %lfsr%
exit /B

Previous method generate random numbers between 1 and 65535.

Very cool! So, if I wanted to generate a random number between 1 and 262,143 all I would have to do is modify the algorithm to:

Code: Select all

if not defined lfsr for /f "tokens=3,4 delims=:." %%a in ("%time%") do set lfsr=3%%a%%b
set /A "bit  = ( (lfsr >> 0) ^ (lfsr >> 7) ) & 1"
set /A "lfsr =   (lfsr >> 1) | (bit << 17)"
echo %lfsr%
exit /B

For 18 bits of precision right? I don't know C but it looks like the bit shifting code in batch is very similar. What is the significance of adding the 3 before the extract from the %time% variable?

[penpen]

You should add the delimiter ',' when setting up lfsr, so it will not set up as "3%%a" in german windows versions (for example):

Code: Select all

if not defined lfsr for /f "tokens=3,4 delims=:.," %%a in ("%time%") do set lfsr=3%%a%%b

penpen

[Squashman]

Digging up this old thread just because. I was commenting on a question at StackOverFlow that was now deleted by the user where they were using this code to generate a 32 character string.

Code: Select all

@echo off
REM Delay in milliseconds for random number generator to recycle.
REM pathping -p 2000 -q 1 localhost >nul

break on
setlocal enabledelayedexpansion

set "xGUID="
for /L %%n in (1,1,32) do (
  set /a "hex=!RANDOM! %% 16"
  if "!hex!"=="10" set "hex=A"
  if "!hex!"=="11" set "hex=B"
  if "!hex!"=="12" set "hex=C"
  if "!hex!"=="13" set "hex=D"
  if "!hex!"=="14" set "hex=E"
  if "!hex!"=="15" set "hex=F"
  set "xGUID=!xGUID!!hex!"
)
endlocal & if not "%~1"=="" (set "%~1=%xGUID%") else echo %xGUID%
exit /b

The main question was why running this code from the command prompt would generate the same string.

Code: Select all

C:\Batch\GUID>(@for /f "delims=" %a in ('call guid.bat') do @echo %a) &(@for /f "delims=" %a in ('call guid.bat') do @echo %a)
8227C16A5DDAB03F11EDCDC677CE6300
8227C16A5DDAB03F11EDCDC677CE6300

If you enable the pathping delay then it would of course generate a different 32 bit string.

But if you ran it from the command prompt this way and with no pathping delay it would generate different strings.

Code: Select all

C:\Batch\GUID>call guid.bat &call guid.bat
7092A72B95EAF5750CF0D9A66CBB05D0
7E375C1741C206F5180F803677E769CC

So that got me thinking I could use the WMIC command to get the seconds down to the thousandths and use that as an additional variable in the random generation. So I changed the code to this.

Code: Select all

@echo off
rem Delay in milliseconds for random number generator to recycle.
REM pathping -p 1000 -q 1 localhost >nul

break on
setlocal enabledelayedexpansion
FOR /F "tokens=3 delims==.-" %%G IN ('wmic os get localdatetime /value') DO SET seed=%%G
set "seed=1%seed:~0,3%"

set "xGUID="
for /L %%n in (1,1,32) do (
  set /a "hex=!RANDOM! * seed %% 16"
  if "!hex!"=="10" set "hex=A"
  if "!hex!"=="11" set "hex=B"
  if "!hex!"=="12" set "hex=C"
  if "!hex!"=="13" set "hex=D"
  if "!hex!"=="14" set "hex=E"
  if "!hex!"=="15" set "hex=F"
  set "xGUID=!xGUID!!hex!"
)
endlocal & if not "%~1"=="" (set "%~1=%xGUID%") else echo %xGUID%
exit /b

That seemed to fix running it from the command line with the FOR command.

Code: Select all

C:\Batch\GUID>(@for /f "delims=" %a in ('call guid.bat') do @echo %a) &(@for /f "delims=" %a in ('call guid.bat') do @echo %a)
F61CE3F57303539CB30F7E0C08DB93A4
EC28C6EAE606A628660EEC0800A62648

But I got a shocking result when I ran the batch file with CALL a couple of times.

Code: Select all

C:\Batch\GUID>call guid.bat &call guid.bat
44AEA0682442644AE6E280E640A0860A
6EC26FC6A858632C2260E4626F3BB9AF

C:\Batch\GUID>call guid.bat &call guid.bat
64F1EB9FD572FD6F86C70AF9F129712D
43DCD0E68692F5AAD03F8CAC4BF43E7C

C:\Batch\GUID>call guid.bat &call guid.bat
00000000000000000000000000000000
00000000000000000000000000000000

I almost sharted when I saw that last result come out. I am not making this up either. I have a screen shot of this as well if nobody believes me. My Photochop skills suck.

I am baffled by two 32 character strings of all zeros! I am probably being dumb right now and not seeing the problem.

Ran it a few more times. Got a 32 bit string of zeros twice in a row.

Code: Select all

C:\Batch\GUID>call guid.bat &call guid.bat
00000000000000000000000000000000
0AE2ECC04A6022E60E226A6C06C8CAE8

C:\Batch\GUID>call guid.bat &call guid.bat
00000000000000000000000000000000
40D8AD702537153262D6B09B116F5E22

[dbenham]

But I got a shocking result when I ran the batch file with CALL a couple of times.

Code: Select all

C:\Batch\GUID>call guid.bat &call guid.bat
44AEA0682442644AE6E280E640A0860A
6EC26FC6A858632C2260E4626F3BB9AF

C:\Batch\GUID>call guid.bat &call guid.bat
64F1EB9FD572FD6F86C70AF9F129712D
43DCD0E68692F5AAD03F8CAC4BF43E7C

C:\Batch\GUID>call guid.bat &call guid.bat
00000000000000000000000000000000
00000000000000000000000000000000

I almost sharted when I saw that last result come out. I am not making this up either. I have a screen shot of this as well if nobody believes me. My Photochop skills suck.

I am baffled by two 32 character strings of all zeros! I am probably being dumb right now and not seeing the problem.

Ran it a few more times. Got a 32 bit string of zeros twice in a row.

Code: Select all

C:\Batch\GUID>call guid.bat &call guid.bat
00000000000000000000000000000000
0AE2ECC04A6022E60E226A6C06C8CAE8

C:\Batch\GUID>call guid.bat &call guid.bat
00000000000000000000000000000000
40D8AD702537153262D6B09B116F5E22

No mystery, and I'm pretty sure the CALL issue is a red herring.

The problem is your formula: set /a "hex=!RANDOM! * seed %% 16"

You have a 1 in 16 chance that your seed value will be evenly divisible by 16, which will result in a final string of all zeros.

You could try adding the seed value instead of multiplying.

Another option is to recompute a new seed for each loop iteration. Perhaps you can simply use the last two digits of !time!, which would be much faster than WMIC. I think seed values ranging from 100 to 199 would be enough to get the variability that you need.


Dave Benham

[Squashman]

Adding instead of multiplying seem to do the trick. I was roughly getting 674 strings generated a minute and when I was multiplying, I would roughly get 40+ strings with all zeros. When I changed to adding the seed, I got none.

I tested two ways.

Code: Select all

REM Tested with these two lines
set /a "hex=(!RANDOM! + seed) %% 16"
REM set /a "hex=(!RANDOM! + 1!time:~-2!) %% 16"

[sst]

Digging up this old thread just because. I was commenting on a question at StackOverFlow that was now deleted by the user where they were using this code to generate a 32 character string.

Code: Select all

@echo off
REM Delay in milliseconds for random number generator to recycle.
REM pathping -p 2000 -q 1 localhost >nul

break on
setlocal enabledelayedexpansion

set "xGUID="
for /L %%n in (1,1,32) do (
  set /a "hex=!RANDOM! %% 16"
  if "!hex!"=="10" set "hex=A"
  if "!hex!"=="11" set "hex=B"
  if "!hex!"=="12" set "hex=C"
  if "!hex!"=="13" set "hex=D"
  if "!hex!"=="14" set "hex=E"
  if "!hex!"=="15" set "hex=F"
  set "xGUID=!xGUID!!hex!"
)
endlocal & if not "%~1"=="" (set "%~1=%xGUID%") else echo %xGUID%
exit /b

The main question was why running this code from the command prompt would generate the same string.

Code: Select all

C:\Batch\GUID>(@for /f "delims=" %a in ('call guid.bat') do @echo %a) &(@for /f "delims=" %a in ('call guid.bat') do @echo %a)
8227C16A5DDAB03F11EDCDC677CE6300
8227C16A5DDAB03F11EDCDC677CE6300

If you enable the pathping delay then it would of course generate a different 32 bit string.

Today I was answering this question on SO but when I hit the post I was shocked by the deleted question. That was very frustrating. All that time, effort and explanation.... poof

This was the suggested code I had prepared:

Code: Select all

@echo off
setlocal enabledelayedexpansion

set "RANDOM="
set "TIME="
for /F "tokens=1,3 delims=0123456789" %%A in ("%TIME: =%") do set "time.delims=%%A%%B"
for /F "tokens=4 delims=%time.delims%" %%A in ("%TIME: =%") do (
    for /F "tokens=* delims=0" %%A in ("%%A") do (
        set /a "seed=%%A+1"
    )
)
for /L %%A in (1,1,%seed%) do set /a "!RANDOM!"

set "hDigits=0123456789ABCDEF"
set "xGUID="
for /L %%n in (1,1,32) do (
    set /a "hex=!RANDOM! %% 16"
    for %%i in (!hex!) do set "xGUID=!xGUID!!hDigits:~%%i,1!" 
)
echo %xGUID%
endlocal & if not "%~1"=="" set "%~1=%xGUID%"
exit /b

[dbenham]

Adding instead of multiplying seem to do the trick. I was roughly getting 674 strings generated a minute and when I was multiplying, I would roughly get 40+ strings with all zeros. When I changed to adding the seed, I got none.

I tested two ways.

Code: Select all

REM Tested with these two lines
set /a "hex=(!RANDOM! + seed) %% 16"
REM set /a "hex=(!RANDOM! + 1!time:~-2!) %% 16"

1 in 16 chance * 674 runs should theoretically yield 42 strings of all zeros. So your results sound about right


Dave Benham

[sst]

Adding instead of multiplying seem to do the trick. I was roughly getting 674 strings generated a minute and when I was multiplying, I would roughly get 40+ strings with all zeros. When I changed to adding the seed, I got none.

I tested two ways.

Code: Select all

REM Tested with these two lines
set /a "hex=(!RANDOM! + seed) %% 16"
REM set /a "hex=(!RANDOM! + 1!time:~-2!) %% 16"

It still have a high rate of producing repeating results with successive calls in new instances of cmd (with both wmic and !time!)

Code: Select all

> (for /L %a in (1,1,50) do @cmd /c guid.bat)|sort

Raw Output (wmic):

D90499C905C6D4550F1B8F0C19B907AB
95C05585C1829011CBD74BC8D575C367
407B00307C3D4BCC7682F67380207E12
1D48DD0D490A1899435FC3405DFD4BEF
95C05585C1829011CBD74BC8D575C367
73AE3363AF607EFFA9B529A6B353A145
1D48DD0D490A1899435FC3405DFD4BEF
FB26BBEB27E8F677213DA12E3BDB29CD
B7E277A7E3A4B233EDF96DEAF797E589
629D22529E5F6DEE98A41895A2429034
FB26BBEB27E8F677213DA12E3BDB29CD
B7E277A7E3A4B233EDF96DEAF797E589
C8F388B8F4B5C344FE0A7EFB08A8F69A
407B00307C3D4BCC7682F67380207E12
E3722E38DF60653D066EE650A952761A
7C0BB7C168F9FEC69FF77FE932EB0FA3
F4833F49E071764E177FF761BA63872B
9E2DD9E38A1B10E8B119910B540D21C5
7C0BB7C168F9FEC69FF77FE932EB0FA3
49D8849E35C6CB936CC44CB60FB8DC70
D2611D27CE5F542CF55DD54F98416509
7C0BB7C168F9FEC69FF77FE932EB0FA3
0594405AF182875F28800872CB74983C
C1500C16BD4E431BE44CC43E873054F8
9E2DD9E38A1B10E8B119910B540D21C5
5AE995AF46D7DCA47DD55DC710C9ED81
0594405AF182875F28800872CB74983C
B04FFB05AC3D320AD33BB32D762F43E7
7C0BB7C168F9FEC69FF77FE932EB0FA3
0594405AF182875F28800872CB74983C
AF3EEAF49B2C21F9C22AA21C651E32D6
38C7738D24B5BA825BB33BA5FEA7CB6F
E3722E38DF60653D066EE650A952761A
C1500C16BD4E431BE44CC43E873054F8
49D8849E35C6CB936CC44CB60FB8DC70
8D1CC8D2790A0FD7A00880FA43FC10B4
3213E7DBFD4E395941F571E97E4029CD
CBAC706486D7C2E2DA8E0A7207D9B256
87683C2042938EAE964AC63EC3957E12
10F1C5B9DB2C17372FD35FC75C2E07AB
87683C2042938EAE964AC63EC3957E12
0FE0B4A8CA1B06261EC24EB64B1DF69A
BA9B6F5375C6B1D1C97DF961F6C8A145
10F1C5B9DB2C17372FD35FC75C2E07AB
87683C2042938EAE964AC63EC3957E12
EDCE9286A8F9E404FCA02C9429FBD478
543509FD1F605B7B6317930B90624BEF
CBAC706486D7C2E2DA8E0A7207D9B256
CBAC706486D7C2E2DA8E0A7207D9B256
4324F8EC0E5F4A6A520682FA8F513ADE

Sorted:

0594405AF182875F28800872CB74983C
0594405AF182875F28800872CB74983C
0594405AF182875F28800872CB74983C
0FE0B4A8CA1B06261EC24EB64B1DF69A
10F1C5B9DB2C17372FD35FC75C2E07AB
10F1C5B9DB2C17372FD35FC75C2E07AB
1D48DD0D490A1899435FC3405DFD4BEF
1D48DD0D490A1899435FC3405DFD4BEF
3213E7DBFD4E395941F571E97E4029CD
38C7738D24B5BA825BB33BA5FEA7CB6F
407B00307C3D4BCC7682F67380207E12
407B00307C3D4BCC7682F67380207E12
4324F8EC0E5F4A6A520682FA8F513ADE
49D8849E35C6CB936CC44CB60FB8DC70
49D8849E35C6CB936CC44CB60FB8DC70
543509FD1F605B7B6317930B90624BEF
5AE995AF46D7DCA47DD55DC710C9ED81
629D22529E5F6DEE98A41895A2429034
73AE3363AF607EFFA9B529A6B353A145
7C0BB7C168F9FEC69FF77FE932EB0FA3
7C0BB7C168F9FEC69FF77FE932EB0FA3
7C0BB7C168F9FEC69FF77FE932EB0FA3
7C0BB7C168F9FEC69FF77FE932EB0FA3
87683C2042938EAE964AC63EC3957E12
87683C2042938EAE964AC63EC3957E12
87683C2042938EAE964AC63EC3957E12
8D1CC8D2790A0FD7A00880FA43FC10B4
95C05585C1829011CBD74BC8D575C367
95C05585C1829011CBD74BC8D575C367
9E2DD9E38A1B10E8B119910B540D21C5
9E2DD9E38A1B10E8B119910B540D21C5
AF3EEAF49B2C21F9C22AA21C651E32D6
B04FFB05AC3D320AD33BB32D762F43E7
B7E277A7E3A4B233EDF96DEAF797E589
B7E277A7E3A4B233EDF96DEAF797E589
BA9B6F5375C6B1D1C97DF961F6C8A145
C1500C16BD4E431BE44CC43E873054F8
C1500C16BD4E431BE44CC43E873054F8
C8F388B8F4B5C344FE0A7EFB08A8F69A
CBAC706486D7C2E2DA8E0A7207D9B256
CBAC706486D7C2E2DA8E0A7207D9B256
CBAC706486D7C2E2DA8E0A7207D9B256
D2611D27CE5F542CF55DD54F98416509
D90499C905C6D4550F1B8F0C19B907AB
E3722E38DF60653D066EE650A952761A
E3722E38DF60653D066EE650A952761A
EDCE9286A8F9E404FCA02C9429FBD478
F4833F49E071764E177FF761BA63872B
FB26BBEB27E8F677213DA12E3BDB29CD
FB26BBEB27E8F677213DA12E3BDB29CD

Mine does not produce repeating results that much but it has a problem of producing shifted results but the amount of shift is small and fixed and is completely noticable:

Code: Select all

> for /L %a in (1,1,4) do @cmd /c sst_guid.bat

Output:

8289B91FF7B6F9E1F3F604EE2B1EAA17
289B91FF7B6F9E1F3F604EE2B1EAA174
89B91FF7B6F9E1F3F604EE2B1EAA174A
9B91FF7B6F9E1F3F604EE2B1EAA174A3

Changed this line

Code: Select all

set /a "seed=%%A+1"

to this

Code: Select all

set /a "seed=%%A+1, seed+=((seed %% 10)+1)*100"

Now the shift is much bigger and variable (it still increases predictably then wraps around) but no correlation can be detected with naked eye. It has the potential to get optimized further and be more random looking by modular arithmetic.
Then also adding the seed to !RANDOM! as Squashman did can help to reduce the correlation further.

[Squashman]

It still have a high rate of producing repeating results with successive calls in new instances of cmd (with both wmic and !time!)

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.