I'm going to write myself a little cookbook db and was wondering what the best way to enter fractions would be. Eventually, I want to be able to scale recipes so I can't enter it as text (or at least I don't think I can) because I wouldn't be able to do any math on the value. Any ideas?

You could use two integers, one for nominator and one for demoninator. That makes math and display quite easy, doesn't it?

Greetings

Perhaps you could use 'Floating Point Number' data type for the column?

We're currently not supporting decimal data type in Kexi, which would be better choice than the Floating Poing Number because the latter causes inexactness.

Using float will probably make it difficult to display the numbers as fractions in the recipe -- unless you want to write some fancy approximate-float-by-small-fraction algorithm

Greetings

@scummos: of course we always need a place to keep a unit (kg, spoons...). It's more needed if searching by ingredients/quantities is expected.

Floating point numbers are acceptable with rounding used upon displaying. Decimal type is ideal solution though.

Please note that we have no place to currently enter complex expressions in the form boxes; some arithmetic can be entered in SQL queries although forms based on queries are read-only at the moment.

Scriptability of database layer and GUI would solve the problem, data could be broked down in many columns when needed, e.g. like you proposed.

Okay, I see.

Of course floating point numbers have the needed accuracy, but they will make it difficult to display "half a cup" or "4/5 liters". That's what I was hinting at.

Greetings,
Sven

scummos wrote:"half a cup"

Symbolically, using two columns (value, unit) it could be:

(0.5, "cup")

scummos wrote:"4/5 liters"

(0.8, "l")

Scummons' first post got me thinking. Could I do this:

Use a text box to enter the fraction then use "left" and "right" fucntions to peel off the values, convert text to numbers, do the math and then store that value in a field that is not displayed?

Well, at least it has give me some ideas. Thanks all.

jstaniek wrote:

scummos wrote:"half a cup"

Symbolically, using two columns (value, unit) it could be:

(0.5, "cup")

scummos wrote:"4/5 liters"

(0.8, "l")

Yeah, right, but how do you know that you need to display "4/5" when the database reads "0.8"? That's what I see as an at least not entirely trivial problem.

cforput wrote:Use a text box to enter the fraction then use "left" and "right" fucntions to peel off the values, convert text to numbers, do the math and then store that value in a field that is not displayed?

That's what I meant, but I can't tell you whether it's actually reasonably possible.

Greetings

A little knowledge of the problem domain may come in handy.

In general, cooking comes in 2 flavors: savory and pastry (sweets, breads and the like); odd cooking (brewing e.g.) will often be like pastry.

Pastry is far more precise than savory and is generally done by weight rather than volume. For scaling purposes professional pastry cooks use "baker's percentages". (Google is your friend.) If a pastry cook is to use your database, being able to work in weights and/or BP will be valuable.

Savory cooks tend to round up and down a lot more. Many savory recipes still work if values are off by as much as 30% even though that's extreme.

A scale-up that resulted in 4 cups plus 1.375 teaspoon will immediately be rounded down to 4 cups by all but the newest savory cooks unless they know WHY that extra teaspoon is required. You'll need a way to know whether to round and by how much. Being overprecise will only annoy your user.

Fractional values are almost always in fourths, halves and sometimes thirds. ETA: Oh yes, 16th unless working metric

Just to make it messier, people who cook both will vary the technique by which it is: when I make bread, I weigh. When I make stew I eyeball it.

Hope this helps,

Tom