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

[Chris Angelico]

On Wed, Mar 5, 2014 at 2:42 PM, Mark H. Harris <harrismh777 at gmail.com> wrote:
>    The idea of python number means that there are no types, no limits, no
> constraints, and that all python numbers are dynamic. The upper level
> syntax is also very simple; all python numbers are simply human.
>
>    My influence for this preference is rooted in the Rexx programming
> language; attributed to Mike Cowlishaw, former IBM fellow. The Rexx
> programming language is dynamic, and has no types. To put it more
> succinctly for those of you who have not used Rexx, the only data type
> is a string of characters (that's it).  Rexx numbers are simply those
> strings of characters that may be interpreted as a valid Rexx number.

I've used REXX extensively. (It's the native scripting language of
OS/2, which I first met in the early 1990s and am still using - albeit
usually in a VM under Linux these days - as it's still a good thing,
just a little left-behind.) There are two huge downsides to that kind
of proposal.

1) Performance. Huge huge performance hit. I can take Pike to OS/2, an
unoptimized build on an unsupported platform, and absolutely cream a
REXX program at any sort of computational work. By specifically
working with integers rather than "numbers", I can run code blazingly
fast.

2) Accuracy. With REXX, all arithmetic is governed by a single setting
of NUMERIC DIGITS, which specifies how many digits of accuracy you
want to preserve. (Python can improve granularity with separate
contexts, but the same issue will still apply - contexts just let you
use different NUMERIC DIGITS settings simultaneously in one program.)
Set it too high and performance suffers because the system has to
calculate more than you actually care about. Set it too low and
accuracy suffers. Even when you're working with integers, going past
DIGITS means it goes exponential.

3) Not so huge a downside, but also worth considering: REXX doesn't
have complex number support at all. You have to simulate it with two
variables. There's no way for the "Python number" system to
intrinsically handle complexes.

So really, what you're looking at is unifying int/float/Decimal into a
single data type, which is basically Decimal. I'd say merging int into
that is a bad idea, but you can get most of what you want to achieve
simply by encouraging the use of Decimal everywhere.

Maybe in some distant future version, the Python literal 1.234 will
represent a Decimal rather than a float. (And then there'd be other
consequences, like what you get when you divide one integer by
another.) But until then, all you can really do is encourage people to
explicitly use Decimal.

ChrisA