Nope, this time I really have nothing more to say. On Mon, Oct 19, 2020, 9:22 AM Paul Moore <p.f.mo...@gmail.com> wrote:
> Wes, you seem to just be throwing out a load of questions, to all of > which my answer is "I don't know" (and usually "I don't care either"). > > Do you have an actual proposal here, and if so could you state it > clearly and in the form of a description, not a question, please? I'm > struggling to find anything useful in your posts at the moment. > > Paul > > On Mon, 19 Oct 2020 at 13:10, Wes Turner <wes.tur...@gmail.com> wrote: > > > > Which [Python,] CAS support transfinite and/or surreal numbers and/or > other piecewise axioms for an infinity symbol? > > > > Are they vectorizable? > > > > What's wrong with substituting a standard symbol for infinity (instead > of prematurely discarding e.g. coefficients/scalars and exponents)? > > > > https://github.com/sympy/sympy/wiki/SymPy-vs.-Sage#functionality > > > https://github.com/sympy/sympy/wiki/SymPy-vs.-Sage#some-syntax-differences > sympy.Symbol('Inf') sage. var('Inf') > > > > Should CPython try to be a CAS? > > > > > > On Mon, Oct 19, 2020, 7:36 AM Henk-Jaap Wagenaar < > wagenaarhenkj...@gmail.com> wrote: > >> > >> 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! > >> > >> On Sun, 18 Oct 2020 at 23:03, Steven D'Aprano <st...@pearwood.info> > wrote: > >>> > >>> 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?), > >> > >> > >> Yes, due to Cantor's diagonal argument: > https://en.wikipedia.org/wiki/Cantor%27s_diagonal_argument > >> > >> > >>> > >>> 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 > >> > >> > >> *generalized* Continuum Hypothesis, and in fact it isn't "only true if > (G)CH" is much stronger, it is in fact the same statement (if your "..." > means "for all ordinals" as GCH (CH is just the first one of those). See > https://en.wikipedia.org/wiki/Continuum_hypothesis#The_generalized_continuum_hypothesis > . > >> _______________________________________________ > >> 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/Z67R35LP7VT5UJA7F7ZTBGHTERK33IEJ/ > >> 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/76V2ICZM6SQL66ZFW65I66AK5XFPUKQB/ > > 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/LBOGM3UB7TYGSJWQDKAJEOFQDWSVY6W4/ Code of Conduct: http://python.org/psf/codeofconduct/
