I have commented on Steven's comments about alephs below.
It seems to me that this discussion (on having "different" infinities and allowing/storing arithmetic on them) is dead-on-arrival because:
- the scope of people who would find this useful is very small
- it would change current behaviour
- it would be unusual/a first among (popular) programming languages*
- consistency is basically impossible: as somebody pointed out, if you have a (Python) function that is 1 / (x ** 2), will the outcome be (1/0)**2 or just 1/0? (1/0)**2 is the consistent outcome, but would require implementing zeros with multiplicity...
This would also create problems underlying, because Python floats (I guess) correspond to the C and CPU floats, so performance and data structure/storage (have to store additional data beyond a C(PU) float to deal with infinities and their size, which would be unbounded if you e.g. allowed exponentials as you would get into things like Cantor Normal Form (
https://en.wikipedia.org/wiki/Ordinal_arithmetic#Cantor_normal_form)).
I honestly think this way lies madness for the floats of a general purpose programming language.
* of course, somebody has got to be first!
Oops, I messed up. (Thanks David for pointing that out.)
On Sun, Oct 18, 2020 at 07:45:40PM +1100, Steven D'Aprano wrote:
> 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
I conflated what I was thinking:
# note the change in comparison
2**aleph_0 > aleph_0
2**aleph_1 > aleph_1
2**aleph_2 > aleph_2
...
which I think is correct regardless of your position on the Continuum
Hypothesis (David, care to comment?),
with this:
2**aleph_0 = aleph_1
2**aleph_1 = aleph_2
2**aleph_2 = aleph_3
...
which is only true if the Continuum Hypothesis is true