> 1) Are we pretty sure we want to stick with A == B returning an array of
> bools?
If this hyperlink works as expected, here's a hyperlink to the entire
thread the last time we discussed this topic:
https://sourceforge.net/p/chapel/mailman/message/30190640/
And for those with a shorter attention span, here's my summary of the
opinions received on the thread:
https://sourceforge.net/p/chapel/mailman/message/30194273/
I was feeling good about the arguments put forth there for maintaining the
status quo until Michael posted his final gotcha (which is what he
responded to below I'm now noticing, and is how we left the conversation):
https://sourceforge.net/p/chapel/mailman/message/30194494/
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.
So today what I'm wondering is whether Python/NumPy deals with the generic
programming issue, if the same argument is applicable there. Does anybody
know the answer there? (I don't think it particularly is in Fortran?)
To Michael's second question:
> 2) Can we add a method, like A.equals(B) or something, that returns a single
> bool?
If we keep the status quo for ==, I wouldn't have any objections to this
and it should be fairly easy to implement I think. In which case, we may
want to implement it completely generically so that it works on all types
and solves Michael's original problem/query?
But let's chew a little more on the "How does Python/NumPy deal with the
generic issue" before going down that path if possible...
-Brad
On Thu, 2 Jan 2014, Michael Ferguson wrote:
> Hi -
>
> I recently wanted to compare two arrays, and I remembered
> this discussion but did not remember where we ended up.
>
> So, two questions:
> 2) Can we add a method, like A.equals(B) or something, that returns a single
> bool?
>
> -michael
>
> On 12/06/2012 02:57 PM, Brad Chamberlain wrote:
>>
>> FWIW, this is more or less exactly how the topic came
>> up yesterday. We were looking into what it would take
>> to have an associative domain with array indices/keys,
>> and since our associative domains are hash tables and
>> hash tables need to see whether two things are the
>> same, things were blowing up.
>>
>> In the specific case of associative domains, since those
>> are more or less built into the language, we can work around
>> this issue whatever's decided with some effort -- but that's
>> what got the question started. Michael's question points out
>> that associative domains won't be the only generic
>> data type to run into this question...
>>
>> -Brad
>>
>>
>> On Thu, 6 Dec 2012, Michael P Ferguson wrote:
>>
>>> Hi -
>>>
>>> I think I just have one thing to add that I don't think
>>> has been brought up yet. First, I'll say I lean towards
>>> doing something more Fortran-y in this case.
>>>
>>> But, I worry that when doing generic programming, generic
>>> routines will all-the-time need special cases code for
>>> arrays.... For example, what if I want to create a generic
>>> set data structure? The most basic set structure
>>> would need a 'contains' method that tells us whether
>>> or not a given element is in the set. Imagine our
>>> very slow initial implementation looked like this:
>>>
>>> proc set.contains(x) {
>>> for a in myElements {
>>> if a == x then return true;
>>> }
>>> return false;
>>> }
>>>
>>> Now, what if I want to store arrays in my set?
>>> I don't want generic-library-writers to have to
>>> consider separately every kind of thing that might
>>> go into their data structure... and naturally,
>>> a more efficient set data structure would use
>>> some kind of comparison operator (ie < not just ==).
>>> Of course, the generic library author could just
>>> insist on a 'setcmp' function being available for
>>> the stored type - but I think that's not a great
>>> idea for other reasons.
>>>
>>> So - to conclude - I'd like somebody
>>> to think about how you'd write a reasonable generic
>>> set (or other data structure)... and propose
>>> some way of writing it (and possible language
>>> additions) that makes sense.
>>>
>>> -michael
>>>
>>> ----- Original Message -----
>>> From: "Brad Chamberlain" <[email protected]>
>>> To: "Chapel Users Mailing List" <[email protected]>
>>> Sent: Thursday, December 6, 2012 1:51:41 PM
>>> Subject: Re: meaning of == and != on arrays
>>>
>>>
>>> Thanks everyone for the detailed and heartfelt responses to this
>>> question. As expected, there were opinions on both sides of the fence
>>> on this topic; I was a little surprised at the number of responses in
>>> favor of preserving the status quo -- there were more than I was
>>> anticipating.
>>>
>>> None of the following should be interpreted as a final decision, just
>>> my thoughts on the topic as a result of the discussion. The
>>> organization of the following is:
>>>
>>> * my executive summary (for what it's worth)
>>>
>>> * a summary of the arguments received (so far) for both sides
>>>
>>> * a few responses to specific questions asked
>>>
>>>
>>> Summary of my thoughts
>>> ======================
>>>
>>> The responses received suggest to me that the conservative thing to do
>>> would be to take the third/compromise approach proposed in the
>>> original mail: Preserve the status quo (== and != on arrays generate
>>> arrays of bools), but for convenience provide versions of == and != on
>>> arrays that return a single bool in a standard helper module that a
>>> user can choose to include.
>>>
>>> Playing devil's advocate, I think the main thing that worries me about
>>> this approach is that it's become somewhat of a FAQ for new Chapel
>>> programmers to write something like:
>>>
>>> if (A == B) then ...
>>>
>>> and then be confused about why it doesn't work "as expected." While
>>> the explanation usually ends up making sense once it's been explained,
>>> if the main goal was to avoid tripping up the new/naive user, that
>>> might suggest adopting the 'return a bool' approach, since power users
>>> who might be more likely to want an array of bools will presumably
>>> know enough to realize they can use zippered iteration to obtain the
>>> current behavior:
>>>
>>> forall (a,b) in zip(A,B) do (a == b)
>>>
>>> A counterargument to that made off-list is that the syntactic overhead
>>> for overriding the default using zippered iteration is much more
>>> heavyweight than using an and/or (or any/all) reduction/function in
>>> the status quo. So we'd be penalizing the power user in favor of the
>>> naive one.
>>>
>>>
>>> Summary of opinions heard
>>> =========================
>>>
>>> Note that some of these were received off-list.
>>>
>>>
>>> In favor of status quo:
>>> -----------------------
>>> * 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 a single boolean:
>>> ---------------------------------------
>>> * 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
>>>
>>>
>>> Other notes:
>>> ------------
>>>
>>> * any/all reductions are useful (I believe these are equivalent to
>>> Chapel's logical boolean | and & reductions, though I could imagine
>>> supporting any/all as a more readable alternative -- either as a new
>>> reduction operator or as a utility function; main downside is
>>> pollution of the namespace and/or the potential confusion of having
>>> multiple ways to say the same thing, so perhaps these should be part
>>> of an optional standard module if supplied at all).
>>>
>>> * the ability to compare identity ('are these the same array?') might
>>> also be useful. (My opinion: I agree that this is valuable, but
>>> don't think it would be consistent for Chapel to use '==' for this
>>> purpose, so it should be done via some other operator or function.
>>> So I consider this to be an orthogonal topic/feature).
>>>
>>> * the ability to be able to cast an array of bools to a boolean might
>>> be nice. (My opinion: Maybe, though it leaves it ambiguous whether
>>> you want an any or all interpretation; I also don't find it all that
>>> intuitive. My preference here would be to add the ability for users
>>> to define casts to the language and then a specific user group can
>>> introduce this type of shortcut into their programs if it's what
>>> they want).
>>>
>>> * there was some confusion about what any()/all() did, but I think
>>> that was already clarified on-list.
>>>
>>>
>>> Answers to questions asked
>>> ==========================
>>>
>>> Q: Can I define my own == for my data types?
>>>
>>> A: Yes, you can.
>>>
>>>
>>> Q: Can I compare an array to a scalar value?
>>>
>>> A: Yes, and currently the result is also a vector of boolean results.
>>>
>>>
>>> ------------
>>>
>>>
>>> On Wed, 5 Dec 2012, Brad Chamberlain wrote:
>>>
>>>>
>>>> Hi Chapel Users --
>>>>
>>>> We were having a discussion about the meaning of == and != on arrays at
>>>> Cray
>>>> today and wanted to solicit the broader community's opinions on the
>>>> topic.
>>>>
>>>>
>>>> Historically in Chapel, == and != have not been defined explicitly for
>>>> arrays. This means that by default, applying them to two arrays will
>>>> promote
>>>> the scalar comparisons across all elements, resulting in a logical array
>>>> of
>>>> booleans as the result. A user could then choose to apply a reduction
>>>> operator in order to determine whether or not the arrays are equal
>>>> overall.
>>>>
>>>> Arguably, a more intuitive definition might be to define == and != on
>>>> arrays
>>>> to return a single bool indicating whether or not all of the
>>>> corresponding
>>>> pairs of elements are == (essentially, roll the reduction into the
>>>> operator).
>>>>
>>>> I feel as though in the early days of Chapel, we had reasons for
>>>> believing
>>>> that the current approach was the correct one, but today I'm doubting
>>>> that
>>>> and not remembering the rationale (if we had one). To that end, we're
>>>> curious what you, the user community thinks.
>>>>
>>>>
>>>> Here are the arguments we've been wrestling with today:
>>>>
>>>>
>>>> Tradeoffs related to defining == and != on arrays to return a single bool
>>>> =========================================================================
>>>>
>>>> + arguably makes arrays more consistent with other Chapel types
>>>>
>>>> + arguably supports a common case intuitively and conveniently
>>>>
>>>> - for users who might want the "array of bools" result, requires them
>>>> to do a bit more work to get it (explicitly zipper iterate over the
>>>> two arrays)
>>>>
>>>> - it's not entirely clear what adopting this suggests for '<', '>', '<=',
>>>> and '>=' on arrays (today they would also return an array of bools).
>>>> Some options would be...
>>>>
>>>> * leave as-is? (feels potentially confusing w.r.t. == and !=)
>>>>
>>>> * define like strcmp in C (feels a little arbitrary/confusing for
>>>> arrays)
>>>>
>>>> * other?
>>>>
>>>>
>>>>
>>>> Keep the status quo
>>>> ===================
>>>>
>>>> + more easily permits different users/modules to overload == and != on
>>>> arrays as they wish
>>>>
>>>> + already implemented! :)
>>>>
>>>> * otherwise, generally the opposite of the tradeoffs in the above section
>>>>
>>>>
>>>>
>>>> A third option (really a variant on the status quo) would be to supply
>>>> these
>>>> operators in an optional standard module so that users who wanted the
>>>> capability could get it via a 'use' statement.
>>>>
>>>>
>>>> Opinions?
>>>>
>>>> Thanks,
>>>> -Brad
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>> Remotely access PCs and mobile devices and provide instant support
>>> Improve your efficiency, and focus on delivering more value-add services
>>> Discover what IT Professionals Know. Rescue delivers
>>> http://p.sf.net/sfu/logmein_12329d2d
>>> _______________________________________________
>>> Chapel-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/chapel-users
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>> Remotely access PCs and mobile devices and provide instant support
>>> Improve your efficiency, and focus on delivering more value-add services
>>> Discover what IT Professionals Know. Rescue delivers
>>> http://p.sf.net/sfu/logmein_12329d2d
>>> _______________________________________________
>>> Chapel-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/chapel-users
>>>
>>
>
>
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
