[Python-ideas] Re: Make 10**400 / 1e200 work?
On Saturday, February 19, 2022, Stefan Pochmann
wrote:
> >>> 1e200.is_integer()
> True
>
> So that could losslessly be converted to int, and then the division would
> succeed
If the float argument isn't an integer, you can multiply both sides by a
power of 2 that makes it one (if it's finite, obviously), so this would
still work.
Currently, int/int and float/float are always properly rounded. It would be
nice if you could just say that a/b is properly rounded whenever a and b
are int or float, and forget about conversion issues. So I'm +1 on this.
It would make certain divisions more expensive than they currently are, but
only those where one argument is float and the other is an int that isn't
exactly representable as a float (meaning, in particular, its absolute
value is greater than 2**53). It seems unlikely to me that anyone is doing
a lot of divisions of that kind and needs the speed, but if they are and
do, casting to float beforehand is an easy workaround.
Also, 10**400/float('inf') should return +0.0 instead of raising
OverflowError, and 10**400/float('nan') should be NaN. The division should
behave as though both arguments are promoted to arbitrary-precision
floating point (but the result is rounded to 64-bit float). I wouldn't
suggest that if it was hard to implement, but I think it's pretty easy
when long_true_divide already exists.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/6GP4CN6DGNJ4WCYOPYE7BXDAL5NFDREH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using "Get Satisfaction" for Python Suggestions
On Sat, Feb 19, 2022 at 06:04:28AM +1100, Chris Angelico wrote: > Popularity is a *terrible* way to judge ideas. I'm currently fighting > with another platform on that same topic. Can we ask which platform? > All you can see from a system like that is how many of the popular > ideas get implemented. It says nothing about how many good ideas end > up languishing with a small number of votes, simply because they never > reach critical mass and not enough people see them. Rather like the way we tell people to publish on PyPI and see if it becomes popular. > Does GetSatisfaction allow downvotes? If yes: how do you stop a vocal > few from shooting down any idea they don't like? Nothing like Python-Ideas then :-) Typically voting systems only allow logged-in users to vote, and you can only vote once. You can change your vote at any time, but a vocal few is limited to only downvoting once each, they can't vote a thousand times each and overwhelm the popular voice. Same applies to up-voting. > There is no way to make a popular vote fair. That's an odd take. A better take is that, fair or not, popularity is not necessarily a good judge of what works well in a language. Language design requires skill and taste, and it is not obvious that the wisdom of the crowd extends that far. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VZFR5D34AV4SMYRTMANWPMRYGYOZEXCO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using "Get Satisfaction" for Python Suggestions
Democracy has its pros and cons. ...RM On Fri, Feb 18, 2022 at 10:57 AM Samuel Muldoon wrote: > *The python-ideas mailing list is a very cumbersome way to vet changes to > the Python interpreter or other aspects of the python language. If the > power-that-be would work with GetSatisfaction people to make a copy-cat of > the GetSatisfaction page for Minecraft, I think that the python community > could then better drive PEPs (Python Enhancement Proposals)* > -- Richard Mateosian Berkeley, California ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BKDK5SMCP3ZN25RATUBZ35LDR5JXXGUN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
[Tim] >> int.__truediv__ makes semi-heroic efforts to >> get 10**400 / int(1e200) "right" (well, as right as can be) [Stefan Pochmann ] > Yes, those semi-heroic efforts actually are what inspired my > question. A few days ago I noticed that and was delighted it works. > > Use case was the exact calculation of value around 8, for which > I used fractions.Fraction. Numerator and denominator were large, but > the division numerator/denominator still successfully provided a > readable and right-as-can-be float. > > So yes, even I who brought this up only noticed *that* semi-heroism > after years of using Python, I was similarly surprised that a Fraction instance with giant numerator and denominator converted to a float beautifully. That wasn't always so in Python .> and don't have an actual use case for the int-and-float division. The int/int > one just gave me the impression that Python is trying hard to give me > results when possible, so I wondered about this case. I believe there's something deeper at work with int / int: Python has long said that numeric values that compare equal have the same hash code, and can be used interchangeably as, e.g., dict keys. But if we're going to say that some Fraction f "is equal" to some float `x`,then surely Fraction(x) == f and float(f) == x should be true too. That's of real practical value, because it simplifies reasoning about code mixing floats and Fractions (and Decimals). I believe that's what drove int.__truediv__'s heroism: a desire to support that high-level promise about Python's numerics. BTW, the promise that numeric values that compare equal have the same hash code, regardless of type, is a tricky thing to support. Mark Dickinson nailed it :-) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZROOR4XNHYYPCRFECSJSBPVLCBMEQ3EN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Requirements.txt inside virtual environment
On Sat, Feb 19, 2022 at 10:17:58AM +, Paul Moore wrote: > On Fri, 18 Feb 2022 at 23:53, Steven D'Aprano wrote: > > When pip resolves dependencies, it does it in the simplest possible way > > that *usually* works. It has no satisfiability solver. [...] > This is no longer true - pip incorporated a proper dependency resolver in > 2020. Good to know! Thanks. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/J37ZAVRS77II2DM57X5YCFZNVGV2CTH5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
Tim Peters wrote: > int.__truediv__ makes semi-heroic efforts to > get 10**400 / int(1e200) "right" (well, as right as can be) Yes, those semi-heroic efforts actually are what inspired my question. A few days ago I noticed that and was delighted it works. Use case was the exact calculation of value around 8, for which I used fractions.Fraction. Numerator and denominator were large, but the division numerator/denominator still successfully provided a readable and right-as-can-be float. So yes, even I who brought this up only noticed *that* semi-heroism after years of using Python, and don't have an actual use case for the int-and-float division. The int/int one just gave me the impression that Python is trying hard to give me results when possible, so I wondered about this case. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XQXLUS2BLYQ5JYS4T2EJMU3BGD6CS62M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
Christopher Barker wrote: > On Sat, Feb 19, 2022 at 6:31 AM Damian Shaw damian.peter.s...@gmail.com > wrote: > > That sounds like a lot of extra checks to put on "/" > > This isn’t about the division — it’s about the literal. No, it's about the division. Not about the literal. Sorry I was unclear. I don't want 1e200 to become an int, I meant the division could be as "semi-heroic" (as Tim put it) as the int/int division. That is, when it notices the overflow, instead of just raising the error it could check whether the float is an integer and provide the result that way. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UYT3CJSSWKKPRULRTJF2B5CII4NCNIE2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
[Stefan Pochmann ] > It crashes because it tries to convert 10**400 to a float and that fails: > > >>> 10**400 / 1e200 > Traceback (most recent call last): > File "", line 1, in > 10**400 / 1e200 > OverflowError: int too large to convert to float > > But with two ints it succeeds: > > >>> 10**400 / 10**200 > 1e+200 Simlalary for 1e200 / 10**400. That is, it doesn't matter to this whether int.__truediv__ or float.__truediv__ is invoked. If the types are mixed, the operands are coerced to float first. > Note that 1e200 is an integer: > > >>> 1e200.is_integer() > True > > So that could losslessly be converted to int, and then the division would > succeed: > > >>> 10**400 / int(1e200) > 1e+200 > > So could/should 10**400 / 1e200 be implemented to do that instead of > raising the error? It could. But I don't think it "should". > Or is it a too rare use case and not worth the effort, or does > something else speak against it? Too rare, and expensive. int.__truediv__ makes semi-heroic efforts to get 10**400 / int(1e200) "right" (well, as right as can be), and that's expensive, and probably more surprising than not.for most users. For example, >>> int(1e200) 6973312221251036165947450327545502362648241750950346848435554075534196338404706251868027512415973882408182135734368278484639385041047239877871023591066789981811181813306167128854888448 is, all on its own, probably more surprising than not for most users. It's not to me (or presumably to you), but I have no use for Python magically converting a float to int. It doesn't in other contexts either: [1, 2, 3][2.0] Traceback (most recent call last): ... TypeError: list indices must be integers or slices, not float In purely computational contexts, "when an inf and a float are mixed, the int is converted to a float first" is a simple, predictable,and reliable rule: >>> pow(10**400, 0.5) Traceback (most recent call last): ,,, OverflowError: int too large to convert to float In practice, over decades I've seen that kind of exception only a handful of times, and it always pointed to a logical error in my code. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FA6UQS3F6ITIKI7WUYRYZ4DP65WWEKED/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
On Sun, 20 Feb 2022 at 06:50, Christopher Barker wrote: > > On Sat, Feb 19, 2022 at 6:31 AM Damian Shaw > wrote: >> >> That sounds like a lot of extra checks to put on "/" > > > This isn’t about the division — it’s about the literal. The “e” notation > makes a float. And floats have fixed precision. > > Python could try to be smart and create an integer for e notation that > happens to be an integer value, but I really don’t see the utility in that. > > The other “Solution” would be for Python to adopt unlimited precision floats. > A major change. > Currently, ints will automatically upcast to floats as needed. In theory, any float greater than 1<<52 (on IEEE 64-bit floats) could be losslessly upcast to integer the same way. I don't think the value would justify the uncertainty of type conversions, though - float(x) + int(y) could be either int or float depending on the values given. IMO the only way to justify this kind of flip-flop casting would be for the Python data type to simply be "number", and then it's internally implemented in whichever way makes sense - and that would be an even bigger change than unlimited-precision floats. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NRJISHF5MDEWS524CEOJZ6IL6N3CNDCQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
On Sat, Feb 19, 2022 at 6:31 AM Damian Shaw wrote: > That sounds like a lot of extra checks to put on "/" > This isn’t about the division — it’s about the literal. The “e” notation makes a float. And floats have fixed precision. Python could try to be smart and create an integer for e notation that happens to be an integer value, but I really don’t see the utility in that. The other “Solution” would be for Python to adopt unlimited precision floats. A major change. -CHB when the error message is clear and the user could implement their own > checks if they are running into this niche use case and do 10**400 / > int(1e200). > > Damian (he/him) > > On Sat, Feb 19, 2022 at 8:36 AM Stefan Pochmann > wrote: > >> It crashes because it tries to convert 10**400 to a float and that fails: >> >> >>> 10**400 / 1e200 >> Traceback (most recent call last): >> File "", line 1, in >> 10**400 / 1e200 >> OverflowError: int too large to convert to float >> >> But with two ints it succeeds: >> >> >>> 10**400 / 10**200 >> 1e+200 >> >> Note that 1e200 is an integer: >> >> >>> 1e200.is_integer() >> True >> >> So that could losslessly be converted to int, and then the division would >> succeed: >> >> >>> 10**400 / int(1e200) >> 1e+200 >> >> So could/should 10**400 / 1e200 be implemented to do that instead of >> raising the error? Or is it a too rare use case and not worth the effort, >> or does something else speak against it? >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/O7FE5AAWPA77QRQPKJVT6AB3XK7QPUZG/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/LBNH5IOG2LI6TU5IVCFI76GPPOLV4ZZF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ODU43U3C3DTJPW36RZ3FHXCSEQGDGCBW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Irrelevant venv? [was: Requirements.txt inside virtual environment]
On Sat, Feb 19, 2022 at 04:14:57PM +0900, Stephen J. Turnbull wrote: > Steven D'Aprano writes: > > > by the time you have finished debugging the script, the reason for > > creating the venv in the first place is no longer relevent. > > Eh? Would you be willing to unpack that reference to 'venv' > specifically, or was that just your patent-pending snark? I can't > recall a venv being obviated by later developments, You have never created a venv and then later decided that it wasn't needed because the project was cancelled, the job fell through, somebody solved the problem in another way, your client changed the project specifications and you deleted the old venv and created a new one, you decided to work on something else instead, the company went bust, etc? Lucky you. For a mailing list community that loves to be hyper-skeptical about the usefulness of 90% of ideas proposed here, we sure are touchy about any suggestion that pip and venvs aren't the greatest tools ever made. Here's a hint for the future. When I follow a comment with a smiley emoticon or emoji, or *wink*, it means that my comment isn't intended to be taken too seriously. It's a bit of light-hearted banter. And there's at least a 50% chance that it is intended to be self-mocking, or at least affectionate teasing of the tropes and memes that are common in programming circles, such as the "Three Strikes Rule". http://wiki.c2.com/?ThreeStrikesAndYouAutomate especially the tendency to spend more time automating a task than will ever be saved by the automation. Even XKCD has joked about that. https://xkcd.com/1319/ -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OFCA37W4N7Z3X6LKIL3V3DA7G6LA2G63/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
That sounds like a lot of extra checks to put on "/" when the error message is clear and the user could implement their own checks if they are running into this niche use case and do 10**400 / int(1e200). Damian (he/him) On Sat, Feb 19, 2022 at 8:36 AM Stefan Pochmann wrote: > It crashes because it tries to convert 10**400 to a float and that fails: > > >>> 10**400 / 1e200 > Traceback (most recent call last): > File "", line 1, in > 10**400 / 1e200 > OverflowError: int too large to convert to float > > But with two ints it succeeds: > > >>> 10**400 / 10**200 > 1e+200 > > Note that 1e200 is an integer: > > >>> 1e200.is_integer() > True > > So that could losslessly be converted to int, and then the division would > succeed: > > >>> 10**400 / int(1e200) > 1e+200 > > So could/should 10**400 / 1e200 be implemented to do that instead of > raising the error? Or is it a too rare use case and not worth the effort, > or does something else speak against it? > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/O7FE5AAWPA77QRQPKJVT6AB3XK7QPUZG/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LBNH5IOG2LI6TU5IVCFI76GPPOLV4ZZF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Make 10**400 / 1e200 work?
It crashes because it tries to convert 10**400 to a float and that fails: >>> 10**400 / 1e200 Traceback (most recent call last): File "", line 1, in 10**400 / 1e200 OverflowError: int too large to convert to float But with two ints it succeeds: >>> 10**400 / 10**200 1e+200 Note that 1e200 is an integer: >>> 1e200.is_integer() True So that could losslessly be converted to int, and then the division would succeed: >>> 10**400 / int(1e200) 1e+200 So could/should 10**400 / 1e200 be implemented to do that instead of raising the error? Or is it a too rare use case and not worth the effort, or does something else speak against it? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/O7FE5AAWPA77QRQPKJVT6AB3XK7QPUZG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Requirements.txt inside virtual environment
On Fri, 18 Feb 2022 at 23:53, Steven D'Aprano wrote: > When pip resolves dependencies, it does it in the simplest possible way > that *usually* works. It has no satisfiability solver. > > "No effort is made to ensure that the dependencies of all packages are > fulfilled simultaneously. This can lead to environments that are broken > in subtle ways, if packages installed earlier in the order have > incompatible dependency versions relative to packages installed later in > the order." > > https://www.anaconda.com/blog/understanding-conda-and-pip This is no longer true - pip incorporated a proper dependency resolver in 2020. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RL4UQMN2E7XZHY45AKOJ7XZNZEWSRM7O/ Code of Conduct: http://python.org/psf/codeofconduct/
