Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #56535 > unrolled thread

I am never going to complain about Python again

Back to article view | Back to comp.lang.python

Contents

  I am never going to complain about Python again Steven D'Aprano <steve@pearwood.info> - 2013-10-10 04:36 +0000
    Re: I am never going to complain about Python again Chris Angelico <rosuav@gmail.com> - 2013-10-10 15:50 +1100
    Re: I am never going to complain about Python again Chris Rebert <clp2@rebertia.com> - 2013-10-09 22:26 -0700
    Re: I am never going to complain about Python again Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-10 06:39 +0100
    Re: I am never going to complain about Python again Christian Gollwitzer <auriocus@gmx.de> - 2013-10-10 08:41 +0200
    Re: I am never going to complain about Python again "Frank Millman" <frank@chagford.com> - 2013-10-10 10:23 +0200
    Re: I am never going to complain about Python again MRAB <python@mrabarnett.plus.com> - 2013-10-10 12:10 +0100
    Re: I am never going to complain about Python again Tim Chase <python.list@tim.thechases.com> - 2013-10-10 06:43 -0500
    Re: I am never going to complain about Python again "Frank Millman" <frank@chagford.com> - 2013-10-10 13:44 +0200
    Re: I am never going to complain about Python again Roy Smith <roy@panix.com> - 2013-10-10 09:09 -0400
      Re: I am never going to complain about Python again Neil Cerutti <neilc@norwich.edu> - 2013-10-10 15:51 +0000
        Re: I am never going to complain about Python again Rotwang <sg552@hotmail.co.uk> - 2013-10-10 16:57 +0100
          Re: I am never going to complain about Python again MRAB <python@mrabarnett.plus.com> - 2013-10-10 17:10 +0100
            Re: I am never going to complain about Python again Neil Cerutti <neilc@norwich.edu> - 2013-10-10 17:48 +0000
              Re: I am never going to complain about Python again Ian Kelly <ian.g.kelly@gmail.com> - 2013-10-10 12:35 -0600
                Re: I am never going to complain about Python again Neil Cerutti <neilc@norwich.edu> - 2013-10-10 18:49 +0000
              Re: I am never going to complain about Python again Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-10 20:47 +0100
                Re: I am never going to complain about Python again Neil Cerutti <neilc@norwich.edu> - 2013-10-10 19:54 +0000
              Re: I am never going to complain about Python again Cameron Simpson <cs@zip.com.au> - 2013-10-11 08:52 +1100
              Re: I am never going to complain about Python again Roy Smith <roy@panix.com> - 2013-10-10 20:07 -0400
                Is this the room for an argument? John Ladasky <john_ladasky@sbcglobal.net> - 2013-10-10 21:26 -0700
                  Re: Is this the room for an argument? Roy Smith <roy@panix.com> - 2013-10-11 09:49 -0400
              Re: I am never going to complain about Python again Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-11 02:23 +0000
                Re: I am never going to complain about Python again Neil Cerutti <neilc@norwich.edu> - 2013-10-11 12:31 +0000
      Re: I am never going to complain about Python again Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-10-10 20:09 -0400
      Re: I am never going to complain about Python again Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-11 02:08 +0000
        Re: I am never going to complain about Python again Joshua Landau <joshua@landau.ws> - 2013-10-11 09:17 +0100
          Re: I am never going to complain about Python again Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-11 09:11 +0000
            Re: I am never going to complain about Python again Chris Angelico <rosuav@gmail.com> - 2013-10-11 20:52 +1100
            Re: I am never going to complain about Python again Joshua Landau <joshua@landau.ws> - 2013-10-11 17:56 +0100

Page 2 of 2 — ← Prev page 1 [2]

#56642 — Is this the room for an argument?

On Thursday, October 10, 2013 5:07:11 PM UTC-7, Roy Smith wrote:
> I'd like an argument, please.

'Receptionist' (Rita Davies) - Yes, sir?
'Man' (Michael Palin) - I'd like to have an argument please.
'Receptionist' - Certainly sir, have you been here before...?
'Man' - No, this is my first time.
'Receptionist' - I see. Do you want to have the full argument, or were you thinking of taking the course?
'Man' - Well, what would be the cost?
'Receptionist' - Yes, it's one pound for a five-minute argument, but only eight pounds for a course of ten.
'Man' - Well, I think it's probably best if I start with the five-minute one and see how it goes from there. OK?
'Receptionist' - Fine - I'll see who's free at the moment...Mr.Du-Bakey's free, but he's a little bit concilliatory...Yes, try Mr.Barnard - Room 12.
'Man' - Thank you.

:^)

[toc] | [prev] | [next] | [standalone]

#56681 — Re: Is this the room for an argument?

In article <5223ac4a-783e-405d-84a4-239070b665c5@googlegroups.com>,
 John Ladasky <john_ladasky@sbcglobal.net> wrote:

> On Thursday, October 10, 2013 5:07:11 PM UTC-7, Roy Smith wrote:
> > I'd like an argument, please.
> 
> 'Receptionist' (Rita Davies) - Yes, sir?
> 'Man' (Michael Palin) - I'd like to have an argument please.
> 'Receptionist' - Certainly sir, have you been here before...?
> 'Man' - No, this is my first time.
> 'Receptionist' - I see. Do you want to have the full argument, or were you 
> thinking of taking the course?
> 'Man' - Well, what would be the cost?
> 'Receptionist' - Yes, it's one pound for a five-minute argument, but only 
> eight pounds for a course of ten.
> 'Man' - Well, I think it's probably best if I start with the five-minute one 
> and see how it goes from there. OK?
> 'Receptionist' - Fine - I'll see who's free at the moment...Mr.Du-Bakey's 
> free, but he's a little bit concilliatory...Yes, try Mr.Barnard - Room 12.
> 'Man' - Thank you.
> 
> :^)

Well, that was half of the joke.  I'm waiting to see if anybody gets the 
other half.

[toc] | [prev] | [next] | [standalone]

#56633

On Thu, 10 Oct 2013 17:48:16 +0000, Neil Cerutti wrote:

> >>> 5.0 == abs(3 + 4j)
>  False

Did you maybe accidentally rebind abs? If not, what version of Python are 
you using?


[steve@ando ~]$ for a in 2.4 2.5 2.6 2.7 3.2 3.3 ; do
> python$a -c "print( 5.0 == abs(3 + 4j) )" ;
> done
True
True
True
True
True
True



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#56679

On 2013-10-11, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Thu, 10 Oct 2013 17:48:16 +0000, Neil Cerutti wrote:
>
>> >>> 5.0 == abs(3 + 4j)
>>  False
>
> Did you maybe accidentally rebind abs? If not, what version of
> Python are you using?

Honestly, I think I got my Python term and my Vim term mixed up.
I Shall not post technical stuff while working on other thing.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#56623

On Thu, 10 Oct 2013 09:09:42 -0400, Roy Smith <roy@panix.com> declaimed the
following:


>BTW, here's a Python equality oddity:
>
>>>> r = 0.0
>>>> c = 0 + 0j
>>>> r == c
>True
>>>> int(r) == int(c)
>Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>TypeError: can't convert complex to int
>
>If x == y, then f(x) should also equal f(y).  More specifically, if x == 
>y, and x is in the domain of f(), then y should also be in the domain of 
>f().

	But the int(c) is a downgrade -- it would require losing all
information that the item was an element of the complex plain...

>>> r = 0.0
>>> c = 0 + 0j
>>> r
0.0
>>> c
0j
>>> complex(r) == c
True
>>> 

	Maybe some language exists that considers "c" to be a downgradable
match to "r" (it may even be some language I've used -- but never had to
consider the condition prior). Note that in the above, the representation
of "c" doesn't even display a real component!
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#56631

On Thu, 10 Oct 2013 09:09:42 -0400, Roy Smith wrote:

> BTW, here's a Python equality oddity:
> 
>>>> r = 0.0
>>>> c = 0 + 0j
>>>> r == c
> True

Mathematically, this is only to be expected.


>>>> int(r) == int(c)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: can't convert complex to int


This is also to be expected. What should int(a+bj) return?

★  int(a) + int(b)j

★  int(a)

★  int(b)

★  int(abs(a + bj))


It's quite ambiguous, there is no obvious mapping from complex to 
integers, and so should raise an exception.


 
> If x == y, then f(x) should also equal f(y).

Not necessarily. If x and y are different types, which they are here, 
then function f may be defined on one type but not the other. Which is 
exactly the case with int() on floats and complexes.


> More specifically, if x == y,
> and x is in the domain of f(), then y should also be in the domain of
> f().

Incorrect. By definition, complex numbers are in the Complex domain, not 
the Real domain.

Your mistake here seems to be that you're assuming that if two numbers 
are equal, they must be in the same domain, but that's not the case. 
(Perhaps you think that 0.0 == 0+0j should return False?) It's certainly 
not the case when it comes to types in Python, and it's not even the case 
in mathematics. Given:

x ∈ ℝ, x = 2  (reals)
y ∈ ℕ, y = 2  (natural numbers)

we have x = y, but since 1/y is undefined (there is no Natural number 
1/2), 1/x != 1/y.

