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 iabc =~ ABC
must be False, because iabc =~ abc must be false also! To define it
otherwise leads to the
Steven D'Aprano ste...@remove.this.cybersource.com.au 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 iabc equals
abc.
Right! And if you didn't want an equivalence relation, then `==' will
suit you
Steven D'Aprano ste...@remove.this.cybersource.com.au 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
On Tue, 06 Jan 2009 12:42:13 +, Mark Wooding wrote:
Steven D'Aprano ste...@remove.this.cybersource.com.au 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
Steven D'Aprano ste...@remove.this.cybersource.com.au 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
Steven D'Aprano st...@remove-this-cybersource.com.au 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
Steven D'Aprano ste...@remove.this.cybersource.com.au 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
On Tue, 06 Jan 2009 01:24:58 +, Mark Wooding wrote:
Steven D'Aprano ste...@remove.this.cybersource.com.au 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
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 Python's
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 mentioned
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 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 it
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, ll.index(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 following all throw errors:
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 in ll, 3 not in ll,
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 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 part of
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
Numeric (now numpy)
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 that
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 the
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, 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:
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 class?
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
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 feasible.
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
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't
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 to
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 stdin, line 1, in module
ValueError: The truth value of an
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
Blame IEEE
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.
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
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 inconsistent and
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 inconsistent
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 -0600, Robert Kern
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 -0600,
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
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__
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
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
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 use
case
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
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 ('x
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
these
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 x and y directly.
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:
Current
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,
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 allow non-boolean
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 throw an error
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 to
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 function
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 function
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 would
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,))
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
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
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
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
--
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
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
one.
There is nothing
James Stroud wrote:
div class=moz-text-flowed style=font-family: -moz-fixedRasmus
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
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 that one. Rich
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 checking equality on NaN to
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
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 these
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.
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 stdin, line 1, in module
ValueError: The truth value of an array with more than one element is
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 stdin, line 1, in module
ValueError: The truth value of an array with more than
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 a
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 bool
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.
Robert Kern wrote:
James Stroud wrote:
py 112 = [1, y]
py y in 112
Traceback (most recent call last):
File stdin, line 1, in module
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,
James Stroud wrote:
Robert Kern wrote:
James Stroud wrote:
py 112 = [1, y]
py y in 112
Traceback (most recent call last):
File stdin, line 1, in module
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
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 ==
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,
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
76 matches
Mail list logo
