Why can't you exactly divide a year-long interval by days?

[hadley]

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?

[garrettgman]

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,

today <- today()
next_yearish <- today() + years(1) + days(1)

(today %--% next_yearish) / months(1)

Perhaps the message should just say something like, "Performing %/%; convert denominator to an interval or duration if you want a remainder."

[garrettgman]

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,

today <- today()
next_yearish <- today() + years(1) + days(1)

(today %--% next_yearish) / months(1)

Perhaps the message should just say something like, "Performing %/%; convert denominator to an interval or duration if you want a remainder."

[vspinu]

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]

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]

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.

[vspinu]

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]

Yeah, I think it's a reasonable change.

[hadley]

Yeah, I think it's a reasonable change.