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

[Mark H. Harris]

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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140305/8a485596/attachment-0001.html>