Instead of an overcomplicated form:
decay = exp( (-t/7) x ln(2) )
you can use:
decay = (1/2)^(t/7)
as:
exp( (-t/th) x ln(2) ) = e^( (-t/th) x ln(2) ) = e^( ln(2^(-t/th)) ) = 2^(-t/th) = (1/2)^(t/th)
Instead of an overcomplicated form:
decay = exp( (-t/7) x ln(2) )
you can use:
decay = (1/2)^(t/7)
as:
exp( (-t/th) x ln(2) ) = e^( (-t/th) x ln(2) ) = e^( ln(2^(-t/th)) ) = 2^(-t/th) = (1/2)^(t/th)
You call it overcomplicated but it's actually the most common way of describing decay: using a decay constant. At least where I have used it before. Yours describes it using the half life time. I guess it's a matter of taste or field of use?
https://en.wikipedia.org/wiki/Half-life has them explained.
What I see they use on wikipedia page you linked exactly the same form I've used above.
Basically, what I expect, one software engineer forgot at one point that for x>0 (what is the case) e^(ln(x)) = x.
Why to calculate logarithm from 2, then e to power of ln(2) to find it is 2 you knew from the beginning?
Instead of
They wrote something like:
As I said, they are equal. As to why I have no idea. I just know the form the BOINC team uses is a form I encounter more than what you showed.
As for the computation. This is what I tell my team all the time: there are two rules to optimize an application:
In code they don't use ln(2) but the result, a constant. I have no idea how a compiler would optimize what you propose or what is in the BOINC code, neither do I have an idea how the floating point unit would handle them.
That said, your comment can be helpful to others, that's why I upvoted it ;-)