Steven D'Aprano wrote:
> It's only incoherent if you need equality to be an equivalence relation.
> If you don't, it is perfectly reasonable to declare that i"abc" equals
> "abc".
Right! And if you didn't want an equivalence relation, then `==' will
suit you fine. The problem is that some ap
On Wed, 07 Jan 2009 01:23:19 +, Mark Wooding wrote:
> A case-sensitive string is /not the same/ as a case-insensitive string.
> One's a duck, the other's a goose. I'd claim here that i"abc" =~ "ABC"
> must be False, because i"abc" =~ "abc" must be false also! To define it
> otherwise leads t
Steven D'Aprano wrote:
> To prove my claim, all you need is two domains with a mutually
> incompatible definition of equality. That's not so difficult, surely? How
> about equality of integers, versus equality of integers modulo some N?
No, that's not an example. The integers modulo N form a
On Tue, 06 Jan 2009 12:42:13 +, Mark Wooding wrote:
> Steven D'Aprano wrote:
>
>> Such assumptions only hold under particular domains though. You can't
>> assume equality is an equivalence relation once you start thinking
>> about arbitrary domains.
>
> From a formal mathematical point of v
Steven D'Aprano wrote:
> Such assumptions only hold under particular domains though. You can't
> assume equality is an equivalence relation once you start thinking
> about arbitrary domains.
>From a formal mathematical point of view, equality /is/ an equivalence
relation. If you have a relation
On Tue, 06 Jan 2009 01:24:58 +, Mark Wooding wrote:
> Steven D'Aprano wrote:
>
>> I've already mentioned NaNs. Sentinel values also sometimes need to
>> compare not equal with themselves. Forcing them to compare equal will
>> cause breakage.
>
> There's a conflict between such domain-specif
Steven D'Aprano wrote:
> I've already mentioned NaNs. Sentinel values also sometimes need to
> compare not equal with themselves. Forcing them to compare equal will
> cause breakage.
There's a conflict between such domain-specific considerations (NaNs,
strange sentinels, SAGE's equations), and r
Steven D'Aprano wrote:
> There is nothing to blame them for. This is the correct behaviour. NaNs
> should *not* compare equal to themselves, that's mathematically
> incoherent.
Indeed. The problem is a paucity of equality predicates. This is
hardly surprising: Common Lisp has four general-pu
On 2008-12-10 23:21, Luis Zarrabeitia wrote:
> On Wednesday 10 December 2008 02:44:45 pm you wrote:
>>> Even in statically typed languages, when you override the equality
>>> operator/function you can choose not to return a valid answer (raise an
>>> exception). And it would break all the cases men
On Wed, 10 Dec 2008 17:58:49 -0500, Luis Zarrabeitia wrote:
> On Sunday 07 December 2008 09:21:18 pm Robert Kern wrote:
>> The deficiency is in the feature of rich comparisons, not numpy's
>> implementation of it. __eq__() is allowed to return non-booleans;
>> however, there are some parts of Pyth
On Wed, 10 Dec 2008 17:21:51 -0500, Luis Zarrabeitia wrote:
> I do numeric work... I'm finishing my MSc in applied math and I'm
> programing mostly with python. And I'd rather have a.compare_with(b), or
> a.elementwise_compare(b), or whatever name, rather than (a==b).all().
Unluckily for you, th
On Sunday 07 December 2008 09:21:18 pm Robert Kern wrote:
> The deficiency is in the feature of rich comparisons, not numpy's
> implementation of it. __eq__() is allowed to return non-booleans; however,
> there are some parts of Python's implementation like list.__contains__()
> that still expect t
On Wednesday 10 December 2008 02:44:45 pm you wrote:
> > Even in statically typed languages, when you override the equality
> > operator/function you can choose not to return a valid answer (raise an
> > exception). And it would break all the cases mentioned above (element in
> > list, etc). But th
On 2008-12-10 20:01, Luis Zarrabeitia wrote:
> On Wednesday 10 December 2008 10:50:57 am M.-A. Lemburg wrote:
>> On 2008-12-10 16:40, Luis Zarrabeitia wrote:
>>> Quoting Rasmus Fogh <[EMAIL PROTECTED]>:
Rhamphoryncus wrote:
>> Rich comparisons were added to Python at the request of the
>> Nume
On Wednesday 10 December 2008 10:50:57 am M.-A. Lemburg wrote:
> On 2008-12-10 16:40, Luis Zarrabeitia wrote:
> > Quoting Rasmus Fogh <[EMAIL PROTECTED]>:
> >> Rhamphoryncus wrote:
>
> Rich comparisons were added to Python at the request of the
> Numeric (now numpy) developers and they have been pa
Rasmus Fogh wrote:
Rhamphoryncus wrote:
You grossly overvalue using the "in" operator on lists.
Maybe. But there is more to it than just 'in'. If you do:
c = numpy.zeros((2,))
ll = [1, c, 3.]
then the following all throw errors:
3 in ll, 3 not in ll, ll.index(3), ll.count(3), ll.remove(3)
c
On Dec 10, 7:49 am, Rasmus Fogh <[EMAIL PROTECTED]> wrote:
> Rhamphoryncus wrote:
> > You grossly overvalue using the "in" operator on lists.
>
> Maybe. But there is more to it than just 'in'. If you do:>>> c =
> numpy.zeros((2,))
> >>> ll = [1, c, 3.]
>
> then the following all throw errors:
> 3
On 2008-12-10 16:40, Luis Zarrabeitia wrote:
> Quoting Rasmus Fogh <[EMAIL PROTECTED]>:
>> Rhamphoryncus wrote:
>>> You grossly overvalue using the "in" operator on lists.
>> Maybe. But there is more to it than just 'in'. If you do:
> c = numpy.zeros((2,))
> ll = [1, c, 3.]
>> then the foll
Quoting Rasmus Fogh <[EMAIL PROTECTED]>:
> Rhamphoryncus wrote:
> > You grossly overvalue using the "in" operator on lists.
>
> Maybe. But there is more to it than just 'in'. If you do:
> >>> c = numpy.zeros((2,))
> >>> ll = [1, c, 3.]
> then the following all throw errors:
> 3 in ll, 3 not in ll
Rhodri James wrote:
> On Mon, 08 Dec 2008 14:24:59 -, Rasmus Fogh wrote:
>> On the minus side there would be the difference between
>> '__equal__' and '__eq__' to confuse people.
> This is a very big minus. It would be far better to spell __equal__ in
> such a way as to make it clear why i
Rhamphoryncus wrote:
> You grossly overvalue using the "in" operator on lists.
Maybe. But there is more to it than just 'in'. If you do:
>>> c = numpy.zeros((2,))
>>> ll = [1, c, 3.]
then the following all throw errors:
3 in ll, 3 not in ll, ll.index(3), ll.count(3), ll.remove(3)
c in ll, c not i
On Mon, 08 Dec 2008 14:24:59 -, Rasmus Fogh <[EMAIL PROTECTED]>
wrote:
On the minus side there would be the difference between
'__equal__' and '__eq__' to confuse people.
This is a very big minus. It would be far better to spell __equal__ in
such a way as to make it clear why it wasn'
You grossly overvalue using the "in" operator on lists. It's far more
common to use a dict or set for containment tests, due to O(1)
performance rather than O(n). I doubt the numpy array supports
hashing, so an error for misuse is all you should expect.
In the rare case that you want to test for
Mark Dickinson wrote:
> On Dec 8, 2:24 pm, Rasmus Fogh <[EMAIL PROTECTED]> wrote:
>> So, I would much prefer a language change. I am not competent to even
>> propose one properly, but I'll try.
> I don't see any technical problems in what you propose: as
> far as I can see it's entirely feasibl
Steven DAprano wrote:
> On Mon, 08 Dec 2008 14:24:59 +, Rasmus Fogh wrote:
snip
>> What might be a sensible behaviour (unlike your proposed wrapper)
Sorry
1) I was rude,
2) I thanked TJR for your wrapper class proposal in a later mail. It is
yours.
> What do you dislike about my wrapper cla
On Dec 8, 2:24 pm, Rasmus Fogh <[EMAIL PROTECTED]> wrote:
> So, I would much prefer a language change. I am not competent to even
> propose one properly, but I'll try.
I don't see any technical problems in what you propose: as
far as I can see it's entirely feasible. However:
> should. On the
Steven DAprano wrote:
> On Mon, 08 Dec 2008 14:24:59 +, Rasmus Fogh wrote:
>> For my personal problem I could indeed wrap all objects in a wrapper
>> with whatever 'correct' behaviour I want (thanks, TJR). It does seem a
>> bit much, though, just to get code like this to work as intended:
>>
On Dec 8, 7:44 pm, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> On Mon, 08 Dec 2008 10:20:56 -0800, Rhamphoryncus wrote:
> > On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED]
> > cybersource.com.au> wrote:
> >> On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
> >> > Rasmus Fogh wrote:
>
>
On Sun, 07 Dec 2008 16:24:58 -0800, George Sakkis wrote:
> On Dec 7, 6:37 pm, Steven D'Aprano <[EMAIL PROTECTED]
> cybersource.com.au> wrote:
...
>> Given:
>>
>> x = log(-5) # a NaN
>> y = log(-2) # the same NaN
>> x == y # Some people want this to be true for NaNs.
>>
>> Then:
>>
>> # Compare
On Mon, 08 Dec 2008 10:20:56 -0800, Rhamphoryncus wrote:
> On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED]
> cybersource.com.au> wrote:
>> On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
>> > Rasmus Fogh wrote:
>>
>> >> Current behaviour is both inconsistent and counterintuitive, as
>
On Mon, 08 Dec 2008 14:24:59 +, Rasmus Fogh wrote:
> For my personal problem I could indeed wrap all objects in a wrapper
> with whatever 'correct' behaviour I want (thanks, TJR). It does seem a
> bit much, though, just to get code like this to work as intended:
> alist.append(x)
> print (
Robert Kern wrote:
Terry Reedy wrote:
Rasmus Fogh wrote:
much, though, just to get code like this to work as intended:
alist.append(x)
print ('x is present: ', x in alist)
Even if rich comparisons as you propose, the above would *still* not
necessarily work. Collection classes can def
On Dec 8, 2:51 pm, Robert Kern <[EMAIL PROTECTED]> wrote:
> Rhamphoryncus wrote:
> > "We've always done it that way" is NOT a use case! Certainly, it's a
> > factor, but it seems quite weak compared to the sort use case.
>
> I didn't say it was. I was explaining that sorting was probably *not* a u
MRAB wrote:
Terry Reedy wrote:
Rasmus Fogh wrote:
For my personal problem I could indeed wrap all objects in a wrapper
with
whatever 'correct' behaviour I want (thanks, TJR). It does seem a bit
I was not suggesting that you wrap *everything*, merely an adaptor for
numpy arrays in whatever
Terry Reedy wrote:
Rasmus Fogh wrote:
For my personal problem I could indeed wrap all objects in a wrapper with
whatever 'correct' behaviour I want (thanks, TJR). It does seem a bit
I was not suggesting that you wrap *everything*, merely an adaptor for
numpy arrays in whatever subclass and s
Terry Reedy wrote:
Rasmus Fogh wrote:
much, though, just to get code like this to work as intended:
alist.append(x)
print ('x is present: ', x in alist)
Even if rich comparisons as you propose, the above would *still* not
necessarily work. Collection classes can define a __contains__ t
Rasmus Fogh wrote:
For my personal problem I could indeed wrap all objects in a wrapper with
whatever 'correct' behaviour I want (thanks, TJR). It does seem a bit
I was not suggesting that you wrap *everything*, merely an adaptor for
numpy arrays in whatever subclass and source it is that fee
Rhamphoryncus wrote:
On Dec 8, 1:04 pm, Robert Kern <[EMAIL PROTECTED]> wrote:
Rhamphoryncus wrote:
On Dec 8, 11:54 am, Robert Kern <[EMAIL PROTECTED]> wrote:
Rhamphoryncus wrote:
On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
On Sun, 07 Dec 2008 15:32:53 -0
On Dec 8, 1:04 pm, Robert Kern <[EMAIL PROTECTED]> wrote:
> Rhamphoryncus wrote:
> > On Dec 8, 11:54 am, Robert Kern <[EMAIL PROTECTED]> wrote:
> >> Rhamphoryncus wrote:
> >>> On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED]
> >>> cybersource.com.au> wrote:
> On Sun, 07 Dec 2008 15:32:53
Rhamphoryncus wrote:
On Dec 8, 11:54 am, Robert Kern <[EMAIL PROTECTED]> wrote:
Rhamphoryncus wrote:
On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
Rasmus Fogh wrote:
Current behaviour is both inconsiste
On Dec 8, 11:54 am, Robert Kern <[EMAIL PROTECTED]> wrote:
> Rhamphoryncus wrote:
> > On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED]
> > cybersource.com.au> wrote:
> >> On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
> >>> Rasmus Fogh wrote:
> Current behaviour is both inconsiste
Rhamphoryncus wrote:
On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
Rasmus Fogh wrote:
Current behaviour is both inconsistent and counterintuitive, as these
examples show.
x = float('NaN')
x == x
False
Robert Kern wrote:
There is an explicit policy that __eq__() methods can return non-bools
for various purposes. I consider that policy to a "presence that can be
removed". There is no check because that policy exists, not the other
way around.
OK, presence in manual versus presence in code.
On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
> > Rasmus Fogh wrote:
>
> >> Current behaviour is both inconsistent and counterintuitive, as these
> >> examples show.
>
> > x = float('NaN')
> > x == x
Rober Kern wrote:
>James Stroud wrote:
>> Steven D'Aprano wrote:
>>> On Sun, 07 Dec 2008 13:57:54 -0800, James Stroud wrote:
Rasmus Fogh wrote:
ll1 = [y,1]
y in ll1
> True
ll2 = [1,y]
y in ll2
> Traceback (most recent call last):
> File "", l
Robert Kern wrote:
James Stroud wrote:
I think it skips straight to __eq__ if the element is not the first in
the list.
No, it doesn't skip straight to __eq__(). "y is 1" returns False, so
(y==1) is checked. When y is a numpy array, this returns an array of
bools. list.__contains__() tries t
James Stroud wrote:
Robert Kern wrote:
James Stroud wrote:
py> 112 = [1, y]
py> y in 112
Traceback (most recent call last):
File "", line 1, in
ValueError: The truth value of an array with more than one element is...
but not
py> ll1 = [y,1]
py> y in ll1
True
It's this discrepancy that see
Robert Kern wrote:
James Stroud wrote:
py> 112 = [1, y]
py> y in 112
Traceback (most recent call last):
File "", line 1, in
ValueError: The truth value of an array with more than one element is...
but not
py> ll1 = [y,1]
py> y in ll1
True
It's this discrepancy that seems like a bug, not th
James Stroud wrote:
Robert Kern wrote:
James Stroud wrote:
I'm missing how a.all() solves the problem Rasmus describes, namely
that the order of a python *list* affects the results of containment
tests by numpy.array. E.g. "y in ll1" and "y in ll2" evaluate to
different results in his example
On Sun, 07 Dec 2008 16:23:59 +, Rasmus Fogh wrote:
> Just to keep you from shooting at straw men:
>
> I would have liked it to be part of the design contract (a convention,
> if you like) that
> 1) bool(x == y) should return a boolean and never throw an error
Can't be done without making b
Robert Kern wrote:
James Stroud wrote:
I'm missing how a.all() solves the problem Rasmus describes, namely
that the order of a python *list* affects the results of containment
tests by numpy.array. E.g. "y in ll1" and "y in ll2" evaluate to
different results in his example. It still seems like
James Stroud wrote:
Steven D'Aprano wrote:
On Sun, 07 Dec 2008 13:57:54 -0800, James Stroud wrote:
Rasmus Fogh wrote:
ll1 = [y,1]
y in ll1
True
ll2 = [1,y]
y in ll2
Traceback (most recent call last):
File "", line 1, in
ValueError: The truth value of an array with more than one elemen
Steven D'Aprano wrote:
On Sun, 07 Dec 2008 13:57:54 -0800, James Stroud wrote:
Rasmus Fogh wrote:
ll1 = [y,1]
y in ll1
True
ll2 = [1,y]
y in ll2
Traceback (most recent call last):
File "", line 1, in
ValueError: The truth value of an array with more than one element is
ambiguous. Use a
Terry Reedy wrote:
Robert Kern wrote:
Terry Reedy wrote:
Rasmus Fogh wrote:
Personally I would like to get these [EMAIL PROTECTED]&* misfeatures removed,
What you are calling a misfeature is an absence, not a presence that
can be removed.
That's not quite true.
In what way, pray tell.
On Dec 7, 6:37 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sun, 07 Dec 2008 23:20:12 +, Steven D'Aprano wrote:
> > On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
>
> >> Rasmus Fogh wrote:
>
> >>> Current behaviour is both inconsistent and counterintuitive, as
Steven D'Aprano wrote:
On Sun, 07 Dec 2008 23:20:12 +, Steven D'Aprano wrote:
On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
Rasmus Fogh wrote:
Current behaviour is both inconsistent and counterintuitive, as these
examples show.
x = float('NaN')
x == x
False
Blame IEEE for t
On Sun, 07 Dec 2008 13:57:54 -0800, James Stroud wrote:
> Rasmus Fogh wrote:
>> Current behaviour is both inconsistent and counterintuitive, as these
>> examples show.
>>
> x = float('NaN')
> x == x
>> False
>
> Perhaps this should raise an exception?
Why on earth would you want checkin
On Sun, 07 Dec 2008 23:20:12 +, Steven D'Aprano wrote:
> On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
>
>> Rasmus Fogh wrote:
>>
>>> Current behaviour is both inconsistent and counterintuitive, as these
>>> examples show.
>>>
>> x = float('NaN')
>> x == x
>>> False
>>
>>
James Stroud wrote:
Rasmus
Fogh wrote:
Current behaviour is both inconsistent and counterintuitive, as these
examples show.
x = float('NaN')
x == x
False
Perhaps this should raise an exception? I think the problem is not
with comparisons in general but with the fact that nan is type float:
On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
> Rasmus Fogh wrote:
>
>> Current behaviour is both inconsistent and counterintuitive, as these
>> examples show.
>>
> x = float('NaN')
> x == x
>> False
>
> Blame IEEE for that one. Rich comparisons have nothing to do with that
> o
Rasmus Fogh wrote:
Can anybody see a way this could be fixed (please)? I may well have to
live with it, but I would really prefer not to.
I made a suggestion in my first response, which perhaps you missed.
tjr
--
http://mail.python.org/mailman/listinfo/python-list
James Stroud wrote:
[cast to bool] for numpy works like a unary ufunc.
Scratch that. Not thinking and typing at same time.
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
http://www.jamesstroud.com
--
http://mail.python.org/mailman/listinfo/pyt
Robert Kern wrote:
Terry Reedy wrote:
Rasmus Fogh wrote:
Personally I would like to get these [EMAIL PROTECTED]&* misfeatures removed,
What you are calling a misfeature is an absence, not a presence that
can be removed.
That's not quite true.
In what way, pray tell. My statement still
Rasmus Fogh wrote:
Current behaviour is both inconsistent and counterintuitive, as these
examples show.
x = float('NaN')
x == x
False
Perhaps this should raise an exception? I think the problem is not with
comparisons in general but with the fact that nan is type float:
py> type(float('Na
Luis Zarrabeitia wrote:
Quoting James Stroud <[EMAIL PROTECTED]>:
First, here is why the ability to throw an error is a feature:
class Apple(object):
def __init__(self, appleness):
self.appleness = appleness
def __cmp__(self, other):
assert isinstance(other, Apple), 'must comp
Rasmus Fogh wrote:
Current behaviour is both inconsistent and counterintuitive, as these
examples show.
x = float('NaN')
x == x
False
Blame IEEE for that one. Rich comparisons have nothing to do with that one.
ll = [x]
x in ll
True
x == ll[0]
False
import numpy
y = numpy.zeros((3,))
On Dec 7, 4:23 pm, Rasmus Fogh <[EMAIL PROTECTED]> wrote:
> If is is possible to change the language, how about having two
> diferent functions, one for overloading the '==' operator, and another
> for testing list and set membership, dictionary key identity, etc.?
I've often thought that this wo
> On Sun, 07 Dec 2008 13:03:43 +, Rasmus Fogh wrote:
>> Jamed Stroud Wrote:
> ...
>>> Second, consider that any value in python also evaluates to a truth
>>> value in boolean context.
> But bool(x) can fail too. So not every object in Python can be
> interpreted as a truth value.
>>> Third, e
On Sun, 07 Dec 2008 13:03:43 +, Rasmus Fogh wrote:
> Jamed Stroud Wrote:
...
>> Second, consider that any value in python also evaluates to a truth
>> value in boolean context.
But bool(x) can fail too. So not every object in Python can be
interpreted as a truth value.
>> Third, every func
Quoting James Stroud <[EMAIL PROTECTED]>:
> First, here is why the ability to throw an error is a feature:
>
> class Apple(object):
>def __init__(self, appleness):
> self.appleness = appleness
>def __cmp__(self, other):
> assert isinstance(other, Apple), 'must compare apples t
Jamed Stroud Wrote:
> Rasmus Fogh wrote:
>> Dear All,
>> For the first time I have come across a Python feature that seems
>> completely wrong. After the introduction of rich comparisons, equality
>> comparison does not have to return a truth value, and may indeed return
>> nothing at all and thro
Robert Kern Wrote:
>Terry Reedy wrote:
>> Rasmus Fogh wrote:
>>> Personally I would like to get these [EMAIL PROTECTED]&* misfeatures
>>> removed,
>>
>> What you are calling a misfeature is an absence, not a presence that
>> can be removed.
>
> That's not quite true. Rich comparisons explicitly al
Rasmus Fogh wrote:
Dear All,
For the first time I have come across a Python feature that seems
completely wrong. After the introduction of rich comparisons, equality
comparison does not have to return a truth value, and may indeed return
nothing at all and throw an error instead. As a result, co
Terry Reedy wrote:
Rasmus Fogh wrote:
Dear All,
For the first time I have come across a Python feature that seems
completely wrong. After the introduction of rich comparisons, equality
comparison does not have to return a truth value, and may indeed return
nothing at all and throw an error inst
Rasmus Fogh wrote:
Dear All,
For the first time I have come across a Python feature that seems
completely wrong. After the introduction of rich comparisons, equality
comparison does not have to return a truth value, and may indeed return
nothing at all and throw an error instead. As a result, co
Dear All,
For the first time I have come across a Python feature that seems
completely wrong. After the introduction of rich comparisons, equality
comparison does not have to return a truth value, and may indeed return
nothing at all and throw an error instead. As a result, code like
if foo == b
76 matches
Mail list logo
