make sprand type stable

[KristofferC]

fixes #16073

[KristofferC]

Actually, maybe the second sprand function is better as:

function sprand{T}(m::Integer, n::Integer, density::AbstractFloat,
                rfn::Function, t::Type{T}=eltype(rfn(1)))
    return sprand(GLOBAL_RNG, m, n, density, rfn, t)
end

[KristofferC]

Added that.

Edit: Removed that. The passed random function doesn't take a RNG object for the second sprand function

[KristofferC]

Interesting, git reset --hard to an old commit and then force pushing that commit means that travis will fail because it thinks a newer commit exist.

[nalimilan]

Maybe git commit --amend date=now?

[KristofferC]

I just rebased on a newer master commit

[KristofferC]

This is wrong. Will fix in a while. rfn should not take a RNG.

[KristofferC]

Test passes, ready for review / merge.

[Sacha0]

Why x -> round(Int, rand(x)*100) rather than x -> rand(0:100, x)?

[KristofferC]

I just copied this from another test that happened to fail when I did a mistake in implementing this PR:

julia/test/sparsedir/sparse.jl

Line 592 in e8601e8

let S = sprand(50, 30, 0.5, x->round(Int,rand(x)*100)), I = sprandbool(50, 30, 0.2)

[KristofferC]

Bump

[ViralBShah]

I guess we should separately have a version of sprand for random sparse vectors.

[ViralBShah]

We already do - this was just a type inference issue in the sprand case for matrices. All good. Thanks.