Can you explain why Python should behave differently than other languages? Python: >>> math.inf == 2 * math.inf True
JavaScript: > Infinity == 2 * Infinity true Wolfram Alpha: https://www.wolframalpha.com/input/?i=inf+%3D+2+*+inf+%3D+3+*+inf ∞ = 2∞ = 3∞ True On Sun, 2020-10-11 at 17:39 -0400, Wes Turner wrote: No, 2 times something is greater than something. Something over somethi ng is 1. If we change the division axiom to be piecewise with an exception only for infinity, we could claim that any problem involving division of a s ymbol is unsolvable because the symbol could be infinity. This is incorrect: x / 2 is unsolvable because x could be infinity x / 2 > x / 3 (where x > 0; Z+) is indeterminate because if x is infini ty, then they are equal. assert 1 / 0 != 2 / 0 assert 2*inf > inf assert inf / inf == 1 I should have said capricious (not specious). I'm again replying to the main thread because this is relevant: there would need to be changes t o tests in order to return (scalar times) infinity instead of ZeroDivis ionError. We should not discard the scalar in scalar*infinity expressions. On Sun, Oct 11, 2020, 5:18 PM Chris Angelico <ros...@gmail.com> wrote: > On Mon, Oct 12, 2020 at 8:07 AM Wes Turner <wes.tur...@gmail.com> wro > te: > > > > So you're arguing that the scalar is irrelevant? > > That `2*inf == inf`? > > > > I disagree because: > > ```2*inf > inf``` > > On what basis? If you start by assuming that infinity is a number, > then sure, you're going to deduce that double it must be a greater > number. But you're just concluding your own assumption, not proving > anything. > > > And: > > > > ```# Given that: > > inf / inf = 1 > > Is that the case? > > >>> from math import inf > >>> inf / inf > nan > > > # When we solve for symbol x: > > 2*inf*x = inf > > 2*x = 1 > > x = 1/2 > > > > # If we discard the scalar instead: > > 2*inf*x = inf > > inf*x = inf > > x = 1 > > > > # I think it's specious to argue that there are infinity solutions > ; that axioms of symbolic mathematics do not apply because infinity > > ``` > > Once again, you start by assuming that infinity is a number, and that > > you can divide by it (which is what happens when you "solve for x" by > > removing the infinities). You can't prove something by first assuming > > it. > > "Infinity" isn't a number. In the IEEE 754 system, it is a value, but > > it's still not a number (although it's distinct from Not A Number, > just to confuse everyone). In mathematics, it's definitely not an > actual number or value. > > ChrisA > ______________________________ On Sun, Oct 11, 2020 at 5:04 PM Wes Turner <wes.tur...@gmail.com> wrote : > So you're arguing that the scalar is irrelevant?That `2*inf == inf`? > > I disagree because: > ```2*inf > inf``` > And: > > ```# Given that: > inf / inf = 1 > > # When we solve for symbol x: > 2*inf*x = inf > 2*x = 1 > x = 1/2 > > # If we discard the scalar instead: > 2*inf*x = inf > inf*x = inf > x = 1 > > # I think it's specious to argue that there are infinity solutions; > > > that axioms of symbolic mathematics do not apply because infinity > ``` > > This is relevant to the (now- > forked) main thread if the plan is to return inf/- > inf/+inf instead of raising ZeroDivisionError; so I'm replying to the > > > main thread. > > On Sun, Oct 11, 2020, 4:10 PM Chris Angelico <ros...@gmail.com> wrote > > > : > On Mon, Oct 12, 2020 at 5:06 AM Wes Turner <wes.tur...@gmail.com> wro > > > te: > > > > SymPy ComplexInfinity, 1/0 < 2/0, *tests* for symbolic results > > > > FWIW, SymPy (a CAS: Computer Algebra System) has Infinity, Negative > > > Infinity, ComplexInfinity. > > > > Regarding a symbolic result for 1/0: > > > > If 1/0 is infinity (because 0 goes into 1 infinity times), > > is 2/0 2*inifnity (because 0 goes into 2 2 times more than into 1) > > > > If you try to treat "infinity" as an actual number, you're inevitably > > > > going to run into paradoxes. Consider instead: 1/x tends towards +∞ a > > > s > x tends towards 0 (if x starts out positive), therefore we consider > that 1/0 is +∞. By that logic, the limit of 2/0 is the exact same > thing. It's still not a perfect system, and division by zero is alway > > > s > going to cause problems, but it's far less paradoxical if you don't > try to treat 2/0 as different from 1/0 :) > > BTW, you're technically correct, in that 2/0 would be the same as 2 * > > > > (whatever 1/0 is), but that's because 2*x tends towards +∞ as x tends > > > > towards +∞, meaning that 2*∞ is also ∞. > > ChrisA > > On Sun, Oct 11, 2020 at 2:03 PM Wes Turner <wes.tur...@gmail.com> wro > > te: > > SymPy ComplexInfinity, 1/0 < 2/0, *tests* for symbolic results > > > > FWIW, SymPy (a CAS: Computer Algebra System) has Infinity, Negative > > > Infinity, ComplexInfinity. > > Regarding a symbolic result for 1/0: > > > > If 1/0 is infinity (because 0 goes into 1 infinity times), > > is 2/0 2*inifnity (because 0 goes into 2 2 times more than into 1) > > > > A proper CAS really is advisable. FWIU, different CAS have differen > > > > > t outputs for the above problem (most just disregard the scalar bec > > > > > ause it's infinity so who care if that cancels out later). > > > > Where are the existing test cases for arithemetic calculations with > > > > > (scalar times) IEEE-754 int, +inf, or -inf as the output? > > > > On Tue, Sep 15, 2020 at 1:54 AM David Mertz <me...@gnosis.cx> wrote > > > > > : > > > Thanks so much Ben for documenting all these examples. I've been > > > > > > > > > frustrated by the inconsistencies, but hasn't realized all of tho > > > > > > > > > se you note. > > > > > > It would be a breaking change, but I'd really vastly prefer if al > > > > > > > > > most all of those OverflowErrors and others were simply infinitie > > > > > > > > > s. That's much closer to the spirit of IEEE-754. > > > > > > The tricky case is 1./0. Division is such an ordinary operation, > > > > > > > > > and it's so easy to get zero in a variable accidentally. That one > > > > > > > > > still feels like an exception, but yes 1/1e-323 vs. 1/1e- > > > 324 would them remain a sore spot. > > > > > > Likewise, a bunch of operations really should be NaN that are exc > > > > > > > > > eptions now. > > > > > > On Mon, Sep 14, 2020, 5:26 PM Ben Rudiak- > > > Gould <benrud...@gmail.com> wrote: > > > > On Mon, Sep 14, 2020 at 9:36 AM Stephen J. Turnbull <turnbull. > > > > stephen...@u.tsukuba.ac.jp> wrote: > > > > > Christopher Barker writes: > > > > > > IEEE 754 is a very practical standard -- > > > > > it was well designed, and is > > > > > > widely used and successful. It is not perfect, and in cert > > > > > > > > > > > > > > > > > > > > > > > > > ain use cases, it > > > > > > may not be the best choice. But it's a really good idea to > > > > > > > > > > > > > > > > > > > > > > > > > keep to that > > > > > > standard by default. > > > > > > > > > > > > > I feel the same way; I really wish Python was better about foll > > > > > > > > > > > > > > > > > > > > > > > > owing IEEE 754. > > > > > > > > > I agree, but Python doesn't. It raises on some infs (general > > > > > > > > > > > > > > > > > > > > > > > > > ly > > > > > speaking, true infinities), and returns inf on others (genera > > > > > > > > > > > > > > > > > > > > > > > > > lly > > > > > speaking, overflows). > > > > > > > > > > > > > It seems to be very inconsistent. From testing just now: > > > > > > > > * math.lgamma(0) raises "ValueError: math domain error" > > > > > > > > * math.exp(1000) raises "OverflowError: math range error" > > > > > > > > * math.e ** 1000 raises "OverflowError: (34, 'Result too large' > > > > > > > > > > > > > > > > > > > > > > > > )" > > > > > > > > * (math.e ** 500) * (math.e ** 500) returns inf > > > > > > > > > > > > > > > > * sum([1e308, 1e308]) returns inf > > > > > > > > * math.fsum([1e308, 1e308]) raises "OverflowError: intermediate > > > > > > > > > > > > > > > > > > > > > > > > overflow in fsum" > > > > > > > > * math.fsum([1e308, inf, 1e308]) returns inf > > > > > > > > > > > > * math.fsum([inf, 1e308, 1e308]) raises "OverflowError: interme > > > > > > > > > > > > > > > > > > > > > > > > > > > > diate overflow in fsum" > > > > > > > > > > > > > > > > * float('1e999') returns inf > > > > > > > > * float.fromhex('1p1024') raises "OverflowError: hexadecimal va > > > > > > > > > > > > > > > > > > > > > > > > lue too large to represent as a float" > > > > > > > > I get the impression that little planning has gone into this. T > > > > > > > > > > > > > > > > > > > > > > > > here's no consistency in the OverflowError messages. 1./0. rais > > > > > > > > > > > > > > > > > > > > > > > > es ZeroDivisionError which isn't a subclass of OverflowError. l > > > > > > > > > > > > > > > > > > > > > > > > gamma(0) raises a ValueError, which isn't even a subclass of Ar > > > > > > > > > > > > > > > > > > > > > > > > ithmeticError. The function has a pole at 0 with a well- > > > > defined two- > > > > sided limit of +inf. If it isn't going to return +inf then it o > > > > > > > > > > > > > > > > > > > > > > > > ught to raise ZeroDivisionError, which should obviously be a su > > > > > > > > > > > > > > > > > > > > > > > > bclass of OverflowError. > > > > > > > > Because of the inconsistent handling of overflow, many function > > > > > > > > > > > > > > > > > > > > > > > > s aren't even monotonic. exp(2*x) returns a float for x <= 709. > > > > > > > > > > > > > > > > > > > > > > > > 782712893384, raises OverflowError for 709.782712893384 < x <= > > > > > > > > > > > > > > > > > > > > > > > > 8.98846567431158e+307, and returns a float for x > 8.9884656743 > > > > > > > > > > > > > > > > > > > > > > > > 1158e+307. > > > > > > > > 1./0. is not a true infinity. It's the reciprocal of a number t > > > > > > > > > > > > > > > > > > > > > > > > hat may have underflowed to zero. It's totally inconsistent to > > > > > > > > > > > > > > > > > > > > > > > > return inf for 1/1e-323 and raise an exception for 1/1e- > > > > 324, as Python does. > > > > > > > > _______________________________________________ > > > > 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/pyth > > > > on-id...@python.org/message/TXEZTNVIKJFEGPH535KYZ4B5KVNNGBZZ/ > > > > 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 > > > -id...@python.org/message/GLUX5WVRF3VBJTD3EBH5MCSRWBASJZOZ/ > > > 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/WFPPQ2R4Q74IW3XME5Q4LARXZRDYHKXL/ 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/TOJ6WBKOZRNK3GEYCJLGUXFGYH25UL34/ Code of Conduct: http://python.org/psf/codeofconduct/
