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

[Steven D'Aprano]

On Thu, Mar 06, 2014 at 07:53:15PM -0800, Mark H. Harris wrote:
[...]
> because it might be expected that the user should know how to construct 
> Decimals, and 
> could be educated to construct them properly--> Decimal('0.1');  I concur.
>        It is worse in these two scenarios (and others too):
>             sqrt(.1)
>             sin(.1)

Decimal won't save you in those two cases.

For square roots, the result is usually a surd, an irrational number. 
The only way to store surds exactly is to store it symbolically. 
Should we try to turn Python into Mathematica?

In the case of sines, the same applies. While it is possible to 
calculate exact rational values for some angles, but for most the 
calculation rapidly becomes untenable, and in general trigonometric 
values are irrational, like surds.


>        No one would expect that the user should know to quote the 
> number---when is that ever done?

OF COURSE WE DO. This is a programming language, not a calculator.

We expect users -- programmers -- to know how to write functions, define 
classes, import modules, use regular expressions, call external 
processes, and so on. In other words, we expect them to know how to 
program.

>        QED   this is broken. 

No it is not.

Another factor you are not taking into account is that there is a reason 
that the computer industry has standardised on base-2 floats rather than 
10. 30 years ago, it was quite common to find applications using some 
variant of Decimal, perhaps using BCD (binary coded decimal) as their 
native numeric format. Going back even further, computers were built 
using decimal-based hardware:

http://en.wikipedia.org/wiki/Decimal_computer

But people moved to binary for multiple reasons:

- it's cheaper;

- it's faster;

- it's less surprising.


For example, between 1 and 100000, about 12% of integer-valued floats 
fail the "1/(1/n) == n" test, but over 51% of the integer-valued 
Decimals:

py> from decimal import Decimal as D
py> sum(1/(1/n) != n for n in range(1, 100001))
11846
py> sum(1/(1/D(n)) != n for n in range(1, 100001))
51665


Likewise we can test how many fail the "(1/n)*n == 1" test:

py> sum((1/n)*n != 1 for n in range(1, 100001))
13117
py> sum((1/D(n))*n != 1 for n in range(1, 100001))
36806

13% for floats versus 36% for Decimals.


One more to prove it isn't a fluke: the "sqrt(n)**2 == n" test:

py> sum((n**0.5)**2 != n for n in range(1, 100001))
49544
py> sum((n**D("0.5"))**2 != n for n in range(1, 100001))
71303


That's three for three in favour of binary floats.


[...]
>        Yes, and at a bare minimum, that is the immediate change I have been 
> asking for, for now; nothing more.

You're not going to get an immediate change, no matter how solid the 
case you ask for, no matter how logical the argument. Python 3.4 is not 
receiving any new features. The earliest this could come out is 3.5, in 
about 18 months or so.


>        I answered Guido's questions in hopes that he might be willing to 
> dialogue --- not dismiss.

You've had at least three emails from Guido. That's three more than most 
radical or wild ideas receive. The fact that so many people are 
continuing to discuss this with you is proof that we recognise that 
computer maths is hard and unintuitive. But just because you have 
identified a problem doesn't mean that your answer is a solution.


[...]
> > 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. 

It's statements like this that strongly suggest that you don't really 
understand how numbers work in computer programming. Or the practical 
limitations of what is *possible*. And as soon as you start talking 
about using an AI to decide what value the user intended, you've entered 
crackpot territory.

Speaking of AIs, perhaps you ought to see what Wolfram Alpha is capable 
of:

https://www.wolframalpha.com/input/?i=%28square+root+of+2.01%29+to+the+power+of+2

Not surprisingly for something with Mathematica behind it, it gets the 
exact right answer. Do you understand why Python the language cannot 
duplicate Mathematica's abilities with symbolic maths? Hint: it's not 
because it isn't technically possible. See, for example, libraries 
like sympy.



-- 
Steven