[Guido] > I don't think Python needs the full matrix of exact and inexact > versions of all kind of numbers. I see not enough need for inexact > ints or rationals, nor for exact floats or complex numbers. #i3 is "an inexact integer" in Scheme, but that says nothing about how it's *implemented*. In fact, it's almost certainly implemented as a float, much as #e3.0 is almost certainly implemented as an integer. Scheme hides the internal implementation, so that the programmer doesn't need to care; the flip side is that programmers who do care can't force the issue in a portable way. > So I'd like to continue our partition of numeric types as follows: > > exact | inexact > ------------------------------------ > int/long rational | float complex > > But we can do this, which is pretty much what Tim proposes in the end: > > 1 -> int > 1.0 -> float > > 1r -> rational > 1.0r -> rational Yes, that's exactly what I was proposing. s/r/#i/ and it's the same as Scheme's rules, although Scheme doesn't promise anything about internal representation. > If we ever add a fixed-point decimal type, that could use 'f' for a > suffix. If we ever add a floating-point decimal type (like the one > Aahz is working on -- I mistakenly called it a fixed-point type > before) then it could use 'd' as a suffix, or it could become the > default and we could use 'b' as a suffix to get binary floating point. Etc. > But I also agree with a recent trend in this thread: let's not rush > to add syntax. Let's first add rationals to the library. > > I hereby declare this thread closed. (Ha, ha. :-) You should have put that sentence first -- my editor still doesn't go backwards <wink>.
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