python-pep@ccraig.org <python-pep@ccraig.org>: > I just uploaded a reference implementation of how rationals might look > in Python as patch 617779 [1]. I do have some new issues for > discussion that I'd like to get some comments on before I change the > PEP. > > 1) Should future division return rationals rather than floats. I had > sort of assumed this would happen, but I just had a discussion with > Kirby Urner and couldn't convince him it was a good idea, so I guess > it isn't so clear. > > Arguments for: > - you don't lose precision on divides > - It provides a really nice way to specify rationals (i.e. 1/3) > - It allows you to eventually unify int/long/rationals so that > rationals with a denominator of 1 are automagically upcast. > > Arguments against: > - people who have already changed their code to expect floats will > have to change it again > - rationals are slow +1 for returning rationals. It's the right thing -- and if it fails, it will fail noisily, right? > 2) Should floats compare equal with rationals only when they are > equal, or whenever the are the closest float? (i.e. will .2 > compare equal to rational(1, 5)) > > 3) Should rationals try to hash the same as floats? My leaning on > this is that it will be decided by (2). If they compare equal when > 'close enough' then they should hash the same, if not then they should > only hash the same when both are integral. I would rather not see .5 > hash with rational(1, 2) but not .2 with rational(1, 5). APL faced this problem twenty-five years ago. I like its solution; a `fuzz' variable defining the close-enough-for-equality range. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
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