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> wrote:
>
> SymPy ComplexInfinity, 1/0 < 2/0, *tests* for symbolic results
>
> FWIW, SymPy (a CAS: Computer Algebra System) has Infinity,
NegativeInfinity, 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 +∞ as
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 always
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> wrote:
> SymPy ComplexInfinity, 1/0 < 2/0, *tests* for symbolic results
>
> FWIW, SymPy (a CAS: Computer Algebra System) has Infinity,
> NegativeInfinity, 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 different
> outputs for the above problem (most just disregard the scalar because 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 those you
>> note.
>>
>> It would be a breaking change, but I'd really vastly prefer if almost all
>> of those OverflowErrors and others were simply infinities. 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 exceptions
>> 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 certain 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 following
>>> IEEE 754.
>>>
>>> I agree, but Python doesn't. It raises on some infs (generally
>>>> speaking, true infinities), and returns inf on others (generally
>>>> 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: intermediate
>>> overflow in fsum"
>>>
>>> * float('1e999') returns inf
>>>
>>> * float.fromhex('1p1024') raises "OverflowError: hexadecimal value too
>>> large to represent as a float"
>>>
>>> I get the impression that little planning has gone into this. There's no
>>> consistency in the OverflowError messages. 1./0. raises ZeroDivisionError
>>> which isn't a subclass of OverflowError. lgamma(0) raises a ValueError,
>>> which isn't even a subclass of ArithmeticError. 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 ought to raise ZeroDivisionError, which should obviously be a
>>> subclass of OverflowError.
>>>
>>> Because of the inconsistent handling of overflow, many functions 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.98846567431158e+307.
>>>
>>> 1./0. is not a true infinity. It's the reciprocal of a number that 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/python-ideas@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-ideas@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/JQPNUQXELOYKP25XJ77SX3TVVG24QS72/
Code of Conduct: http://python.org/psf/codeofconduct/
