Numeric don't compare arrays correctly

[Alexander Schmolck]

"Mike C. Fletcher" <mcfletch at rogers.com> writes:

> >Well, it is only obvious because you (and I) are already used to a rather
> >hackish notation.
> >
> Ah, but what I'm saying is that, if you see this construct:
>     a < b < c
> 
> then the only non-hackish interpretation is a is less than b which is less
> than c, which is taken directly from mathematics. 
> The hackish (low-level, fiddly) intpretation says "what would the machine
> do" and figures out that it's grouping the statements and basically
> producing random data ;) .

There is of course no straightforward exension of the usual meaning of ``<``
to booleans. However the interpretation that ``<`` is an operator and that
operators straighforwardly translate into functions calls (if you know
precedence, associativity etc.) , such that ``(a # b # c)`` can be thought of
as either ``#(a, #(b, c))`` or ``#(#(a, b), c)`` seems to me certainly much
less hackish and fiddly than assuming that, unlike pretty much everything
else, ``a < b < c`` really is, say, a single function whose arguments are
comparison operator tokens and unevaluated expressions plus an environment.

And if you choose something in between, as python does, where '<' is some sort
of pseudo-infix operator that can return arbitary (not just boolean) results
than you're certainly inviting trouble.


> Certainly bad rich-comparisons are a wart, but in the line of cutting it
> off, I'd rather have an error raised (syntax error) for a < b < c than have
> it work as a built-in random data generator :) . That is, the (current)
> common sense behaviour is by far preferable to the (randomising) behaviour
> of those unnamed languages, but really, who needs either behaviour so much
> that the subtle errors it can introduce are worth the risk? Yes, the symetry
> with x == y == z is nice, but again, dropping that construct entirely would
> be better than switching to (x == y) == z semantics. I mean x == y and y ==
> z isn't *that* much harder to type, and neither is (x == y) & (y==z) if you
> want the element-wise stuff. 

Depends on what you mean by "*that* much harder":

  max([another_func(x) for x in points if a < some_func(x) < b])

becomes

  res = []
  for x in points:
      func_of_x = some_func(x)
      if a < func_of_x and func_of_x < b:
         res.append(another_func(x))
  max(res)
      
> Explicit is better, ...yada, yada... refuse to
> guess :) .

My feeling is that the mistake was not to make rich comparisons explicit (by
either introducing new operators (e.g. ~<) or forcing function notation). They
just aren't simply some generalization of normal comparisons but something
quite different, as their elementwise character doesn't fit in the
(necessarily atomic) boolean context within which normal comparisons are
(almost always) used. The chaining wart is just a symptom -- my guess would be
that almost no code designed for atomic comparisons does something meaningful
when handed arrays or other rich-comparing objects.


'as