Re: converting float to double


*** T. Winter wrote:
In article <1167366399.093609.254300@xxxxxxxxxxxxxxxxxxxxxxxxxxx> "William Hughes" <wpihughes@xxxxxxxxxxx> writes:
> *** T. Winter wrote:
> > 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).
>
> This is irrelevent, unless the rules specified can only be implemented
> in integer arithmetic.

It is extremely relevant. Dividing the interest rate for a period by two
to get the interest rate for a half period is almost certainly wrong.
I would not be surprised if there are rules in some branches that state the
a 5% yearly interest rate should be converted to a 2.24695% interest rate
for a half period.


And as this has absolutely nothing to do with the question
of whether calculations should be done in integer or
floating point it is irrelevent.

> The floating point calculations are almost
> exact, the only possible problem occurs at the equality condition.
> Given principal in hundreths, and interest in thousandths, the
> minimum spacing is 10 ^-5.

So it will not work for conversion of pre-euro valuta to euro valuta
and the other way around.

No, if you change your minimum spacing you have
to change your constant. You have a different problem but it is still
discrete.
There must exist a minimum spacing. True some values have
to change, but this is also true of the integer math
(indeed going from three decimal places to four is
easier in the floating point case. Consider the difference between
going from
i_1000, to i_10000, as opposed to changing the value of i and changing
0.004995 to 0.0049995).


I think you do not have any idea about the
way the financial market works. In 2001 we have done a strong analysis
when converting gulden to euro and the reverse did work, and whether the
back conversion resulted in the original (upto the cent). The conversion
factors were stated with four digits after the decimal point. For bankers
it was important that the back conversion indeed did give the original
value *upto a cent*. Such an analysis is not as simple as you apparently
think.


Whatever gives you that idea? I have a very good appreciation
of approximate inverse functions and what you have to do
when f(g(x)) does not equal x as g is only an approximate inverse. If
your
forward function is new = round(conversion*original), the inverse
function will probably not be simple (and may not be unique, what if
there
are two values of original which lead to the same new).
However, it can be calculated using either integer or floating point
math.

Also you wrote:
> The problem here is that 0.00495 was used instead of the
> needed 0.004995. I miscounted intitially and did not update this.

To me that makes it clear that to use floating point is much more
difficult than to use integer arithmetic. A simple miscount can
result in an error. This more so for people who do not understand
the subtleties of floating point.

I would argue that "much more" is overstating the case. Agreed, there
are some subtleties that you have to be aware of but overall
the real problems are in undestanding and specifying the
accounting algorithms, which do not follow the rules
of integer or floating point math.


- William Hughes

.