Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we add "i" as a suffix for imaginary numbers (while keeping "j" also)? #92938

Open
gvanrossum opened this issue May 19, 2022 · 5 comments
Open
Labels
type-feature

Comments

@gvanrossum
Copy link
Member

@gvanrossum gvanrossum commented May 19, 2022

See https://stackoverflow.com/questions/24812444/why-are-complex-numbers-in-python-denoted-with-j-instead-of-i

Why couldn't we support both 1j and 1i with equivalent meanings?

@gvanrossum gvanrossum added the type-feature label May 19, 2022
@serhiy-storchaka
Copy link
Member

@serhiy-storchaka serhiy-storchaka commented May 19, 2022

Isn't it a duplicate of #54771? 😉

@gvanrossum
Copy link
Member Author

@gvanrossum gvanrossum commented May 19, 2022

10+ years later we can change our mind. Of course we should keep 'j' as well -- no deprecation.

@serhiy-storchaka
Copy link
Member

@serhiy-storchaka serhiy-storchaka commented May 19, 2022

Agree, things are changing and some arguments against this are not so strong now.

I prefer i over j, but before reading the StackOverflow answers my thought were:

  1. It can be confused with digit 1. In Python 2 it could also be confused with suffix l (which almost nobody used in the lowercase form due to confusion with 1).
  2. The output will be with j in any case. This may confuse beginners.
  3. We may reserve this suffix for something different in future. Unlikely, but there were talks about the i prefix for strings.
  4. It will complicate the parser. There are already problems with else after decimal integer, or after 0, for after hexadecimal integer. It will add problems with if and in after decimal integer. A warning is emitted now in such potentially confusing cases (#87999), thing may be slightly simpler after making it an error in future versions. There are no current plans to make it an error.

They are not very strong arguments, but on other hand, supporting the i suffix will brought not much benefit either.

@stevendaprano
Copy link
Member

@stevendaprano stevendaprano commented May 19, 2022

Is there a specific reason why you are considering changing your mind now? Has something changed since that SO question was asked seven years ago, or last answered two years ago?

"Python uses the engineering convention for complex numbers rather than the maths convention" is a perfectly valid reason to stick with j. Back in the Python 1,5 days I was annoyed that Python used j rather than i, but I got used to it, and I see no strong benefit to adding a second way to write complex literals.

Although in support of this suggestion Coconut allows i as an alternative syntax.

If we allowed i, there will surely be people who write numbers like 1I and that's just going to be awful, so maybe we shouldn't tempt them?

I think that short of setting the ground work to eventually add quaternion literals 1+2i+3j+4k I kinda feel that this is churn for no real benefit. But I don't object to it.

@gvanrossum
Copy link
Member Author

@gvanrossum gvanrossum commented May 19, 2022

I was reminded of this by a privat document I read recently and regretted the choice of j. IIUC it’s only a small subcommunity (electrical engineering, where complex numbers represent A/C currents with phase) that really prefers j. In high school and college math(s) they teach i. I read on StackOverflow that C++ will get i. I figured I’d at least test the waters to see if there’s appetite for this now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-feature
Projects
None yet
Development

No branches or pull requests

3 participants