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,