subject:"\[Python\-ideas\] Re\: 'Infinity' constant in Python"

Actually, where in the docs is it clarified which parts of IEEE-754 are
obeyed by Python?
Or where should this be clarified?

To my understanding (according to Wikipedia), IEEE-754 returns +- infinity
for DivideByZeroError and for FloatOverflow.

...

It's a rare use case; but one use case where this matters could be code
that is mutating and selecting (evolutionary algorithms) to evolve a
**symbolic** function. It could be documented that Python code could be so
permuted for infinity and never find the best fitting function due to this
limit.

A vectorizable CAS (with support for variable axioms in order to support
things like e.g. transfinite and surreal numbers) would be a better fit.

But that's way OT for (though likely an eventual tangential implication of)
this discussion of a **float, IEEE-754*** infinity constant; so I'll stop
talking now.

On Sun, Oct 18, 2020 at 12:28 PM Wes Turner  wrote:

> Thank you for the explanation. I have nothing more to add to this
> discussion
>
> On Sun, Oct 18, 2020, 4:47 AM Steven D'Aprano  wrote:
>
>> On Sun, Oct 18, 2020 at 03:26:11AM -0400, Wes Turner wrote:
>>
>> > assert math.inf**0 == 1
>> > assert math.inf**math.inf == math.inf
>>
>> Wes, I don't understand what point you are trying to make here. Are you
>> agreeing with that behaviour? Disagreeing? Thought it was so surprising
>> that you can't imagine why it happens? Something else?
>>
>> If you find a behaviour which is forbidden or contradicted by the
>> documentation, then you should report it as a bug, but just
>> demonstrating what the behaviour is with no context isn't helpful.
>>
>> Please remember that the things which are blindingly obvious to you
>> because you just thought them are not necessarily obvious to those of us
>> who aren't inside your head :-)
>>
>> Python's float INFs and NANs (mostly?) obey the rules of IEEE-754
>> arithmetic. Those rules are close to the rules for the extended Real
>> number line, with a point at both positive and negative infinity.
>>
>> These rules are not necessarily the same as the rules for transfinite
>> arithmetic, or the projective number line with a single infinity, or
>> arithmetic on cardinal numbers, or surreal numbers.
>>
>> Each of these number systems have related, but slightly different,
>> rules. For example, IEEE-754 has a single signed infinity and 2**INF is
>> exactly equal to INF. But in transfinite arithmetic, 2**INF is strictly
>> greater than INF (for every infinity):
>>
>> 2**aleph_0 < aleph_1
>> 2**aleph_1 < aleph_2
>> 2**aleph_2 < aleph_3
>>
>> and so on, with no limit. There is no greatest aleph, there is always a
>> larger one.
>>
>> Do you have a concrete suggestion you would like to make for a change or
>> new feature for Python? If not, I suggest that this thread is going
>> nowhere.
>>
>>
>> --
>> 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/U5WXW3WTNRNWV5PEADF6CDZC6FFBBUJG/
>> 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/ODANBEU6GW5A5SPEXPDL2ZLTY2QIFRLE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

Thank you for the explanation. I have nothing more to add to this discussion

On Sun, Oct 18, 2020, 4:47 AM Steven D'Aprano  wrote:

> On Sun, Oct 18, 2020 at 03:26:11AM -0400, Wes Turner wrote:
>
> > assert math.inf**0 == 1
> > assert math.inf**math.inf == math.inf
>
> Wes, I don't understand what point you are trying to make here. Are you
> agreeing with that behaviour? Disagreeing? Thought it was so surprising
> that you can't imagine why it happens? Something else?
>
> If you find a behaviour which is forbidden or contradicted by the
> documentation, then you should report it as a bug, but just
> demonstrating what the behaviour is with no context isn't helpful.
>
> Please remember that the things which are blindingly obvious to you
> because you just thought them are not necessarily obvious to those of us
> who aren't inside your head :-)
>
> Python's float INFs and NANs (mostly?) obey the rules of IEEE-754
> arithmetic. Those rules are close to the rules for the extended Real
> number line, with a point at both positive and negative infinity.
>
> These rules are not necessarily the same as the rules for transfinite
> arithmetic, or the projective number line with a single infinity, or
> arithmetic on cardinal numbers, or surreal numbers.
>
> Each of these number systems have related, but slightly different,
> rules. For example, IEEE-754 has a single signed infinity and 2**INF is
> exactly equal to INF. But in transfinite arithmetic, 2**INF is strictly
> greater than INF (for every infinity):
>
> 2**aleph_0 < aleph_1
> 2**aleph_1 < aleph_2
> 2**aleph_2 < aleph_3
>
> and so on, with no limit. There is no greatest aleph, there is always a
> larger one.
>
> Do you have a concrete suggestion you would like to make for a change or
> new feature for Python? If not, I suggest that this thread is going
> nowhere.
>
>
> --
> 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/U5WXW3WTNRNWV5PEADF6CDZC6FFBBUJG/
> 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/4QCHCCN3FKLUKFAICQPXYNLC4BXERZDW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-18 Thread Steven D'Aprano

On Sun, Oct 18, 2020 at 03:26:11AM -0400, Wes Turner wrote:

> assert math.inf**0 == 1
> assert math.inf**math.inf == math.inf

Wes, I don't understand what point you are trying to make here. Are you
agreeing with that behaviour? Disagreeing? Thought it was so surprising
that you can't imagine why it happens? Something else?

If you find a behaviour which is forbidden or contradicted by the
documentation, then you should report it as a bug, but just
demonstrating what the behaviour is with no context isn't helpful.

Please remember that the things which are blindingly obvious to you
because you just thought them are not necessarily obvious to those of us
who aren't inside your head :-)

Python's float INFs and NANs (mostly?) obey the rules of IEEE-754
arithmetic. Those rules are close to the rules for the extended Real
number line, with a point at both positive and negative infinity.

These rules are not necessarily the same as the rules for transfinite
arithmetic, or the projective number line with a single infinity, or
arithmetic on cardinal numbers, or surreal numbers.

Each of these number systems have related, but slightly different,
rules. For example, IEEE-754 has a single signed infinity and 2**INF is
exactly equal to INF. But in transfinite arithmetic, 2**INF is strictly
greater than INF (for every infinity):

2**aleph_0 < aleph_1
2**aleph_1 < aleph_2
2**aleph_2 < aleph_3

and so on, with no limit. There is no greatest aleph, there is always a
larger one.

Do you have a concrete suggestion you would like to make for a change or
new feature for Python? If not, I suggest that this thread is going
nowhere.

--
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/U5WXW3WTNRNWV5PEADF6CDZC6FFBBUJG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

Its probably best to
Carry on with the infinity constant discussion

On Sun, Oct 18, 2020, 3:26 AM Wes Turner  wrote:

> assert math.inf**0 == 1
> assert math.inf**math.inf == math.inf
>
> On Sun, Oct 18, 2020, 3:13 AM Wes Turner  wrote:
>
>> Thanks for your feedback Rob.
>>
>> On Sun, Oct 18, 2020, 12:27 AM Rob Cliffe via Python-ideas <
>> python-ideas@python.org> wrote:
>>
>>>
>>>
>>> On 11/10/2020 22:47, Wes Turner wrote:
>>>
>>> Indeed, perhaps virtual particles can never divide by zero and thus the
>>> observed laws of thermodynamic systems are preserved.
>>>
>>> Would you please be so kind as to respond in the main thread so that
>>> this is one consecutive thread?
>>>
>>> No, 2 times something is greater than something. Something over
 something 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
 symbol 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
 infinity, then they are equal.

>>>
>>> Which of these are you arguing should fail if Python changes to
>>> returning [+/-]inf instead of raising ZeroDivisionError?
>>>
>>>
 assert 1 / 0 != 2 / 0
 assert 2*inf > inf

