Re: converting float to double

In article <1167451758.987601.260240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> "William Hughes" <wpihughes@xxxxxxxxxxx> writes:
*** T. Winter wrote:
....
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).

In integer math it is a difference in the scale, in f-p math it is a
different constant.

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.

You do not appreciate it. The formal rules, as stated, did not guarantee
a round conversion exact to the cent, and precise conditions under which
that would happen had to be provided. However the error would be for such
large amounts that it was thought to be insignificant. (It had to do with
the transfer of money that was in euro to accounts that were still in
gulden.) Doing it in floating point would be much more problematical.

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).

The inverse function was also precisely stated.

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.

They follow the rules of (and are stated in) fixed point math which is
easily emulated with scaled integers, but much less easy with floating
point. For instance, the rules for gulden to euro vv. were a conversion
rate of 1 euro = 2.20371 gulden and the result should be rounded to the
nearest cent (and note: 2.20371 is exact).
--
*** t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~***/
.