See also MealPlanningResources
This is a status update for the Gourmet Meal Planner, and its integration with Free Life Planner. So recently, I said it was finished. What exactly does that mean?
Well basically here is its capability at present. Firstly, whenever you buy a piece of food, you can scan its barcode in the FLP Pantry Manager, part of the FLP Inventory Manager. (Note it doesn't presently allow you to enter foods that do not have a UPC). This records the barcode. It then queries upccodes.com and nutritionix.com to get product and nutrition information. Dependending on the grocery store you shop at, the products will be mostly covered or not.
The next part of the system I only mention in passing because it is not working very well yet, but that is the receipt parsing system. The idea of this system is eventually to extract supplier price information (for use in meal cost planning) and to track grocery expenses. This works but in practice I found that the tesseract engine does not deliver the required accuracy due to the nature of the receipts, which have a lot of visual junk that interferes with OCR. So I am going to set up OmniPage and test that next.
From here, you have a list of products. Now, when the FLP Pantry/Inventory Manager is finished, you should be able to specify how many of each product you have, and even the state of individual such products. Because for instance, a given instance of a product type might have a different expiration date than a different instance of that type. Also, you may have opened it and such. Inferring which is which is a hard problem (which I literally just solved while typing this - I have to use clp(FD) constraint programming in Prolog, or make use of dmiles solution to Einstein's puzzle (a famous constraint problem). Often times just explaining things is enough to make you realize how to solve them).
Once inventory is working, it will be much easier to generate a correct plan. For now the system simply assumes that you have 1 serving each from 1 instance of every scanned product type for which nutrition information was found. Using that was a simplifiying assumption to speed things up, and can be remedied, although it is unclear how to do nonintegral portion sizes yet. I am thinking about using functions for everything in order to do that.
So, you have a list of the nutrient requirements, which looks like this:
;; daily values mode
;; <= fat 65g (at end (<= (intake total_fat grams ?agent) 65.0))
;; <= saturated fat 20g (at end (<= (intake saturated_fat grams ?agent) 20.0))
;; <= cholesterol 300mg (at end (<= (intake cholesterol milligrams ?agent) 300.0))
;; <= sodium 2400mg (at end (<= (intake sodium milligrams ?agent) 2400.0))
;; <= carboydrate 300g (at end (<= (intake total_carbohydrate grams ?agent) 300.0))
;; >= dietary fiber 25g (at end (>= (intake dietary_fiber grams ?agent) 25.0))
(at start (>= (intake calories calories_u ?agent) 1850.0)) (at end (<= (intake calories calories_u ?agent) 2150.0))
This is put as a precondition to an action with an effect of being replete. So the current system will then, using the respective nutrition information which has been translated into the PDDL format, generate a plan. As it only allows 1 serving of each, the plan looks rather silly. It has a lot of single servings of a ton of different foods. But the key here is that, for instance, I could limit sodium to the point where no plan is found, then relax that, perhaps using newtons method or something, to figure out the point at which a plan exists. Note that planning is fairly efficient here, and generally spits a plan out in a few seconds.
The plans have a few bugs, for instance currently it generates meals past the end of the single session for some as of yet unknown reason. But it is expected that debugging will resolve that issue shortly.
It was actually a lot of work to get to this point, and not everything is in tip top shape. In particular, the generation of the product information is weak - it has to invoke a script which then regenerates everything. It will be much better when new information is brought on at scan time and such.
So there remains a lot of work on the Gourmet Meal Planner, but the basic gimmick - generating metric nutrition plans - is working. Some areas to improve next are obviously the servings, the inventory system, but also adding the cost information to the process. There are tons of areas for improvement, especially as it comes to having KBs of different food properties, such as which foods may be substited for others, and so on. This is really a very large problem. But for starters, having nutrition plans generating is a good start.
As far as the system for doing newton's method, I recently made good progress on it. What the FLP needs is a centralized planner that coordinates all of the other planning systems, such as meal, financial, task, etc. This could be a BDI agent, which we are working on as well, but could also be the FLUX system. I recently got it to generate plans (using a very slow approach - Bread-First Search), but it does generate working plans. The next steps will be to implement faster search algorithms as well as to implement the proper domains for controlling the other planners and doing planning on them. This will require completing the FLUX-FRDCSA planner's bidirectional PDDL interface. Fortunately this ties in with some bounty work for getting the PDDL planning capabilities isolated into their own SWIPL pack. So it shouldn't take much longer to have this central integration.
https://frdcsa.org/~andrewdo/projects/mealplanning/caloriesingle.d.verb
https://frdcsa.org/~andrewdo/projects/mealplanning/caloriesingle.p.verb