Re: Comparison of functions
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 > 3+4j > 4 > 4+2j It's clear which algorithm you used to sort these: py> lst = [3+3j, 3+4j, 1+7j, 2, 3-3j, 4, 4+2j, 1, 1+0j, 2+3j] py> def complex2tuple(c): ... c = complex(c) ... return c.real, c.imag ... py> for item in sorted(lst, key=complex2tuple): ... print item ... 1 (1+0j) (1+7j) 2 (2+3j) (3-3j) (3+3j) (3+4j) 4 (4+2j) What isn't clear is that this should be the default algorithm for sorting complex numbers. STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 = ['2+2j', 1+1j] ->>> lst.sort(key=str) ->>> lst [(1+1j), '2+2j'] > > Python is just saying "He's trying to sort complex > > numbers. No can do". > > Python is quite happy to sort a list with one single complex number and > nothing else, so it is not SORTING complex numbers that Python objects > to, merely greater or less than comparisons. It is an accident of > implementation that Python blindly uses GT or LT comparisons for sorting > complex numbers, but not other objects. Python uses GT/LT comparisons for sorting *everything*. The wart is not in list.sort, but in the inconsistent implementation of the comparison operators. > ... > Which has been my point all along: Python confuses the specific case of > NUMERIC COMPARISONS with the general case of SORTING. Worse, Python > doesn't even do that consistently: it is quite happy to let you compare > floats with strings, even though mathematically that is just as > much nonsense as to compare floats with complex numbers. > > As I've said, the two are similar enough that such a mistake is easy to > make. And at this time, I'm not sure how to implement a better solution, > or even if there is a better solution, but I am giving it some thought. How's this? # This would be the default cmp function for list.sort def sortcmp(x, y): try: return x.__sortcmp__(y) except (AttributeError, TypeError): try: return -(y.__sortcmp__(x)) except (AttributeError, TypeError): return cmp(x, y) # Example class for __sortcmp__ method class SaneComplex(complex): def __sortcmp__(self, other): other = complex(other) return cmp((self.real, self.imag), (other.real, other.imag)) lst = map(SaneComplex, [1, 1+0j, 1+7j, 2, 2+3j, 3+3j, 3-3j, 3+4j, 4, 4+2j]) lst.sort(sortcmp) print lst -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 on complex numbers.
> So you can't order them, and you can't compare them.
Debate the merits of Python's method of sorting all you want, but for
the love of all that is good and holy, please do not claim that the
current way of doing things is somehow mathematically pure. The best
explanation of the current method is that it is a compromise borne out
of the best use cases encountered as the language grew in it's infancy,
and we're stuck with it currently because it would break too much to
change things right now.
E.g.:
1 < '2' => True
'1' < 2 => False
20 < 'Five' => True
None < 0 => True
[1,2] < (1,2) => True
(1,2) < [100,200] => False
(None,) < None => False
{1:None,2:None} < [1,2] => True
[None, 1, 'five', open('README'), (1,2,3)].sort() => works just fine
[None, 1, 'five', open('README'), (1,2,3), 1j].sort() => crashes and burns
None of these make sense mathematically, nor were they motivated
primarily by mathematical arguments. Why is [1,2] < (1,2)? Because
'list' < 'tuple' - No more, no less.
One could argue that you could think of complex numbers as tuples of
values - but then why does
[(1,2),(4,1),(4,-3),(7.2,-1.2)].sort() work and
[(1+2j),(4+1j),(4-3j),(7.2-1.2j)].sort() fail?
"Practicality beats purity." Python has it's current ordering/sorting
scheme not because it is theoretically pure, but because it seemed like
the best option at the time. Please don't pretend it's perfect - it's
even been admitted that things are going to change in the future,
although I haven't yet seen a conversation where it has been made clear
exactly what will change.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 = lambda y: y >>b = lambda y: y >>a >>> at 0xf70598ec> >>b >>> at 0xf7059844> >>a < b >>> False >>> >>> So I'm puzzled about how Python compares the two. >> >> Seems to me the object addresses are compared in this case. But I'm too >> lazy to check it in the source. ;) > >Strangely enough, I'm lazy enough to not check the source too :-) > >Actually, more to the point, I don't read C, so even if I did check the >source, I wouldn't know what it was trying to tell me. > >> However, the doc [1] warns you about such comparisons: """Most other >> types compare unequal unless they are the same object; the choice >> whether one object is considered smaller or larger than another one is >> made arbitrarily but consistently within one execution of a program.""" > >I am aware of that. That's a wart. > What if rich sorting "measured" the objects it was sorting, to form a measurement tuple of primitive types, so that you'd wind up sorting as if by a decorated list with the measurement tuple as the decoration, e.g., (an I think having to wrap complex for sorting is CWrap ;-) Just a sketch to illustrate an idea for sorting... < richlysorted.py >- def richlysorted(seq): return ((type(v) is CWrap and [v.v] or [v])[0] for d,v in sorted(measure_dec(seq))) INT = LONG = FLOAT = 0 COMPLEX = 1 STR = 2 UNICODE = 3 FUNCTION = 4 TYPE = 5 DEFAULT = 6 type_sort_order = dict( int=INT, long=LONG, float=FLOAT, complex=COMPLEX, str=STR, unicode=UNICODE, function=FUNCTION, type=TYPE) class CWrap(object): def __init__(self, v): self.v=v def __eq__(self, other): return True def measure_dec(seq): for v in seq: sort_priority = type_sort_order.get(type(v).__name__, DEFAULT) if sort_priority == COMPLEX: yield (sort_priority, v.real, v.imag), CWrap(v) elif sort_priority <= UNICODE: yield (sort_priority,), v elif sort_priority == FUNCTION: yield (sort_priority, v.func_name, v.func_code.co_argcount), v elif sort_priority == TYPE: yield (sort_priority, v.__name__), v else: yield (sort_priority, type(v).__name__, repr(v)) , v def test(): class C: pass class D(object): pass def foo(): pass def bar(a,b): pass tbs = [1, -1.0, 1+0j, 2j, lambda x:x, test, measure_dec, lambda:None, foo, bar, D, D(), C(), C, 2**32, -2**32] for tup in zip(tbs, measure_dec(tbs)): print '%35s | %-s' % tup print '%s\nSorted:'% (50*'-') for item in richlysorted(tbs): print '%35s' % item if __name__ == '__main__': test() [16:57] C:\pywk\ut>py24 richlysorted.py 1 | ((0,), 1) -1.0 | ((0,), -1.0) (1+0j) | ((1, 1.0, 0.0), <__main__.CWrap object at 0x02F00B2C>) 2j | ((1, 0.0, 2.0), <__main__.CWrap object at 0x02F00B4C>) at 0x02EE8DF4> | ((4, '', 1), at 0x02EE8DF4>) | ((4, 'test', 0), ) | ((4, 'measure_dec', 1), ) at 0x02EE8E2C> | ((4, '', 0), at 0x02EE8E2C>) | ((4, 'foo', 0), ) | ((4, 'bar', 2), ) | ((5, 'D'), ) <__main__.D object at 0x02F0044C> | ((6, 'D', '<__main__.D object at 0x02F0044C>'), <__main__. D object at 0x02F0044C>) <__main__.C instance at 0x02F004CC> | ((6, 'instance', '<__main__.C instance at 0x02F004CC>'), < __main__.C instance at 0x02F004CC>) __main__.C | ((6, 'classobj', ''), ) 4294967296 | ((0,), 4294967296L) -4294967296 | ((0,), -4294967296L) -- Sorted: -4294967296 -1.0 1 4294967296 2j (1+0j) at 0x02EE8E2C> at 0x02EE8DF4> <__main__.D object at 0x02F0044C> __main__.C <__main__.C instance at 0x02F004CC> Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 it is unintuitive > too? I strongly suspect that 99.8% of (let's say non-newbie) programmers would have no expectation that the default sort routine would do something other than barf on that input. You want "garbage in, garbage out", but in Python it's supposed to be "garbage in, exception out, please be explicit about what you want next time". I can't think of any use case for sorting a list like that which wouldn't most appropriately be handled with a custom comparison routine passed to sort. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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. Python doesn't have a distinction between these two, so yes, you're sorting with comparison operators. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis I am not a Virginian, but an American. -- Patrick Henry -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 lexicographic sorting has no meaning >> whatsoever. >> > > I think I answered this in another post... If you want to order text > strings (as complex numbers in an index in a book, or in a lexicographic > sort are) do so. I understand the importance it has to you, but it's > hardly reasonable to argue that Python should do the most unintuitive > thing with complex numbers by default just because it suits you. Adriano, list.sort() is not an operation on complex numbers. It is an operation on a list. What is unintuitive is that you can't sort a list merely because of the arithmetical properties of an object in that list. Why should that make a difference? We're not doing arithmetic on the objects, we're sorting the list. It isn't even about *complex numbers* as such -- that was just a convenient example. There are no end to the possible objects which don't define greater than and less than. But you should still be able to sort a list containing them. Sorting is not numeric comparisons! 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 it is unintuitive too? This conversation has been an exercise in futility. I'm sorry that so many of the people answering find it difficult to see the difference between numeric comparisons of complex numbers (which are rightly forbidden) and sorting of lists of arbitrary objects (which should always succeed): in effect, confusing the current implementation of sort() in Python with the general principle of sorting. Unless anyone comes up with constructive comments (which does not necessarily mean "agrees with me"), I plan to drop this thread until such time, if ever, that I have something more concrete to suggest. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 string that just happens to look like a complex number: ['1+1j', '2+2j']. Now convert it back the way it was. > Python is just saying "He's trying to sort complex > numbers. No can do". Python is quite happy to sort a list with one single complex number and nothing else, so it is not SORTING complex numbers that Python objects to, merely greater or less than comparisons. It is an accident of implementation that Python blindly uses GT or LT comparisons for sorting complex numbers, but not other objects. > You're trying to make it guess that you want them > sorted as strings, not as numbers. I don't see how Python treats things > the same way. I see that real numbers and strings can be compared and > sorted (asciibetically? don't remember). It has nothing to do with > complex numbers. The abstraction or overloading or what it is fails, > because they don't have an order as numbers, and Py is not intelligent > enough to know that you want them asciibetized Which has been my point all along: Python confuses the specific case of NUMERIC COMPARISONS with the general case of SORTING. Worse, Python doesn't even do that consistently: it is quite happy to let you compare floats with strings, even though mathematically that is just as much nonsense as to compare floats with complex numbers. As I've said, the two are similar enough that such a mistake is easy to make. And at this time, I'm not sure how to implement a better solution, or even if there is a better solution, but I am giving it some thought. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 another post... If you want to order text strings (as complex numbers in an index in a book, or in a lexicographic sort are) do so. I understand the importance it has to you, but it's hardly reasonable to argue that Python should do the most unintuitive thing with complex numbers by default just because it suits you. -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 NOT the same, and it is an ugliness in an otherwise >> beautiful language that Python treats them as the same. >> >> Mathematically, 1 == 1.0 == 1+0j but in the dictionary "1" should sort >> before "1.0" which sorts before "1.0+0.0j". > > Because, of course, when I sort numbers the first thing I think of is > looking at the ascii table... Here I was, thinking maths was useful. > Sorting numbers "lexicographically" might make sense to you, but it's > totally unintuitive to me. For example, why or how would I guess that > "3-3j" is bigger (or smaller) than "3+3j"? 3-3j is NOT bigger than 3+3j, nor is it smaller. You said so yourself: "it's not possible to define an order that preserves the properties of arithmetical operations on complex numbers." Fortunately, when we sort a list, we don't care about preserving the properties of arithmetical operations, we just need to place each item in a known, non-arbitrary (or at least not too arbitrary) position. > You'll still want to sort complex numbers lexicographically. It'll still > have no meaning whatsoever, so you might as well leave the list > unsorted. Your mathematical purity does you great credit. Unfortunately, it is also quite impractical. I'll give you a real-world actual case where sorting complex numbers is important: "The Penguin Dictionary Of Curious and Interesting Numbers" by David Wells. Some few hundreds of numbers are listed, including i. Should Wells have listed those numbers in random unsorted order just to satisfy some purists who insist that placing i in the list makes sorting the other 399 entries meaningless? > You might think you sorted something. 100? 200? years of maths > say you didn't. Sorting is not just numeric ordering. There are many different collation systems, not just ordering numbers by their magnitude. Think about sorting guests around a dinner table: married couples next to each other, single people across from another single person of the opposite sex, children at the end of the table, babies next to their mother, Uncle Enno as far away from Aunt May as possible. It is a complicated algorithm, but it is still sorting (people, in this case, not numbers). I appreciate your strong feelings about not doing comparisons on complex numbers, but if you actually studied the mathematics of orderings sets, you would realise how silly it was to say that a century of mathematics says that I didn't sort a list. Mathematicians are fully aware that numeric sorting is just one way of many of sorting. 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. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 that the >>> implementation is confusing numeric ordering with sort order. >> >> Sorting is implemented with comparison operators. How should it be otherwise? > > That's a good question, and that's why I'm exploring different comparisons > in Python, trying to understand what Python already does, and the pros and > cons thereof, before I suggest anything new. > >> Would you prefer a __sort__ method to specify sort order? > > Well, there are an infinite number of sort orders. Most of them are pretty > much useless, but even if we limit ourselves to common, useful sort > orders, there are still a good half dozen or more. That's why the sort method does have certain keyword arguments with which you can customize sorting to your liking. But unless the standard sort without arguments should be disallowed, it has to resort to comparison. > So at this time, I'd rather not be pinned down to some half-baked > "solution" before I have even understood the problem. That's wise. >> But complex numbers are not greater or littler than others. You can't order >> them, >> not on a one-dimensional scale. > > Of course you can order them. You are confusing order with magnitude. The > two are not identical, although they are similar enough in some contexts > as to cause confusion. Well, you can order everything according to some specs, but you can't find a default sort order for everything. That's where custom comparison functions can help. Correct me if I'm wrong, but is there a default order for complex number? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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. 1 == 1+0j > 0 > Traceback (most recent call last): > File "", line 1, in ? > TypeError: cannot compare complex numbers using <, <=, >, >= Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 Python treats them as the same. The point is Python does not. The order you proposed above can be implemented using a comparison function you can pass to the sort function of lists [1] or the sorted builtin [2]. If the elements can be compared, Python offers you not to pass the cmp function to sort if you want to use this default order. Python allows you to use the default ordering to sort a list but does not treat both questions in the same manner. However, the fact is ordering a list using the default '<' happens pretty often. In the case of complex numbers, no mathematically sound comparison function exists and Python does not impose some default function that would be called a wart. [1] http://docs.python.org/lib/typesseq-mutable.html [2] http://docs.python.org/lib/built-in-funcs.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 0x00EE83F0> False False Regards, Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 an order that >>preserves the properties of arithmetical operations on complex numbers. >>So you can't order them, and you can't compare them. > > > 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 > 3+4j > 4 > 4+2j > > > 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 Python treats them as the same. > > Mathematically, 1 == 1.0 == 1+0j but in the dictionary "1" should sort > before "1.0" which sorts before "1.0+0.0j". > If you want to treat numbers as strings, why not convert them before sorting them? Python is just saying "He's trying to sort complex numbers. No can do". You're trying to make it guess that you want them sorted as strings, not as numbers. I don't see how Python treats things the same way. I see that real numbers and strings can be compared and sorted (asciibetically? don't remember). It has nothing to do with complex numbers. The abstraction or overloading or what it is fails, because they don't have an order as numbers, and Py is not intelligent enough to know that you want them asciibetized -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 confusing numeric ordering with sort order. > > Sorting is implemented with comparison operators. How should it be otherwise? That's a good question, and that's why I'm exploring different comparisons in Python, trying to understand what Python already does, and the pros and cons thereof, before I suggest anything new. > Would you prefer a __sort__ method to specify sort order? Well, there are an infinite number of sort orders. Most of them are pretty much useless, but even if we limit ourselves to common, useful sort orders, there are still a good half dozen or more. So at this time, I'd rather not be pinned down to some half-baked "solution" before I have even understood the problem. > And how would you sort a list of complex numbers? Answered in another post. >> Then there is this: >> > 1 > 0 >> True > > Okay. > > 1+0j == 1 >> True > > Okay. > > 1+0j == 1 > 0 >> True > > (1+0j == 1) yields True, which is comparable to 0. No, 1+0j == 1 > 0 is calculated as 1+0j == 1 and 1 > 0. > 1+0j > 0 >> Traceback (most recent call last): >> File "", line 1, in ? >> TypeError: cannot compare complex numbers using <, <=, >, >= > > But complex numbers are not greater or littler than others. You can't order > them, > not on a one-dimensional scale. Of course you can order them. You are confusing order with magnitude. The two are not identical, although they are similar enough in some contexts as to cause confusion. I admit that I haven't fully grasped all the subtleties of the general ordering problem. Fortunately, my needs are much less lofty. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 five is larger than the number four? Why does hundred > come before ten? What does it mean to say that elephant is less than > mouse? > > When you can answer those questions, you will be enlightened. > >>> 'a' > 'A' True >>> 'a' > '-' True >>> 'a' > 'h' False Whii. I just discovered the Ascii table! wooot! (Your EBCDIC mileage might vary) What does it have to do with complex numbers, pray tell? and how do you think any string sort works if not by comparing the numerical value of each character? Once more: >>> 'five' < 'four' True >>> 'five' < 'Four' False >>> 'Five' < 'Four' True Ooohhh! magic of ascii! -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 that Python treats them as the same. > > Mathematically, 1 == 1.0 == 1+0j but in the dictionary "1" should sort > before "1.0" which sorts before "1.0+0.0j". Because, of course, when I sort numbers the first thing I think of is looking at the ascii table... Here I was, thinking maths was useful. Sorting numbers "lexicographically" might make sense to you, but it's totally unintuitive to me. For example, why or how would I guess that "3-3j" is bigger (or smaller) than "3+3j"? You'll still want to sort complex numbers lexicographically. It'll still have no meaning whatsoever, so you might as well leave the list unsorted. You might think you sorted something. 100? 200? years of maths say you didn't. -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 does hundred come before ten? What does it mean to say that elephant is less than mouse? When you can answer those questions, you will be enlightened. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 properties of arithmetical operations on complex numbers. > So you can't order them, and you can't compare them. 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 3+4j 4 4+2j 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 Python treats them as the same. Mathematically, 1 == 1.0 == 1+0j but in the dictionary "1" should sort before "1.0" which sorts before "1.0+0.0j". -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
* 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: cannot compare complex numbers using <, <=, >, >= -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 difference senses of > comparisons is jammed into one, leading to such such warts as these: > L = [] L.sort() # we can sort lists L.append(1+1j) L.sort() # even if they include a complex number L.append(1) L.sort() # but not any more > Traceback (most recent call last): > File "", line 1, in ? > TypeError: cannot compare complex numbers using <, <=, >, >= > > 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. Sorting is implemented with comparison operators. How should it be otherwise? Would you prefer a __sort__ method to specify sort order? And how would you sort a list of complex numbers? > Then there is this: > 1 > 0 > True Okay. 1+0j == 1 > True Okay. 1+0j == 1 > 0 > True (1+0j == 1) yields True, which is comparable to 0. 1+0j > 0 > Traceback (most recent call last): > File "", line 1, in ? > TypeError: cannot compare complex numbers using <, <=, >, >= But complex numbers are not greater or littler than others. You can't order them, not on a one-dimensional scale. > I applaud that Python has got rich comparisons for those who need them. > But by confusing the question "which comes first in a sorted list?" with > "which is larger?", you get all sorts of warts like being unable to sort > lists with some objects, while being able to make meaningless > comparisons like ''.join >= [].append. That's a wart indeed, and intended to be removed for 3.0, if I'm informed correctly. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 operations on complex numbers. > So you can't order them, and you can't compare them. > Sorry, that should have been "you can't sort them, and you can't compare them with greater than, lesser than, etc. Of course, using == will work. But tell me, how do you think sort works if not with <, >, ==, <= and >= ? I'm really interested. -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 difference senses of > comparisons is jammed into one, leading to such such warts as these: > > L = [] L.sort() # we can sort lists L.append(1+1j) L.sort() # even if they include a complex number L.append(1) L.sort() # but not any more > > Traceback (most recent call last): > File "", line 1, in ? > TypeError: cannot compare complex numbers using <, <=, >, >= > > 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. > > Then there is this: > > 1 > 0 > > True > 1+0j == 1 > > True > 1+0j == 1 > 0 > > True > 1+0j > 0 > > Traceback (most recent call last): > File "", line 1, in ? > TypeError: cannot compare complex numbers using <, <=, >, >= > > I applaud that Python has got rich comparisons for those who need them. > But by confusing the question "which comes first in a sorted list?" with > "which is larger?", you get all sorts of warts like being unable to sort > lists with some objects, while being able to make meaningless > comparisons like ''.join >= [].append. > > I'm not sure what the solution to this ugly state of affairs is. I'm not > even sure if there is a solution. But I'm willing to make a good effort to > *look*, and even though you were joking, I don't appreciate being told > not to. 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 on complex numbers. So you can't order them, and you can't compare them. -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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> >a < b >> False >> >> So I'm puzzled about how Python compares the two. > > Seems to me the object addresses are compared in this case. But I'm too > lazy to check it in the source. ;) Strangely enough, I'm lazy enough to not check the source too :-) Actually, more to the point, I don't read C, so even if I did check the source, I wouldn't know what it was trying to tell me. > However, the doc [1] warns you about such comparisons: """Most other > types compare unequal unless they are the same object; the choice > whether one object is considered smaller or larger than another one is > made arbitrarily but consistently within one execution of a program.""" I am aware of that. That's a wart. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 into one, leading to such such warts as these: >>> L = [] >>> L.sort() # we can sort lists >>> L.append(1+1j) >>> L.sort() # even if they include a complex number >>> L.append(1) >>> L.sort() # but not any more Traceback (most recent call last): File "", line 1, in ? TypeError: cannot compare complex numbers using <, <=, >, >= 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. Then there is this: >>> 1 > 0 True >>> 1+0j == 1 True >>> 1+0j == 1 > 0 True >>> 1+0j > 0 Traceback (most recent call last): File "", line 1, in ? TypeError: cannot compare complex numbers using <, <=, >, >= I applaud that Python has got rich comparisons for those who need them. But by confusing the question "which comes first in a sorted list?" with "which is larger?", you get all sorts of warts like being unable to sort lists with some objects, while being able to make meaningless comparisons like ''.join >= [].append. I'm not sure what the solution to this ugly state of affairs is. I'm not even sure if there is a solution. But I'm willing to make a good effort to *look*, and even though you were joking, I don't appreciate being told not to. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 the two. Seems to me the object addresses are compared in this case. But I'm too lazy to check it in the source. ;) However, the doc [1] warns you about such comparisons: """Most other types compare unequal unless they are the same object; the choice whether one object is considered smaller or larger than another one is made arbitrarily but consistently within one execution of a program.""" [1] http://docs.python.org/ref/comparisons.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
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 > (lambda y: y) < (lambda y: y) > False > > This behaviour should be easy for experienced Pythonisters to answer, but > will probably confuse beginners greatly. Beginners should not be comparing lambdas. Neither should you. ;-) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Comparison of functions
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 This behaviour should be easy for experienced Pythonisters to answer, but will probably confuse beginners greatly. For the benefit of beginners, imagine we expand the first line into two, and commit what some people call an abuse of lambdas: we bind them to names. >>> a = lambda y: y >>> b = lambda y: y >>> a at 0xf70598ec> >>> b at 0xf7059844> a and b are now bound to two objects, each of which is an anonymous function that just happens to do the same thing. But each time you create a lambda function, you get a different object at some unpredictable location in memory. This is where my level of Python knowledge fails me. I don't understand how Python is comparing the two objects since neither a nor b have any rich comparison methods or even the old-style __cmp__ method. >>> a < b False So I'm puzzled about how Python compares the two. If we compare a and b again, we will always get the same answer. But if we create a new pair of anonymous functions with lambda, and compare them, it is the luck of the draw each time whether the first compares bigger or smaller than the second. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
