# Rand chokes on UInt64

**URL:** <https://discourse.julialang.org/t/rand-chokes-on-uint64/7790>\
**Category:** Internals & Design\
**Created:** [December 15, 2017, 2:47pm UTC](https://discourse.julialang.org/t/rand-chokes-on-uint64/7790 "2017-12-15T14:47:11Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ndbecker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ndbecker/32/10829_2.png) [@ndbecker](https://discourse.julialang.org/u/ndbecker)\
**Post date:** [December 15, 2017, 2:47pm UTC](https://discourse.julialang.org/t/rand-chokes-on-uint64/7790/1 "2017-12-15T14:47:11Z")

</div>

IMO, rand should be able to accept any sort on Integer, and in this case unsigned is actually the only logical value, so I would call this a bug.

julia\> rand(Base.Random.GLOBAL\_RNG, 0:10, UInt64(4))  
ERROR: MethodError: no method matching rand(::MersenneTwister, ::UnitRange{Int64}, ::UInt64)  
Closest candidates are:  
rand(::AbstractRNG, !Matched::Integer…) at random.jl:369  
rand(::AbstractRNG, !Matched::Type, ::Integer, !Matched::Integer…) at random.jl:372  
rand(::AbstractRNG, ::UnitRange{#s267} where #s267\<:Union{BigInt, Bool, Signed, Unsigned}) at random.jl:654  
…  
Stacktrace:  
[1] macro expansion at ./REPL.jl:97 [inlined]  
[2] (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:73

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [December 15, 2017, 2:55pm UTC](https://discourse.julialang.org/t/rand-chokes-on-uint64/7790/2 "2017-12-15T14:55:41Z")

</div>

Try

```julia
rand(Base.Random.GLOBAL_RNG, 0:10, 4)

```

Even though indexes are “logically” unsigned for plain vanilla arrays, the convention in Julia is to use `Int`. This prevents unpleasant surprises when doing arithmetic (eg consider subtraction which would result in a negative value, etc).

Slightly related, see the discussion there:

> [@Fill function requiring same Int type in the tuple](https://discourse.julialang.org/t/fill-function-requiring-same-int-type-in-the-tuple/7660):
>
> I would have thought that the fill() function is smarter. Now I have to cast to the widest type before calling it… Any thoughts? Am I too picky? julia\> fill(0, (Int64(10), Int32(8))) ERROR: MethodError: no method matching fill(::Int64, ::Tuple{Int64,Int32}) Closest candidates are: fill(::Any, ::Tuple{Vararg{Int64,N}} where N) at array.jl:253 fill(::Any, ::Integer...) at array.jl:254 julia\> fill(0, (Int64(10), Int64(8))) 10×8 Array{Int64,2}: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0…

---

<div class="post-metadata">

**Author:** ![rfourquet](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rfourquet/32/3610_2.png) [@rfourquet](https://discourse.julialang.org/u/rfourquet)\
**Post date:** [December 15, 2017, 5:33pm UTC](https://discourse.julialang.org/t/rand-chokes-on-uint64/7790/3 "2017-12-15T17:33:16Z")

</div>

> [@ndbecker](#):
>
> so I would call this a bug

It’s “fixed” on master, no idea when exactly!