Re: storing fractions of inches in a data field

Booth Martin wrote:

Most all of these ideas make sense, and I really do appreciate the feedback. In thinking this through a little more I realize the real problem may lay with what we expect from the users, and what they are used to seeing and using with their PCs. What would a spiffy Windows application do to define/display/store an item that is 8 1/2" by 11" by 1/16" ? Included in the solution would be the ability to sort items by any of those dimensions.

The simplest Windows solutions would show the data in a grid, with one dimension per column, and provide the ability to sort on the alpha value. This would obviously be less than optimal for data like this, since it doesn't sort nicely.

Better solutions would store the data in the table as a numeric value and attach a helper to the grid that converts the numeric value to a display value. The sort method sorts the model using the numeric value, but the user sees the formatted value. Relatively easy, unless you have to allow input. Editing fractional input is tedious.

Storing fractions is difficult, because the number of decimals required can jump quickly and of course for many denominators you can't even store a true decimal representation. There are alternate schemes. For example, one way is to identify the smallest unit and store that as the decimal portion of the number. For example, we used to deal in "teenies", or 16ths, for commodity prices. We stored them as 2 decimal positions, so that 4.13 represented 4 13/16, while 4.08 was 4 1/2. For actual calculations we had a routine that would convert those numbers to four decimals, which as Bob pointed out is sufficient for 16ths (rule of thumb is one additional decimal for each power of two to store fractions exactly).

Anyway, the two requirements are: pick a suitable storage format that represents the fractional data in a naturally sortable format, and use a display methodology that separates the model from the view.

Joe