Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix bug in sparse matrix indexing #1651

Merged

Conversation

leftaroundabout
Copy link
Contributor

As per #1650, the new implementation of ProductSpaceOperator after #1642 has a problem with element-wise accessing of the constituent operators, specifically with the indexing into the matrix of these operators.

I traced the problem to Python's lack of type safety - specifically the fact that the new COOMatrix class does not guarantee its row- and column indices are stored as NumPy arrays as ProductSpaceOperator requires.

A simple explicit conversion through np.asarray fixes this problem.

@pep8speaks
Copy link

pep8speaks commented Aug 9, 2024

Checking updated PR...

Line 58:77: E202 whitespace before ')'
Line 58:17: E128 continuation line under-indented for visual indent
Line 57:17: E201 whitespace after '('

Comment last updated at 2024-08-12 09:24:28 UTC

Previously, they could also be stored as plain lists, which would happen
whenever the COOMatrix objects was initialised with lists. Most operations
still worked ok then, but equality check means something completely
different for NumPy arrays, and ProductSpaceOperator's __getitem__
method relies on this behaviour to look up the desired linear index for
a requested element in the matrix of operators. If the index is a list,
this would give wrong results.
@leftaroundabout leftaroundabout force-pushed the bug/sparsematrix-indexing branch from 319af32 to 3b4a7db Compare August 12, 2024 09:24
Copy link

@Emvlt Emvlt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class is a custom implementation of sparse COO arrays, for the special case of sparse arrays of operators, feature which scipy does not support anymore. This feature is important in methods such as Kaczmarz algorithms, hence this class. The type checking was not sufficient, for using list to declare the non zeros elements of the array would then cause issues downstream. So Justus had to convert the list to an array from the beginning.

Copy link
Contributor

@JevgenijaAksjonova JevgenijaAksjonova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants