[issue36228] Support coercion of complex to float/int

[Mark Dickinson]

Mark Dickinson  added the comment:

@nagayev I applaud your enthusiasm here, but multiple core developers have 
already rejected your suggestions in this discussion. Given that, it would 
probably not be a great use of your time to pursue this.

Maybe you could take a look around the bug tracker for other possible issues 
you might be interested in pursuing instead?

If you did wanted to pursue this issue[*] in spite of the discussion above (who 
knows: maybe the core devs who responded on this issue are all misguided, or 
maybe we're all missing an obvious use case), your best bet would be to bring 
it up for wider discussion on the python-ideas mailing list.

[*] There are really two issues in this discussion, not one: there's one about 
`__float__` and `__int__` for complex numbers, and one for extending `floor` 
and `ceil` to complex numbers, but my understanding of the discussion is that 
both those have been rejected at this point.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Марат Нагаев]

Марат Нагаев  added the comment:

ping @tim.peters

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Марат Нагаев]

Марат Нагаев  added the comment:

Can I implement this methods?
@tim.peters

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Fredrik Johansson]

Fredrik Johansson  added the comment:

I can think of two reasons to extend floor() and ceil() to complex numbers, and 
they lead to different extensions.

The first is as a way to map complex numbers to nearby Gaussian integers by 
defining floor(z) = floor(z.real) + floor(z.imag)*1j, etc. Definition in mpmath 
borrowed from Mathematica. Conceivably handy for data quantization, or discrete 
plane geometry... but I honestly never used it myself and can't remember ever 
seeing it used.

The second is to extend piecewise analytic functions on R to piecewise 
holomorphic functions on C so that the real analytic segments extend to complex 
analytic neighborhoods, most easily achieved by defining floor(z) = 
floor(z.real). This one I've actually had use for (think complex step 
differentiation, contour integration), but it's a bit esoteric.

My opinion? If a Python user calls floor() and ceil() with a complex input, 
it's probably because of a bug in their code, and TypeError is appropriate. 
It's a one-line lambda to define your own complex extension if you really need 
it.

On the other hand: if it exists, someone will eventually find a way to use it 
for code golf ;-)

--
nosy: +fredrikj

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Tim Peters]

Tim Peters  added the comment:

I have no use for this either, and agree with rejecting it - in nearly 30 
years, nobody has asked for this before, and it's still the case that we don't 
have an actual programming use case (some theoretical use in an abstract 
mathematical model isn't a programming use case).  Seems far more likely that 
someone applying floor() or ceil() to a complex number is confused.

math.tau was essentially useless too, but Guido wanted to add it mostly as a 
light-hearted inside joke:

https://bugs.python.org/issue12345

Against that, I see that the popular mpmath Python package does support it (for 
floor and ceil).  Perhaps you could get mpmath's author to chime in here with a 
"good" argument for adding it to the core language?

http://mpmath.org/doc/current/general.html#floor

"""
The floor function is defined for complex numbers and acts on the real and 
imaginary parts separately:

>>> floor(3.25+4.75j)
mpc(real='3.0', imag='4.0')
"""

--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Марат Нагаев]

Марат Нагаев  added the comment:

I think at bank.
I find post (Russian) about complex numbers:
https://cyberleninka.ru/article/v/primenenie-kompleksnyh-chisel-v-finansovyh-operatsiyah
And rounding was used.
Sorry, I don't know about English version of this article.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Mark Dickinson]

Mark Dickinson  added the comment:

> Maybe the best solution is to add functions floor and ceil to cmath module

You say "solution", but what problem would this be a solution to? So far, I 
don't think there's a demonstrated need to have this functionality. What is it 
useful for?

So IMO, the best solution is to make no change: there isn't an actual problem 
to be solved here. :-)

Again: what's the use-case?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Марат Нагаев]

Марат Нагаев  added the comment:

>For those rare cases where this is needed, it isn't that hard to spell out 
>`complex(floor(z.real)
But in Python we have math.tau. However it's just 2*pi.
>`math.floor` of a `float` object returns an `int`
Maybe the best solution is to add functions floor and ceil to cmath module and 
edit floor and ceil function (in case passing complex argument these function 
could raise TypeError)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Mark Dickinson]

Mark Dickinson  added the comment:

> So I suggest:
> 1. Methods __floor__ and __ceil__ for complex object.

What's the use-case for these? It's not a particularly natural operation, and 
I've never had a need for a complex "floor" operation, either as a 
mathematician or as a developer. Do you have an example of real-world code that 
would benefit?

For those rare cases where this is needed, it isn't that hard to spell out 
`complex(floor(z.real), floor(z.imag))`, or to write a custom `complex_floor` 
function.

Also, what type should `math.floor` return when applied to a complex number? 
`math.floor` of a `float` object returns an `int`, so the analogous operation 
on a complex number should return a Gaussian integer. But we don't have a 
Gaussian integer type in standard Python, and it wouldn't be appropriate to add 
one.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Марат Нагаев]

Марат Нагаев  added the comment:

Oh, __floor__ can return anything.
So I suggest:
1. Methods __floor__ and __ceil__ for complex object.
2. Don't change __float__ and __int__ methods.
3. So I think it isn't nessesary to add methods floor and ceil to complex 
module.
Example:
from math import *
z=1.1+1.1j
floor(z) #1+1j, same as z.__floor__()
ceil(z) #2+2j, samse as z.__ceil__()

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Марат Нагаев]

Марат Нагаев  added the comment:

I think math.floor should raise TypeError if complex argument passed,
but we need cmath.floor(and ceil).
As I know floor complex number is just floor real part and floor imag.
Example:
z=1.1+2.5j
floor(z) #2+3j
I think it's correct.
But I don't know about complex to float and to int.
Maybe you are right

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Mark Dickinson]

Mark Dickinson  added the comment:

Agreed with the closure.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Zachary Ware]

Zachary Ware  added the comment:

Agreed with Josh and closing the issue as rejected.  I'm adding our math 
experts just in case they disagree or want to provide further clarity.

--
components: +Interpreter Core -Extension Modules, Library (Lib)
nosy: +lemburg, mark.dickinson, rhettinger, stutzbach, zach.ware
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36228] Support coercion of complex to float/int

[Josh Rosenberg]

Change by Josh Rosenberg :


--
title: Add function to complex object -> Support coercion of complex to 
float/int

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com