On Tuesday 2004-08-10 14:35, Skip Montanaro wrote: > > >> I think it would be worth considering all the numeric types at once > >> and come up with a reasonable hierarchy that includes float, complex > >> and decimal types as well. (It's clear there is no "best" way to do > >> that.) > > Dmitry> Something like following? > > Dmitry> object > Dmitry> numeric > Dmitry> integer > Dmitry> int > Dmitry> long > Dmitry> float > Dmitry> complex > > At some level it seems that float is a specialization of complex (w/ imag > field == 0). Also, it's not clear that float or complex don't have > something other than a sibling relationship to integers. Start by thinking about the mathematical types, which have nice clear subset relationships between them: number complex real integer Python doesn't have anything between "number" and "complex" and there's no particular reason to think it ever will, so let's simplify: number real integer Now consider the different implementation types and fit them in: number complex real (Decimal) float integer int long I've reintroduced "complex" here as a name for the implementation type, which in some sense should really be called complex_float or something like that. By way of clarification of the principles here, this is what would happen to the hierarchy if Python were to acquire a type for ratios of integers. I'll call that type "fraction" and the underlying mathematical type "rational". Then we'd get: number complex real (Decimal) float rational fraction integer int long (You could argue that floats are rationals really, but that's misleading even though it's true. The *structure* of arithmetic operations on floats isn't the same as that on rationals.) -- g
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4