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.

marcus