[Python-ideas] Python Numbers as Human Concept Decimal System

[Cameron Simpson]

On 06Mar2014 19:53, Mark H. Harris <harrismh777 at gmail.com> wrote:
> On Thursday, March 6, 2014 8:53:35 PM UTC-6, Andrew Barnert wrote:
[... lots of stuff, snipped along with Mark's replies ...]
> > You proposed some complicated AI-based solution to solve the problem of 
> > using separate number classes in a single expression, even though Python 
> > (almost exactly like C++, in this case) has already solved that problem 
> > with operator overloading. 
> 
>         No, I did not.  I suggested that unifying numbers in an (AI) way 
> could solve this problem (conceptually) by 
> regarding all numbers as *PythonNumbers. *Decimals should not only be 
> default, they should be integrated, not
> tacked on with duck tape. 

This sounds to me like keeping the original numeric text around and
only turning it into some efficient-for-a-machine representation
when it comes time to work on it.

One issue with that is that when the work occurs, it can be far
from where the number was defined, and the correct internal
representation might be poorly chosen.

> > (And note that Python is flexible enough that third-party libraries can 
> > easily insert new types like quaternions, matrices, symbolic expressions, 
> > etc. into the hierarchy in a way that's transparent to end users. I can 
> > multiply a NumPy matrix of float64 values by the builtin in 2 just by 
> > writing "m * 2", and it works exactly the way you'd want it to. It's hard 
> > to imagine that would be even feasible with an AI-based solution, but with 
> > the current design, that's the easiest part of NumPy.) 
> 
>        That's nice for you.  Because  sqrt(.23709)  does not behave as I 
> expect, sadly, I have to train my users to enter  sqrt('0.23709'). 

That's partly because .23709, in current python, becomes an IEEE float with some loss of precision
because binary fractions and base-10 fractions do not round trip.

But also partly because sqrt() (in the pure mathematical sense)
often produces transcendental numbers,
which are not representation by any fixed precision intergal base
notation - effectively IEEE floats and Decimal floats are
fractions/rationals.

So sqrt() will, for almost all numbers, involve loss of precision
no matter what base your backing storage is: base 2 as in IEEE float
or base 10 as in a Decimal. Steven (or Stephen) has already pointed
this out to you; perhaps it has been missed.

And going back (eg sqrt(2.01)*sqrt(2.01) ==> not-quite-2.01) just
extends this loss of precision.

This is an inherent problem unless sqrt() doesn't convert to a
"concrete" type, and instead just lurks as some symbolic representation,
so that any expression involving it becomes a progressively more
elaboration representation of an algebraic expression. Which may
be correct, but only until you try to evaluate it to get a concrete
number again.

> > There are some ideas in your posts that are worth responding to, 
> 
>         Thank you.  If a user goes to the time and trouble to present an 
> idea clearly, I would expect the responders 
> to respect the effort and respond to the points that make sense.

Many people have. You should see the short shrift some ideas receive.

I think part of the problem is not your wish for a "number" but that lack
of a concrete proposal to implement it.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au>

The Usenet is not the real world. The Usenet usually does not even resemble
the real world. - spaf at cs.purdue.edu