@@ -70,8 +70,7 @@ vectorized functions" strategy common to other languages. What we lack
7070is a "sparse iteration API" that lets you write the main algorithms of
7171sparse linear algebra efficiently in a generic way. Our current model
7272is probably fine for ` SparseLike*Dense ` operations, but gets to be
73- harder to manage if you want to efficiently compute, e.g., `Bidiagonal
74- * SparseMatrixCSC`: the number of possible combinations you have to
73+ harder to manage if you want to efficiently compute, e.g., ` Bidiagonal*SparseMatrixCSC ` : the number of possible combinations you have to
7574support grows rapidly with more sparse types, and thus represents a
7675powerful incentive for developing efficient, generic low-level
7776operations.
@@ -130,8 +129,7 @@ It's also worth pointing out some problems:
130129
131130- Most importantly, it requires that one adopt a slightly different
132131 programming style. Despite being well into another release cycle,
133- this transition is still [ not complete, even in Base]
134- (https://github.com/JuliaLang/julia/pull/15434#issuecomment-194991739 ).
132+ this transition is still [ not complete, even in Base] ( https://github.com/JuliaLang/julia/pull/15434#issuecomment-194991739 ) .
135133
136134- For algorithms that involve two or more arrays, there's a
137135 possibility that their "best" iterators will be of different
0 commit comments