Comparison of functions

Discussion in 'Python' started by Steven D'Aprano, Jul 30, 2005.

  1. 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

    <function <lambda> at 0xf70598ec>
    >>> b

    <function <lambda> 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.
     
    Steven D'Aprano, Jul 30, 2005
    #1
    1. Advertising

  2. Steven D'Aprano

    Peter Hansen Guest

    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
     
    Peter Hansen, Jul 30, 2005
    #2
    1. Advertising

  3. Steven D'Aprano

    tiissa Guest

    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

    > <function <lambda> at 0xf70598ec>
    >>>>b

    > <function <lambda> 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
     
    tiissa, Jul 30, 2005
    #3
  4. 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 "<stdin>", 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 "<stdin>", 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:
    ICQ: 4410132
     
    Adriano Varoli Piazza, Jul 30, 2005
    #4
  5. 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:
    ICQ: 4410132
     
    Adriano Varoli Piazza, Jul 30, 2005
    #5
  6. 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 "<stdin>", 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 "<stdin>", 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
     
    Reinhold Birkenfeld, Jul 30, 2005
    #6
  7. 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 "<stdin>", 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 "<stdin>", 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.
     
    Steven D'Aprano, Jul 30, 2005
    #7
  8. 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

    >> <function <lambda> at 0xf70598ec>
    >>>>>b

    >> <function <lambda> 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.
     
    Steven D'Aprano, Jul 30, 2005
    #8
  9. Steven D'Aprano

    Georg Neis Guest

    * Reinhold Birkenfeld <> 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 "<stdin>", line 1, in ?
    TypeError: cannot compare complex numbers using <, <=, >, >=
     
    Georg Neis, Jul 30, 2005
    #9
  10. 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:
    ICQ: 4410132
     
    Adriano Varoli Piazza, Jul 30, 2005
    #10
  11. Steven D'Aprano ha scritto:
    > On Sat, 30 Jul 2005 13:30:20 +0000, 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

    Whiiiiii. 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:
    ICQ: 4410132
     
    Adriano Varoli Piazza, Jul 30, 2005
    #11
  12. On Sat, 30 Jul 2005 13:22:47 +0000, 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.
     
    Steven D'Aprano, Jul 30, 2005
    #12
  13. On Sat, 30 Jul 2005 13:30:20 +0000, 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.
     
    Steven D'Aprano, Jul 30, 2005
    #13
  14. Steven D'Aprano ha scritto:
    > On Sat, 30 Jul 2005 13:22:47 +0000, 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:
    ICQ: 4410132
     
    Adriano Varoli Piazza, Jul 30, 2005
    #14
  15. 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 "<stdin>", 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.
     
    Steven D'Aprano, Jul 30, 2005
    #15
  16. Steven D'Aprano

    Kay Schluehr Guest

    Some indications:

    >>> for i in range(5):

    .... x = lambda x:x
    .... y = lambda y:y
    .... print x,y,x<y,id(x)<id(y)
    ....
    <function <lambda> at 0x00EE83F0> <function <lambda> at 0x00EE8FB0>
    True True
    <function <lambda> at 0x00EE8AB0> <function <lambda> at 0x00EE83F0>
    False False
    <function <lambda> at 0x00EE8FB0> <function <lambda> at 0x00EE8AB0>
    False False
    <function <lambda> at 0x00EE83F0> <function <lambda> at 0x00EE8FB0>
    True True
    <function <lambda> at 0x00EE8AB0> <function <lambda> at 0x00EE83F0>
    False False

    Regards,
    Kay
     
    Kay Schluehr, Jul 30, 2005
    #16
  17. Steven D'Aprano

    tiissa Guest

    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
     
    tiissa, Jul 30, 2005
    #17
  18. Georg Neis wrote:
    > * Reinhold Birkenfeld <> 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 "<stdin>", line 1, in ?
    > TypeError: cannot compare complex numbers using <, <=, >, >=


    Reinhold
     
    Reinhold Birkenfeld, Jul 30, 2005
    #18
  19. 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
     
    Reinhold Birkenfeld, Jul 30, 2005
    #19
  20. 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:
    ICQ: 4410132
     
    Adriano Varoli Piazza, Jul 30, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xiangliang Meng
    Replies:
    1
    Views:
    1,614
    Victor Bazarov
    Jun 21, 2004
  2. Charlie Zender

    Need warning-free qsort() comparison functions

    Charlie Zender, Jan 1, 2004, in forum: C Programming
    Replies:
    21
    Views:
    1,262
  3. W. eWatson
    Replies:
    17
    Views:
    510
    W. eWatson
    Aug 30, 2008
  4. Deepu
    Replies:
    1
    Views:
    245
    ccc31807
    Feb 7, 2011
  5. Jayden
    Replies:
    1
    Views:
    215
Loading...

Share This Page