Thanks Kent - I have obviously explained my concern / point badly. I will
have a chat with you today


On Tue, May 27, 2014 at 12:32 AM, Kent Quirk <notifications@github.com>wrote:

> In data-model/v1.md:
>
> > +### creationTime
> > +
> > +There is a `creationTime` field that is auto-generated on all events.  This is the machine time that the event was first created.
> > +
> > +### modifiedTime
> > +
> > +There is a `modifiedTime` field that is auto-generated on all events that have been modified.  This is the machine time of the most recent modification of the event.
> > +
> > +## Units
> > +
> > +The Tidepool platform processes blood glucose data in `mg/dL` format.  We chose `mg/dL` instead of `mmol/L` because `mg/dL` is an integer and dealing with integers generally avoids weird behaviors that can arise from working with floating point numbers.  While the likelihood of `mmol/L` actually causing any of those is admittedly low, neither unit is necessarily "better" than the other and this "reason" provided a tie breaker for the decision.
> > +
> > +Most event types that include a blood glucose reading can also have a units field specified.  When that field is `mmol/L`, we will convert the value to `mg/dL` and store the result.  The units field will be preserved, but the numerical values will all be in `mg/dL`.  The algorithm followed for conversion is
> > +
> > +1. If units field exists and is `mmol/L`
> > +2. Check the value, if below 39 convert
>
> Thank you for that POV, Jamie. The problem is that floating point is only
> "approximately" equal -- and if you're not careful about it, you can see
> things like this:
>
> User enters 4.8; we multiply by 18.01559 and round -- we get 86. We store
> 86. For display back to the user's units, we convert from 86 by dividing by
> 18.01559 and then round to the nearest single decimal place. We display
> 4.7. That's bad.
>
> If we store the BG values as integers in mg/dL, this will always happen,
> no matter how we condition the data, because integers don't have enough
> resolution. It may be within the resolution of the meter, but it's not what
> humans expect to see.
>
> If, instead, we store floating point numbers measured in mmol/L, and round
> displays to one decimal place on display of mmol/L and to integers on
> mg/dL, we get absolutely correct displays for both types of units for all
> values of bg from 0 to 4000 mg/dL. (I wrote code to try it.)
>
> We should NOT store numbers as entered as numbers, and the database should
> not have two different types of readings in it. That way lies madness.
>
> What we should do is store values in floating point units as mmol/L -- if
> they're entered as mg/dL the values will contain lots of significant
> digits. We do not drop those.
>
> So if you enter 100 mg/dL, when converted that's stored as 5.55074799105.
> When you convert it back and round to the nearest int, you get 100 again.
> If you happen to need to display it in mmol/L, you display it as 5.6.
>
> To summarize -- values must be stored in a single unit as floating point
> and not truncated or rounded in storage. They are converted to display
> units using floating point math and then rounded to the appropriate number
> of decimal digits for display. We should have fields for the text string we
> were originally given as a number, if any, and for the units we were given.
> But those are only for provenance purposes; we should never need to
> interpret them again.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/tidepool-org/tidepool-org.github.io/pull/14/files#r13045770>
> .
>