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:
CLASSES builtins.object Number Complex Real Rational Integral
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 Decimal('1.10000000000000000555111512312578270211816')
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) Decimal('1.1')
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.