Hi -
I recently wanted to compare two arrays, and I remembered
this discussion but did not remember where we ended up.
So, two questions:
1) Are we pretty sure we want to stick with A == B returning an array of
bools?
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
>>
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
