Talk:Price fraction

Table extension

What do you get for an input price of 0.99 or 1.00? --Paddy3118 09:56, 15 March 2010 (UTC)

That's covered by the final case: >= 0.96 < 1.01  := 1.00 which is handled in the Clipper code with

ELSEIF npQuantDispensed >= .96
    nResult = 1

--Axtens 02:36, 16 March 2010 (UTC)

Ah, I get it. You just forgot to add it to the table in the task descrition here, and I just looked and saw that the Clipper table had the same entries as the original table and assumed that what was missing was what I then added. (Which in this case just happened to match the Clipper code).
Damn! I would have liked to save that luck for the lottery :-)
--Paddy3118 06:35, 16 March 2010 (UTC)

Actually, the case was always there and the redundant bit of code as well. All you've done is to point out that there's pudding between my ears. --Axtens 08:10, 16 March 2010 (UTC)

What about invalid values?

What's supposed to happen if you get a negative number, or a number greater than 1.01? -- Eriksiers 19:13, 15 March 2010 (UTC)

The calling routine takes care of those details --Axtens 02:30, 16 March 2010 (UTC)

Floating point for money?!

Floating point for money? Don't they teach kids anything these days? --IanOsgood 20:15, 15 March 2010 (UTC)

I've had that exact conversation with a friend in the past few weeks. All I can say is... I (at least) never think of the problems, or the alternatives. -- Eriksiers 20:44, 15 March 2010 (UTC)

Two topics on the original wiki, Floating Point Currency and Money Object, contain many anecdotes, cautionary tales, and useful links. For a toy problem like this, using an integer in units of cents should suffice. --IanOsgood 01:29, 16 March 2010 (UTC)

All good points. However, (1) I'm the maintenance programmer, and (2) to work in integers would require a significant rewrite, something I have neither the time nor the patience for (I don't get paid for the work, and have to fit it in wherever and whenever possible.) --Axtens 02:30, 16 March 2010 (UTC)