On Thursday, March 6, 2014 4:41:08 PM UTC-6, Chris Angelico wrote:

What does your proposed hierarchy offer that numbers.Number doesn't?

hi Chris,  numbers.Number is the right concept, but not the correct relationship...
in sixty's vernacular, its the right hoo hoo but the wrong tah tah...

Here is the numbers.Number hierarchy:


Compare numbers.Number with my proposal. (I am not wanting to go into semantics at
this point, but the numbers.Number model is not unified and has problems.  If it were
ok, we would not be having this discussion. )  The age old question, "How's that working
for you?"   Well, not too well.  

Chris, its not just the virtual function table, its also operator overloading, and its policy 
handled by (AI) that intelligently decides what to do if someone tries to add a real_b with
a real_d.   But, it should not do this:

>>> from pdeclib import *
>>> x=1
>>> y=Decimal(.1)
>>> x+y

The policy hidden under the abstraction way down in the guts of the Class
hierarchy should make the decision to do this:

>>> ====== RESTART =====
>>> from pdeclib import *
>>> x=1
>>> y=.1
>>> def add_(x, y):
return d(x)+d(y)

>>> add_(x, y)

Please don't pick at this.  The point is not the code or the syntax. The point
is that the policy in a correctly related Class hierarchy can handle somebody
asking the system to add a  1.23b with a 1.23d , and if setup correctly, will 
just work. 

The idea is to unify numbers, so that efficient intelligent processing can occur
without "types" or "limits".

I'll say more later... after we see how folks respond.