Comments (14)
I apologize about calling your PRs half-baked. It was uncalled for and shitty of me. I appreciate all your work on these things and don’t want to discourage it. I’m frustrated about a few things:
- That the sparse APIs didn’t get more attention pre-1.0, which is obviously not your fault and is water under the bridge at this point;
- That we had a pretty solid plan a year ago that didn’t get any traction or much attention;
- That there are too many PRs making breaking changes that we definitely can’t merge.
- That sparse and linear algebra in general has a distinct lack of maintenance and leadership for the past year or so.
- Because sparse and linalg are still stdlibs, this had become a pretty major burden for language development: there are more stalled out sparse and linalg issues and PRs than any another category of issue/PR on the repo.
My proposal: either reopen Simon’s issue proposing better names or create a new issue (not a PR) to discuss what to do about the sparse APIs; come to some kind of agreement on that issue and only then set about executing the plan.
I do not think that we can break existing code that accesses fields, but we can rename fields and provide getproperty methods that allow the old names to continue to work. So pick the names you want, change them to those, make the old ones work, update the docs.
from sparsearrays.jl.
I would personally be in favour of deprecating and generally having everyone use accessor methods for all sparse data structures going forward.
But, at the same time, we probably have many other things to do in sparse matrix land and this is perhaps not the most pressing issue. While the implementation of this is straightforward, it may cause quite a bit of follow-up work as it propagates through the packages.
How about we leave this issue open to collect comments for now (while we focus our attention on other things)?
from sparsearrays.jl.
The only way to use and modify SparseMatrixCSC efficiently in many situations is to use these field so they are de facto public. Just removing/changing their name is likely to be very disruptive to the ecosystem (grepping through packages for .colptr
etc should make this clear)
from sparsearrays.jl.
(ping @fredrikekre as you reacted in the previous discussion)
from sparsearrays.jl.
Thinking about this a bit after the previous discussion JuliaLang/julia#32953 (comment), I'm now somewhat against deprecating or banning the field access. It is very trivial for new AbstractSparseMatrixCSC
subtypes to implement SparseMatrixCSC
-compatible getproperty
. So, making old code base compatible with (SparseMatrixCSC
-compatible) AbstractSparseMatrixCSC
subtypes is as easy as relaxing the type constraints. Considering there is unknown amount of public and private code bases using SparseMatrixCSC
I don't think it would make sense to break them just for pinging them that we now have AbstractSparseMatrixCSC
.
from sparsearrays.jl.
+1 for leaving it open and focusing on other issues. We can come back to this anytime later.
from sparsearrays.jl.
Actually, the fields of SparseMatrixCSC
are mentioned in the documentation
It explicitly says "internal representation" so I don't know if it is considered a public API though.
from sparsearrays.jl.
I believe those are documented for the purpose of explanation. Internal representation certainly means "do not count on these".
from sparsearrays.jl.
There are like five issues/PRs discussing changing the sparse array APIs at this point. And the one that Simon opened with the clearest plan has been closed in favor of a PR with an unclear plan and breaking changes that we definitely cannot make. Can we reopen the original plan issue and actually come up with a coherent plan before making any more half-baked PRs changing things?
from sparsearrays.jl.
The one that Simon had was not about API but rationalization of field names, which is something we are clearly not doing. I don't see the point about opening up that discussion again.
from sparsearrays.jl.
What half-baked PRs are you talking about? It can be confusing to follow along since the work is spread out across several PRs, but I don't see how you can label these contributions as half-baked.
from sparsearrays.jl.
There are like five issues/PRs discussing changing the sparse array APIs at this point.
That's why I closed JuliaLang/julia#33050 in favor of JuliaLang/julia#33054 (see JuliaLang/julia#33050 (comment)). I thought to keep opening this issue makes sense as JuliaLang/julia#33054 is about API addition, not deletion.
Simon opened with the clearest plan has been closed in favor of a PR with an unclear plan and breaking changes that we definitely cannot make.
There is nothing breaking in JuliaLang/julia#33054 at all. Or at least that has been my intention. Please comment in JuliaLang/julia#33054 if you find anything breaking.
from sparsearrays.jl.
I have reopened https://github.com/JuliaLang/julia/issues/25118 that @simonbyrne opened about fieldnames for SparseMatrixCSC.
from sparsearrays.jl.
@StefanKarpinski I think I understand your frustration about linear algebra / sparse arrays code base. I imagine many maintainers and contributors share similar feelings. (Off topic, but it would be nice if these stdlibs can go to Pkg-like development mode which may mitigate some of the issues.)
I summarize the recent activities related to SparseMatrixCSC in the issue opened by @simonbyrne https://github.com/JuliaLang/julia/issues/25118#issuecomment-524654446. It would be nice if you can share thoughts about it there.
from sparsearrays.jl.
Related Issues (20)
- strange method definition overwritten WARNING in tests HOT 3
- Solving a system of linear equations `A\b` uses up more memory when `A` is sparse then when `A` is dense HOT 1
- typos HOT 1
- Document what `issparse(A)` guarantees or requires
- Displaying large sparse matrices in REPL takes too long HOT 7
- SparseMatrixCSC format cannot handle efficiently very large matrices HOT 3
- SparseArrays: + has type-instability for `ArbNumerics.jl` type `ArbFloat` HOT 3
- `vcat`-related method ambiguities HOT 4
- SparseArrays.nzrange could benefit from a Base.@propagate_inbounds
- Unable to sum `::SparseVector{Num,Int}`s HOT 1
- Mishandling of lu on view of SparseMatrixCSC HOT 3
- Adding views of sparse matrices generates a dense matrix
- GPU component of CHOLMOD as package extension HOT 3
- JLL-style LibSuiteSparse headers are incompatible with new platforms HOT 3
- Document usage of UMFPACK control vector
- Allow UMFPACK to be run with an alternative BLAS under the hood HOT 12
- SparseMatrixCSC type conversion (sometimes) drops structural nonzeros
- Factorize a sparse symmetric indefinite matrix
- Regression for `mul!` from 1.9 to 1.10 HOT 11
- Using `@view` leads to 100x performance loss HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sparsearrays.jl.