Re: converting float to double

In article <1167280845.058848.99960@xxxxxxxxxxxxxxxxxxxxxxxxxxx> "William Hughes" <wpihughes@xxxxxxxxxxx> writes:
*** T. Winter wrote:
....
Note this part of my article:

If the period is 1/2 year, the interest per period is not one half of
the year interest.
Try to do it over a five year period. A yearly
interest rate of .05 gives after five years $ 127.63 and an half-yearly
interest rate of .025 gives after five years $ 128.01. A difference
that some accountants worry about. There are specific rules how to
do interest about a period smaller than the base period (although the
rules depend on the situation).

Teach me to try to program at 4 am.

Yes, that is approximately the time that I normally write my articles.
I am a bit early now.

i_1000_per_n = i_1000 / 2;
i_per_n = i/2.0;

And see what I wrote above about this. But otherwise your results are
now correct. Although I can not see a guarantee from your floating
point formulation that it always will be correct, although off-hand
I can not find wrong examples. Ah, I found one. 31 cent initial
capital, interest per period 1.6%. The correct method gives zero
interest after one period, your double method gives one cent interest.
After 200 periods your double precision method gives 849 cents, while
with the correct method there has been no accumulation at all. Now
that I have this case it is easy to create other cases as well.
And I may note that interest percentages are frequently stated in
decimals. My account gives an interest of 3.6% if I remember right.

I see no clear advantage to using integer or floating
point. Yes, both can be optimized, but as calculation
speed is unlikely to be the bottleneck, optimization is
unlikely to be needed.

In the financial world calculation speed frequently *is* the bottleneck.
And as for speed, for 1000000 iterations, mine goes in 0.32 seconds,
your integer variant in 0.61 seconds and your floating point variant
in 0.096 seconds. And the advantage of integer over floating point
is that with the first you have a guarantee that the result is correct,
while with the second you cannot give that guarantee at all (and I am
stating this as a numerical mathematician, which I have been some time).

(I do not find the doubling trick to be very natural, and
it does not generalize to other forms of rounding)

It is not natural. But that is the way you would code when doing
fixed point arithmetic. It does generalise to some other forms of
rounding (round up, round down), it does not generalise to, e.g.,
bankers rounding. But there are other methods that can handle that.
--
*** t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~***/
.