# Random number generation
**URL:** https://discourse.julialang.org/t/random-number-generation/110010
**Category:** General Usage
**Tags:** question, random
**Created:** [February 9, 2024, 8:27pm UTC](https://discourse.julialang.org/t/random-number-generation/110010 "2024-02-09T20:27:03Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@math\_opt](https://discourse.julialang.org/u/math_opt)
#### Post date: [February 9, 2024, 8:27pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/1 "2024-02-09T20:27:03Z")
Why do I get different result when I run the `rand` command twice with the same seed in the Julia REPL?
```julia
using Random
using Distributions
rng = MersenneTwister(1234)
rand(rng) # outputs 0.5908446386657102
#run again
rand(rng) # outputs 0.7667970365022592
```
Any help appreciated. Thanks!
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [February 9, 2024, 8:28pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/2 "2024-02-09T20:28:32Z")
`rand` mutates the rng.
```julia
julia> rng = MersenneTwister(1234)
MersenneTwister(1234)
julia> rand(rng)
0.5908446386657102
julia> rng
MersenneTwister(1234, (0, 1002, 0, 1))
```
P.S. you probably want to use `Xoshiro` which is typically better than `MersenneTwister`
---
### Author:  [@math\_opt](https://discourse.julialang.org/u/math_opt)
#### Post date: [February 9, 2024, 8:34pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/3 "2024-02-09T20:34:32Z")
Thanks @Oscar_Smith. That explains the behavior. So to ensure the same output, I guess the best way is to make sure the `rng` is redefined before every call to `rand`. Is that right? So maybe putting it inside a function is better. Just trying to know how people go about seeding their codes.
Also, never heard of `Xoshiro`. Thanks for pointing that out. Is there any particular reason why it’s _better_ than `MersenneTwister` apart from what’s mentioned in the documentation [`Apart from the high speed, Xoshiro has a small memory footprint, making it suitable for applications where many different random states need to be held for long time.`]?
---
### Author:  [@adienes](https://discourse.julialang.org/u/adienes)
#### Post date: [February 9, 2024, 8:37pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/4 "2024-02-09T20:37:29Z")
> [@math\_opt](#):
>
> So to ensure the same output, I guess the best way is to make sure the `rng` is redefined before every call to `rand`. Is that right?
you can also `seed!` an existing rng, e.g. `Random.seed!(rng, 1234)`
---
### Author:  [@math\_opt](https://discourse.julialang.org/u/math_opt)
#### Post date: [February 9, 2024, 8:44pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/5 "2024-02-09T20:44:33Z")
Not sure I understand completely. I still get different outputs via this approach. Do you mind providing a simple example on how to use it? Thanks!
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [February 9, 2024, 8:47pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/6 "2024-02-09T20:47:37Z")
> [@math\_opt](#):
>
> Is there any particular reason why it’s _better_ than `MersenneTwister` apart from what’s mentioned in the documentation
AFAIK the Xoshiro family has much better statistical properties than the Mersenne Twister. You can find some relevant papers with Google Scholar, but the non-cryptographic pseudorandom generators are mostly evaluated via test suites like Practrand.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [February 9, 2024, 8:49pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/7 "2024-02-09T20:49:54Z")
> [@math\_opt](#):
>
> So to ensure the same output, I guess the best way is to make sure the `rng` is redefined before every call to `rand`.
If you want _every_ call to `rand` to give the same result, why are you calling `rand` multiple times? Why not just set `a_random_x = rand()` once and then use `a_random_x` as needed?
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [February 9, 2024, 8:50pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/8 "2024-02-09T20:50:56Z")
> [@math\_opt](#):
>
> I still get different outputs via this approach. Do you mind providing a simple example on how to use it?
```julia-repl
julia> using Random
julia> g = Xoshiro(123);
julia> rand(g)
0.521213795535383
julia> Random.seed!(g, 123)
Xoshiro(0xfefa8d41b8f5dca5, 0xf80cc98e147960c1, 0x20e2ccc17662fc1d, 0xea7a7dcb2e787c01, 0xf4e85a418b9c4f80)
julia> rand(g)
0.521213795535383
```
---
### Author:  [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)
#### Post date: [February 9, 2024, 9:19pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/9 "2024-02-09T21:19:35Z")
Think a random number generator (RNG) to something that when you seed (or first create) provides a fixed, deterministic sequence of random numbers. Everytime you then call `rand` you pop out a single element from that sequence.
I wrote “deterministic” sequence because if you seed or construct the RNG with a given number, than the sequence that the RNG provides is always the same.
---
### Author:  [@abraemer](https://discourse.julialang.org/u/abraemer)
#### Post date: [February 9, 2024, 9:37pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/10 "2024-02-09T21:37:21Z")
On a more serious note: it is a slight inconsistency that `rand(rng)` mutates the input but has no `!`… I can see why though.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [February 10, 2024, 4:02am UTC](https://discourse.julialang.org/t/random-number-generation/110010/11 "2024-02-10T04:02:06Z")
It’s not inconsistent and it’s documented. The `!` is used to warn the caller that a function modifies the contents of a data structure. It is not used for all modification of any state. You do not need a warning that `readline(io)` changes the state of the io argument—of course it does, that’s the only way for I/O operations to work. You also don’t need a warning that `rand(rng)` changes the state of the rng for much the same reason. By comparison there are many reasonable functions that take arrays and don’t mutate them. So when some function does mutate an array, you want a warning, and that’s what the `!` is for.
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [February 10, 2024, 4:11am UTC](https://discourse.julialang.org/t/random-number-generation/110010/12 "2024-02-10T04:11:21Z")
The current API isn’t bad, but I do kinda think a strict rule “mutate any argument, get a `!`” could be easier to learn and remember, e.g. `read!(io)` and `readinto!(io, out)`, just because “always” is a simpler mnemonic than “unless it’s obvious”.
---
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [February 10, 2024, 6:13am UTC](https://discourse.julialang.org/t/random-number-generation/110010/13 "2024-02-10T06:13:29Z")
A random number generator has no official (documented) internal state, hence nothing is being mutated, officially. As far as the caller is concerned, the RNG might as well be measuring some cosmic radiation and simply return those bits.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [February 10, 2024, 2:25pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/14 "2024-02-10T14:25:55Z")
That would make it impossible to express that some IO operations mutate their array argument.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [February 10, 2024, 2:31pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/15 "2024-02-10T14:31:31Z")
Right, and similarly IO objects in principle just interact with the outside world. Of course there are buffers and other _private_ state, but the primary state that changes is the outside world, which is entirely different from mutating a program-visible data structure. This is exactly the difference: `!` is about warning that a function modifies a publicly visible data structure like an array or a dictionary. The state of I/O streams or RNGs is not that—it’s implicit internal state.
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [February 10, 2024, 6:36pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/16 "2024-02-10T18:36:13Z")
> [@StefanKarpinski](#):
>
> Of course there are buffers and other _private_ state, but the primary state that changes is the outside world, which is entirely different from mutating a program-visible data structure. This is exactly the difference: `!` is about warning that a function modifies a publicly visible data structure like an array or a dictionary.
Great, this is the core of the argument. I favor a somewhat larger conception of “publicly visible” than that.
Specifically: my inclination is that a function without `!` would modify internal state of its argument only if that state is not externally visible, such as a private cache that helps with the structure’s performance. Any function that has an effect on the argument visible from public APIs would have `!`. For example in
```julia
julia> let io = IOBuffer("hello")
read(io), read(io)
end
(UInt8[0x68, 0x65, 0x6c, 0x6c, 0x6f], UInt8[])
```
this `read` is (1) not `:consistent` because (2) it mutates its argument, so it would have `!`.
By contrast, if it didn’t take the `io` as an argument and just (2) mutated some hidden global state, or if it (1) reset the publicly readable state of its argument afterwards so that subsequent reads were consistent, then it would just be `read()`.
---
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [February 10, 2024, 7:48pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/17 "2024-02-10T19:48:30Z")
The “official” interpretation is that `read(io)` doesn’t mutate `io`. It’s the state of the world that changed, not the `io` object.
> I favor a somewhat larger conception of “publicly visible” than that.
That’s fine, but the Julia designers had to draw the line somwhere on what is explicit state and what is implicit state. There’s always going to be examples where one could argue whether that line might have been better moved a bit in one direction or the other. In some sense, _every_ function mutates, since it changes the content of your RAM or at least the registers in the CPU.
Functional languages like Haskell tend to draw the line for what is explicit state a lot closer and probably would support that `read(io)` should be considered mutating. But fundamentally, it’s a language design decision, and [Julia is not at that stage of development anymore](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872). So the semantics or name of `read` isn’t going to change.
Personally, I find the decisions that were made for Julia quite sensible, but it’s hard to argue if your intuition is different (maybe because you’re coming from a more functional language background?)
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [February 10, 2024, 8:11pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/18 "2024-02-10T20:11:32Z")
> [@goerz](#):
>
> Julia designers had to draw the line somwhere on what is explicit state and what is implicit state. There’s always going to be examples where one could argue whether that line might have been better moved a bit in one direction or the other. In some sense, _every_ function mutates, since it changes the content of your RAM or at least the registers in the CPU.
The internal state of memory is not public API, nor would be any internal cache or memory management structure. RAM and CPU state are of course not public either. The state of such things is not guaranteed by any public interface, so whether they are mutated is immaterial to the API design.
By contrast, the bytes returned by a buffer read are part of its public API: usage of `read` counts on it returning different bytes in successive reads. I don’t see what distinction is being implied between the state of a buffer and the state of an array, since both are mutated in such a way that they fail to return the same value by public APIs invoked twice.
```julia
julia> let xs = [1,2]
pop!(xs), pop!(xs)
end
(2, 1)
```
---
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [February 10, 2024, 8:41pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/19 "2024-02-10T20:41:46Z")
If an `IOBuffer` was the primary object that `read` was designed to act on, I’d be inclined to agree with you. But more commonly, `io` is a file handle or stream like `stdin`, and then the situation is much less clear-cut. And for other methods of `read` like `read(filename)` or `read(command)`, thinking of `read` as mutating its argument wouldn’t make any sense at all.
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [February 10, 2024, 10:42pm UTC](https://discourse.julialang.org/t/random-number-generation/110010/20 "2024-02-10T22:42:48Z")
> [@goerz](#):
>
> Personally, I find the decisions that were made for Julia quite sensible, but it’s hard to argue if your intuition is different (maybe because you’re coming from a more functional language background?)
For names, no. I have found I disagree with basically every decision the core team has made about naming in general (I blame the Matlab influence). The rest of the language is great, but every other month I think about starting a project that could somehow shadow all the base names and replace them by sensible alternatives for people that agree with me to use.