-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Add more documentation on array iteration #10902
Conversation
Cool. As an aside, I'm wondering if for the purposes of JuliaLang/LinearAlgebra.jl#136 it might make sense to add an |
It's an interesting idea, but #6769 made the prospect of asking "what is a nonzero?" absolutely terrifying. Someone braver than me will have to implement it 😄. |
|
|
Add more documentation on array iteration
Really #6769 is more noise than substance. Anyone who actually works with sparse matrices regularly is perfectly comfortable with allowing explicitly stored zeros. A structural/stored nonzero can have a value equal to zero, and it shouldn't change any calculation results if things are implemented correctly.
That's exactly the point. Better than re-writing the same messy structure-specific iteration code inside every single method you want to implement for each matrix type. I'd rather write the iteration code once per type and use that everywhere, than have to duplicate it ntypes * nmethods times. |
Still, I'm not sure if you really want to use reading and assignment to |
(We could move this discussion elsewhere? JuliaLang/LinearAlgebra.jl#136 maybe?) For CSC as an example, the analog to CartesianIndex would need to store column index and nonzero index. Reading from or writing to an existing nonzero can be efficient in that case. The inefficient operations would be inserting a new nonzero that was not previously allocated in the structure, or removing an existing nonzero from the structure. There would be a slight ambiguity in whether |
I agree with all of the above, and JuliaLang/LinearAlgebra.jl#136 seems like a good place to continue the discussion. |
Also agreed, @tkelman, including the move of future discussion. |
Following up on suggestion for further documentation in #10858.