-
Notifications
You must be signed in to change notification settings - Fork 1.3k
int(1.0/7*7) == 0 ??? #1220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
FYI
but
|
It may print as
|
interesting
|
4.0.0 on M4 is still the same:
Not sure what the difference is: it might be a compilation flag or some setup of the floating point unit. I thought both nRF and Atmel used the same conversion routines, so I'm a little surprised, but ma7be the don't. |
I thought this might be because we are using the MicroPython-supplied |
This is the gist of the code from datetime.py that I work on: import math as _math
class timedelta:
def __new__(cls, days=0, seconds=0, microseconds=0,
milliseconds=0, minutes=0, hours=0, weeks=0):
days += weeks*7
if isinstance(days, float):
dayfrac, days = _math.modf(days)
d = int(days)
else:
d = days
self = object.__new__(cls)
self._days = d
return self The test wants these to be equal:
Any idea how I can achieve that in a general way under the current circumstances? |
In floating point math, it's not generally true that Here's a similar "problem" on desktop Python 3.5.3:
In this case, the duration is reported as 2 microseconds longer than 7 days. If this problem is arising from a doctest, I suggest that perhaps the doctest could be rewritten so that it asserts that a timedelta of 1/7 weeks is close to a timedelta of 1 day, instead of asserting that it is equal exactly. For instance, you could assert that both are within 1 second of each other via the |
Thanks for the explanation, floats and its lack of precision keep tripping me up. Thanks all. Example of the (im)precision showing the value I need to use to get exactly one day as a result:
|
class TestTimeDelta(HarmlessMixedComparison, unittest.TestCase):
def test_constructor(self):
# Check float args to constructor
+ def aeq(td1, td2): ### Handle float imprecision
+ self.assertAlmostEqual(td1.total_seconds(), td2.total_seconds(), delta=1)
- eq(td(weeks=1.0/7), td(days=1))
+ aeq(td(weeks=1.0/7), td(days=1))
- eq(td(days=1.0/24), td(hours=1))
+ aeq(td(days=1.0/24), td(hours=1))
- eq(td(hours=1.0/60), td(minutes=1))
+ aeq(td(hours=1.0/60), td(minutes=1))
eq(td(minutes=1.0/60), td(seconds=1))
eq(td(seconds=0.001), td(milliseconds=1))
eq(td(milliseconds=0.001), td(microseconds=1)) |
I'm working on converting the datetime module and came across this.
Is it a known limitation or a bug?
The text was updated successfully, but these errors were encountered: