Make COO canonical in the constructor.

[hameerabbasi]

Based on recommendations in scipy/scipy#8162 (comment) I believe that we should make COO always be canonical.

This has several advantages:

• Nobody really wants the non-canonical version.
• We don't have to keep track of when or if it's ever canonical.
• The x.sum_duplicates() calls just disappear.
• The string representation becomes simpler. The sorted=?, duplicates=? was just confusing to someone who didn't know how COO really worked.
• The object is now truly immutable.

[codecov-io]

Codecov Report

Merging #141 into master will decrease coverage by 0.09%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master     #141     +/-   ##
=========================================
- Coverage   95.91%   95.81%   -0.1%     
=========================================
  Files          10       10             
  Lines        1223     1195     -28     
=========================================
- Hits         1173     1145     -28     
  Misses         50       50

Impacted Files	Coverage Δ
sparse/dok.py	93.57% <ø> (ø)	⬆️
sparse/coo/indexing.py	100% <ø> (ø)	⬆️
sparse/coo/umath.py	96.66% <100%> (-0.05%)	⬇️
sparse/coo/common.py	96.11% <100%> (-0.11%)	⬇️
sparse/utils.py	97.14% <100%> (-0.06%)	⬇️
sparse/coo/core.py	93.67% <100%> (-0.31%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b2913d7...8fc71e7. Read the comment docs.

[hameerabbasi]

@nils-werner This should address your concerns in #58. You're welcome to review as well.

[mrocklin]

I don't have enough experience with performance applications to know if this is a good or a bad idea performance-wise in the common case. I recommend that we ping the original author of the comment, @perimosocordiae , for his thoughts. It might also be good to ask for more information and possibly for a wider viewpoint from some of the author maintainers of the library. Perhaps this is a good use of the scipy-dev mailing list? cc @stefanv

[hameerabbasi]

This isn't meant to improve performance (since we already skip these steps when already done for an object). I believe @perimosocordiae was arguing maintenance wise. We don't have all the extra fluff in the object, and don't have to think "is it canonical now?" because it always will be.

[mrocklin]

I still recommend asking more broadly within the scipy community. They may have reasons for the sum_duplicates behavior. Do we know why this is? Are there cases where this is important? I don't personally have enough hands-on experience with the uses of COO to make this kind of decision.

…

On Mon, Apr 23, 2018 at 11:20 AM, Hameer Abbasi ***@***.***> wrote: This isn't meant to improve performance (since we already skip these steps when already done for an object). I believe @perimosocordiae <https://github.com/perimosocordiae> was arguing maintenance wise. We don't have all the extra fluff in the object, and don't have to think "is it canonical now?" because it always will be. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASszOlydjt59cIDxrchxma3lY2yp6ugks5trfFYgaJpZM4TfJQX> .

[perimosocordiae]

I think this is a good idea. At least with scipy's sparse matrices, so many operations require canonical (or at least duplicate-summed) matrices that the odds of constructing a COO matrix with dups and never indirectly calling sum_duplicates are very low. This approach front-loads that work, which makes performance a lot simpler to reason about. It also makes maintenance easier, like @hameerabbasi commented.

The downside is that you're explicitly disallowing some uses of the object, like representing a multi-graph. I'd argue that those users are better served by an object designed for that purpose, though, and since this package is very new you're unlikely to break anyone's existing code.

Pinging the scipy-dev list for objections is a good idea.

[hameerabbasi]

I posted it to the Scipy-Dev mailing list. Link to thread.

[hameerabbasi]

Allowing another day for comments and then merging, in the absence of objections.

[mrocklin]

Sounds good. Thanks for doing this @hameerabbasi !

…

On Wed, Apr 25, 2018 at 4:09 AM, Hameer Abbasi ***@***.***> wrote: Allowing another day for comments and then merging, in the absence of objections. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASszDwOhEbnsVaEcft8KtjcdksHZDyKks5tsC9EgaJpZM4TfJQX> .

[shoyer]

Just to be clear, this "canonicalizes" COO arrays, right? So you an still provide non-canonical inputs to the COO constructor, and this will convert them into canonical form?

If so, this makes complete sense to me.

[hameerabbasi]

Yes, that's what it does. In addition, you can pass two flags (as before), sorted and has_duplicates which signify that canonicalization should be skipped. Technically, you could pass invalid values to keep things in non-canonical form, but it might break things (as it already did before).