Closed quinnj closed 10 years ago
The typical usecase for division, I'd imagine would be date(x) - date(y)/ year(1)
. You'd want to multiply the result by something (eg, interest rate), which begs the question of whether the result of the division should be a bare number rather than a period (0.5
or even 1//2
instead of year(1/2)
)
But in real life, division is not so simple, you need to consider day count conventions (Actual/Actual
or 30/365
etc ..). So I wonder if making this an error, rather than giving a naive result is better. cf: https://github.com/aviks/Ito.jl/blob/master/src/time/day_count.jl
In any case, I think /
should not promote to div
. They ask different questions in the domain: what fraction of of a year is a month vs how many months in a year.
I agree with @aviks.
Sounds good. To be clear, date(x) - date(y)/ year(1)
, is not allowed because you'd be trying to divide Day/Year
. After ditching automatic Period conversions, I haven't figured out a more clean API for specifying a conversion strategy, so that's another issue for another day.
Up till now, I've only defined
div(::Period,::Period)
and left/(::Period,::Period)
as a no method error. Mainly to match Base's promotional behavior of/
and truncation behavior ofdiv
because with the discrete behavior of Dates, we only truncate on division (i.e. Periods are like Integers). I'm wondering if it makes sense to go ahead and define/
. Would people be confused if they tried to doYear(1)/Year(2)
and gotYear(1)
as the result?cc: @StefanKarpinski, @aviks