Now, arguably in this case we could implicitly promote y to the reals 
before performing the division. I would consider that acceptable, since 
there is only one way to do the promotion: natural 2 -> real 2. But going 
the other way certainly isn't: demoting real x to the naturals is 
ambiguous, and even if it weren't, then declaring that 1/x isn't defined 
would make the whole exercise pointless.

Bringing this back to the initial example of int(0.0) == int(0+0j), to 
have this work the way you want would require demoting the complex number 
to the reals, and that is ambiguous. There are three distinct ways to do 
this: take the real part, the imaginary part, or the absolute value. That 
makes the operation "demote to real" ambiguous, the mere fact that all 
three operations would happen to give the same result for this particular 
number is irrelevant.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#56659

On 11 October 2013 03:08, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Your mistake here seems to be that you're assuming that if two numbers
> are equal, they must be in the same domain, but that's not the case.
> (Perhaps you think that 0.0 == 0+0j should return False?) It's certainly
> not the case when it comes to types in Python, and it's not even the case
> in mathematics. Given:
>
> x ∈ ℝ, x = 2  (reals)
> y ∈ ℕ, y = 2  (natural numbers)
>
> we have x = y, but since 1/y is undefined (there is no Natural number
> 1/2), 1/x != 1/y.

Surely 1/y is perfectly well defined, as only y, not 1/y, is
constrained to the natural numbers.

[toc] | [prev] | [next] | [standalone]

#56667

On Fri, 11 Oct 2013 09:17:37 +0100, Joshua Landau wrote:

> On 11 October 2013 03:08, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Your mistake here seems to be that you're assuming that if two numbers
>> are equal, they must be in the same domain, but that's not the case.
>> (Perhaps you think that 0.0 == 0+0j should return False?) It's
>> certainly not the case when it comes to types in Python, and it's not
>> even the case in mathematics. Given:
>>
>> x ∈ ℝ, x = 2  (reals)
>> y ∈ ℕ, y = 2  (natural numbers)
>>
>> we have x = y, but since 1/y is undefined (there is no Natural number
>> 1/2), 1/x != 1/y.
> 
> Surely 1/y is perfectly well defined, as only y, not 1/y, is constrained
> to the natural numbers.

Context is important, and usually implied. 1/y within the natural numbers 
is treated in the same way as sqrt(-1) within the reals. Try it on your 
calculator, and chances are very good you'll get an error. Try it in 
Python 2, or nearly any other programming language (but not Python 3), 
and again, chances are you'll get an error.

If you implicitly decide to promote entities, then of course you can 
promote y to a real then take the invoice. But that trick still doesn't 
work for the original example, int(0.0) == int(0+0j) because promoting 0 
to complex doesn't help, you have to demote 0+0j to real and that's 
ambiguous.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#56673

On Fri, Oct 11, 2013 at 8:11 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> If you implicitly decide to promote entities, then of course you can
> promote y to a real then take the invoice.

Either you're channelling Bugs Bunny or you're trying to sell me
something... you mean "take the inverse", I assume, here :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#56693

On 11 October 2013 10:11, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Fri, 11 Oct 2013 09:17:37 +0100, Joshua Landau wrote:
>
>> On 11 October 2013 03:08, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>>>
>>> Given:
>>>
>>> x ∈ ℝ, x = 2  (reals)
>>> y ∈ ℕ, y = 2  (natural numbers)
>>>
>>> we have x = y, but since 1/y is undefined (there is no Natural number
>>> 1/2), 1/x != 1/y.
>>
>> Surely 1/y is perfectly well defined, as only y, not 1/y, is constrained
>> to the natural numbers.
>
> Context is important, and usually implied. 1/y within the natural numbers
> is treated in the same way as sqrt(-1) within the reals.

I don't know; a rational tends to be described as any number of the
form x/y where x, y ∈ ℕ. Hence I don't agree that it's reasonable to
ever assume that 1/y has to exist in the same space as y unless
explicitly stated or generally working within, say, the integers.
Neither of those are remotely true of Python so I don't see how this
point is relevant when discussing Python's concept of equality.

> Try it on your
> calculator, and chances are very good you'll get an error. Try it in
> Python 2, or nearly any other programming language (but not Python 3),
> and again, chances are you'll get an error.

*Remains unconvinced.* None of that seems to actually matter.

> If you implicitly decide to promote entities, then of course you can
> promote y to a real then take the invoice.

I'm not. I'm just not applying the restrictions on y to the function it's in.

> But that trick still doesn't
> work for the original example, int(0.0) == int(0+0j) because promoting 0
> to complex doesn't help, you have to demote 0+0j to real and that's
> ambiguous.

I agree on this. The correct interpretation of

    0.0 == 0 + 0j

is, of course

    complex(0.0) == 0 + 0j

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web