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)

Note that once you have a function which works with integers it should be trivial in most languages to wrap it with something which multiplies floating point numbers by 100 and gets the nearest integer and divides the result by 100. Some languages also let you mark the floating point variant as "obsolete" with a message that points at the other approach. --Rdm 19:20, 18 March 2010 (UTC)

Representing the data

One issue, with this kind of problem, has to do with the form that potential future changes might take. This touches on some perhaps interesting topics.

For example, consider the J implementation:

<lang J>le=: -0.96 0.91 0.86 0.81 0.76 0.71 0.66 0.61 0.56 0.51 0.46 0.41 0.36 0.31 0.26 0.21 0.16 0.11 0.06 0 out=: 1 0.98 0.94 0.9 0.86 0.82 0.78 0.74 0.7 0.66 0.62 0.58 0.54 0.5 0.44 0.38 0.32 0.26 0.18 0.1</lang>

This, of course, works. But perhaps a better approach might be to simply incorporate the text of the original table in the program. The TCL implementation did this. A J version of this approach might be:

<lang J>'g1 out1'=:|:|.(1 5 { 0 ". ]);._2]0 :0 >= 0.00 < 0.06  := 0.10 >= 0.06 < 0.11  := 0.18 >= 0.11 < 0.16  := 0.26 >= 0.16 < 0.21  := 0.32 >= 0.21 < 0.26  := 0.38 >= 0.26 < 0.31  := 0.44 >= 0.31 < 0.36  := 0.50 >= 0.36 < 0.41  := 0.54 >= 0.41 < 0.46  := 0.58 >= 0.46 < 0.51  := 0.62 >= 0.51 < 0.56  := 0.66 >= 0.56 < 0.61  := 0.70 >= 0.61 < 0.66  := 0.74 >= 0.66 < 0.71  := 0.78 >= 0.71 < 0.76  := 0.82 >= 0.76 < 0.81  := 0.86 >= 0.81 < 0.86  := 0.90 >= 0.86 < 0.91  := 0.94 >= 0.91 < 0.96  := 0.98 >= 0.96 < 1.01  := 1.00 ) priceFraction=: out {~ (-g) I. - </lang>

The problem with this approach, though, is that it invites the casual reader to think the code is doing more than it is. Are we prepared to deal with different sorts of expressions in this table? The answer should be no, unless the table was designed for use by our language or unless we have designed that facility to work properly.

Another problem with this approach is bulk. This table is somewhat regular and that regularity could be used to provide compact definitions of these required constants:

<lang J>out=: |.+/\1 2 4 12 1 0#0.02*i.-6 le=: -0.01+0.05*i.-#out priceFraction=: out {~ le I. -</lang>

The problem, here, is that a future "casual maintainer" might not be able to figure out how to modify this table. This might be seen as an advantage or a disadvantage, depending on the likely value and role of casual maintainers.

In some contexts, the specification would not be set in stone but would be a part of a discussion between the person (or people) developing the code and the people that need it to do something useful. In this sort of environment, both parties would have valuable insight to offer.

In an "strongly specified" sort of problem, the specification would be set in stone and the developers' insights would not be relevant to the specification.

I'd be open to standardizing on CSV as a format for tabular data, and hold a strong recommendation that tasks that make use of tabular data present it in CSV, and that examples that make use of it import it from such. It depends on it being fairly portable; one would be increasing the complexity of every task to including either processing stream input or file input. --Michael Mol 21:36, 18 March 2010 (UTC)

Real code parses it in whatever idiotic form the local legislature decides to publish it in. These days, that means whatever format one gets when one cuts-n-pastes it out of some PDF… –Donal Fellows 22:27, 18 March 2010 (UTC)