Rounding problems

It resolves to 12 decimal places for me, and does not give any errors on edit. I didn't write the fraction handling functions. If someone would like to look into this, it would be appretiated. Also, what is the desired way fractions are supposed to work?

what is the desired way fractions are supposed to work?

Ah, what a great philosophical question! Unfortunately, most people are unaware of the mathemetical rules about significant digits. The "correct" answer is that the result should have nor more signifiant digits than one more than the fewest significant digits in the original numbers. For example 2/11: "2" has one significant digit; "11" has two. So the correct answer is "0.22" - that is two signifiant digits (one more than one).

The next problem is that most Americans don't understand decimals very well at all (there's another advantage to the metric system - you learn decimals better). For us, fractions are better, but only to a point. Once the dividend (bottom of the fraction) goes over about 8, we get lost. Further, some fractions are easier to understand than others; for example, we have a reasonable grasp on 1/2, 1/3, 1/4, and 1/8, but 1/5, 1/6, and 1/7 elude most of us.

So my bottom line is, as an American, I'd prefer to see fractions adjusted to the closest half, third, quarter, or eighth. Yes, this is a lot more programming, but makes a much better cookbook.

I have a recipe that makes roughly 25 servings, when I change the quantity, I really don't want to see 12/25 of something. Showing that as 1/2 is good enough for cooking. Likewise, 18/25 is close enough to 3/4 to work.

Should we then write a fraction handling function that converts decimals to the closest of x/1, x/2, x/3, x/4, x/8. which would always be within 1/16 of the original "decimal" answer.

I guess the problem with this is that we would only want this to be used for the US Customary units, as the metric system does fine with decimals rounded to the nearest 0,05.

As far as significant figures go... it doesn't much matter if we follow the rules of sig figs if we aren't going to be cooking using calibrated Erlenmeyer flasks. More likely our cooking equipment can measure to .1, or greater, which means we could round all measurements to the nearest .1, but this causes problems with the fractions that we use in the US. .125 would be rounded to .1 and then someone may not use the 1/8th.

If we go forward with different rounding functions depending on the unit, we may be required to make a database change to the units database, that would add a value to specify which rounding function if any would be used on.

I put the stuff about significant digits for those who were saying they were getting 12 decimals - totally bad for cooking.

I would think a simple field that says "Show units as:" and has choices for "Fractions" or "Decimals" (or maybe "English" or "Metric") would be sufficient. Then, yes, I would suggest a handling routine (or two) that would do this. But certainly showing 12 decimals is just unnecessary.

Looks like the code to catch these cases isn't being used if the fraction display hasn't been explicitly set by the user. A work around is to go and add a . on the end of the setting, save, then remove the . again and re-save.
I'm checking in a fix now (or at least I hope I am, I've gone and set the variable now!)