Re^10: Math::GSL::SparseMatrix is broken if installed on latest 5.32.1.1 "Strawberry Perl PDL edition", whom to report this issue to? [OT]

No more virtual memory?

Ok - that would mean that "there are some mysterious rules of usage that I am overlooking".
In fairness to them, perhaps that's not at all "mysterious" - but I wasn't expecting that sufficient memory would be allocated to actually store so many zeros.

Thanks for the discussion.
It was interesting to poke at (part of) the GSL library again.

Cheers,
Rob

Comment on Re^10: Math::GSL::SparseMatrix is broken if installed on latest 5.32.1.1 "Strawberry Perl PDL edition", whom to report this issue to? [OT]

Replies are listed 'Best First'.
Re^11: Math::GSL::SparseMatrix is broken if installed on latest 5.32.1.1 "Strawberry Perl PDL edition", whom to report this issue to? [OT] by Anonymous Monk on Nov 16, 2022 at 06:53 UTC
In fairness, it's not space for zeros which is allocated, but data, i, p (each 10% of total), and AVL tree. E.g. 40K x 40K matrix of type double would require ~12.8 GB of dense storage, but ~7.5 GB (checked "Commit size") of sparse COO storage. I agree it's unexpectedly very much. If I change density to 20%, then value goes up to ~15 GB. Already more than for dense matrix. Well, for my initial purposes of "very large 64-bit indexes" actual population would be very low. Sorry to continue after discussion seemingly was supposed to end :)	[reply]

Replies are listed 'Best First'.

Re^11: Math::GSL::SparseMatrix is broken if installed on latest 5.32.1.1 "Strawberry Perl PDL edition", whom to report this issue to? [OT]
by Anonymous Monk on Nov 16, 2022 at 06:53 UTC

In fairness, it's not space for zeros which is allocated, but data, i, p (each 10% of total), and AVL tree. E.g. 40K x 40K matrix of type double would require ~12.8 GB of dense storage, but ~7.5 GB (checked "Commit size") of sparse COO storage. I agree it's unexpectedly very much. If I change density to 20%, then value goes up to ~15 GB. Already more than for dense matrix. Well, for my initial purposes of "very large 64-bit indexes" actual population would be very low. Sorry to continue after discussion seemingly was supposed to end :)

[reply]