-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
PEP 791: imath --- module for integer-specific mathematics functions #4422
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
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
| ------------------------------------ | ||
|
|
||
| Unless we can just provide bindings to some well supported mathematical library | ||
| like the GMP, the module scope should be limited. For example, no primality |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not exclude this. Primality testing was in the original proposition for imath, and I would need it more than perm() or isqrt().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's in "Open Issues". I think we can make list more exhaustive later.
The idea is to put some rough boundary between possible content of the module and something, that not belongs to it. I'm with @pfmoore (from the 2018 thread) and think that primaility testing and factorization is outside of the stdlib scope. (Unless we will not support implementation.) Do you have a better candidate to replace that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the scope is "number theory", then you are already saying that it's in scope. Why not just leave these questions to future PEPs and not worry about it here? Is imath going to be rejected because primality testing could be added?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm with @pfmoore (from the 2018 thread) and think that primaility testing and factorization is outside of the stdlib scope.
Actually, in that thread I supported isprime and factors. What I was against was an inefficient implementation. I don't think they necessarily have to be "best of breed" implementations (although I wouldn't object!) but I would want them to be good enough to be used in non-specialist code.
I quite often come up against problems where these functions would be useful. Not in production code (typically in "solve a puzzle in the REPL" types of situation), but certainly real life cases.
As I said elsewhere, though, I think we should keep the scope small for now. Adding functions later is fine, let's not risk the PEP failing over an argument about what's the "best" prime testing algorithm...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's close to what I meant; I did update for this section. I used "production" word, maybe it's not the best. But I think it fits "being used in real life cases" scenario, e.g. by non-professionals.
let's not risk the PEP failing over an argument about what's the "best" prime testing algorithm...
Do you think we shouldn't discuss possible extensions for the module and just restrict our attention to existing functions?
Co-authored-by: Victor Stinner <vstinner@python.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to rename the module to "intmath" because there are already two "imath" projects, and it seems like "imath" name is more confusing than intmath: https://mail.python.org/archives/list/python-ideas@python.org/message/JV5HYIYIHAG6PQA2RXX6NCVTCNHM7IXY/
Ok, let's start with this. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
Thanks for making the grammar changes! LGTM |
|
@NeilGirdhar, would you like to be added as co-author? |
|
@skirpichev If you feel my contributions have been valuable, then happily yes, but I'll leave it up to you. No hard feelings either way 😄 |
|
Minor observation from an (ex) number theorist: "number-theoretic" feels too specific here. E.g., I'd think of For me, the characterising properties of these functions are that (a) they typically accept and return integers, (b) they have zero dependence on the platform floating-point format or behaviour, and zero dependence on the platform math library ("libm"). So unlike most of the functions in |
@tim-one, the abstract highlight restrictions to both co-domain and domain:
BTW, are you ok with title suggestion: "imath --- module for integer-specific mathematics functions"? |
@hugovk, added. |
Co-authored-by: Mikhail Efimov <efimov.mikhail@gmail.com>
And I'm saying it should not. The co-domain is irrelevant to the standard meaning of "number-theoretic function". That they're restricted to the domain of integers is the whole banana. I don't want us to box ourselves into a corner with needless restrictions. Why do it? It just so happens that most such functions in common use (and all those Python has implemented so far) return ints. The von Mangoldt function, and the n'th harmonic number. were already given as examples of number-theoretic functions that don't return ints. I'm not saying we should add them, but am saying whatever is written now should not preclude the possibility. |
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Sure, but Mark suggested above something like a strict reproducibility ("deterministic and portable"). I doubt this is possible, if co-domain will be something more generic than integers/rationals or algebraic numbers (and already this case seems to be "too much for the stdlib"). I.e. that essentially excludes floating-point math.
The pros of this seems rather hypothetical: can we have a good candidate for the sidlib right now? While cons is obvious: we can't say anymore that output should be platform-independent (and implementation-independent). I think we can later relax this requirement in case of real need, i.e. specify in docs "All return values are integers, except when explicitly noted otherwise." |
|
Well, can only say I'm baffled by why you want to handcuff future generations before the module even exists 😉. The harmonic numbers, for example, are rationals, and there are far more efficient ways to compute them exactly than via the naïve summation loop (much as there are far more efficient ways to compute factorial than naïve use of I don't want to burn time arguing about specific functions now. I want the PEP & the docs not to create needless obstacles to whatever the future may bring. |
@tim-one, I worry that removing this obstacle will smash also much more useful constraint, noted by Mark. What do you think about such version of the abstract (small rewrite of this suggestion):
? |
|
I like that fine! But suggest dropping the ", following arithmetic rules ..." part. "Exact" already meant exact. and doesn't really benefit from elaboration. Maybe just: |
Ok, done with a minor tone change (can -> must). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a great improvement over the first draft! And I know it's exhausting when you're getting so many people pushing you.
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
Co-authored-by: Neil Girdhar <mistersheik@gmail.com>
|
@skirpichev: So what do you think of renaming the module to intmath to avoid confusion and conflicts with existing projects? |
@vstinner, I think this should be postponed to final decision about naming. I.e. we can do this right now if either
Else this can introduce extra work for the implementation pr. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Basic requirements (all PEP Types)
pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) andPEPheaderAuthororSponsor, and formally confirmed their approval // @vstinner at https://discuss.python.org/t/91337/47Author,Status(Draft),TypeandCreatedheaders filled out correctlyPEP-Delegate,Topic,RequiresandReplacesheaders completed if appropriate.github/CODEOWNERSfor the PEPStandards Track requirements
Python-Versionset to valid (pre-beta) future Python version, if relevantDiscussions-ToandPost-History📚 Documentation preview 📚: https://pep-previews--4422.org.readthedocs.build/pep-0791/