I noticed that rand(Complex{Float64}) seems to have support in \{z ~|~ 0 \le \textrm{Re}(z) \le 1 ~ \wedge ~ 0 \le \textrm{Im}(z) \le 1\}. I certainly understand why this happens from a computing perspective (it just calls rand(Float64) + im*rand(Float64)) but I’m wondering if this makes sense in any real application, no pun intended. Instead, I’d think that the analogous behavior to rand(Float64) returning numbers in \{r~|~ 0 \le r \le 1\} would be to return numbers in \{z ~ | ~ 0 \le |z| \le 1\} i.e. sqrt(rand(Float64))*exp(im*2*pi*rand(Float64)). This seems like a far more useful behavior for an stdlib function especially since it’s easy enough for users just to call rand(Float64) + im*rand(Float64) if needed. Thoughts?
Do you have any concrete application in mind for complex random variates? Examples would help focus the discussion.
TBH, I don’t know if rand(Complex) is really useful for anything. If one has a specific distribution in mind, that should be specified explicitly. rand(Float64) is uniform, which is a useful building block for various frequently used distributions, but AFAIK rand(Complex) isn’t.
It may still be useful for unit testing, but for that I would go with the cheapest option (rand(Float64) twice).
1 Like
But this wouldn’t be uniformly distributed in the unit disc, would it? I agree with @Tamas_Papp that there’s probably no canonical definition of rand(Complex) and it would make more sense to have a package which would provide support for commonly useful distributions.
Honestly every time I try to think of an example it seems that I would generate the real and imaginary parts separately. It’s just an inconsistency that bothered me.
Sorry, see correction above.
1 Like