PEP239 (Rational Numbers) Reference Implementation and new issues
Paul Rubin
phr-n2002b at NOSPAMnightsong.com
Wed Oct 2 19:20:35 EDT 2002
More information about the Python-list mailing list
Wed Oct 2 19:20:35 EDT 2002
- Previous message (by thread): PEP239 (Rational Numbers) Reference Implementation and new issues
- Next message (by thread): PEP239 (Rational Numbers) Reference Implementation and new issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
python-pep at ccraig.org writes: > 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. No--on the theory that 3/2 == 1.5 in future division for the benefit of newbies who get confused by 3/2 == 1 as we're used to from int arithmetic. Future division returns floats because that's what non-programmers are used to from BASIC and spreadsheets. They don't expect rationals, so rationals aren't the right thing. > 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). Unless there's a good reason to do something different, follow existing standards, e.g. do what Scheme or Common Lisp does in these situations.
- Previous message (by thread): PEP239 (Rational Numbers) Reference Implementation and new issues
- Next message (by thread): PEP239 (Rational Numbers) Reference Implementation and new issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list