Didn't feel like creating an account (or figuring out my logon info) for the
post so I'll include my thoughts here:
> Yea, I wrote a blog post on this subject recently if you're interested.
>
> http://blog.kitchenpc.com/2012/06/27/3-4-things-left-to-do/
===============================================
Salt & Pepper is a sub-type of "spice" where generally the chef would
either have some available - or not.
3 eggs + "eggs" = "3+ eggs"
I see three categories of measurement:
Known
Unmeasured (i.e., "to taste")
Measured - Unknown
And two categories for ingredients:
Unit
Bulk
Unit items are those where you can readily count how many you have/need;
generally purchased and used within a handful of meals.
Bulk items are those, like spices, that you buy enough for many meals.
You measure when you use them but otherwise do not keep track of how much is
remaining.
I could see the presentation interface having multiple columns/sections
each listing the appropriate ingredients.
In searching for ranges I think:
\d+\s*(-|to)\s*\d+
would be a better expression (capture the word "to" as well as "-")
Basically a divide-and-conquer strategy. Classify, find differences and
similarities, then decide how to present them to the user.
Also, consider the following:
WITH ruleset (regex_exp) AS ( VALUES ('exp1'), ('exp2') )
SELECT data, regex_emp
FROM ruleset
CROSS JOIN (SELECT 'data' AS data) dt
WHERE dt ~ regex_exp;
This returns one record for each expression that matches "data". I use this
general technique to build a regex-based rule engine in postgresql.
Generally you need to rank the rules and then return the match with the
lowest/highest rank.
////////////////////////////
> Really, the only thing I do with the data is total up amounts to generate
a
> shopping list. With ranges, I simply take the high amount.
> If one recipe calls for 2-3 eggs, and another calls for 4 eggs, I would
add 7
> eggs to the shopping list as that's the most you'd need to buy. The "Low"
> amount is simply for display purposes only, I do no math with this.
However,
> I can't predict what the future holds for the site. Maybe I'll need to
store all
> sorts of crazy things, so it's best to handle things in the best way up
front so I
> don't have to rip apart all this low level code later on.
==============================
Please do not suggest that people should buy an infinite number of eggs...
:)
David J.
