Should array A == array B result in an array or a single bool?

[mppf]

Currently, if A and B are arrays, A == B results in an array of bools, and A.equals(B) is available to return a single bool value. We might consider making A == B on arrays return a single bool.

---

See also related issues #7615 and #11487.

Relevant history:

• chapel-developers discussion https://sourceforge.net/p/chapel/mailman/message/30190640/
• chapel-developers discussion https://sourceforge.net/p/chapel/mailman/message/31854070/
• chapel-developers discussion https://sourceforge.net/p/chapel/mailman/message/30194494/
• commit 5540976d7cfec69bdab30c8ee5ac7996e3b10aba

Summarizing the discussion:

In favor of returning an array of bool:

• it's consistent with how other operators (+, -, *, etc.) are applied to arrays

• it provides richer information (a vector of results contains more content than compressing it down to a single bit/bool would)

• 'Array == scalar' arguably makes most sense if it returns an array of results; if 'Array == Array' returned a single bool, it would seem inconsistent with this intuition. (Or maybe put another way, if we switched, 'Array == scalar' should probably also return a bool for consistency, but this seems more surprising).

• getting the non-default behavior is cleaner than it would be in the other approach (i.e., '& reduce (A == B)' or 'all(A == B)' is cleaner than 'forall (a,b) in zip(A,B) do (a == b)' would be if we switched).

• Fortran90 does this

• Python's Numpy does this

• ZPL does this (but also arguably had more important thematic reasons for doing so)

• returning a single boolean would necessitate communication in the event that the argument arrays are distributed (true, but note that, sans additional "coarsening of parallelism" optimizations, the status quo requires communication as well, to farm out the tasks that will perform the comparisons in parallel).

• returning a single boolean would require '==' to choose between 'any' or 'all' semantics (maybe, but personally I think that only 'all' makes sense for a holistic '==', at least to be consistent with how '==' is used elsewhere in Chapel).

In favor of returning bool

• (new since last discussion)< on arrays can reasonably interpreted as lexicographic ordering. In that context, < should return a single bool and so it follows that all the comparison operators should return a single bool. (Note that if we go the direction of discussion in #8545, there will actually only be one comparison operator that the others call, so we'd want to make the same choice for all of them).

  • easier to write generic code that can work with arrays e.g. a set storing arrays

    proc set.contains(x) {
    for a in myElements {
    if a == x then return true;
    }
    return false;
    }

• C++ STL does this for vectors and other collection types

• Python does this (but Numpy, which is arguably more similar to Chapel, does not)

• returning an array of bools can be confusing to a new user

Potential actions

1. Change == on arrays to return a bool.
2. Provide x.equals(y) overloads for non-array types and call these from compiler-generated comparison operators for records (to resolve #7615 and #11487).

[bradcray]

Here are some of my thoughts on this, quickly:

Every time this issue comes up, I worry that we're rehashing this topic for the nth time where each previous time the majority of opinions that we've heard have preferred the status quo. It's honestly surprised me that the vote has come out in favor of the status quo each time, but at some point it starts to feel a bit like doing a recount in hopes that we'll get a different result somehow rather than considering the matter decided and moving on from there.

Personally, I could imagine going either way on the topic, but the fact that Fortran and NumPy both do what we currently do and feel the closest to what we're trying to achieve (I think), combined with the responses we got the last time we asked the question, gives me some confidence that we're doing the right thing. If we supported Set and List/Vector abstractions, I could imagine making the == on them do true equality, similar to the C++ cases (which I think are less like what we're doing).

Since it's new this time around, I'll note that making < on arrays mean lexicographic ordering makes me pretty uncomfortable, particularly once we start talking about multidimensional or sparse or associative arrays.

[mppf]

@bradcray - thanks for your response. To be clear, I didn't create this issue to rehash an old choice (which I too can live with) but rather because the last post to the mailing list indicated it wasn't settled:

https://sourceforge.net/p/chapel/mailman/message/31854070/

I was feeling good about the arguments put forth there for maintaining the status quo until Michael posted his final gotcha ...

Reading the thread up until that gotcha, I think I come to the same conclusion that I did then -- that an array of bools is probably the right thing to do in the language. And then Michael's gotcha leaves me unsatisfied with either approach.

I think we need to either consider the matter settled or decide to re-hash it again.

[bradcray]

Capturing a relevant comment from https://github.com/chapel-lang/chapel/issues/7615#issuecomment-435432053:

As I've been thinking more about equality on arrays this week, I've been wondering whether there are users / use cases who would want == (or equals) to also say things about (a) the arrays' index sets being identical, (b) the arrays' index sets being identical and distributed identically, (c) the arrays' sharing the same domain. This continues to add to my sense that defining a default == on arrays is fraught.