[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-08-27 Thread Mark Dickinson
Mark Dickinson added the comment: Fixed for Python 3.8. Thank you! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ _

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-08-27 Thread Mark Dickinson
Mark Dickinson added the comment: New changeset 393f1ff62e032f20adaed2613a9e2d2d6bcb1eb3 by Mark Dickinson (Elias Zamaria) in branch 'master': bpo-32968: Make modulo and floor division involving Fraction and float consistent with other operations (#5956) https://github.com/python/cpython/com

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-08-26 Thread Elias Zamaria
Elias Zamaria added the comment: I updated my GitHub username. For the record, it used to be mikez302, and now it is elias6. -- ___ Python tracker ___ ___

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-08-25 Thread Mark Dickinson
Change by Mark Dickinson : -- assignee: -> mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-08-25 Thread Mark Dickinson
Change by Mark Dickinson : -- versions: -Python 3.6, Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-08-25 Thread Mark Dickinson
Mark Dickinson added the comment: Sorry that I've taken so long to get back to this. I've just updated the PR, and I think it's ready to go. Looks like it does need you to update your GitHub username here in the "Your Details" section of the bugtracker, though; sorry about that. > If we can

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-23 Thread Elias Zamaria
Elias Zamaria added the comment: Mark, you have some good points. I didn't fully think about the implications of my change. I undid the change to _operator_fallbacks. I updated the tests to expect 1.0 // 1/10 to equal 9.0 and 1.0 % 1/10 to equal 0.09995. That latter number seems a

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-19 Thread Mark Dickinson
Mark Dickinson added the comment: > Mark, I tried `Fraction(10**23) // 1e22`, and I got 10. Sorry: that result was with your PR (as it was at the time I wrote that comment). On master, you do indeed get 10. > I think the fact that floating-point rounding error sometimes causes > strange resul

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-15 Thread Elias Zamaria
Elias Zamaria added the comment: Mark, I tried `Fraction(10**23) // 1e22`, and I got 10. Your `10**23 // 1e22` example was strange, but then `int(1e23)` and got 1611392. That is kind of unexpected but I think it is rare for anyone to do something like that with numbers that bi

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-15 Thread Mark Dickinson
Mark Dickinson added the comment: Yes, that sort of thing is going to happen as soon as floating-point enters the mix. There will be surprises from Fraction % float as well as float % Fraction: >>> from fractions import Fraction >>> Fraction(10**23) // 1e22 9.0 And that's again surprising, be

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-14 Thread Elias Zamaria
Elias Zamaria added the comment: Mark, what you described (operator_fallbacks for both __rfloordiv__ and __floordiv__, and for both __rmod__ and __mod__) was my initial approach. But that broke one test (which floor-divides 1.0 by 1/10 and expects the result to be an integer). I thought about

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-14 Thread Mark Dickinson
Mark Dickinson added the comment: Thanks for the PR (and apologies for being slow to look at it). I think we want to use the operator_fallbacks approach for both __rfloordiv__ and __floordiv__ (and similarly for __rmod__ and __mod__), else we'll get inconsistent results: >>> Fraction(3) // 5.

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-05 Thread Elias Zamaria
Elias Zamaria added the comment: Done. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-05 Thread Mark Dickinson
Mark Dickinson added the comment: Elias: please do go ahead and update your PR. -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-02 Thread Elias Zamaria
Elias Zamaria added the comment: Any suggestions as to what I should do? I can either update my pull request with my floordiv change, or create a new pull request, or wait a while to see if anyone else has any opinion on changing the behavior. -- _

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-02 Thread Mark Dickinson
Mark Dickinson added the comment: [Elias Zamaria] > I see exactly that. Understood; that's how I interpreted your "changed one test to make sure that it works". It seems we understand each other. :-) So yes, one always needs to be very cautious about changing deliberate, tested behaviour. B

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-01 Thread Elias Zamaria
Elias Zamaria added the comment: I added the pull request. It includes only my changes to modulo, and not the ones to floordiv. -- ___ Python tracker ___ _

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-01 Thread Elias Zamaria
Change by Elias Zamaria : -- keywords: +patch pull_requests: +5721 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-lis

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-01 Thread Elias Zamaria
Elias Zamaria added the comment: Mark, you said "if there's a test that's explicitly checking that `my_fraction // my_float` returns something of type `int`, then the behaviour is clearly intentional". I see exactly that. See https://github.com/python/cpython/blob/bf63e8d55fd2853df3bb99d66de7

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-01 Thread Mark Dickinson
Mark Dickinson added the comment: Serhiy: I think both those results are reasonable, and not too surprising. It should be easy to understand that the mixed-type operation converts one of the arguments to float, and if that conversion overflows we get an exception. A similar thing happens when

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-01 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: Not all Fractions can be converted to float. >>> Fraction(2**2000, 3) // 1.0 Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/fractions.py", line 432, in __floordiv__ return math.floor(a / b) File "/home/serh

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-01 Thread Mark Dickinson
Mark Dickinson added the comment: > I'd argue against such a change in any case And apparently I already did: see issue 22444 for previous discussion on the topic. -- ___ Python tracker

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-03-01 Thread Mark Dickinson
Mark Dickinson added the comment: > It would be a bit strange if mod with a float returns a float and floordiv > with a float returns an int. Agreed: if there are floats involved (Fraction // float or float // Fraction), I think the rule should be that we simply fall back to float behaviour,

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-02-28 Thread Elias Zamaria
Elias Zamaria added the comment: Mark, you have some good ideas. A fraction modulo a float is a float, and an integer modulo infinity produces itself as a float, so it seems reasonable that a fraction modulo infinity should be itself converted to a float. I tried assigning __mod__ and __rmod_

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-02-28 Thread Mark Dickinson
Mark Dickinson added the comment: I'm not quite sure why `Fraction_instance % float_instance` wouldn't simply convert the `Fraction` to a `float` and then use the usual floating-point mod. There's the issue that you want to maintain consistency with the floordiv operation, but if `Fraction_in

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-02-27 Thread Ned Deily
Change by Ned Deily : -- nosy: +mark.dickinson, rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue32968] Fraction modulo infinity should behave consistently with other numbers

2018-02-27 Thread Elias Zamaria
New submission from Elias Zamaria : Usually, a positive finite number modulo infinity is itself. But modding a positive fraction by infinity produces nan: >>> from fractions import Fraction >>> from math import inf >>> 3 % inf 3.0 >>> 3.5 % inf 3.5 >>> Fraction('1/3') % inf nan Likewise, a pos