On Wednesday, March 5, 2014 7:56:46 AM UTC-6, Steven D'Aprano wrote:

On Tue, Mar 04, 2014 at 07:42:28PM -0800, Mark H. Harris 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.

What makes this a "python number"? In what way are they "dynamic"?

At this point in the discussion please try not to think "implementation," rather think

conceptually in an open framework where anything is possible. Dynamic in terms

of python numbers is not that far off from the concept of dynamic name binding used

everywhere else in python.

In terms of unifying numbers as python numbers which needs to be defined at some

point, the idea of dynamic binding means first that numeric symbol sets have no type,

and are not 'bound' until run-time, if at all. Consider:

What is this? ===> PI / 2

Is it two numbers with a divisor,? or a Decimal and an int with a divisor,? or a python number ?

Or, is it a string of characters that are readily recognizable to humans that means 'the top of

the unit circle," or half_of_PI whatever I mean by that, or '1.57079632679489661923132169163975144209858469968755291048747229615390820314'

Dynamic means the symbols sets are bound (name-wise, abstraction-wise) only at run-time, and

with some 'smarts' as it were (AI) so that the right things happen under the covers (not magic)

because the machine has been taught to think, as it were, about numbers and symbols the way

normal humans do (in the kitchen, at high school, at the university, in science and business).

Another way to think of this Steven is to think of 'pretty print' on the TI 89 Platinum edition

graphical programming calculator (my personal favorite). Anyone who plays with it the first time

is frustrated because numbers are symbolized instead of printed out in strings of numerals. So

if I enter {1} [/] {3} and press enter, I get 1/3 <====

Yes, I can press evaluate and get .33333333333333333 but 1/3 is just as good a number as

any other number (and what type is it???) PI / 2 is another example. That's a great number and

I don't really need to see a numeric list of digits to use it, do I... and what is its type??? who cares.

Another very simple (and not quite good enough) example is the pdeclib file I just created over the

past couple of days. I have a need within the module to use PI or half_PI for some method or

function (but I don't need the user to know that, and I don't want to calculate it over and over, and

I want it within accuracy for the context on demand)... so what? I created __gpi__ global PI. It is

reset to Decimal(0) if the dscale(n) precision context changes. Then, and function that requires PI

of half_PI can check first to see if it is cached as __gpi__ and if so pull it back, or if not calculate

it. If the context does not change than I half some whopping value of PI for the duration of the

context (but, and this is the big but, if I don't need it --- then it never gets bound).

Binding for python numbers must be dynamic, typeless, limitless, and no constraints. If I enter a

formula of symbols into python (whatever I mean by that) python just handles it dynamically just

like the TI 89--- if I want explicit control of the processing, I am free to ask for that too, just like

the TI 89.

By the by, complex numbers are no different what-so-ever, nor fractions either, nor any other number.

The system needs to be able to parse symbol sets intelligently (Alonzo Church, Alan Turning, and John

McCarthy dreamed of this, but had no way to accomplish it in their day) and then dynamically bind

the naming / representation to the abstraction (or implementation) that makes sense for that symbol

set in 'that' context, for 'that' problem. This is not simply business as usual... it requires AI, it requires

a severe paradigm shift of a very high order.

Kind regards,

marcus