Make combinations

From AardRock Wiki
Revision as of 20:54, 26 May 2006 by Just (talk | contribs)
Jump to navigation Jump to search

There are 2 ways for searching in de basebase for possible entrees that add to the advise the system can give.

  • direct search
  • fussy search

I show the meanings with an example.

my entries at 8:40 are

  • 8:30 2 slice of cheese
  • 8:30 2 slice of white bread
  • 8:30 1 glass of milk
  • 8:35 1 apple (30 g)
  • health status: normal

question to the system. how much insulin do i have to inject if i want that my concentration glucose in blood is around 5 mmol/l at 11:00.

In the system happens a few things:

  • First a new entry is set in the database.
  • second it calculates the amount of carbonate of the foodintake
  • Third it makes a query of the question to search with in the database

This query is not a straightforward thing. First it will search directly at entries in the past. If it find a match then this is the most trustfull advise the system can give. This in relation to the definition of reproduction. If you do an experiment in the past and you know the results and you do the experiment again. You can expect to get the same result. To give the query a fair change to find entrees, the query have to losen up. How much has to be done experimented empericaly. for the example this means:

look for: 8:15 - 8:45 350-400 gr carbonate(with white bread, cheese, milk and apple as food-intake)

          10:30 - 11:30  4,5 - 5,5 mmol/l glucose units insuline

Lets say it finds entries from previous entries in past. with amounts of units insuline. We can present the mean to the user, if the difference is not signifide, and the entries where the advise is build from is presented to the user. If the user is not satisfied it can say that to the system and it will narrow it searchparameters. The problem is which one so thats still a design thought.

But what if it cannot find a match? It will search fussy. With this search it broads it search window (see the figure what i mean). it starts with broading 1 parameter of the query, untill it finds a entry that match. then it start anew and broads another parameter. when all the paramaters are done it starts broading 2 parameters, untill it finds a match. Last round will be that all the parameters will losen up untill it finds an entry that match. The broadingsteps are fixed and has to be emperical assessed.

What do we have? a collection of entrees with different kinds of answers. But which one is the most rightnest or is a couple of entries from different searchround together beter then just from 1 searchround? A learning system as a neural network could profide that answer. but that part i have to discus with Durk, because maybe he has the answer on that question. Het advise is of less value than a direct search. The user could have the abbility to see which enties the strongest influens had on the advise. Thats simply showing the entries of a searchround with the highest weights.

At the end the system could ask the user to check it's glucose level in blood at some point in time. This to reference that the advise was a good or bad one so it can ajust it weights.

The reason to calculate the carbonate load is:

  • in direct search measures of intake can differ, but the carbonate load not. In the example the apple can weight 50 g. but de carbonate load is allmost the same.
  • in fussy search if we losen the foodintake it goes like this:
  • 2 slice of cheese 2 slice of cheese
  • 2 slice of bread 2 slice of bread
  • 1 glass of milk
  • 350-400 gr carbonate 350-400 gr carbonate

the amount of carbonates is important to find alternatives. In other words you eat different products, but the carbonate stays the same.

Puntenwolk1.jpg

  • red dots: entries found by direct search
  • blue dots: entries found when broading the searchparameters, food intake and time of foodintake
  • clear square: searchwindow by direct search
  • unclear square: searchwindow broadend after one fussy searchround.


The goods and the bad's

The good things about this approtess are:

  • It can handle inconsequent users. If a day is forgotten it can still give advise.
  • Close to what the user allready does. Fill in his logbook en looks up when things went wrong.
  • Easy to implement.
  • can start from the beginning and the more entries it has the better it starts to function.
  • advise is local/personal.

The bad things:

  • Instance based learning is a very simple way of learning. with large databases it is better to use basian learning.
  • There is no involvement from the outside world.
  • Extra knowledge from other users are not shared.