You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Why can't you exactly divide a year-long interval by days? #445
today<- today()
next_year<- today() + years(1)
(today %--% next_year) / days(1)
#> Remainder cannot be expressed as fraction of a period.#> Performing %/%.#> estimate only: convert periods to intervals for accuracy#> [1] 365
I think the warning "convert periods to intervals for accuracy" is also spurious. What period am I supposed to convert?
I think this is a poorly written attempt to warn people away from / with periods (which does not have a precise definition) to %/% which has a precise definition.
/ doesn't have a precise definition because there is no clear rule about how the arithmetic operator should return the remainder in cases like this,
I actually started removing those messages here and there. It's more annoying than helpful. The approximate computation with periods is stated in the docs in multiple places, so people who use those should be already aware of pitfalls.
Given that for a bulk of arithmetic operations with shorter periods is exact and that we currently use surpressWarnings to hide these warnings in a bunch of places, maintaining these warnings appears wrong to me.
So, unless you object I am removing them and adding methods for some arithmetic operations with periods which currently throw errors.
Activity
garrettgman commentedon Jul 27, 2016
I think this is a poorly written attempt to warn people away from
/with periods (which does not have a precise definition) to%/%which has a precise definition./doesn't have a precise definition because there is no clear rule about how the arithmetic operator should return the remainder in cases like this,Perhaps the message should just say something like, "Performing %/%; convert denominator to an interval or duration if you want a remainder."
vspinu commentedon Jul 28, 2016
I actually started removing those messages here and there. It's more annoying than helpful. The approximate computation with periods is stated in the docs in multiple places, so people who use those should be already aware of pitfalls.
vspinu commentedon Aug 2, 2016
Given that for a bulk of arithmetic operations with shorter periods is exact and that we currently use surpressWarnings to hide these warnings in a bunch of places, maintaining these warnings appears wrong to me.
So, unless you object I am removing them and adding methods for some arithmetic operations with periods which currently throw errors.
hadley commentedon Aug 3, 2016
Yeah, I think it's a reasonable change.