Random number generator gnu octave code#

However, when Octave first starts, the vector that is returned from rand('state') is not the actual initial state. # uh oh, they should be equal, let's try againĪs far as I can tell, setting the rand state does reset the rand generator to a known state and the same sequence is produced. # now let's try to go back to the initial state > isequal (init_seed, rand ('seed')) # NOT using 'seed'

> x = rand (100) # generate a few numbers to shift the state # just started Octave (with -norc), rand generator is in some indeterminate state I'm not sure this is worth pursuing, but I have noticed this odd behavior when testing the rand functions: I don't think this is documented anywhere, but again, this would be great to eliminate by phasing out the 'old' algorithm completely. So I think this 'bug 1' only occurs when the previous rand('seed', 'reset') was done within the same second as the next one. > sum = 0 for i = 1:20 pause (1.1) sum += t () endfor sum

> sum = 0 for i = 1:1000 sum += t () endfor sum > function r = t () aa = rand ('seed') randn ('seed', 'reset') bb = rand ('seed') r = isequal (aa, bb) endfunction Now let's test it in loops with different timings: > aa = randn ('seed') rand ('seed', 'reset') bb = randn ('seed') > aa = rand ('seed') randn ('seed', 'reset') bb = rand ('seed') Īns = 0 # But sometimes this returns true, try it multiple times But your observation that one generator resets the other but not the other way around isn't quite correct. I haven't looked into why, but this is probably a Matlab compatibility thing with the old generator.įirst, I have verified that randn('seed', 'reset') does switch the rand generator to the old algorithm. So your test of resetting one generator and comparing the seed of the other probably depends on round-off error with the current system clock. TL DR - I think rand('seed', 'reset') depends on the current time stamp. Thu 01:46:54 AM UTC, comment #12: - I'll file that as a new - I do see some inconsistency with respect to your 'bug 1'. All the while, we are actually using state. He can query a seed, and he can supply the same seed back for reproducible behavior.

Random number generator gnu octave code#

Rand('seed', 'reset') does rand('state', 'reset').įor the person that uses 'seed', his code continues to do what he expects: He can reset the state. Rand('seed', X) => actually imlements rand('state', X).įoo = rand('seed') => Implements K = 1e20*rand(), implement rand('state', K), and output K. These have the advantage that octave never silently switches behind my back to 'seed', while continuing to satisfy code that uses seed: How about these (or similar) drop-in replacements. So, good to maintain 'seed'.īut, they don't REALLY care what underlying mechanism rand() uses. It is understandable that people want their legacy code to continue to work (and sometimes are actually unable to change it, even if they want.). Matlab has been trying for years to get people to abandon them. > It will be hard to switch Octave away from these random number generators. Hence, it really is the numbers themselves that have the necessary magic.Īnyways, it would be better to resolve the issue with the conv2 algorithm rather than messing with our random number generation. But reading in the numbers and executing the conv2 test on them works. I wanted to make sure that it wasn't a strange side effect like initializing the 'seed' generator which also set some CPU processor flags. I also generated a random set of numbers, saved them to a file, and then re-started Octave. Thus, it is not the particular value (42) that we use in the BIST tests, but the fact that we use the 'seed' generator. I tested with different random values of the seed itself and the conv2 test always pass. The root issue now seems to be that the inner and outer convolutions are performed in different directions and the summation of floating point numbers can accumulate different small errors because of that.įor some reason, the random numbers that are generated by the 'seed' generator are apparently precisely represented in IEEE-854 so that they do not accumulate these errors. This function has consistently been a problem.