> 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 [ESR] > +1 for returning rationals. It's the right thing -- and if it fails, > it will fail noisily, right? Not clear at all. ABC did this, and we found that a common problem was that a program doing numeric stuff would run very slowly (i.e. the opposite of failing noisily). How are you going to print rationals? If str(1/3) (and hence print 1/3) or repr(1/3) will return "1/3", that is surely going to cause a huge amount of breakage. > > 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. It's not at all clear that that's the right solution. The problem with a fuzz variable is that there's only one, and library modules may end up fighting over the right value for what they are trying to accomplish. Making it a per-module variable causes the opposite set of problems. I'm all for adding rationals to the language -- but I'd like them segregated until we have a lot more experience with how they behave. --Guido van Rossum (home page: http://www.python.org/~guido/)
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