Steven D'Aprano wrote:
> You are confusing mathematical ordering with sorting a list. Here, I will
> sort some mixed complex and real numbers for you. If you look at them
> closely, you will even be able to work out the algorithm I used to sort
> them.
>
> 1
> 1+0j
> 1+7j
> 2
> 2+3j
> 3+3j
> 3-3j
Steven D'Aprano wrote:
> On Sat, 30 Jul 2005 16:43:00 +, Adriano Varoli Piazza wrote:
>
> > If you want to treat numbers as strings, why not convert them before
> > sorting them?
>
> Because that changes the object and throws away information.
I think he meant doing something like
->>> lst =
Adriano Varoli Piazza wrote:
> As far as I recall from Math Analysis, which I studied two months ago,
> you can't sort complex numbers. It makes no sense. The reason being
> (reading from my book), it's not possible to define an order that
> preserves the properties of arithmetical operations o
On Sat, 30 Jul 2005 23:37:04 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>On Sat, 30 Jul 2005 14:20:50 +0200, tiissa wrote:
>
>> Steven D'Aprano wrote:
>>> Playing around with comparisons of functions (don't ask), I discovered an
>>> interesting bit of unintuitive behaviour:
>>>
>>a = l
Steven D'Aprano wrote:
> Python already allows you to compare "this is not a number" with the float
> 5.0. Mathematically, that is meaningless, but I would bet money that
> 99.9% of programmers would demand that they should be able to sort the
> list ["this is not a number", 5.0]. Do you think that
Steven D'Aprano wrote:
> Um, I didn't ask to compare complex numbers using comparison operators. I
> asked to sort a list. And please don't tell me that that sorting is
> implemented with comparison operators. That just means that the
> implementation is confusing numeric ordering with sort order.
On Sat, 30 Jul 2005 17:57:20 +, Adriano Varoli Piazza wrote:
> Steven D'Aprano ha scritto:
>
>> Do you understand the difference between partial and total ordering, or
>> weakly and strongly ordered? When you do understand them, come back and
>> tell me again whether you still think lexicogra
On Sat, 30 Jul 2005 16:43:00 +, Adriano Varoli Piazza wrote:
> If you want to treat numbers as strings, why not convert them before
> sorting them?
Because that changes the object and throws away information.
Here is a list, containing one complex number converted to a string, and
one stri
Steven D'Aprano ha scritto:
> Do you understand the difference between partial and total ordering, or
> weakly and strongly ordered? When you do understand them, come back and
> tell me again whether you still think lexicographic sorting has no meaning
> whatsoever.
>
I think I answered this in
On Sat, 30 Jul 2005 16:13:22 +, Adriano Varoli Piazza wrote:
> Steven D'Aprano ha scritto:
>
>> It was easy. I never once asked myself whether some complex number was
>> greater or less than another, I just asked "which one comes first in a
>> lexicographic sort?"
>>
>> The two questions are
Steven D'Aprano wrote:
> On Sat, 30 Jul 2005 15:32:45 +0200, Reinhold Birkenfeld wrote:
>
>>> Um, I didn't ask to compare complex numbers using comparison operators. I
>>> asked to sort a list. And please don't tell me that that sorting is
>>> implemented with comparison operators. That just means
Georg Neis wrote:
> * Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>> Steven D'Aprano wrote:
>> 1+0j == 1 > 0
>>> True
>>
>> (1+0j == 1) yields True, which is comparable to 0.
>
> "a == b > c" is equivalent to "a == b and b > c":
Right. Stupid me :) Doesn't do much to the point, though.
>>
Steven D'Aprano wrote:
> It was easy. I never once asked myself whether some complex number was
> greater or less than another, I just asked "which one comes first in a
> lexicographic sort?"
>
> The two questions are NOT the same, and it is an ugliness in an otherwise
> beautiful language that Py
Some indications:
>>> for i in range(5):
... x = lambda x:x
... y = lambda y:y
... print x,y,x at 0x00EE83F0> at 0x00EE8FB0>
True True
at 0x00EE8AB0> at 0x00EE83F0>
False False
at 0x00EE8FB0> at 0x00EE8AB0>
False False
at 0x00EE83F0> at 0x00EE8FB0>
True True
at 0x00EE8AB0> at
Steven D'Aprano ha scritto:
> On Sat, 30 Jul 2005 13:22:47 +, Adriano Varoli Piazza wrote:
>
>
>>As far as I recall from Math Analysis, which I studied two months ago,
>>you can't sort complex numbers. It makes no sense. The reason being
>>(reading from my book), it's not possible to define a
On Sat, 30 Jul 2005 15:32:45 +0200, Reinhold Birkenfeld wrote:
>> Um, I didn't ask to compare complex numbers using comparison operators. I
>> asked to sort a list. And please don't tell me that that sorting is
>> implemented with comparison operators. That just means that the
>> implementation is
Steven D'Aprano ha scritto:
> On Sat, 30 Jul 2005 13:30:20 +, Adriano Varoli Piazza wrote:
>
>
>>But tell me, how do you think sort works if not with <, >, ==, <= and >=
>>? I'm really interested.
>
>
> How do you sort words in a dictionary? Why does five come before four
> when the number
Steven D'Aprano ha scritto:
> It was easy. I never once asked myself whether some complex number was
> greater or less than another, I just asked "which one comes first in a
> lexicographic sort?"
>
> The two questions are NOT the same, and it is an ugliness in an otherwise
> beautiful language t
On Sat, 30 Jul 2005 13:30:20 +, Adriano Varoli Piazza wrote:
> But tell me, how do you think sort works if not with <, >, ==, <= and >=
> ? I'm really interested.
How do you sort words in a dictionary? Why does five come before four
when the number five is larger than the number four? Why do
On Sat, 30 Jul 2005 13:22:47 +, Adriano Varoli Piazza wrote:
> As far as I recall from Math Analysis, which I studied two months ago,
> you can't sort complex numbers. It makes no sense. The reason being
> (reading from my book), it's not possible to define an order that
> preserves the proper
* Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano wrote:
> 1+0j == 1 > 0
>> True
>
> (1+0j == 1) yields True, which is comparable to 0.
"a == b > c" is equivalent to "a == b and b > c":
>>> 1 == 1+0j > 0
Traceback (most recent call last):
File "", line 1, in ?
TypeError: ca
Steven D'Aprano wrote:
> On Sat, 30 Jul 2005 08:13:26 -0400, Peter Hansen wrote:
>
>> Beginners should not be comparing lambdas.
>>
>> Neither should you. ;-)
>
> Actually, yes I should, because I'm trying to make sense of the mess that
> is Python's handling of comparisons. At least two differe
Adriano Varoli Piazza ha scritto:
> As far as I recall from Math Analysis, which I studied two months ago,
> you can't sort complex numbers. It makes no sense. The reason being
> (reading from my book), it's not possible to define an order that
> preserves the properties of arithmetical operati
Steven D'Aprano ha scritto:
> On Sat, 30 Jul 2005 08:13:26 -0400, Peter Hansen wrote:
>
>
>>Beginners should not be comparing lambdas.
>>
>>Neither should you. ;-)
>
>
> Actually, yes I should, because I'm trying to make sense of the mess that
> is Python's handling of comparisons. At least two
On Sat, 30 Jul 2005 14:20:50 +0200, tiissa wrote:
> Steven D'Aprano wrote:
>> Playing around with comparisons of functions (don't ask), I discovered an
>> interesting bit of unintuitive behaviour:
>>
>a = lambda y: y
>b = lambda y: y
>a
>> at 0xf70598ec>
>b
>> at 0xf7059844>
>>>
On Sat, 30 Jul 2005 08:13:26 -0400, Peter Hansen wrote:
> Beginners should not be comparing lambdas.
>
> Neither should you. ;-)
Actually, yes I should, because I'm trying to make sense of the mess that
is Python's handling of comparisons. At least two difference senses of
comparisons is jammed
Steven D'Aprano wrote:
> Playing around with comparisons of functions (don't ask), I discovered an
> interesting bit of unintuitive behaviour:
>
a = lambda y: y
b = lambda y: y
a
> at 0xf70598ec>
b
> at 0xf7059844>
a < b
> False
>
> So I'm puzzled about how Python compares t
Steven D'Aprano wrote:
> Playing around with comparisons of functions (don't ask), I discovered an
> interesting bit of unintuitive behaviour:
>
(lambda y: y) < (lambda y: y)
> False
>
> Do the comparison again and things become even more bizarre:
>
(lambda y: y) < (lambda y: y)
> True
>
Playing around with comparisons of functions (don't ask), I discovered an
interesting bit of unintuitive behaviour:
>>> (lambda y: y) < (lambda y: y)
False
Do the comparison again and things become even more bizarre:
>>> (lambda y: y) < (lambda y: y)
True
>>> (lambda y: y) < (lambda y: y)
False
29 matches
Mail list logo
