Bruno has already explained why sprand/sprandn fail to produce the requested density of arrays. So this answer is here only to add some information. Honestly, I would think they might have done at least a little better job in those codes for matrices that are only semi-sparse. My guess is the author did not consider that anyone would want to generate sparse matrices that are even remotely close to full.
I would add that you really don't have any rational need for high density sparse matrices. That is, a sparse matrix with a density even as large as 50% will be slower in terms of computation. It will take more memory to store.
Af = randn(5000);
Af(rand(size(A)) > 0.5) = 0;
As = sparse(Af);
whos Af As
Name Size Bytes Class Attributes
Af 5000x5000 200000000 double
As 5000x5000 200048280 double sparse
nnz(As)/numel(As)
ans =
0.50002068
This, by the way, has one virtue when computing a semi-sparse matrix, in the sense that it does produce a matrix with a very good approximation of the requested density. A problem of course, is I created a full matrix, and then discarded half of the elements. Not only that, but the way I chose the elements to discard forced me to create a temporary second full matrix of that size. So the method I used above is arguably a poor one. But a more careful sampling scheme would logically have been possible.
Regardless, the sparse version (As) takes more memory to store then the corresponding full matrix (Af). This happens because a sparse matrix needs to store not only the non-zero elements, but also the locations of those elements. And that too requires memory.
Are these quasi-sparse matrices faster to use? Often not the case.
timeit(@() lu(Af))
ans =
0.457781138132
timeit(@() lu(As))
ans =
48.439253306132
timeit(@() Af*Af)
ans =
0.864906439132
timeit(@() As*As)
ans =
32.712310654132
Sparse matrices are splendid tools, when your matrix truly is sparse. But when it is only 50% sparse or even anything in that vicinity, that sparsity becomes a cost, not a gain.