>>> Both of them (assuming that they don't raise an exception).
>>>
>>> assert inf / inf == 1
>>>
>>> That should raise an exception; inf/inf is meaningless (just as division
>>> by zero is meaningless with finite numbers).
>>>
>>> No offence Wes, but you are clearly not familiar with the subject of
>>> transfinite numbers as discovered by Cantor.  I earnestly suggest you learn
>>> something about it before making statements which are - again, no offence
>>> intended, but frankly - nonsense.  Transfinite numbers do not obey the same
>>> rules as finite numbers.  Which can be counter-intuitive and take some
>>> getting used to, but ... that's the way it is.
>>> Best wishes
>>> Rob Cliffe
>>> ___
>>> 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/NKE6DETBHE4SCH3DTQREJTYPTDG3KXRA/
>>> 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/AD6STCK75JTB2HHVQKVE62N55QPENGPR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

assert math.inf**0 == 1
assert math.inf**math.inf == math.inf

On Sun, Oct 18, 2020, 3:13 AM Wes Turner  wrote:

> Thanks for your feedback Rob.
>
> On Sun, Oct 18, 2020, 12:27 AM Rob Cliffe via Python-ideas <
> python-ideas@python.org> wrote:
>
>>
>>
>> On 11/10/2020 22:47, Wes Turner wrote:
>>
>> Indeed, perhaps virtual particles can never divide by zero and thus the
>> observed laws of thermodynamic systems are preserved.
>>
>> Would you please be so kind as to respond in the main thread so that this
>> is one consecutive thread?
>>
>> No, 2 times something is greater than something. Something over something
>>> 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
>>> symbol 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
>>> infinity, then they are equal.
>>>
>>
>> Which of these are you arguing should fail if Python changes to returning
>> [+/-]inf instead of raising ZeroDivisionError?
>>
>>
>>> assert 1 / 0 != 2 / 0
>>> assert 2*inf > inf
>>>
>> Both of them (assuming that they don't raise an exception).
>>
>> assert inf / inf == 1
>>
>> That should raise an exception; inf/inf is meaningless (just as division
>> by zero is meaningless with finite numbers).
>>
>> No offence Wes, but you are clearly not familiar with the subject of
>> transfinite numbers as discovered by Cantor.  I earnestly suggest you learn
>> something about it before making statements which are - again, no offence
>> intended, but frankly - nonsense.  Transfinite numbers do not obey the same
>> rules as finite numbers.  Which can be counter-intuitive and take some
>> getting used to, but ... that's the way it is.
>> Best wishes
>> Rob Cliffe
>> ___
>> 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/NKE6DETBHE4SCH3DTQREJTYPTDG3KXRA/
>> 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/5WPVVLJJ4X5WT3YSNXP3TA2Q53YP2ZNU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

Thanks for your feedback Rob.

On Sun, Oct 18, 2020, 12:27 AM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:

>
>
> On 11/10/2020 22:47, Wes Turner wrote:
>
> Indeed, perhaps virtual particles can never divide by zero and thus the
> observed laws of thermodynamic systems are preserved.
>
> Would you please be so kind as to respond in the main thread so that this
> is one consecutive thread?
>
> No, 2 times something is greater than something. Something over something
>> 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
>> symbol 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
>> infinity, then they are equal.
>>
>
> Which of these are you arguing should fail if Python changes to returning
> [+/-]inf instead of raising ZeroDivisionError?
>
>
>> assert 1 / 0 != 2 / 0
>> assert 2*inf > inf
>>
> Both of them (assuming that they don't raise an exception).
>
> assert inf / inf == 1
>
> That should raise an exception; inf/inf is meaningless (just as division
> by zero is meaningless with finite numbers).
>
> No offence Wes, but you are clearly not familiar with the subject of
> transfinite numbers as discovered by Cantor.  I earnestly suggest you learn
> something about it before making statements which are - again, no offence
> intended, but frankly - nonsense.  Transfinite numbers do not obey the same
> rules as finite numbers.  Which can be counter-intuitive and take some
> getting used to, but ... that's the way it is.
> Best wishes
> Rob Cliffe
> ___
> 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/NKE6DETBHE4SCH3DTQREJTYPTDG3KXRA/
> 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/6UH2W4WT4EP4LPP5OEABKZM3JPU5ZSDG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-17 Thread Rob Cliffe via Python-ideas




On 11/10/2020 22:47, Wes Turner wrote:
Indeed, perhaps virtual particles can never divide by zero and thus 
the observed laws of thermodynamic systems are preserved.


Would you please be so kind as to respond in the main thread so that 
this is one consecutive thread?


No, 2 times something is greater than something. Something over
something 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 symbol 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
infinity, then they are equal.


Which of these are you arguing should fail if Python changes to 
returning [+/-]inf instead of raising ZeroDivisionError?


assert 1 / 0 != 2 / 0
assert 2*inf > inf


Both of them (assuming that they don't raise an exception).


assert inf / inf == 1

That should raise an exception; inf/inf is meaningless (just as division 
by zero is meaningless with finite numbers).


No offence Wes, but you are clearly not familiar with the subject of 
transfinite numbers as discovered by Cantor.  I earnestly suggest you 
learn something about it before making statements which are - again, no 
offence intended, but frankly - nonsense.  Transfinite numbers do not 
obey the same rules as finite numbers.  Which can be counter-intuitive 
and take some getting used to, but ... that's the way it is.

Best wishes
Rob Cliffe
___
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/NKE6DETBHE4SCH3DTQREJTYPTDG3KXRA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-12 Thread Greg Ewing


On 12/10/20 10:39 am, Wes Turner wrote:


We should not discard the scalar in scalar*infinity expressions.


I don't think that would help as much as you seem to imagine it would.

Consider f(x) = 1/x**2, g(x) = 1/x**3, h(x) = f(x) / g(x).

Keeping a scalar multiplier attached to infinities isn't going
to help you get a sensible result for h(0) given f(0) and g(0).

Doing that kind of thing would require a full-blown computer
algebra system capable of reasoning about limits.

--
Greg
___
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/DP32URSLRTP27ZFLL2RAUQLA5XFGRFSI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-12 Thread Oscar Benjamin

On Mon, 12 Oct 2020 at 07:23, Christopher Barker  wrote:
>
> FWIW, if a change were to be made, I'd rather it be some kind of float error 
> handling context: either a global setting, like numpy's, or a context 
> manager. With, of course, the default behavior just like it's been forever.

You can have both a global setting and then a context manager for
altering it, although it would need to be thread-safe. I would
certainly make use of an option to have exceptions instead of nans.

I did suggest something similar at some point and was pointed to fpectl:
https://docs.python.org/2/library/fpectl.html
I haven't looked in any detail but I suspect that making fpectl work
on all platforms is not really viable: this should probably be handled
within the interpreter rather than at the FPU level (although that
could be used as an optimisation for some platforms).

--
Oscar
___
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/FXXAVPHVP56UG7PUWO4ZWF32Q36KPWHQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-12 Thread David Mertz

On Mon, Oct 12, 2020, 9:50 AM Stephen J. Turnbull

> As far as what Steven discussed, the ordinal numbers have the same
> properties (except I've never heard of ω-1 in a discussion of ordinals, but
> it should work I think).  (Maybe the surreals are constructed from the
> ordinals as the reals are constructed from the cardinals?)
>

Not exactly. Cauchy sequences define Reals in terms of countably infinite
sequences of Rational numbers. The Surreals are defined by binary trees of
every transfinite length (not only countably infinite).

Basically, the right-most branch in the Surreal tree is simply the Cantor
ordinals. But in the other paths were encounter things like infinitesimals
and ω-1. Subtraction and division wind up defined over Surreals, unlike for
regular transfinite ordinals.

"If formulated in von Neumann–Bernays–Gödel set theory
,
the surreal numbers are a universal ordered field in the sense that all
other ordered fields, such as the rationals, the reals, the rational
functions , the Levi-Civita
field , the superreal
numbers , and the hyperreal
numbers , can be realized
as subfields of the surreals. The surreals also contain all transfinite
 ordinal numbers
; the arithmetic on them is
given by the natural operations
."
___
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/LKGYFTKAC5B7YZR6W6BZZPMQBVLF4TVB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-12 Thread Paul Moore

On Mon, 12 Oct 2020 at 14:51, Stephen J. Turnbull
 wrote:
>
> As far as what Steven discussed, the ordinal numbers have the same
> properties (except I've never heard of ω-1 in a discussion of
> ordinals, but it should work I think).

I don't think it does. The ordinals are based on the idea of
*orderings* of (potentially infinite) sets. So ω+1 is the ordinal of
something like

1, 2, 3, ... 1

Addition is basically "bunging the second sequence at the end of the
first". There's no obvious meaning for subtraction in the general
sense here - you can't take a chunk off the end of an infinite
sequence. And in particular, I can't think of an ordering that would
map to ω-1 - it would have to be an ordering that, when you added a
single item after it, would be equivalent to ω, which has no "end", so
where did that item you added go?

(Apologies for the informal explanations, my set theory and logic
courses were many years ago, and while my pedantry cries out for
precision, my laziness prevents me from looking up the specifics :-))

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/5NO33KBI6ZPOK27TLDT5JFLWJUG4LB5I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-12 Thread Stephen J. Turnbull

David Mertz writes:
 > On Sun, Oct 11, 2020, 9:07 PM Steven D'Aprano
 > 
 > > Even in the cardinal numbers, two times infinity (aleph-0) is just
 > > aleph-0; however you might be pleased to know that two to the power of
 > > aleph-0 is aleph-1.
 > >
 > 
 > Oh... So you're one of those who believe the Continuum Hypothesis :-).

As any good defense lawyer can tell you, you don't need to believe
something to use it to prove something else. :-)

 > I was going to mention Surreal Numbers also, but I see you touched
 > on it.

As far as what Steven discussed, the ordinal numbers have the same
properties (except I've never heard of ω-1 in a discussion of
ordinals, but it should work I think).  (Maybe the surreals are
constructed from the ordinals as the reals are constrcuted from the
cardinals?)
___
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/YL6EGQIE7X4TPFYXUY4BLT752KQH5KW4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-12 Thread Christopher Barker

On Sun, Oct 11, 2020 at 11:04 PM Wes Turner  wrote:

> (and the proposed Python implementation of IEEE-754's alternative to
> ZeroDivisionError)
>

Is anyone actually proposing this (i.e. changing how Python handles
division by zero, or other float exceptions) ?

There IS a proposal on the table to add math.inf and math.nan to builtins,
which is the only one I know about (and I'm supposed to help write a PEP
for, which has stalled out) But while there has been a bunch of discussion,
I don't know that anyone has actually proposed anything.

But if so -- could whoever it is write the proposal down? (Ideally in a new
thread)

>  this be an appropriate migration strategy for implementing IEEE-754
> inf/+inf/-inf:
>
> from __future__ import floatinfinity
>

FWIW, if a change were to be made, I'd rather it be some kind of float
error handling context: either a global setting, like numpy's, or a context
manager. With, of course, the default behavior just like it's been forever.

-CHB

-- 
Christopher Barker, PhD

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/4ULLXW66QVKSGKOHYZWM57T4WDKBW4IZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-12 Thread Wes Turner

On Mon, Oct 12, 2020, 1:43 AM Greg Ewing 
wrote:

> On 12/10/20 3:44 pm, Wes Turner wrote:
> > [Microscopic] black holes do deal with infinity in certain regards.)
>
> Not really. General relativity predicts that matter will collapse into
> a point of zero size and infinite density inside a black hole. But
> that's more likely to mean that GR is wrong under such extreme
> conditions, than to mean that there's actually a singularity at the
> centre of a black hole.
>

Whether scalar times infinity is relevant to describing the progression of
a black hole / wormhole / whitehole is something that cannot be assessed
without symbolic mathematics; which IEEE-754 (and the proposed Python
implementation of IEEE-754's alternative to ZeroDivisionError) cannot solve
for.

> In any case, this doesn't have anything to do with the present
> discussion. You can't use physics to prove things about maths, or
> vice versa.
>

OT: There are certainly applications for (scalar times) float and non-float
infinity. ZeroDivisionError may be more desirable than attempting to build
a CAS in stdlib; or even handling non-float math.inf in stdlib.

Notably, the https://en.wikipedia.org/wiki/Bekenstein_bound is limited to
certainly less than infinity, but there is disagreement in other forums
over whether black holes have an event horizon or an apparent horizon.

> "the absence of event horizons mean that there are no black holes – in
the sense of regimes from which light can't escape to infinity."

https://en.wikipedia.org/wiki/Event_horizon

"It's just inf; the other terms are then irrelevant" is insufficient for
many applications.

Where are the standard library and third-party tests that catch
ZeroDivisionError?

Something this be an appropriate migration strategy for implementing
IEEE-754 inf/+inf/-inf:

from __future__ import floatinfinity
___
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/TD4WUTR2B4EJ4TSLS3UDCPQQECZKYN5L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-11 Thread Greg Ewing


On 12/10/20 3:44 pm, Wes Turner wrote:

[Microscopic] black holes do deal with infinity in certain regards.)


Not really. General relativity predicts that matter will collapse into
a point of zero size and infinite density inside a black hole. But
that's more likely to mean that GR is wrong under such extreme
conditions, than to mean that there's actually a singularity at the
centre of a black hole.

In any case, this doesn't have anything to do with the present
discussion. You can't use physics to prove things about maths, or
vice versa.

--
Greg
___
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/FHUMRZEZFSKX6NPZLPZ6AQLYPFWB3F7L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-11 Thread David Mertz

On Sun, Oct 11, 2020, 9:07 PM Steven D'Aprano

> Even in the cardinal numbers, two times infinity (aleph-0) is just
> aleph-0; however you might be pleased to know that two to the power of
> aleph-0 is aleph-1.
>

Oh... So you're one of those who believe the Continuum Hypothesis :-).

I was going to mention Surreal Numbers also, but I see you touched on 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/7LPSGOHZOVL6JQTO2JHHUNLFDRFLHFQ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

(OT:
https://en.wikipedia.org/wiki/Banach%E2%80%93Tarski_paradox#Obtaining_infinitely_many_balls_from_one

> Using the Banach–Tarski paradox, it is possible to obtain k copies of a
ball in the Euclidean n-space from one, for any integers n ≥ 3 and k ≥ 1,
i.e. a ball can be cut into k pieces so that each of them is
equidecomposable to a ball of the same size as the original.

... in *Euclidean n-space*.

https://en.wikipedia.org/wiki/Holographic_principle#Limit_on_information_density
:

> This suggests that matter itself cannot be subdivided infinitely many
times and there must be an ultimate level of fundamental particles. As the
degrees of freedom of a particle are the product of all the degrees of
freedom of its sub-particles, were a particle to have infinite subdivisions
into lower-level particles, the degrees of freedom of the original particle
would be infinite, violating the maximal limit of entropy density.

[Microscopic] black holes do deal with infinity in certain regards.)

On Sun, Oct 11, 2020 at 10:40 PM Wes Turner  wrote:

> Thank you for the overview. It seems as though this community will also
> look to IEEE-754 (the IEEE Standard for Floating-Point Arithmetic) for
> Reals and also Infinity.
>
> Should Python raise exceptions for Integers or [Complex] Fractions
> involving Infinity,
> or should Python assume that IEEE-754 is the canonical source of truth
> about infinity?
>
> IEEE-754 (2019), a closed standard, costs $100 for the PDF. I'll Ctrl-F
> for 'infinity' in the Wikipedia article:
>
> https://en.wikipedia.org/wiki/IEEE_754 :
>
> Exception handling
>> The standard defines five exceptions, each of which returns a default
>> value and has a corresponding status flag that is raised when the exception
>> occurs.[e] No other exception handling is required, but additional
>> non-default alternatives are recommended (see § Alternate exception
>> handling).
>> The five possible exceptions are:
>> - Invalid operation: mathematically undefined, e.g., the square root of a
>> negative number. By default, returns qNaN.
>> - Division by zero: an operation on finite operands gives an exact
>> infinite result, e.g., 1/0 or log(0). By default, returns ±infinity.
>> - Overflow: a result is too large to be represented correctly (i.e., its
>> exponent with an unbounded exponent range would be larger than emax). By
>> default, returns ±infinity for the round-to-nearest modes (and follows the
>> rounding rules for the directed rounding modes).
>> - Underflow: a result is very small (outside the normal range) and is
>> inexact. By default, returns a subnormal or zero (following the rounding
>> rules).
>> Inexact: the exact (i.e., unrounded) result is not representable exactly.
>> By default, returns the correctly rounded result.
>
>
> It appears that IEEE-754 implemented as per the binary spec could not
> represent more complex assessments of inifnity:
>
> As with IEEE 754-1985, the biased-exponent field is filled with all 1 bits
>> to indicate either infinity (trailing significand field = 0) or a NaN
>> (trailing significand field ≠ 0). For NaNs, quiet NaNs and signaling NaNs
>> are distinguished by using the most significant bit of the trailing
>> significand field exclusively,[d] and the payload is carried in the
>> remaining bits.
>
>
> json5 extends the JSON to support IEEE-754 +-inf (and +-0, which can also
> be used to indicate 1D directionality sans magnitude).
>
> Presumably, in the IEEE-754 view of the world,
>
> from math import inf, nan
> assert type(inf) == float
> assert isinstance(inf, float)
> assert float("inf") == inf
>
> assert inf / inf == nan
>
> assert inf / 0 == inf   # currently: ZeroDivisionError
>
> assert (x/0) < ((x+1e-10)/0)   # where x>0 (x in Z+)  # Not possible;
> Python is not a CAS
>
>
> https://en.wikipedia.org/wiki/List_of_computer_algebra_systems doesn't
> have a column for a "Surreal Numbers" or "non-Float handling of infinity".
>
>
> https://en.wikipedia.org/wiki/Quantum_field_theory#Infinities_and_renormalization
> deals with Infinities; which have curently been removed.
>
> inf**inf
>
>
>
>
> On Sun, Oct 11, 2020 at 9:07 PM Steven D'Aprano 
> wrote:
>
>>
>> On Sun, Oct 11, 2020 at 05:47:44PM -0400, Wes Turner wrote:
>>
>> > No, 2 times something is greater than something. Something over
>> something
>> > is 1.
>>
>> Define "something". Define "times" (multiplication). Define "greater
>> than". Define "over" (division).
>>
>> And while you are at it, don't forget to define what you mean by
>> "infinity". Do you mean potential infinity, actual infinity, Absolute
>> infinity, aleph and beth numbers, omegas, or something else?
>>
>> https://www.cut-the-knot.org/WhatIs/WhatIsInfinity.shtml
>>
>> I am not being facetious. Getting your definitions right is vital if you
>> wish to avoid error, and to avoid miscommunication. Change the
>> definitions, and you change the meaning of everything said.
>>
>>
>> (1) In the so-called "real numbers", there is no such thing as

[Python-ideas] Re: 'Infinity' constant in Python

Thank you for the overview. It seems as though this community will also
look to IEEE-754 (the IEEE Standard for Floating-Point Arithmetic) for
Reals and also Infinity.

Should Python raise exceptions for Integers or [Complex] Fractions
involving Infinity,
or should Python assume that IEEE-754 is the canonical source of truth
about infinity?

IEEE-754 (2019), a closed standard, costs $100 for the PDF. I'll Ctrl-F for
'infinity' in the Wikipedia article:

https://en.wikipedia.org/wiki/IEEE_754 :

Exception handling
> The standard defines five exceptions, each of which returns a default
> value and has a corresponding status flag that is raised when the exception
> occurs.[e] No other exception handling is required, but additional
> non-default alternatives are recommended (see § Alternate exception
> handling).
> The five possible exceptions are:
> - Invalid operation: mathematically undefined, e.g., the square root of a
> negative number. By default, returns qNaN.
> - Division by zero: an operation on finite operands gives an exact
> infinite result, e.g., 1/0 or log(0). By default, returns ±infinity.
> - Overflow: a result is too large to be represented correctly (i.e., its
> exponent with an unbounded exponent range would be larger than emax). By
> default, returns ±infinity for the round-to-nearest modes (and follows the
> rounding rules for the directed rounding modes).
> - Underflow: a result is very small (outside the normal range) and is
> inexact. By default, returns a subnormal or zero (following the rounding
> rules).
> Inexact: the exact (i.e., unrounded) result is not representable exactly.
> By default, returns the correctly rounded result.


It appears that IEEE-754 implemented as per the binary spec could not
represent more complex assessments of inifnity:

As with IEEE 754-1985, the biased-exponent field is filled with all 1 bits
> to indicate either infinity (trailing significand field = 0) or a NaN
> (trailing significand field ≠ 0). For NaNs, quiet NaNs and signaling NaNs
> are distinguished by using the most significant bit of the trailing
> significand field exclusively,[d] and the payload is carried in the
> remaining bits.


json5 extends the JSON to support IEEE-754 +-inf (and +-0, which can also
be used to indicate 1D directionality sans magnitude).

Presumably, in the IEEE-754 view of the world,

from math import inf, nan
assert type(inf) == float
assert isinstance(inf, float)
assert float("inf") == inf

assert inf / inf == nan

assert inf / 0 == inf   # currently: ZeroDivisionError

assert (x/0) < ((x+1e-10)/0)   # where x>0 (x in Z+)  # Not possible;
Python is not a CAS


https://en.wikipedia.org/wiki/List_of_computer_algebra_systems doesn't have
a column for a "Surreal Numbers" or "non-Float handling of infinity".

https://en.wikipedia.org/wiki/Quantum_field_theory#Infinities_and_renormalization
deals with Infinities; which have curently been removed.

inf**inf




On Sun, Oct 11, 2020 at 9:07 PM Steven D'Aprano  wrote:

>
> On Sun, Oct 11, 2020 at 05:47:44PM -0400, Wes Turner wrote:
>
> > No, 2 times something is greater than something. Something over something
> > is 1.
>
> Define "something". Define "times" (multiplication). Define "greater
> than". Define "over" (division).
>
> And while you are at it, don't forget to define what you mean by
> "infinity". Do you mean potential infinity, actual infinity, Absolute
> infinity, aleph and beth numbers, omegas, or something else?
>
> https://www.cut-the-knot.org/WhatIs/WhatIsInfinity.shtml
>
> I am not being facetious. Getting your definitions right is vital if you
> wish to avoid error, and to avoid miscommunication. Change the
> definitions, and you change the meaning of everything said.
>
>
> (1) In the so-called "real numbers", there is no such thing as infinity.
> Since there is no such thing as infinity, infinity is not "something"
> that can be multiplied or divided, or added or subtracted. In the Real
> number system, there is no coherent way of doing arithmetic on
> "infinity". "Two times infinity" is meaningless.
>
> In the real numbers, there's no sensible way of doing arithmetic with
> "infinity" without leading to contradiction.
>
> Informally, infinity in the Real number system is a process that never
> completes, so doing twice as much doesn't take any longer.
>
>
> (2) Mathematicians have created at least two extensions to the Real
> number line which do include at least one infinity. It is possible to
> construct a coherent system that is not self-contradictory by including
> either a pair of plus and minus infinity, or just a single unsigned
> infinity:
>
> https://en.wikipedia.org/wiki/Extended_real_number_line
>
> https://en.wikipedia.org/wiki/Projectively_extended_real_line
>
> But in doing so, we have to give up certain "common sense" properties of
> finite numbers. For example, with only a single infinity, infinity is
> both greater than everything, and less than (more negative) than
> everything. We lose a

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-11 Thread Paul Bryan

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  wrote:
> On Mon, Oct 12, 2020 at 8:07 AM Wes Turner  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  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  wrote

> 
> 
> :
> On Mon, Oct 12, 2020 at 5:06 AM Wes Turner  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  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,

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-11 Thread Steven D'Aprano

On Sun, Oct 11, 2020 at 05:47:44PM -0400, Wes Turner wrote:

> No, 2 times something is greater than something. Something over something
> is 1.

Define "something". Define "times" (multiplication). Define "greater
than". Define "over" (division).

And while you are at it, don't forget to define what you mean by
"infinity". Do you mean potential infinity, actual infinity, Absolute
infinity, aleph and beth numbers, omegas, or something else?

https://www.cut-the-knot.org/WhatIs/WhatIsInfinity.shtml

I am not being facetious. Getting your definitions right is vital if you
wish to avoid error, and to avoid miscommunication. Change the
definitions, and you change the meaning of everything said.

(1) In the so-called "real numbers", there is no such thing as infinity.
Since there is no such thing as infinity, infinity is not "something"
that can be multiplied or divided, or added or subtracted. In the Real
number system, there is no coherent way of doing arithmetic on
"infinity". "Two times infinity" is meaningless.

In the real numbers, there's no sensible way of doing arithmetic with
"infinity" without leading to contradiction.

Informally, infinity in the Real number system is a process that never
completes, so doing twice as much doesn't take any longer.

(2) Mathematicians have created at least two extensions to the Real
number line which do include at least one infinity. It is possible to
construct a coherent system that is not self-contradictory by including
either a pair of plus and minus infinity, or just a single unsigned
infinity:

https://en.wikipedia.org/wiki/Extended_real_number_line

https://en.wikipedia.org/wiki/Projectively_extended_real_line

But in doing so, we have to give up certain "common sense" properties of
finite numbers. For example, with only a single infinity, infinity is
both greater than everything, and less than (more negative) than
everything. We lose a coherent definition of "greater than".

Even in the extended number lines, two times infinity is just infinity,
and infinity divided by infinity is not coherent and cannot be defined
in any sensible way.

The IEEE-754 standard, and consequently Python floats, closely models
the extended real number line.

(3) In the *cardinal numbers*, there is something called infinity. Or
rather, there are an *infinite number* of infinities, starting with the
smallest, aleph-0, which represents the cardinality of the integers,
i.e. what people usually mean when they think of infinity.

Even in the cardinal numbers, two times infinity (aleph-0) is just
aleph-0; however you might be pleased to know that two to the power of
aleph-0 is aleph-1.

Arithmetic with infinite cardinal numbers is strange.

https://en.wikipedia.org/wiki/Hilbert's_paradox_of_the_Grand_Hotel

(4) In other extensions of the real numbers, such as hyperreal and
surreal numbers, we can work with various different kinds of
infinities (and infinitesimals).

For example, in the surreal numbers, we can do arithmetic on infinities,
and you will be gratified, I am sure, that twice infinity is different
from plain old infinity. In the language of the surreals:

2ω = ω + ω ≠ ω

(That's an omega symbol, not ∞.)

Unfortunately, the surreals are very different from the commonsense
world of the real numbers we know and love. For starters, they form a
tree, not a line. You cannot reach ω by starting at 0 and adding 1
repeatedly. (ω is not the successor of any ordinal number.) Consequently
there are other infinite numbers like ω-1 that are less than infinity
but cannot be reached by counting upwards from zero but only by counting
down from infinity.

And of course, in the surreal numbers, there are an infinity of
ever-growing infinities: not just ω+1 and 2ω but ω^2 and ω^ω and so on,
all of which are "bigger than infinity".

https://en.wikipedia.org/wiki/Surreal_number

All very fascinating I am sure, but I don't think that we should be
trying to emulate the surreal numbers as part of float.

--
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/MI4HG64LQGJ5TZYIOVNYNZKYVTEUHND4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-11 Thread Richard Damon

On 10/11/20 5:47 PM, Wes Turner wrote:
> Indeed, perhaps virtual particles can never divide by zero and thus
> the observed laws of thermodynamic systems are preserved.
>
> Would you please be so kind as to respond in the main thread so that
> this is one consecutive thread?
>
> No, 2 times something is greater than something. Something over
> something 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 symbol 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
> infinity, then they are equal.
>
>
> Which of these are you arguing should fail if Python changes to
> returning [+/-]inf instead of raising ZeroDivisionError?
>  
>
> assert 1 / 0 != 2 / 0
> assert 2*inf > inf
> assert inf / inf == 1
>
All of them will fail. n / 0 is inf or -inf depending on whether n is
positive or negative (and I believe 0/0 is NaN)

n * inf is inf, for all n > 0

inf / inf in NaN (if I remember right).

infinity is NOT just a number that behaves like any finite number.

Maybe you should look into the rules for transfinite mathematics, a lot
of the rules that apply for finite mathematics don't work when you allow
for non-finite numbers.

Note, that for example you last example, the answer of Z+ is correct, as
Z+ does NOT include infinity, so the case where x is infinity, is
outside the domain Z, or even R.

Also note, the the Axioms like the Division Axiom apply to the domains
of Finite numbers, and not all of them apply when you get Infinities.
This is just like some properties in the Real do not apply when you move
to the Complex plane.

>
> On Sun, Oct 11, 2020 at 5:41 PM Richard Damon
> mailto:rich...@damon-family.org>> wrote:
>
> On 10/11/20 5:04 PM, Wes Turner 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
> > ```
> >
> Treating inf as any other number because it works out
> 'symbolically' is
> one of the recipes that allow you to prove that 1 == 2, thus symbolic
> math needs to work with certain preconditions that avoid the
> generation
> of 'numbers' like infinity into the system (or somewhat related,
> avoid a
> divide by 0)
>
> -- 
> Richard Damon
> ___
> 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/SQNY5WFVPRPWXRZ7FW3H3RUGM3UCLCCL/
> 
> 
> 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/4VUULYAKSLEO46HZ5TO4EIFIFDFV4TK3/
> Code of Conduct: http://python.org/psf/codeofconduct/


-- 
Richard Damon
___
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/VXUGORIKP75EZD24LJYCKTHGQCGZFDM3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-11 Thread Chris Angelico

On Mon, Oct 12, 2020 at 8:42 AM Wes Turner  wrote:
>
> No, 2 times something is greater than something. Something over something 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 symbol is 
> unsolvable because the symbol could be infinity.
>

Again, you start with the assumption that infinity is a number. "2
times something is greater than something" applies only to positive
real numbers - not to zero, not to negative numbers, not to complex
numbers.

> 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 infinity, 
> then they are equal.
>
> assert 1 / 0 != 2 / 0
> assert 2*inf > inf
> assert inf / inf == 1
>

Where do these assertions hold true? Certainly not in Python, nor in
mathematical real numbers.

> 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 to tests in 
> order to return (scalar times) infinity instead of ZeroDivisionError.
>
> We should not discard the scalar in scalar*infinity expressions.
>

The scalar becomes irrelevant when infinity is a limit, rather than a number.

Further discussion probably belongs on python-list rather than here.

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/R2CC5PGN5VHQUJDEOP5CWOCRUHELCEBZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

Indeed, perhaps virtual particles can never divide by zero and thus the
observed laws of thermodynamic systems are preserved.

Would you please be so kind as to respond in the main thread so that this
is one consecutive thread?

No, 2 times something is greater than something. Something over something
> 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 symbol 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 infinity,
> then they are equal.
>

Which of these are you arguing should fail if Python changes to returning
[+/-]inf instead of raising ZeroDivisionError?


> assert 1 / 0 != 2 / 0
> assert 2*inf > inf
> assert inf / inf == 1


On Sun, Oct 11, 2020 at 5:41 PM Richard Damon 
wrote:

> On 10/11/20 5:04 PM, Wes Turner 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
> > ```
> >
> Treating inf as any other number because it works out 'symbolically' is
> one of the recipes that allow you to prove that 1 == 2, thus symbolic
> math needs to work with certain preconditions that avoid the generation
> of 'numbers' like infinity into the system (or somewhat related, avoid a
> divide by 0)
>
> --
> Richard Damon
> ___
> 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/SQNY5WFVPRPWXRZ7FW3H3RUGM3UCLCCL/
> 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/4VUULYAKSLEO46HZ5TO4EIFIFDFV4TK3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

No, 2 times something is greater than something. Something over something
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 symbol 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 infinity,
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 to
tests in order to return (scalar times) infinity instead of
ZeroDivisionError.

We should not discard the scalar in scalar*infinity expressions.

On Sun, Oct 11, 2020, 5:18 PM Chris Angelico  wrote:

> On Mon, Oct 12, 2020 at 8:07 AM Wes Turner  wrote:
> >
> > 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  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  wrote:
> On Mon, Oct 12, 2020 at 5:06 AM Wes Turner  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  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  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.

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-11 Thread Richard Damon

On 10/11/20 5:04 PM, Wes Turner 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
> ```
>
Treating inf as any other number because it works out 'symbolically' is
one of the recipes that allow you to prove that 1 == 2, thus symbolic
math needs to work with certain preconditions that avoid the generation
of 'numbers' like infinity into the system (or somewhat related, avoid a
divide by 0)

-- 
Richard Damon
___
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/SQNY5WFVPRPWXRZ7FW3H3RUGM3UCLCCL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-11 Thread Chris Angelico

On Mon, Oct 12, 2020 at 8:07 AM Wes Turner  wrote:
>
> 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
___
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/KQIE47XOK537LM6RUQ5REQA2JUJVYBLX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

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  wrote:
On Mon, Oct 12, 2020 at 5:06 AM Wes Turner  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  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  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 
>> 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

[Python-ideas] Re: 'Infinity' constant in Python

2020-10-11 Thread Chris Angelico

On Mon, Oct 12, 2020 at 5:06 AM Wes Turner  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
___
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/RLGYZGAQCYJNL7XWPZZJPGJ7XLYJ7KEU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

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  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 
> 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

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-17 Thread Stephen J. Turnbull

Christopher Barker writes:

 > Could you all please start another thread if you want to discuss possible
 > changes to Error handling for floats. Or anything that isn't strictly
 > adding some names to builtins.

This is *all* about adding names to builtins.  *Nobody* is seriously
proposing changes to Error handling for floats, although there has
been some speculation that it could be considered.

Subthread tl;dr -- handling of expressions potentially involving
numbers not representable as finite floats in Python is a big mess.
Too much of the mess is already present in the builtins, *don't* add
any more.

 > There's been ongoing confusion from the expansion of the original topic
 > here.

There has been no expansion to other proposed changes, except the
question of whether inf (or Infinity) should be a keyword (I don't
think that's been seriously proposed either, except mayby in the OP).
___
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/PZSVS4WV5CT2SP6QTWPB3C7ZCHAFEBI7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-16 Thread Christopher Barker

Could you all please start another thread if you want to discuss possible
changes to Error handling for floats. Or anything that isn't strictly
adding some names to builtins.

There's been ongoing confusion from the expansion of the original topic
here.

Thanks,
-CHB



On Wed, Sep 16, 2020 at 8:28 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Paul Moore writes:
>  > >  > And as soon as we start considering integer division, we're talking
>  > >  > about breaking a *vast* amount of code.
>  > >
>  > > Yeah, I'm ok with *not* breaking that code.
>  >
>  > You may have misunderstood me - when I said "integer division", I
>  > meant "division of two integers",
>
> Just to clear it up, I understood your point correctly.  "I'm ok with
> *not* breaking that code" means "I'm talking about the mythical Python
> 4.0, obviously we can't change the error raised by 1 / 0".
>
>  > My *only* concern with the points you and Ben were making was that you
>  > seemed to be suggesting changes to the division operator and
>  > ZeroDivisionError,
>
> Once again, I am quite ok with *not* breaking all that code.  My point
> about the inconsistencies is not to suggest fixing them.  I'm quite
> sure that pragmatically we can't fix *all* of them, and most likely
> we'd have to go slow on fixing *any* of them.  Rather that the whole
> float situation is so visually messy that we should leave it alone --
> although it probably works fine in practice until you have need for
> NumPy for other reasons.
> ___
> 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/FXIBYNXE3B53RTGQWUZT2PGNZ5OXB3BM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

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/U3Q7IFJZSEDZG7UKD4UCW5QSZHY5LHFA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-16 Thread Stephen J. Turnbull

Paul Moore writes:
 > >  > And as soon as we start considering integer division, we're talking
 > >  > about breaking a *vast* amount of code.
 > >
 > > Yeah, I'm ok with *not* breaking that code.
 > 
 > You may have misunderstood me - when I said "integer division", I
 > meant "division of two integers",

Just to clear it up, I understood your point correctly.  "I'm ok with
*not* breaking that code" means "I'm talking about the mythical Python
4.0, obviously we can't change the error raised by 1 / 0".

 > My *only* concern with the points you and Ben were making was that you
 > seemed to be suggesting changes to the division operator and
 > ZeroDivisionError,

Once again, I am quite ok with *not* breaking all that code.  My point
about the inconsistencies is not to suggest fixing them.  I'm quite
sure that pragmatically we can't fix *all* of them, and most likely
we'd have to go slow on fixing *any* of them.  Rather that the whole
float situation is so visually messy that we should leave it alone --
although it probably works fine in practice until you have need for
NumPy for other reasons.
___
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/FXIBYNXE3B53RTGQWUZT2PGNZ5OXB3BM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

On Tue, 15 Sep 2020 at 16:48, Stephen J. Turnbull
 wrote:
>
> Paul Moore writes:
>
>  > OK, so to me, 1.0 / 0.0 *is* a "true infinity" in that sense. If you
>  > divide "one" by "zero" the only plausible interpretation - if you
>  > allow infinity in your number system - is that you get infinity as
>  > a result. Of course that just pushes the question back to whether
>  > you mean (mathematical) "one" and "zero" when you make that
>  > statement.
>
> The answer is yes.  I can say so authoritatively :-) because I
> introduced the term "true infinity" into this thread to distinguish
> those results of computations done in the extended real system result
> in infinity from those results of computations in the extended real
> system which result in finite values, but overflow the floating point
> representation.  Both kinds of values are represented by inf in the
> Python (or IEEE 754) floating point number system.
>
> This is not a philosophical question, as you seem to think.  It's
> purely terminological, an abbreviation for the long sentence above.  I
> thought that would be obvious, but I guess I have a Dutch ancestor I
> didn't know about. ;-)  I apologize for not being more careful.

I'm going to skip a huge chunk of your reply. I've read it, and get
what you're saying. I even agree with the majority of the comments. I
was skimming the thread initially, and I think that in doing so I
missed some of the context. I'm not 100% sure I agree with you on
*all* points, but you're right that I'm looking at the discussion from
a perspective that you didn't intend, and by doing so I doubt I'm
helping, so I'll duck out of the philosophy at this point :-)

> I don't have any problem with 1 // 0 raising and 1 / 0 returning inf
> because Python is not Lisp[1]: x / y *always* gives a float result.
> 1 / 0 "should" obey float conventions.  Users need to know that floats
> are weird in a host of ways, so making users learn that 1 / 0 does
> something different from 1 // 0 doesn't seem like a deal-breaker.  If
> I were designing Python numerics for Python 4.0 ... but I'm not.
> 
>
>  > And as soon as we start considering integer division, we're talking
>  > about breaking a *vast* amount of code.
>
> Yeah, I'm ok with *not* breaking that code.

You may have misunderstood me - when I said "integer division", I
meant "division of two integers", not "the // operator", so I was
including 1 / 0. So having 1/0 return inf would break all the code
that checks for ZeroDivisionError on the / operator, which was my
concern. And having 1/0 behave differently than 1.0/0.0 makes me very
uncomfortable, even though you can argue that by using floats I was
implicitly accepting float semantics (and nans).

My *only* concern with the points you and Ben were making was that you
seemed to be suggesting changes to the division operator and
ZeroDivisionError, which I view as being much more controversial than
any other aspect of what you were saying. (Basically, everything else
I'm at best +0 on, and mostly "don't care").

> But I still do not see what practical use there is in putting inf in
> the builtins, except saving a few keystrokes for people who generally
> will not know what they're doing.

This point, I 100% agree with.

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/XQ4E6FO66SZ5AHBU22BDEIHKHSS7ZZ6N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-15 Thread Steve Barnes

 >>> 1 / 0

 >>> 1 / 0.0
inf

Is not true as since python 3 has adopted true division 1/1 returns 1.0 so 1/0 
would also return inf.

Steve Barnes

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Cade Brown<mailto:brown.c...@gmail.com>
Sent: 15 September 2020 15:05
To: Paul Moore<mailto:p.f.mo...@gmail.com>
Cc: python-ideas<mailto:python-ideas@python.org>
Subject: [Python-ideas] Re: 'Infinity' constant in Python

To sum up these discussions, I think it should be said that perhaps a look 
should be taken at the structure of math-based errors and exceptions, but this 
discussion should be moved to a new thread on the mailing list perhaps. (I 
agree that the exceptions make little sense, and I have noticed this)

I'd just like to add that under many circumstances, division by 0 makes perfect 
sense.
For example, in the Riemann Sphere 
(https://en.wikipedia.org/wiki/Riemann_sphere), 1/0 == infinity (of course, 
this is not a signed infinity, but rather a single infinity, sometimes called 
'complex infinity')

And, under complete euclidean division, it makes sense to describe `x // 0 == 
0` and `x % 0 == x`, so that:

(a, b) := (x // y, x % y)
implies
x = a * y + b

However, should Python cater to these use cases? I don't think so, because most 
users are committing some sort of error when they divide by zero, and Python 
should make them acknowledge that explicitly.

Most users aren't abstract theorists. Python shouldn't assume they are

Additionally, not raising an exception on division by float zero would mean the 
following operations behave vastly differently:

 >>> 1 / 0

 >>> 1 / 0.0
inf

This would also be very unexpected

Cade Brown
Research Assistant @ ICL (Innovative Computing Laboratory)
Personal Email: brown.c...@gmail.com<mailto:brown.c...@gmail.com>
ICL/College Email: c...@utk.edu<mailto:c...@utk.edu>

On Tue, Sep 15, 2020 at 7:02 AM Paul Moore 
mailto:p.f.mo...@gmail.com>> wrote:
On Tue, 15 Sep 2020 at 10:29, Stephen J. Turnbull
mailto:turnbull.stephen...@u.tsukuba.ac.jp>>
 wrote:
>
> Paul Moore writes:
>  > On Tue, 15 Sep 2020 at 08:12, Stephen J. Turnbull
>  > 
> mailto:turnbull.stephen...@u.tsukuba.ac.jp>>
>  wrote:
>  > > Ben Rudiak-Gould writes:
>
>  > >  > 1./0. is not a true infinity.
>
>  > > Granted, I was imprecise.  To be precise, 1.0 / 0.0 *could* be a true
>  > > infinity, and in some cases (1.0 / float(0)) *provably* is, while
>  > > 1e1000 *provably* is not a true infinity.
>  >
>  > I think we're getting to a point where the argument is getting way too
>  > theoretical to make sense any more. I'm genuinely not clear from the
>  > fragment quoted here,
>  >
>  > 1. What a "true infinity" is. Are we talking solely about IEEE-754?
>
> Not solely.  We're talking about mathematical infinities, such as the
> count of all integers or the length of the real line, and how they are
> modeled in IEEE-754 and Python.

OK, so to me, 1.0 / 0.0 *is* a "true infinity" in that sense. If you
divide "one" by "zero" the only plausible interpretation - if you
allow infinity in your number system - is that you get infinity as a
result. Of course that just pushes the question back to whether you
mean (mathematical) "one" and "zero" when you make that statement.

I get that Ben is actually saying "things that round to 1" and "things
that round to 0", but at that point error propagation and similar
details come into play, making even equality a somewhat vague concept.

>  > Because mathematically, different disciplines have different views,
>  > and many of them don't even include infinity in the set of numbers.
>
> But in IEEE-754, inf behaves like the positive infinity of the extended
> real number line: inf + inf = inf, x > 0 => inf * x = inf, inf - inf =
> nan, and so on.  We need to be talking about a mathematics that at
> least has defined the extended reals.

OK.

>  > 2. What do 1.0 and 0.0 mean? The literals in Python translate to
>  > specific bit patterns, so we can apply IEEE-754 rules to those bit
>  > patterns. There's nothing to discuss here, just the application of a
>  > particular set of rules.
>
> Except that application is not consistent.  That was the point of
> Ben's post.
>
>  > (Unless we're discussing which set of rules to apply, but I thought
>  > IEEE-754 was assumed).  So Ben's statement seems to imply he's not
>  > talking just about IEEE-754 bit patterns.
>
> He's talking about the arithmetic of floating point numbers, which
> involves rounding rules intended to model the extended real line.

Again OK, but in the face of rounding rules, many

[Python-ideas] Re: 'Infinity' constant in Python

Paul Moore writes:

 > OK, so to me, 1.0 / 0.0 *is* a "true infinity" in that sense. If you
 > divide "one" by "zero" the only plausible interpretation - if you
 > allow infinity in your number system - is that you get infinity as
 > a result. Of course that just pushes the question back to whether
 > you mean (mathematical) "one" and "zero" when you make that
 > statement.

The answer is yes.  I can say so authoritatively :-) because I
introduced the term "true infinity" into this thread to distinguish
those results of computations done in the extended real system result
in infinity from those results of computations in the extended real
system which result in finite values, but overflow the floating point
representation.  Both kinds of values are represented by inf in the
Python (or IEEE 754) floating point number system.

This is not a philosophical question, as you seem to think.  It's
purely terminological, an abbreviation for the long sentence above.  I
thought that would be obvious, but I guess I have a Dutch ancestor I
didn't know about. ;-)  I apologize for not being more careful.

 > I get that Ben is actually saying "things that round to 1" and "things
 > that round to 0", but at that point error propagation and similar
 > details come into play, making even equality a somewhat vague
 > concept.

But that's the genius of IEEE 754: they don't come into play.  IEEE
754 is a system of arithmetic that is internally consistent.  Equality
of IEEE 754 floats is well-defined and exact, as are all IEEE 754
calculations.

The value of IEEE 754 to Python programmers is that for a very wide
range of calculations the IEEE 754 value is tuned to be close to the
value of the calculation using (extended) reals (and cast to float at
the end of the calculation rather than the beginning).  (For example,
"round to nearest, ties to even" usually increases that likelihood by
conserving precision.)  It's true that once we want to take advantage
of "closeness" we may need to do error propagation analysis, and we
almost always want to avoid equality comparisons.  But in many cases
(eg, one matrix multiplication, no matter how large the matrices)
there is no point in error analysis.  You either get over/underflow,
or you don't, and you check that at the end.

On the other hand, this probability of closeness goes way down once
inf enters the calculation.  The odds that an inf result in the IEEE
number system is not only finite in the extended real number system,
but in fact representable as an IEEE float, are unpleasantly high.

 > > He's talking about the arithmetic of floating point numbers, which
 > > involves rounding rules intended to model the extended real line.
 > 
 > Again OK, but in the face of rounding rules, many "obvious"
 > mathematical properties, such as associativity and distributivity,
 > don't hold. So we have to be *very* careful when inferring
 > equivalences like the one you use below, a * b = c => 1.0 / (a * b) =
 > 1.0 / c.

But that's not a problem (unless maybe you're within a few ULP of
sys.float_info.max or sys.float_info.min).  For the examples we're
talking about the problem is entirely that IEEE 754 defaults to
returning inf for a calculation where Python raises:

Division by zero: an operation on finite operands gives an exact
infinite result, e.g., 1/0 or log(0). By default, returns
±infinity.

 > Note that I'm not saying here that Python's behaviour might not be
 > inconsistent, but rather that it's not obvious (to me, at least) that
 > there is an intuitively consistent set of rules

IEEE 754 is strong evidence that there is no such set of rules, at
least for fixed width float representations.  IEEE 754 is internally
consistent, of course (I trust Kahan that far! ;-), but consistency
with intuition is as hard as predicting the future.

 > so Python has chosen one particular way of being inconsistent,

But that's an important aspect of the examples Ben presents: Python
has chosen like half a dozen ways of being inconsistent, some of which
are not even monotonic (I forget the exact example, but there was a
case where as the argument value increases, you go from inf to raise
and then back to inf, or some such sequence).

That kind of thing means that if you are serious about doing large
numbers of computations you have to handle a number of different
exceptions during the loops, as well as cleaning up the inf/nan mess
after the loops.

 > practical considerations like "raising an exception is more user
 > friendly for people who don't understand IEEE-754".

The advocates haven't presented any such arguments for copying
math.inf (and I assume math.nan) to the builtins.

 > >  > 3. Can you give an example of 1.0/0.0 *not* being a "true infinity"? I
 > >  > have a feeling you're going to point to denormalised numbers close to
 > >  > zero, but why are you expressing them as "0.0"?
 > >
 > > Not subnormal numbers, but non-zero numbers that round to zero.

[examples omitted]

 > See

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-15 Thread Cade Brown

To sum up these discussions, I think it should be said that perhaps a look
should be taken at the structure of math-based errors and exceptions, but
this discussion should be moved to a new thread on the mailing list
perhaps. (I agree that the exceptions make little sense, and I have noticed
this)


I'd just like to add that under many circumstances, division by 0 makes
perfect sense.
For example, in the Riemann Sphere (
https://en.wikipedia.org/wiki/Riemann_sphere), 1/0 == infinity (of course,
this is not a signed infinity, but rather a single infinity, sometimes
called 'complex infinity')

And, under complete euclidean division, it makes sense to describe `x // 0
== 0` and `x % 0 == x`, so that:

(a, b) := (x // y, x % y)
implies
x = a * y + b

However, should Python cater to these use cases? I don't think so, because
most users are committing some sort of error when they divide by zero, and
Python should make them acknowledge that explicitly.

Most users aren't abstract theorists. Python shouldn't assume they are


Additionally, not raising an exception on division by float zero would mean
the following operations behave vastly differently:

 >>> 1 / 0

 >>> 1 / 0.0
inf

This would also be very unexpected


*Cade Brown*
Research Assistant @ ICL (Innovative Computing Laboratory)
Personal Email: brown.c...@gmail.com
ICL/College Email: c...@utk.edu




On Tue, Sep 15, 2020 at 7:02 AM Paul Moore  wrote:

> On Tue, 15 Sep 2020 at 10:29, Stephen J. Turnbull
>  wrote:
> >
> > Paul Moore writes:
> >  > On Tue, 15 Sep 2020 at 08:12, Stephen J. Turnbull
> >  >  wrote:
> >  > > Ben Rudiak-Gould writes:
> >
> >  > >  > 1./0. is not a true infinity.
> >
> >  > > Granted, I was imprecise.  To be precise, 1.0 / 0.0 *could* be a
> true
> >  > > infinity, and in some cases (1.0 / float(0)) *provably* is, while
> >  > > 1e1000 *provably* is not a true infinity.
> >  >
> >  > I think we're getting to a point where the argument is getting way too
> >  > theoretical to make sense any more. I'm genuinely not clear from the
> >  > fragment quoted here,
> >  >
> >  > 1. What a "true infinity" is. Are we talking solely about IEEE-754?
> >
> > Not solely.  We're talking about mathematical infinities, such as the
> > count of all integers or the length of the real line, and how they are
> > modeled in IEEE-754 and Python.
>
> OK, so to me, 1.0 / 0.0 *is* a "true infinity" in that sense. If you
> divide "one" by "zero" the only plausible interpretation - if you
> allow infinity in your number system - is that you get infinity as a
> result. Of course that just pushes the question back to whether you
> mean (mathematical) "one" and "zero" when you make that statement.
>
> I get that Ben is actually saying "things that round to 1" and "things
> that round to 0", but at that point error propagation and similar
> details come into play, making even equality a somewhat vague concept.
>
> >  > Because mathematically, different disciplines have different views,
> >  > and many of them don't even include infinity in the set of numbers.
> >
> > But in IEEE-754, inf behaves like the positive infinity of the extended
> > real number line: inf + inf = inf, x > 0 => inf * x = inf, inf - inf =
> > nan, and so on.  We need to be talking about a mathematics that at
> > least has defined the extended reals.
>
> OK.
>
> >  > 2. What do 1.0 and 0.0 mean? The literals in Python translate to
> >  > specific bit patterns, so we can apply IEEE-754 rules to those bit
> >  > patterns. There's nothing to discuss here, just the application of a
> >  > particular set of rules.
> >
> > Except that application is not consistent.  That was the point of
> > Ben's post.
> >
> >  > (Unless we're discussing which set of rules to apply, but I thought
> >  > IEEE-754 was assumed).  So Ben's statement seems to imply he's not
> >  > talking just about IEEE-754 bit patterns.
> >
> > He's talking about the arithmetic of floating point numbers, which
> > involves rounding rules intended to model the extended real line.
>
> Again OK, but in the face of rounding rules, many "obvious"
> mathematical properties, such as associativity and distributivity,
> don't hold. So we have to be *very* careful when inferring
> equivalences like the one you use below, a * b = c => 1.0 / (a * b) =
> 1.0 / c.
>
> Note that I'm not saying here that Python's behaviour might not be
> inconsistent, but rather that it's not obvious (to me, at least) that
> there is an intuitively consistent set of rules - so Python has chosen
> one particular way of being inconsistent, and the question is more
> about whether we like an alternative form of inconsistency better than
> about "should Python be consistent". If a consistent set of rules *is*
> possible then "we should be consistent" is a purity argument that may
> or may not stand against practical considerations like "raising an
> exception is more user friendly for people who don't understand
> IEEE-754".
>
> >  > 3. Can you give an example of

[Python-ideas] Re: 'Infinity' constant in Python

On Tue, 15 Sep 2020 at 10:29, Stephen J. Turnbull
 wrote:
>
> Paul Moore writes:
>  > On Tue, 15 Sep 2020 at 08:12, Stephen J. Turnbull
>  >  wrote:
>  > > Ben Rudiak-Gould writes:
>
>  > >  > 1./0. is not a true infinity.
>
>  > > Granted, I was imprecise.  To be precise, 1.0 / 0.0 *could* be a true
>  > > infinity, and in some cases (1.0 / float(0)) *provably* is, while
>  > > 1e1000 *provably* is not a true infinity.
>  >
>  > I think we're getting to a point where the argument is getting way too
>  > theoretical to make sense any more. I'm genuinely not clear from the
>  > fragment quoted here,
>  >
>  > 1. What a "true infinity" is. Are we talking solely about IEEE-754?
>
> Not solely.  We're talking about mathematical infinities, such as the
> count of all integers or the length of the real line, and how they are
> modeled in IEEE-754 and Python.

OK, so to me, 1.0 / 0.0 *is* a "true infinity" in that sense. If you
divide "one" by "zero" the only plausible interpretation - if you
allow infinity in your number system - is that you get infinity as a
result. Of course that just pushes the question back to whether you
mean (mathematical) "one" and "zero" when you make that statement.

I get that Ben is actually saying "things that round to 1" and "things
that round to 0", but at that point error propagation and similar
details come into play, making even equality a somewhat vague concept.

>  > Because mathematically, different disciplines have different views,
>  > and many of them don't even include infinity in the set of numbers.
>
> But in IEEE-754, inf behaves like the positive infinity of the extended
> real number line: inf + inf = inf, x > 0 => inf * x = inf, inf - inf =
> nan, and so on.  We need to be talking about a mathematics that at
> least has defined the extended reals.

OK.

>  > 2. What do 1.0 and 0.0 mean? The literals in Python translate to
>  > specific bit patterns, so we can apply IEEE-754 rules to those bit
>  > patterns. There's nothing to discuss here, just the application of a
>  > particular set of rules.
>
> Except that application is not consistent.  That was the point of
> Ben's post.
>
>  > (Unless we're discussing which set of rules to apply, but I thought
>  > IEEE-754 was assumed).  So Ben's statement seems to imply he's not
>  > talking just about IEEE-754 bit patterns.
>
> He's talking about the arithmetic of floating point numbers, which
> involves rounding rules intended to model the extended real line.

Again OK, but in the face of rounding rules, many "obvious"
mathematical properties, such as associativity and distributivity,
don't hold. So we have to be *very* careful when inferring
equivalences like the one you use below, a * b = c => 1.0 / (a * b) =
1.0 / c.

Note that I'm not saying here that Python's behaviour might not be
inconsistent, but rather that it's not obvious (to me, at least) that
there is an intuitively consistent set of rules - so Python has chosen
one particular way of being inconsistent, and the question is more
about whether we like an alternative form of inconsistency better than
about "should Python be consistent". If a consistent set of rules *is*
possible then "we should be consistent" is a purity argument that may
or may not stand against practical considerations like "raising an
exception is more user friendly for people who don't understand
IEEE-754".

>  > 3. Can you give an example of 1.0/0.0 *not* being a "true infinity"? I
>  > have a feeling you're going to point to denormalised numbers close to
>  > zero, but why are you expressing them as "0.0"?
>
> Not subnormal numbers, but non-zero numbers that round to zero.
>
> >>> 1e200
> 1e200
> >>> 1e-200
> 1e-200
> >>> 1e200 == 1.0 / 1e-200
> True
> >>> 1e-200 * 1e-200 == 0.0
> True
> >>> 1.0 / (1e-200 * 1e-200)
> Traceback (most recent call last):
>   File "", line 1, in 
> ZeroDivisionError: float division by zero
> >>> 1e200 * 1e200
> inf

See above.

>  > 4. Can you provide the proofs you claim exist?
>
> Proofs of what?  All of this is just straightforward calculations in
> the extended real line, on the one hand, in IEEE 754 floats on the
> other hand, and in Python, on the gripping hand.[1]

You claimed that "1e1000 *provably* is not a true infinity". How would
you prove that?

Typing it into Python gives

>>> 1e1000
inf

That's a proof that in Python, 1e1000 *is* a true infinity. On the
extended real line, 1e1000 is not a true infinity because they are
different points on the line. In IEEE 754 I'd have to check the
details, but I think someone posted that the standard defines parsing
rules such that 1e1000 must translate to infinity.

So when I asked for your proof, I was trying to determine which set of
rules you were using.

> For numbers with magnitudes "near" 1 (ie, less than about 100 orders
> of magnitude bigger or smaller), the three arithmetics agree tolerably
> well for practical purposes (and Python and IEEE 754 agree exactly).
> If you need trignometric or

[Python-ideas] Re: 'Infinity' constant in Python

Chris Angelico writes:

 > Hang on hang on, transcendental quantities are still finite. It may
 > take an infinite sequence to fully calculate them, but they are finite
 > values. We're not talking about pi here, we're talking about treating
 > "infinity" as a value. You can certainly do arithmetic on pi.

Arithmetic, yes, I guess, but not correct trigonometry:

>>> from math import tan, pi
>>> tan(pi/2)
1.633123935319537e+16

That's infinitely wrong in mathematics!  Or 293 orders of magnitude,
if you prefer IEEE, where inf == 1e309 :-)
___
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/AX77HEFHIIGOGARJKVQVJ67Y6CEZNHQQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

Paul Moore writes:
 > On Tue, 15 Sep 2020 at 08:12, Stephen J. Turnbull
 >  wrote:
 > > Ben Rudiak-Gould writes:

 > >  > 1./0. is not a true infinity.

 > > Granted, I was imprecise.  To be precise, 1.0 / 0.0 *could* be a true
 > > infinity, and in some cases (1.0 / float(0)) *provably* is, while
 > > 1e1000 *provably* is not a true infinity.
 > 
 > I think we're getting to a point where the argument is getting way too
 > theoretical to make sense any more. I'm genuinely not clear from the
 > fragment quoted here,
 > 
 > 1. What a "true infinity" is. Are we talking solely about IEEE-754?

Not solely.  We're talking about mathematical infinities, such as the
count of all integers or the length of the real line, and how they are
modeled in IEEE-754 and Python.

 > Because mathematically, different disciplines have different views,
 > and many of them don't even include infinity in the set of numbers.

But in IEEE-754, inf behaves like the positive infinity of the extended
real number line: inf + inf = inf, x > 0 => inf * x = inf, inf - inf =
nan, and so on.  We need to be talking about a mathematics that at
least has defined the extended reals.

 > 2. What do 1.0 and 0.0 mean? The literals in Python translate to
 > specific bit patterns, so we can apply IEEE-754 rules to those bit
 > patterns. There's nothing to discuss here, just the application of a
 > particular set of rules.

Except that application is not consistent.  That was the point of
Ben's post.

 > (Unless we're discussing which set of rules to apply, but I thought
 > IEEE-754 was assumed).  So Ben's statement seems to imply he's not
 > talking just about IEEE-754 bit patterns.

He's talking about the arithmetic of floating point numbers, which
involves rounding rules intended to model the extended real line.

 > 3. Can you give an example of 1.0/0.0 *not* being a "true infinity"? I
 > have a feeling you're going to point to denormalised numbers close to
 > zero, but why are you expressing them as "0.0"?

Not subnormal numbers, but non-zero numbers that round to zero.

>>> 1e200
1e200
>>> 1e-200
1e-200
>>> 1e200 == 1.0 / 1e-200
True
>>> 1e-200 * 1e-200 == 0.0
True
>>> 1.0 / (1e-200 * 1e-200)
Traceback (most recent call last):
  File "", line 1, in 
ZeroDivisionError: float division by zero
>>> 1e200 * 1e200
inf

 > 4. Can you provide the proofs you claim exist?

Proofs of what?  All of this is just straightforward calculations in
the extended real line, on the one hand, in IEEE 754 floats on the
other hand, and in Python, on the gripping hand.[1]

For numbers with magnitudes "near" 1 (ie, less than about 100 orders
of magnitude bigger or smaller), the three arithmetics agree tolerably
well for practical purposes (and Python and IEEE 754 agree exactly).
If you need trignometric or exponential functions, things get quite a
bit more restricted -- things break down at pi/2.

For numbers with magnitudes "near" infinity, or nearly infinitesimal,
things break down in Python.  Whether you consider that breakdown to
be problematic or not depends on how you view the (long) list of
Curious Things The Dog Did (Not Do) In The Night in Ben's post.  I
think they're pretty disastrous.  I'd be much happier with *either*
consistently raising on non-representable finite results, or
consistently returning -inf, 0.0, inf, or nan.  That's not the Python
we have.

 > (Note: this has drifted a long way from anything that has real
 > relevance to Python - arguments this theoretical will almost certainly
 > fall foul of "practicality beats purity" when we get to arguing what
 > the language should do. I'm just curious to see how the theoretical
 > debate pans out).

I disagree.  This is entirely on the practical side of things!

Calculations on the extended real line are "just calculations", as are
calculations with IEEE 754 floats.  Any attentive high school student
can learn to do them (at least with the help of a computer for correct
rounding in the case of IEEE 754 floats :-).  There's no theory to
discuss (except for terminology like "true infinity").

The question of whether Python diverges from IEEE 754 (which turns on
whether IEEE 754 recommends that you raise exceptions or return
inf/nan but not both), and the question of whether the IEEE 754 model
of "overflow as infinity" is intuitive/useful to users of Python who
*don't* use NumPy, are the questions under discussion here.

Now, to be fair, there is a practicality beats purity argument.  It
can be argued (I think Ben or maybe Chris A alluded to this) that
"overflows usually' just happen but division by zero usually' is a
logic error".  Therefore returning inf in the case of overflow (and
continuing the computation), and raising on zero division (stopping
the computation and getting the attention of the user), is the
pragmatic sweet spot.  I disagree, but it's a viable argument.

Footnotes: 
[1]  If you haven't read The Mote in God's Eye, that's the third hand
of the aliens, which is big, powerful, clumsy,

[Python-ideas] Re: 'Infinity' constant in Python

On Tue, 15 Sep 2020 at 08:12, Stephen J. Turnbull
 wrote:
>
> Ben Rudiak-Gould writes:
>
>  > 1./0. is not a true infinity.
>
> Granted, I was imprecise.  To be precise, 1.0 / 0.0 *could* be a true
> infinity, and in some cases (1.0 / float(0)) *provably* is, while
> 1e1000 *provably* is not a true infinity.

I think we're getting to a point where the argument is getting way too
theoretical to make sense any more. I'm genuinely not clear from the
fragment quoted here,

1. What a "true infinity" is. Are we talking solely about IEEE-754?
Because mathematically, different disciplines have different views,
and many of them don't even include infinity in the set of numbers.
2. What do 1.0 and 0.0 mean? The literals in Python translate to
specific bit patterns, so we can apply IEEE-754 rules to those bit
patterns. There's nothing to discuss here, just the application of a
particular set of rules. (Unless we're discussing which set of rules
to apply, but I thought IEEE-754 was assumed). So Ben's statement
seems to imply he's not talking just about IEEE-754 bit patterns.
3. Can you give an example of 1.0/0.0 *not* being a "true infinity"? I
have a feeling you're going to point to denormalised numbers close to
zero, but why are you expressing them as "0.0"?
4. Can you provide the proofs you claim exist? I'm not actually that
interested in the proofs themselves, I'm just trying to determine what
your axioms and underlying model are.

(Note: this has drifted a long way from anything that has real
relevance to Python - arguments this theoretical will almost certainly
fall foul of "practicality beats purity" when we get to arguing what
the language should do. I'm just curious to see how the theoretical
debate pans out).

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/JX4OV22O7ZXXX5FUQ4UBT6EK2PPR3HMC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-15 Thread Chris Angelico

On Tue, Sep 15, 2020 at 5:17 PM Stephen J. Turnbull
 wrote:
>
> Chris Angelico writes:
>
>  > In mathematics, "infinity" isn't a value. One cannot actually perform
>  > arithmetic on it.
>
> That's a rather controversial opinion.  Even intuitionist
> mathematicians perform arithmetic on infinities; they just find it
> very distasteful that they have to do so.
>
>  > Computers can't do that.
>
> This is flat wrong.  It is very *inefficient* to have *current*
> computers perform arithmetic on infinities (transcendental quantities,
> etc), but Stephen Wolfram (and his net worth) would be very surprised
> at your statement.
>

Hang on hang on, transcendental quantities are still finite. It may
take an infinite sequence to fully calculate them, but they are finite
values. We're not talking about pi here, we're talking about treating
"infinity" as a value. You can certainly do arithmetic on pi.

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/VKEPF3HDS5WQRIV3AWS3PP524MT7AW6J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

Chris Angelico writes:

 > In mathematics, "infinity" isn't a value. One cannot actually perform
 > arithmetic on it.

That's a rather controversial opinion.  Even intuitionist
mathematicians perform arithmetic on infinities; they just find it
very distasteful that they have to do so.

 > Computers can't do that.

This is flat wrong.  It is very *inefficient* to have *current*
computers perform arithmetic on infinities (transcendental quantities,
etc), but Stephen Wolfram (and his net worth) would be very surprised
at your statement.

 > So we have a set of rules for approximating mathematics in ways
 > that are useful,

Exactly right.

 > even though they're not true representations of real numbers.

That's imprecise.  They are *true* representations of certain real
numbers, but they are also *approximate* representations of other real
numbers, and the function from value to representation is not
invertible (as an extended-real-valued function).

 > They're *good enough* for real-world usage.

True for *finite* IEEE floats.  Very controversial for inf and nan,
and especially for Python's rather inconsistent API for IEEE float.

 > And that's why we need "Infinity" to be a value, of sorts.

That's a non sequitur.  First, inf already *is a value* in Python, it
has a name both as str and repr, and it even has a pseudo-literal name
in the math module.  It just doesn't have a pseudo-literal name in
builtins (and that is all that is on offer here -- the proponents say
over and over again that they're not asking for keywords, and haven't
proposed a literal name for -inf yet).  Second, that the connected
spaces of positive and negative reals which have float representations
are usefully approximated by floats does not imply that the isolated
points of -infinity, zero, and +infinity are equally useful
approximations.  They may be, but my strongly-held opinion is "nah."

In practice, the justification for inf and nan is that in an inner
loop it's extremely inefficient to raise and handle exceptions every
time an overflow, underflow, or domain error occurs.  So you
substitute inf or nan as appropriate, keep looping until done, and
then work with the presumed accurate finite values that remain.  *inf
and nan don't need to have names to serve such functions*, let alone
names in builtins.

 > If you want to define infinity as any particular value, you're going
 > to get into a contradiction somewhere sooner or later. But its
 > behaviour in IEEE arithmetic is well defined and *useful* even without
 > trying to make everything make sense.

As Ben Rudiak-Gould shows, the behavior of operations whose results do
not have representation as Python floats is anything but "well-defined".

 > Let's stick to discussing whether "inf" (or "Infinity") should become
 > a new builtin name

Definitely not "Infinity" (unless you want to go for a keyword, in
which case a capitalized keyword in the tradition of None, False, and
True seems appropriate).  We've used "inf" for (a) decade(s), we don't
need a new name.

As for builtins, "what's so ungood about 'from math import inf, nan'?"
I don't see a persuasive answer to that.
___
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/XQHR4N7M3AHYYDPN3C73JYOAIEJFUDV4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-15 Thread Steve Barnes




> We need to remember that a significant number of Python users don't
> have any idea what IEE-754 is, and have never heard of a NaN (and
> possibly even of infinity as a number). Those people are *far* better
> served by being told "you made a mistake" in the form of an exception,
> rather than via a weird numeric value that doesn't work how they
> expect and doesn't even look like a number when they print it.
>
> Paul

My feeling is that both viewpoints can be satisfied by having a context whereby 
if USE_IEEE_SPECIAL_VALUES (to pick a random name) is False (the default) such 
operations will raise an exception but if it is True INF, -INF or NaN is 
returned (ideally with some debug output – this would be in the spirit of the 
IEEE Signalling NaN).

Steve Barnes
___
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/IYQPDLIQTTT3PVIISM6NEXMRYOE2VQU3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

Ben Rudiak-Gould writes:

 > 1./0. is not a true infinity.

Granted, I was imprecise.  To be precise, 1.0 / 0.0 *could* be a true
infinity, and in some cases (1.0 / float(0)) *provably* is, while
1e1000 *provably* is not a true infinity.
___
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/KGNKANSO3Z7U2YVRAE3A773L6KNY4O7H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

On Tue, 15 Sep 2020 at 06:54, David Mertz  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.

We need to remember that a significant number of Python users don't
have any idea what IEE-754 is, and have never heard of a NaN (and
possibly even of infinity as a number). Those people are *far* better
served by being told "you made a mistake" in the form of an exception,
rather than via a weird numeric value that doesn't work how they
expect and doesn't even look like a number when they print it.

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/M7AXLKSSKDOUC6AUIEGJC2HISJFHMV5H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-14 Thread David Mertz

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  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] Re: 'Infinity' constant in Python

2020-09-14 Thread Chris Angelico

On Tue, Sep 15, 2020 at 3:45 AM Richard Damon  wrote:
>
> On 9/14/20 12:34 PM, Stephen J. Turnbull wrote:
> > That's fine, but Python doesn't give you that.  In floats, 0.0 is not
> > true 0, it's the set of all underflow results plus true 0.  So by your
> > argument, in float arithmetic, we should not have ZeroDivisionErrors.
> > But we do raise them.
>
> Actually, with IEEE, 0.0 should be all numbers, when rounded to the
> nearest representation give the value 0.
>
> When we get to very small numbers, the 'sub-normals', we get numbers
> that are really some integral value times 2 to some negative power (I
> think it is something like 2 to the -1022 for the standard 64 bit
> floats). This says that as we approach 0, we have  sequence of evenly
> spaced representable values, 3*2**-1022, 2*2**-1022, 1*2**-1022, 0*2**-1022
>
> Thus the concept of "Zero" makes sense as the nearest representable value.
>
>
> Now, as been mentioned, "Infinity", doesn't match this concept, unless
> you do something like define it as it represents a value just above the
> highest represntable value, but that doesn't match the name.
>

In mathematics, "infinity" isn't a value. One cannot actually perform
arithmetic on it. But in mathematics, it's perfectly acceptable to
talk about stupid big numbers and do arithmetic that wouldn't ever be
possible with full precision (eg calculating the last digits of
Graham's Number). Mathematicians are also perfectly happy to work with
transcendental numbers as actual values, and, again, to perform
arithmetic on them even though we don't know the exact value.

Computers can't do that. So we have a set of rules for approximating
mathematics in ways that are useful, even though they're not true
representations of real numbers. (Something something "practicality
beats purity" yada yada.) That's why we have to deal with rounding
errors, that's why we have to work with trig functions that aren't
perfectly precise, etc, etc. They're *good enough* for real-world
usage. And that's why we need "Infinity" to be a value, of sorts. If
you wish, every IEEE float can be taken to represent a range of values
(all those that would round to it), but that's not often useful
(although AIUI that's how Python chooses to give a shorter display for
many numbers - it finds some short number that would have the same
representation and prints that). Much more practical to treat them as
actual numbers, including that 0.0 really does mean the additive
identity (and is the sole representation of it), even though this
leads to contradictions of sorts:

x = 1.0
x != 0.0 # True
y = float(1<<53)
x + y == y # True
# Subtract y from both sides, proving 1.0 == 0.0

If you want to define infinity as any particular value, you're going
to get into a contradiction somewhere sooner or later. But its
behaviour in IEEE arithmetic is well defined and *useful* even without
trying to make everything make sense.

Let's stick to discussing whether "inf" (or "Infinity") should become
a new builtin name, and let the IEEE experts figure out whether
infinity is a thing or not :)

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/GKULPWOYKSM4HWE6UUTNA4LSU32DASKT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-14 Thread Richard Damon

On 9/14/20 12:34 PM, Stephen J. Turnbull wrote:
> That's fine, but Python doesn't give you that.  In floats, 0.0 is not
> true 0, it's the set of all underflow results plus true 0.  So by your
> argument, in float arithmetic, we should not have ZeroDivisionErrors.
> But we do raise them.

Actually, with IEEE, 0.0 should be all numbers, when rounded to the
nearest representation give the value 0.

When we get to very small numbers, the 'sub-normals', we get numbers
that are really some integral value times 2 to some negative power (I
think it is something like 2 to the -1022 for the standard 64 bit
floats). This says that as we approach 0, we have  sequence of evenly
spaced representable values, 3*2**-1022, 2*2**-1022, 1*2**-1022, 0*2**-1022

Thus the concept of "Zero" makes sense as the nearest representable value.

Now, as been mentioned, "Infinity", doesn't match this concept, unless
you do something like define it as it represents a value just above the
highest represntable value, but that doesn't match the name.

-- 
Richard Damon
___
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/LDQKH6J2GISGQ26TVWZQJNJE5S2TBV3Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-14 Thread Stephen J. Turnbull

Christopher Barker writes:
 > On Sun, Sep 13, 2020 at 8:10 AM Stephen J. Turnbull <
 > turnbull.stephen...@u.tsukuba.ac.jp> wrote:
 > 
 > > As Steven points out, it's an overflow, and IEEE *but not Python* is
 > > clear about that.  In fact, none of the actual infinities I've tried
 > > (1.0 / 0.0 and math.tan(math.pi / 2.0)) result in values of inf.  The
 > > former raises ZeroDivisionError and the latter gives the finite value
 > > 1.633123935319537e+16.
 > 
 > probably because math.pi is not exact, either -- I'm pretty sure Python is
 > wrapping the C lib for math.tan, so that's not a Python issue.

The issue is that Python doesn't produce true infinities as far as I
know, so "inf" is a very poor name for float('inf') in builtins.  I
wince at math.inf as well, but at least there it feels like "this is
an IEEE 754 feature that Python uses".

 > In the Python world, numpy lets the user control the error
 > handling:

Not every 1_000_000 line module needs to be a builtin.  We're talking
about adding these names to the builtins, what NumPy does is
irrelevant (and NumPy already has its own inf).

 > As you've noticed, Python itself has limited use for Inf and NaN values,
 > which is probably why it got as far as it did with the really bad support
 > before 2.6. But these special values are used in external code called from
 > Python (including numpy), an so it's helpful to have good support for them
 > in Python anyway.

What's ungood about "from math import inf, nan"?
Or "from numpy import inf, nan"?

 > 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 agree, but Python doesn't.  It raises on some infs (generally
speaking, true infinities), and returns inf on others (generally
speaking, overflows).  To change that you need to bring in C
extensions.

 > Note that one of the key things about numpy, and why its defaults are
 > different, is that it does array-oriented math. Most people do not want
 > their entire computation to be stopped if only one value in an array under-
 > or over-flows, etc.

That's fine, but Python doesn't give you that.  In floats, 0.0 is not
true 0, it's the set of all underflow results plus true 0.  So by your
argument, in float arithmetic, we should not have ZeroDivisionErrors.
But we do raise them.

 > Anyway, the only  thing on the table now is putting a couple names in the
 > builtin namespace.

Which is why I've tried pretty hard to stick to those aspects of inf
and nan that are builtin to Python or available directly with "from
math import inf, nan".
___
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/2DZLX5WARQVNNQT4MIANSN4IFDULOQJN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-14 Thread Cade Brown

To me it seems like a useful shortcut that means:

 >>> x == True and type(x) == bool

But, as you say, it is best to just let the Python interpreter treat it as
a boolean (i.e. within an `if`, it is converted automatically)

Now, I am thinking it would actually be *bad* to have the CPython
implementation define `inf` singletons -- imagine a 3rd party library (for
example, sympy) that defines '==' for new types:

```
>>> from sympy import oo
>>> oo == inf
True
>>> oo is inf
False
```
Again, it would be useful for a shortcut: `x is inf` is the same as `x ==
inf and type(x) == float`, but with 3rd party libraries I don't think it's
something good to rely on.



On Mon, Sep 14, 2020, 12:05 AM Steven D'Aprano  wrote:

> On Mon, Sep 14, 2020 at 12:16:54PM +1000, Chris Angelico wrote:
>
> > (How often do people even use "x is True"?)
>
> Alas, that is a common idiom. For example:
>
>
> https://stackoverflow.com/questions/50816182/pep-8-comparison-to-true-should-be-if-cond-is-true-or-if-cond
>
> It's possibly less common than it used to be now that PEP 8 warns
> against it:
>
> https://www.python.org/dev/peps/pep-0008/
>
> and so linters flag it. But I've seen it used by beginners and
> experienced programmers alike.
>
> There is some justification for it in the case that you want to test
> specifically for the True instance, being much shorter than:
>
> arbitrary_object == 1 and type(arbitrary_object) is bool
>
> but many people have a mental blindspot and write:
>
>
> if flag is True:
> true_condition()
> else:
> false_condition()
>
>
> even when they know full well that flag is guaranteed to be a bool.
>
> I know that sometimes I catch myself doing the same. I recently
> rediscovered some old Pascal code I write in the 1990s and sure enough,
> I have "if flag == true" in that too.
>
> Of course we all know that it should be written:
>
> if flag is True is True:
> ...
>
> except I never know when to stop:
>
> if flag is True is True is True is True is True is True is ...
>
>
> *wink*
>
>
> --
> 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/45KTF4Z6EMXLSLN5PFXKS4QGIM3QEKGR/
> 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/3IX5OHELMZPGIYEOLTAW3P47NABXAOQG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-14 Thread Steve Barnes


I think that it might be worth re-iterating the value of NaN & Infinity – there 
are times when you are performing calculations and need to flag where something 
problematic happened but __not__ stop. Examples would be real-time control 
where you could discard a bad result but still need to move on to the next or 
operations on large chunks of data where you need to perform the calculation on 
every element and then discard/ignore the invalid results, (this is almost 
certainly why Pandas makes a lot of use of NaN).

The value of NaN is that it is a valid input to any float point calculation but 
will always result in a NaN out. Therefore if something goes wrong at any point 
in your calculation you can log that a problem occurred and carry on without 
loosing the fact that the result is invalid. (This is much liked in the 
functional programming world).

One of the many things that I like about python is that it is easy to create a 
NaN _with `float(‘nan’)`_ if you wish to generate & return an invalid value (it 
is a  nightmare to do in C – e.g. for when a sensor hasn’t replied but you 
still have to complete the read & reply process).

Personally I also like the IEEE INF & -INF values with their grantee that 
regardless of bit length they can never be an actual value – I have had a lot 
of issues with code that returns a clipped valid value when it really means 
overflow. I have even argued that it would be great to have a `int(‘nan’)` & 
‘int(‘inf’)` values to be able to mirror these useful properties.

I am ambivalent on the need to have constants for these special values but 
would like to argue strongly against any constructs such as infinity = 1e300, 
etc., after all would this still be an overflow on a machine that supported 
decimal128 (overflow at 1e6145) & Octuple (256 bit) overflow at about 
1.62e78913 values and in the future 512/1024 bit floats – I love the cross 
platform support of python.

Sorry to be teaching grandma to suck eggs.

Steve Barnes
___
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/35LNTGXNIPT24XPBJWE6BA2C6AGJFHRK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-13 Thread Steven D'Aprano

On Mon, Sep 14, 2020 at 12:16:54PM +1000, Chris Angelico wrote:

> (How often do people even use "x is True"?)

Alas, that is a common idiom. For example:

https://stackoverflow.com/questions/50816182/pep-8-comparison-to-true-should-be-if-cond-is-true-or-if-cond

It's possibly less common than it used to be now that PEP 8 warns
against it:

https://www.python.org/dev/peps/pep-0008/

and so linters flag it. But I've seen it used by beginners and
experienced programmers alike.

There is some justification for it in the case that you want to test
specifically for the True instance, being much shorter than:

arbitrary_object == 1 and type(arbitrary_object) is bool

but many people have a mental blindspot and write:

if flag is True:
true_condition()
else:
false_condition()

even when they know full well that flag is guaranteed to be a bool.

I know that sometimes I catch myself doing the same. I recently
rediscovered some old Pascal code I write in the 1990s and sure enough,
I have "if flag == true" in that too.

Of course we all know that it should be written:

if flag is True is True:
...

except I never know when to stop:

if flag is True is True is True is True is True is True is ...

*wink*

--
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/45KTF4Z6EMXLSLN5PFXKS4QGIM3QEKGR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-13 Thread Steven D'Aprano

On Sat, Sep 12, 2020 at 05:48:30PM -0700, Paul Bryan wrote:
> I meant to ask, why is nan not comparable? Even:
> 
> >>> math.nan == math.nan
> False

It is worth explaining why the IEEE-754 standards committee agreed to 
make NANs unequal to everything.

"It is not possible to specify a fixed-size arithmetic type that 
satisfies all of the properties of real arithmetic that we know and 
love. The 754 committee has to decide to bend or break some of them. 
This is guided by some pretty simple principles:

1. When we can, we match the behavior of real arithmetic.

2. When we can't, we try to make the violations as predictable and as 
easy to diagnose as possible."

https://stackoverflow.com/a/1573715

Having NANs compare equal to NANs would lead to nonsensical results 
like:

* sqrt(-2) == sqrt(-3)
* 0.0/0.0 == acos(2.0)
* infinity - infinity == log(-1.0)

NANs represent an exceptional state in your calculation. Some wag once 
argued that these are exceptional cases because, no matter what we 
choose to do, someone will take exception to it. NANs are no exception 
(pun intended) and I think that there is no single right answer.

-- 
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/S6MB3F5CCTSZ7XIDO2JRSPMI5I2ETKSM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-13 Thread Cade Brown

Hence why I said 'would', 'if' etc. And it was brought up/suggested, having
singletons. It does naturally flow from having a built-in (much like having
singletons for booleans does):

sugggesting that one reason that they were made keywords is that it's
> useful for them to be singletons, which is much harder to do (or at least
> use consistently) if the names can be reassigned.
> But these float special values can't be singletons anyway -- they could
> come from anywhere, so you really don't want to have people doing:
>

(to be honest, to me it does make sense to have 'inf' singletons, but not
for 'nan's. but, neither is part of the PEP).

'inf' is a very special value, and there are only 2 infinite floats (inf,
-inf).
Having a singleton is useful also perhaps as a memory optimization (i.e.
whenever creating a float from C, check if it is infinite, and if so,
return a new reference to the global inf/-inf variable).

Again, this is not part of the PEP, so I don't think we want to spend much
time discussing whether they should be singletons. For now, the answer
seems to be: no
Thanks,

*Cade Brown*
Research Assistant @ ICL (Innovative Computing Laboratory)
Personal Email: brown.c...@gmail.com
ICL/College Email: c...@utk.edu




On Sun, Sep 13, 2020 at 10:19 PM Chris Angelico  wrote:

> On Mon, Sep 14, 2020 at 11:05 AM Cade Brown  wrote:
> > This would become relevant, if, say Python 4.0 migrated 'inf' and 'nan'
> to builtin names (like True and False). If that happened, a 'nan' singleton
> wouldn't make sense unless you had 2**53 of them, so code like:
> >
> >   >>> x is nan
> >
> > Would be a flawed formulation
> >
>
> Nobody's suggesting that they become keywords representing singletons,
> which is what True and False are. (At least, I don't think so.) What's
> being proposed is simply a builtin name that has a value of
> float("inf"). People don't write "x is 1.5" and they shouldn't use "x
> is inf". It doesn't matter that there are multiple bit patterns that
> represent nan; you shouldn't be doing this even when there's only one
> bit pattern for the value. Yes, sometimes people do this with small
> integers, and in CPython it may work ("x is 5" will usually be true
> for any integer 5), but it's just as buggy there and I don't think
> that's particularly relevant.
>
> (How often do people even use "x is True"?)
>
> 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/PAQQ4J6YHRB6B7HTCR6IQQ2EZN32SOCE/
> 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/KFTJJT6A45YCJBXSB2E7ICVFGBZ3MS3D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-13 Thread Chris Angelico

On Mon, Sep 14, 2020 at 11:05 AM Cade Brown  wrote:
> This would become relevant, if, say Python 4.0 migrated 'inf' and 'nan' to 
> builtin names (like True and False). If that happened, a 'nan' singleton 
> wouldn't make sense unless you had 2**53 of them, so code like:
>
>   >>> x is nan
>
> Would be a flawed formulation
>

Nobody's suggesting that they become keywords representing singletons,
which is what True and False are. (At least, I don't think so.) What's
being proposed is simply a builtin name that has a value of
float("inf"). People don't write "x is 1.5" and they shouldn't use "x
is inf". It doesn't matter that there are multiple bit patterns that
represent nan; you shouldn't be doing this even when there's only one
bit pattern for the value. Yes, sometimes people do this with small
integers, and in CPython it may work ("x is 5" will usually be true
for any integer 5), but it's just as buggy there and I don't think
that's particularly relevant.

(How often do people even use "x is True"?)

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/PAQQ4J6YHRB6B7HTCR6IQQ2EZN32SOCE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-13 Thread Cade Brown

I never said it was, he specifically said as an aside for a book he was
writing. He said he hadn't heard of code using it, so I provided an example

You are talking about an *internal implementation detail* in the C code
> of the Javascript engine, not a Javascript language feature. There is no
> Javascript API for the JS programmer to perform NAN boxing or to encode
> pointers inside the 51 payload bits of NANs.
>

I never claimed there was, just that that was a use case of tagged nans,
was common for JS engine implementers to use, and indeed was a use case in
which inspecting the payload bits and having unique nan values was relevant.

Imagine that a Python program would use a `libc` binding (for example,
C-types) to interface with such an engine. It would have to be able to
differentiate.
Obviously, there are good reasons Python doesn't support it, and people
shouldn't grow to expect it, and this isn't really relevant to the
discussion (insofar as the PEP proposed doesn't specify that 'inf' and
'nan' be treated as singletones, just as default builtins).

This would become relevant, if, say Python 4.0 migrated 'inf' and 'nan' to
builtin names (like True and False). If that happened, a 'nan' singleton
wouldn't make sense unless you had 2**53 of them, so code like:

  >>> x is nan

Would be a flawed formulation

Thanks,

*Cade Brown*
Research Assistant @ ICL (Innovative Computing Laboratory)
Personal Email: brown.c...@gmail.com
ICL/College Email: c...@utk.edu




On Sun, Sep 13, 2020 at 8:57 PM Steven D'Aprano  wrote:

> On Sat, Sep 12, 2020 at 08:16:36PM -0400, Cade Brown wrote:
> > As per tagged nans, check for JavaScript tagged NaN optimization.
> > Essentially, the tag of the NaN (i.e. the mantissa) is interpreted as a
> > pointer. Obviously, this is a very advanced use case, probably not worth
> > Python guaranteeing such behavior.
> > Here is one article:
> >
> https://brionv.com/log/2018/05/17/javascript-engine-internals-nan-boxing/
>
> You are talking about an *internal implementation detail* in the C code
> of the Javascript engine, not a Javascript language feature. There is no
> Javascript API for the JS programmer to perform NAN boxing or to encode
> pointers inside the 51 payload bits of NANs.
>
> Aside from the extra complexity, which may or may not pay off in speed
> improvements, the downside of NAN boxing is the serious security hole
> that if you can introduce an arbitrary NAN value into a JS primitive
> value, you get a pointer to arbitrary memory and can use that to get
> up to all sorts of shenanigans.
>
> To avoid that security hole, JS has to normalise all incoming NANs to a
> single canonical NAN (thus, losing any possibility of user code making
> use of NAN payloads).
>
> In CPython's case, the interpreter uses pointers as object references,
> not the payload bits of a NAN. Jython and IronPython use whatever the
> JVM and .Net CLR use, which probably isn't NANs either.
>
> So while NAN boxing is a clever use of NAN payloads, it's not really
> relevant here. Python code doesn't have a notion of pointers to
> arbitrary addresses, but if it did, user code probably wouldn't have to
> manipulate the payload bits of a NAN float object to get one.
>
>
>
> --
> 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/54RN6HEE2LKANJ2Z7INQKLSULOL4J6WJ/
> 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/VDS47GCAZTGXI3OGWQK67Z47RWEXJ4Y6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-13 Thread Steven D'Aprano

On Sat, Sep 12, 2020 at 08:16:36PM -0400, Cade Brown wrote:
> As per tagged nans, check for JavaScript tagged NaN optimization.
> Essentially, the tag of the NaN (i.e. the mantissa) is interpreted as a
> pointer. Obviously, this is a very advanced use case, probably not worth
> Python guaranteeing such behavior.
> Here is one article:
> https://brionv.com/log/2018/05/17/javascript-engine-internals-nan-boxing/

You are talking about an *internal implementation detail* in the C code 
of the Javascript engine, not a Javascript language feature. There is no 
Javascript API for the JS programmer to perform NAN boxing or to encode 
pointers inside the 51 payload bits of NANs.

Aside from the extra complexity, which may or may not pay off in speed 
improvements, the downside of NAN boxing is the serious security hole 
that if you can introduce an arbitrary NAN value into a JS primitive 
value, you get a pointer to arbitrary memory and can use that to get 
up to all sorts of shenanigans.

To avoid that security hole, JS has to normalise all incoming NANs to a 
single canonical NAN (thus, losing any possibility of user code making 
use of NAN payloads).

In CPython's case, the interpreter uses pointers as object references, 
not the payload bits of a NAN. Jython and IronPython use whatever the 
JVM and .Net CLR use, which probably isn't NANs either.

So while NAN boxing is a clever use of NAN payloads, it's not really 
relevant here. Python code doesn't have a notion of pointers to 
arbitrary addresses, but if it did, user code probably wouldn't have to 
manipulate the payload bits of a NAN float object to get one.

-- 
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/54RN6HEE2LKANJ2Z7INQKLSULOL4J6WJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-13 Thread Christopher Barker

On Sun, Sep 13, 2020 at 8:10 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> As Steven points out, it's an overflow, and IEEE *but not Python* is
> clear about that.  In fact, none of the actual infinities I've tried
> (1.0 / 0.0 and math.tan(math.pi / 2.0)) result in values of inf.  The
> former raises ZeroDivisionError and the latter gives the finite value
> 1.633123935319537e+16.
>

probably because math.pi is not exact, either -- I'm pretty sure Python is
wrapping the C lib for math.tan, so that's not a Python issue.

And I don't think that IEEE 754 requires that all overflows go to inf.
Apparently it does for literals (thanks Steven), but you can, at the
language / library level choose to raise exceptions for overflow.

In the Python world, numpy lets the user control the error handling:

https://numpy.org/doc/stable/reference/generated/numpy.seterr.html

by default, overflow warns, but results in an infinity:

In [47]: arr = np.array([1e300])

In [48]: arr * 1e300

:1: RuntimeWarning: overflow encountered in
multiply
  arr * 1e300
Out[48]: array([inf])

So you get a warning, but still the infinity.

But if you change the error handling, you can get an Exception.

In [49]: np.seterr(over='raise')

Out[49]: {'divide': 'warn', 'over': 'warn', 'under': 'ignore', 'invalid':
'warn'}

In [50]: arr * 1e300

---
FloatingPointErrorTraceback (most recent call last)
 in 
> 1 arr * 1e300

FloatingPointError: overflow encountered in multiply

Python used to have an interface to the fpectl system, presumably to do
things like this, but it was removed in py3.7:

"""
The fpectl module has been removed. It was never enabled by default, never
worked correctly on x86-64, and it changed the Python ABI in ways that
caused unexpected breakage of C extensions. (Contributed by Nathaniel J.
Smith in bpo-29137.)
"""

As you've noticed, Python itself has limited use for Inf and NaN values,
which is probably why it got as far as it did with the really bad support
before 2.6. But these special values are used in external code called from
Python (including numpy), an so it's helpful to have good support for them
in Python anyway.

Which brings up a point about the Singleton idea (yes, I know that no ine
is proposing making singletons of inf and nan at this point anyway): while
the Python float type *could* enforce that they be singletons (essentially
like interning the special values), you can get them in  other types, from
other sources, so I think you wouldn't want them to be singletons. Example:
numpy float32 type:

In [52]: np32inf = np.float32('inf')

In [53]: type(np32inf)

Out[53]: numpy.float32

In [54]: math.inf == np32inf

Out[54]: True

An "is" check would never work there.

> that mathematical infinities and overflows map to inf, mathematical

> undefineds map to nan, overflows map to inf, and underflows map to
> zero.  But, as a large set of values, perhaps we'd be better off with
> overflow treated as nan?

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.

If we wanted Python to allow users more control, we could add an fp error
handling context, maybe like numpy's -- but I don't think there's been much
demand for it.

Note that one of the key things about numpy, and why its defaults are
different, is that it does array-oriented math. Most people do not want
their entire computation to be stopped if only one value in an array under-
or over-flows, etc.

That may apply in pure python to things like comprehensions, but most folks
doing heavy duty number crunching are using numpy anyway.

Anyway, the only  thing on the table now is putting a couple names in the
builtin namespace.

-CHB

-- 
Christopher Barker, PhD

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/C3XMIA5AVXJDVEY4L72KT7HLIEYWMC7U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-13 Thread Stephen J. Turnbull

Cade Brown writes:

 > When I read "1e1000" or such a number it doesn't strike me as
 > infinite

As Steven points out, it's an overflow, and IEEE *but not Python* is
clear about that.  In fact, none of the actual infinities I've tried
(1.0 / 0.0 and math.tan(math.pi / 2.0)) result in values of inf.  The
former raises ZeroDivisionError and the latter gives the finite value
1.633123935319537e+16.

Steven D'Aprano writes:

 > Nobody is recommending that [as] the best way to create an infinity

Is there a way to create an infinity in base Python, though?  You can
create infs (with 1e1000 or 2e308 or 1e10 or 2e200 * 2e200),
but those aren't infinities, those are overflows.  All the examples in
this thread, and infs in general Pythonic practice, are expressions
which have well-defined mathematical values, but overflow the range of
floats, and *inf doesn't tell you which mathematical value*, or indeed
even admit that "YMMV".[1]

It's not obvious to me why 1e309 and 9e308 should be equal in Python
-- 1e309 - 9e308 is close to the largest number you can express as a
Python float!  The point is that inf arithmetic only makes sense if
carefully analyzed in the context, not just of the application but
even down to the specific calculation.

I assume that IEEE did some sort of generic analysis and concluded
that mathematical infinities and overflows map to inf, mathematical
undefineds map to nan, overflows map to inf, and underflows map to
zero.  But, as a large set of values, perhaps we'd be better off with
overflow treated as nan?  Or perhaps overflow should be rounded to
sys.float_info.max since all finite values are closer to that than
they are to infinity?  Or maybe overflow should be a different kind of
thing, where some operations produce another overflow (adding a
positive finite number, multiplying by a number with magnitude > 1),
while others produce nans (overflow - overflow, as with infs, but also
overflow - positive_finite).  Maybe all nans should raise by default.

 > Using something like 1e1000 [...] is a fall back

I prefer to think of it as being honest: this isn't infinity, this is
overflow -- and the way Python treats infs, here be Dragons, all bets
are off, "magic is loose in the world", and anything can happen.

Footnotes: 
[1]  Float 0 also makes little sense for the same reason, but somehow
"anything close enough to zero 'is' zero" doesn't bother me as much as
"anything a little bit bigger than 1e308 'is' infinite" does.  I guess
it should 
___
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/KHFVP7RJ3H7MNPR533KG3BUNALQ5UTFN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-13 Thread Stephen J. Turnbull

Christopher Barker writes:

 > But why are they keywords? In Py2, True and False were just identifiers-
 > they were made keywords in py3.
 > 
 > I’m suggesting that one reason that they were made keywords is that
 > it's useful for them to be singletons, which is much harder to do
 > (or at least use consistently) if the names can be reassigned.

Except that the obvious assignments are True = 1 and False = 0, which
both denote singletons (in CPython, anyway and as it happens).[1]  That
is, since bool() returns only True and False, as long as you use only
those literals (0, False, 1, True) and bool(), "is" works as well as
"==".  So it's reserving the names, not the "singleton-ness", that's
important.

I assume that what the advocates of a true Boolean type wanted was
{False, True} to be *disjoint* from the integers, so that "True is 1"
is false.  In order to give them actual literal names (ie, compiling
to specific objects rather than to references to bindings), they
needed to be made keywords.  The whole Boolean project makes little
sense unless the true and false objects have literal syntax, and in
Python that means keyword names.

 > But these float special values can't be singletons anyway

Of course they *can*, they just aren't.  There's no reason not to make
1e1000 is inf and (1e1000 - 1e999) is nan "work" (and it might even be
more efficient to special-case them and return singletons rather than
allocate objects and wrap them in floats -- if they were useful, but
they're not so why bother?)

But you don't want programmers doing something == nan or something ==
inf, either.  For the former, they *have* to use math.isnan because of
how math.nan.__eq__ is defined (and of course the system is probably
delivering NaNs different from math.nan).  The latter "works"
*because* inf is a specific value (in IEEE 754), but it's nonsense
interpreted as "infinity", since in Python it mostly denotes a value
for an expression whose computation overflowed at some point but in
many cases has a value in the real number system that is representable
as a float.

 > Which means there really isn't a reason to make them keywords at
 > all.

There's the same reason as for True and False: the principle that all
values of certain fundamental types should have fixed literal
representations in the language.  The fact that there are other
objects that are equal to inf would be the same as bool: True is not 1
but True == 1.

 > we would not want to [add new values of these types] even if it
 > were even possible.

If you're referring to inf and nan, that's not clear.  We could have
inf_unrepresentable and inf_denormalized_or_unrepresentable (the
latter would be used if you want any loss of precision due to "near"
overflow to be considered inf), and nan_quiet and nan_signaling, so
that operations that in math result in a NaN will all either have a
NaN value which propagates or result in an immediate exception,
depending on whether nan is the former or the latter.[2]  I guess you
could look at NumPy and friends for evidence whether those
distinctions are ever worth making in Python programs, but at least in
theory they're possibly useful.

As for Booleans, Goedel showed that a consistent logic sufficient to
support proving theorems of arithmetic is inherently 3-valued:

A is True, A is False, A is Undecidable.

But Goedel's logic is unimplementable in our computers by the very
definition of undecidable.  Some of the most subtle Buddhist texts are
well-rationalized by a logic with four truth values for A:

A is True, A is False, A is neither True nor False, A is both True
and False.

Some Buddhists are very tolerant, they accept inconsistent logics.  Of
course, we probably don't want to use those logics in computers. :-)

Footnotes: 
[1]  I'm not saying that the integer 1 is a singleton; it's not, there
can be many distinct int objects equal to 1.  I'm saying that the int
denoted by "1" in a Python program is a singleton.

[2]  Of course these distinctions can't be made in plain Python, but
they can be made from C extensions.
___
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/43KEPOUJXAXW7YI5BYCK2PTASKL657SY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-12 Thread Steve Barnes



Indeed the usual definition of isnan reads:

def isnan(x):
return x != x




___
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/CPDLKMXMX74MIA5QFGJK2ZH6LLKB52Q3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

On Sat, Sep 12, 2020 at 02:09:11PM -1000, David Mertz wrote:
> On Sat, Sep 12, 2020, 2:02 PM Steven D'Aprano  wrote:
> 
> > In general though, Python doesn't support generating the full range of
> > NANs with payloads directly.
> 
> 
> I've researched this a little bit for discussion in a book I'm writing, and
> I have not been able to identify ANY widely used programming language or
> tool that does anything meaningful with the NaN payloads.
> 
> It's possible I've missed something, but certainly not the top 20 languages
> are libraries that might come to mind.

Alas, NAN payloads have been under-utilized. It has been a vicious 
circle: programming languages have, in general, not supported setting 
the payload, or any consistent meaning for them, so people don't use the 
feature, so programming languages don't support it, so people don't use 
it, and so on...

But back in the early 1990s, when IEEE-754 was brand new, one of the 
first platforms to support it was Apple's SANE (Standard Apple Numerics 
Environment), and they not only supported NAN payloads, but defined 
standard meanings for them. So Apple's maths libraries would parse 
strings like "NAN(123)" (by memory) and return the NAN with payload 123. 
Printing NANs would display the payload. And you could use the payload 
information to help debug what failed, e.g. 

NANSQRT = 1  # invalid square root
NANADD = 2  # invalid addition, e.g. INF + (-INF)

But when Apple moved their SANE maths libraries out of software and into 
the Motorola floating point chip, that was all lost.

-- 
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/WHKXWQSSPIG2ZGLXCNFVOKB35KFIAWGM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

On Sat, Sep 12, 2020 at 05:37:23PM -0700, Christopher Barker wrote:
> On Sat, Sep 12, 2020 at 5:05 PM Steven D'Aprano  wrote:

> > IEEE-754 requires that float literals overflow to infinity.
> 
> sure, which means that, e.g.  1e100 * 1e300 would overflow to Inf.
> 
> But that doesn't say anything about interpreting a literal. I don't if C
> libs necessarily parse:

Sorry, I didn't explain correctly. What I attempted, but failed, to say 
is that the standard requires that if the float literal cannot be 
represented as a numeric value because it would overflow, then it should 
be interpreted as an infinity.

So `1e300` can be represented as a double precision float, so that's 
what you get, but `1e1000` cannot be, it overflows, so you get infinity 
instead.

This doesn't mean that the standard requires the parser to read the 
mantissa and exponent separately and actually perform a multiplication 
and power.

I expect that the standard will require *correctly rounded* results. So 
for example, this literal rounds down to the largest possible finite 
float:

py> 1.7976931348623158e+308
1.7976931348623157e+308

but this literal rounds up to infinity:

py> 1.7976931348623159e+308
inf

because the closest representable binary number to 1.79...159e+308 would 
overflow the available bits.

> So that's what I'm wondering -- is there a standard that says the a
> too-large literal should overflow, and therefgor create and inf, rather
> than being an error.

Yep, that's what I'm saying :-)

Or at least tried to say.

-- 
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/WSNITPXWL2J2EZK35VU4EBRONDDXQDJY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-12 Thread Richard Damon

On 9/12/20 8:48 PM, Paul Bryan wrote:
> I meant to ask, why is nan not comparable? Even:
>
> >>> math.nan == math.nan
> False

It's the IEEE definition of nan, a nan will compare unequal to ALL
values, even another nan.

It is also neither greater than or less than any value.

-- 
Richard Damon
___
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/MPNZG6PXMDDLLCLMPL5R53JLPSMG2FGE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-12 Thread Paul Bryan

I meant to ask, why is nan not comparable? Even:

>>> math.nan == math.nan
False

___
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/AIKVPIUWFZW5HY5LYWYMOKSFFLH3ZFV7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-12 Thread Paul Bryan

On Sun, 2020-09-13 at 10:01 +1000, Steven D'Aprano wrote:
> If you have an INF, then you can generate a NAN with `INF - INF`.

>>> math.inf - math.inf
nan
>>> (math.inf - math.inf) == math.nan
False





___
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/BGW7ZX6RUKF2C4K7HPAVLWRIOYDIRKIQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-12 Thread Christopher Barker

On Sat, Sep 12, 2020 at 5:05 PM Steven D'Aprano  wrote:

> On Sat, Sep 12, 2020 at 12:56:25PM -0700, Christopher Barker wrote:
>
> > Is there any guarantee in Python or the C spec, or the IEEE spec that,
> e.g.:
> > 1e1
> > would create an Inf value, rather than an error of some sort?
>
> IEEE-754 requires that float literals overflow to infinity.
>

sure, which means that, e.g.  1e100 * 1e300 would overflow to Inf.

But that doesn't say anything about interpreting a literal. I don't if C
libs necessarily parse:

xxEyy

and then do xx * 10**yy, which would be an overflow, or if they do
something more direct, in which case, they *could* note that the value is
not representable and raise an error.

So that's what I'm wondering -- is there a standard that says the a
too-large literal should overflow, and therefgor create and inf, rather
than being an error.

by the way, this behavior is not consistent with python, which will give an
error, rather than returning inf when the same operation overflows:

In [22]: math.pow(10, 1000)

---
OverflowError Traceback (most recent call last)
 in 
> 1 math.pow(10, 1000)

OverflowError: math range error

So in Python, at least, interpreting the literal is not the same as
computing the pow().

-CHB






> I don't have a source for this (I cannot find a copy of the IEEE-754
> standard except behind paywalls) but I have a very strong memory of
> either Tim Peters and Mark Dickinson stating this, and I believe them.
> (If either of them are reading this, please confirm or deny.)
>
>
> > And there's still NaN -- any way to get that with a literal?
>
> If you have an INF, then you can generate a NAN with `INF - INF`.
>
> In general though, Python doesn't support generating the full range of
> NANs with payloads directly.
>
>
>
> --
> 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/LX5XVAN3FZCXBBHVKU6MGKWXZAS63Y2D/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

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/HIGHOUUIA7G4CL5EO43TMYXX56QR5ZTV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-12 Thread David Mertz

I probably should have added "user exposed" or something to my comment.
Those extra bits certainly seem to offer compiler optimization
possibilities, as apparently SpiderMonkey does with WASM.

I can easily *imagine* a library like NumPy or PyTorch deciding to expose
something useful with those 52 unused mantissa bits. But that's some future
version, if ever.

On Sat, Sep 12, 2020, 2:16 PM Cade Brown  wrote:

> As per tagged nans, check for JavaScript tagged NaN optimization.
> Essentially, the tag of the NaN (i.e. the mantissa) is interpreted as a
> pointer. Obviously, this is a very advanced use case, probably not worth
> Python guaranteeing such behavior.
> Here is one article:
> https://brionv.com/log/2018/05/17/javascript-engine-internals-nan-boxing/
>
> On Sat, Sep 12, 2020, 8:10 PM David Mertz  wrote:
>
>> On Sat, Sep 12, 2020, 2:02 PM Steven D'Aprano 
>> wrote:
>>
>>> In general though, Python doesn't support generating the full range of
>>> NANs with payloads directly.
>>
>>
>> I've researched this a little bit for discussion in a book I'm writing,
>> and I have not been able to identify ANY widely used programming language
>> or tool that does anything meaningful with the NaN payloads.
>>
>> It's possible I've missed something, but certainly not the top 20
>> languages are libraries that might come to mind.
>> ___
>> 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/FZ7QGRV5IRV2WFX6YFDO7KR5C2Y5BJHG/
>> 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/DL62J56XOFI6Z4SJ23NYF5VQGMDHK2KU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-12 Thread Cade Brown

As per tagged nans, check for JavaScript tagged NaN optimization.
Essentially, the tag of the NaN (i.e. the mantissa) is interpreted as a
pointer. Obviously, this is a very advanced use case, probably not worth
Python guaranteeing such behavior.
Here is one article:
https://brionv.com/log/2018/05/17/javascript-engine-internals-nan-boxing/

On Sat, Sep 12, 2020, 8:10 PM David Mertz  wrote:

> On Sat, Sep 12, 2020, 2:02 PM Steven D'Aprano  wrote:
>
>> In general though, Python doesn't support generating the full range of
>> NANs with payloads directly.
>
>
> I've researched this a little bit for discussion in a book I'm writing,
> and I have not been able to identify ANY widely used programming language
> or tool that does anything meaningful with the NaN payloads.
>
> It's possible I've missed something, but certainly not the top 20
> languages are libraries that might come to mind.
> ___
> 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/FZ7QGRV5IRV2WFX6YFDO7KR5C2Y5BJHG/
> 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/HEWH35252NLRDWWFU3TFAH7FWCPR4FJZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-12 Thread David Mertz

On Sat, Sep 12, 2020, 2:02 PM Steven D'Aprano  wrote:

> In general though, Python doesn't support generating the full range of
> NANs with payloads directly.

I've researched this a little bit for discussion in a book I'm writing, and
I have not been able to identify ANY widely used programming language or
tool that does anything meaningful with the NaN payloads.

It's possible I've missed something, but certainly not the top 20 languages
are libraries that might come to mind.
___
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/FZ7QGRV5IRV2WFX6YFDO7KR5C2Y5BJHG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

On Sat, Sep 12, 2020 at 12:56:25PM -0700, Christopher Barker wrote:

> Is there any guarantee in Python or the C spec, or the IEEE spec that, e.g.:
> 
> 1e1
> 
> would create an Inf value, rather than an error of some sort?

IEEE-754 requires that float literals overflow to infinity.

I don't have a source for this (I cannot find a copy of the IEEE-754 
standard except behind paywalls) but I have a very strong memory of 
either Tim Peters and Mark Dickinson stating this, and I believe them. 
(If either of them are reading this, please confirm or deny.)

> And there's still NaN -- any way to get that with a literal?

If you have an INF, then you can generate a NAN with `INF - INF`.

In general though, Python doesn't support generating the full range of 
NANs with payloads directly.

-- 
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/LX5XVAN3FZCXBBHVKU6MGKWXZAS63Y2D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-12 Thread Christopher Barker

not really relevant anyway, but the issue with using a really large literal
to get Infinity is not that some possible future system could hold really
huge numbers, but whether a too-large-for-the-implimentation literal get
evaluated as Inf at all.

Is there any guarantee in Python or the C spec, or the IEEE spec that, e.g.:

1e1

would create an Inf value, rather than an error of some sort?

It apparently works in all cases anyone in this thread has tried (and me
too), but is it guaranteed anywhere?

And there's still NaN -- any way to get that with a literal?

-CHB


On Sat, Sep 12, 2020 at 10:34 AM Steven D'Aprano 
wrote:

> On Sat, Sep 12, 2020 at 11:06:35AM -0400, Cade Brown wrote:
> > If, in the future, Python used a library such as MPFR and made all
> floats a
> > given precision (say, by giving a flag to the interpreter "python
> > -prec2048"), it would never be enough to make infinity because it only
> has
> > the limitation of a 64 bit exponent.
>
> Nobody is recommending that the best way to create an infinity is by
> writing 1e1000 or whatever other out of range number you choose.
> We're not using Python 2.4 anymore, and the correct ways to create an
> infiniy float is one of:
>
> float('inf')
> from math import inf
>
> (Or rather, most of us aren't using Python 2.4 anymore. For my sins, I
> am still maintaining code that is expected to run back to 2.4. Yay.)
>
> Using something like 1e1000 (or choose a larger exponent) is a fall back
> for when nothing else works, and if that trick doesn't work either, then
> you have no hope for it, you are running on some weird machine without
> IEEE-754 semantics and there probably isn't an infinity at all.
>
> In my own code I have something like this:
>
>
> try:
> from math import inf
> except ImportError:
> try:
> inf = float('inf')
> except ValueError:
> # Could be Windows in 2.4 or 2.5?
> try:
> inf = float('1.#INF')
> except ValueError:
> # Desperate times require desperate measures.
> try:
> inf = 1e1000
> assert inf > 0 and inf == 2*inf
> except (OverflowError, AssertionError):
> # Just give up, there is no infinity available.
> pass
>
>
> Fortunately, I don't have to support some hypothetical future Python
> with 2048 bit non-IEEE-754 floats, but if I did, I'm sure that the
> import from math would work and the rest of the nested blocks would
> never be called.
>
>
> > This is just an example of course, probably won't happen, but when I read
> > "1e1000" or such a number it doesn't strike me as infinite (although a
> > particular version of IEEE floating point may consider it that), it
> strikes
> > me as a lazy programmer who thinks it's bigger than any other number he's
> > processing.
>
> Well, I guess the code above makes me a lazy programmer.
>
>
> --
> 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/NH7O6ABMAZBTA7WOGS4NMTW3C65EYBC6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

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/JKZD3SZYFJHF35KQBLA5MKFVFJCYBMGR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

On Sat, Sep 12, 2020 at 11:06:35AM -0400, Cade Brown wrote:
> If, in the future, Python used a library such as MPFR and made all floats a
> given precision (say, by giving a flag to the interpreter "python
> -prec2048"), it would never be enough to make infinity because it only has
> the limitation of a 64 bit exponent.

Nobody is recommending that the best way to create an infinity is by 
writing 1e1000 or whatever other out of range number you choose. 
We're not using Python 2.4 anymore, and the correct ways to create an 
infiniy float is one of:

float('inf')
from math import inf

(Or rather, most of us aren't using Python 2.4 anymore. For my sins, I 
am still maintaining code that is expected to run back to 2.4. Yay.)

Using something like 1e1000 (or choose a larger exponent) is a fall back 
for when nothing else works, and if that trick doesn't work either, then 
you have no hope for it, you are running on some weird machine without 
IEEE-754 semantics and there probably isn't an infinity at all.

In my own code I have something like this:

try:
from math import inf
except ImportError:
try:
inf = float('inf')
except ValueError:
# Could be Windows in 2.4 or 2.5?
try:
inf = float('1.#INF')
except ValueError:
# Desperate times require desperate measures.
try:
inf = 1e1000
assert inf > 0 and inf == 2*inf
except (OverflowError, AssertionError):
# Just give up, there is no infinity available.
pass

Fortunately, I don't have to support some hypothetical future Python 
with 2048 bit non-IEEE-754 floats, but if I did, I'm sure that the 
import from math would work and the rest of the nested blocks would 
never be called.

> This is just an example of course, probably won't happen, but when I read
> "1e1000" or such a number it doesn't strike me as infinite (although a
> particular version of IEEE floating point may consider it that), it strikes
> me as a lazy programmer who thinks it's bigger than any other number he's
> processing.

Well, I guess the code above makes me a lazy programmer.

-- 
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/NH7O6ABMAZBTA7WOGS4NMTW3C65EYBC6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-12 Thread Cade Brown

If, in the future, Python used a library such as MPFR and made all floats a
given precision (say, by giving a flag to the interpreter "python
-prec2048"), it would never be enough to make infinity because it only has
the limitation of a 64 bit exponent.

This is just an example of course, probably won't happen, but when I read
"1e1000" or such a number it doesn't strike me as infinite (although a
particular version of IEEE floating point may consider it that), it strikes
me as a lazy programmer who thinks it's bigger than any other number he's
processing. I've added this case to my PEP .rst file and why it's not a
good solution

Thanks,
Cade

On Sat, Sep 12, 2020, 8:25 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Guido van Rossum writes:
>
>  > I don't actually understand why Stephen made this claim about
>  > arithmetic operations,
>
> Stephen is often mistaken about computers (among many topics).  That's
> why he mostly posts on -ideas, and mostly throws drafts away rather
> than post them. :-)
>
> I would not claim that evaluating a literal such as 1e1000 is not an
> arithmetic operation, I just "forgot" that these examples exist
> (mostly in a context of trying to get NaN with math.asin(2) and got
> ValueError instead ;-/ ).
>
> I still stand by the argument that since some common ways of producing
> true infinities (rather than overflows) and NaNs such as 1.0/0.0 and
> 0.0/0.0 end up as Exceptions rather than float values, inf and nan
> have rather small usefulness in Python with only builtins, especially
> nan.  "from math import inf" has to be the least annoying thing about
> working with infinities and overflows in Python (which, to be fair, is
> quite annoying in any context, on computers or on paper).
> ___
> 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/22TKQDJV4PNMOK5KUAX74QHX3KP74XCT/
> 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/PBFPTMQ3M4TWI6PFR7DNBD5QH2JOCUQW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

2020-09-12 Thread Stephen J. Turnbull

Guido van Rossum writes:

 > I don't actually understand why Stephen made this claim about
 > arithmetic operations,

Stephen is often mistaken about computers (among many topics).  That's
why he mostly posts on -ideas, and mostly throws drafts away rather
than post them. :-)

I would not claim that evaluating a literal such as 1e1000 is not an
arithmetic operation, I just "forgot" that these examples exist
(mostly in a context of trying to get NaN with math.asin(2) and got
ValueError instead ;-/ ).

I still stand by the argument that since some common ways of producing
true infinities (rather than overflows) and NaNs such as 1.0/0.0 and
0.0/0.0 end up as Exceptions rather than float values, inf and nan
have rather small usefulness in Python with only builtins, especially
nan.  "from math import inf" has to be the least annoying thing about
working with infinities and overflows in Python (which, to be fair, is
quite annoying in any context, on computers or on paper).
___
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/22TKQDJV4PNMOK5KUAX74QHX3KP74XCT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python