Total daily protein less than daily meals

Rounding?

Meals and individual items maybe round up each item, whereas the daily total sums the exact amount of each item.

e.g. three items at 2.6g may show as 9g total, but it's actually 7.8g or 8g.

that doesn’t make sense. Law of averages would say half are rounded up and half are rounded down.

And you’ve only got the option for six meals (speaking from memory). I’ve got breakfast, lunch, dinner, afternoon snack, evening snack, and chai. Even if all were rounded down, that’s only 6 grams.

Can you post screen shots?

You're making an assumption about how they do the rounding per item, per meal and per day. They may round to nearest, or highest, or one calculation uses one form of rounding and a different calculation uses another form.

I'm not going to dig too deeply into it, but e.g. yesterday the old diary on the website says I had 178g total protein in my meals, and 178g daily. On the new diary, the meals total 185g, and the daily total says 186g. It's all the same food items!

Sure, it's all just estimates anyway, but it would be nice if it were consistent here, and to reduce confusion.

That was one diary day, just looking at yesterday. Those numbers never change. Although as shown, there's a difference with the old diary and new diary about how they round things and maybe also when they do the rounding.

You don't use the website? The diary has an option there to view the new format if you want to.

One or two grams can be rounding, sure . . . maybe in a rare long-list case a bit more.

I can't give you a mathematical proof, but I share the skepticism that being off by 10g in one day's diary is likely to be a rounding error.

As far as whether they're rounding up or down generically: I think the realistic options are either truncating fractional amounts, or rounding up/down based on the standard rule of 0.5 and above rounding up, 0.4 and below rounding down. In any language I've ever written code in (a dozen or so), any other form of rounding would require more elaborate intentional coding, something a programmer would only do if ordered to do it that weird way intentionally, which would be very unusual. Truncation is straightforward in many languages, standard rounding is generally an easy-to-code function invocation.

At least in the Android app, 14.7g rounds up to 15g on the per-meal total, 8.2 rounds down to 8 for the meal. I messed around with it a little, looked at the diary and Nutrition areas, and it looked like detail values are used in the calculations behind the scenes for meal or day totals, then totals rounded for display using a standard rounding function, but I didn't do an exhaustive all-conditions test.

If it's actually off by 10g for a single day, some other kind of bug seems more likely than rounding error.

I ran some test cases last night, too. I can't test the Apple version (don't have one), but tested Android and web, both old and new web.

Yes, it looks like current web version rounds - using normal rounding rules - for display purposes, and then uses the rounded versions to calculate meal and day totals. The new (future) web version appears to round the meal and day totals for display, but it uses the decimal details in both cases to reach the meal and day totals. The totals are still rounded using normal rounding rules for display, but the total will differ in some cases. The Android app behaves like the new web version, i.e., to me it looks like they've fixed the error in the new web version, and that it was already done in the right order in the Android app.

In all cases, in an individual line, 8.2g displayed as 8g; 14.7g displayed as 15g. In the Android app and the new diary, if I added three lines of the 14.7, each displayed as 15 on the individual lines, but the daily totals reflected my 100g goal minus the real total of 44.1, i.e. it displayed 56g remaining, which is 100 minus 44.1 equals 55.9, which rounds up for display to 56. Same deal at the meal level. The same is true of the new web diary, but not the old/current web diary.

In the Android app and the new web diary, this suggests they're adding the detail values behind the scenes to get meal and daily totals, rounding the totals to whole numbers for display using normal rounding rules. The new and old web diaries both have the problem with weird long decimal values, but the Android version doesn't appear to have that.

Strictly speaking, the old (current) web version has an error in the order of operations, i.e., what you add and when you round it, but appears to be rounding values in the normal way when it rounds. It just uses rounded values when it shouldn't.

I have a speculation about what could be causing the weird decimal values, but I'd need to know more about the technology underpinning the web version to know whether it's probable or not. I'm not going to go into it because it's too hard to explain. If that's the reason, I'd still call it a bug, because they should probably round for display anyway.

Maybe someone can come up with an end case where you can have a day where rounding error alone gets a total off by 10g on a total value that's somewhere in the low 100s, but it's a very improbable case to occur in real life. Maybe the OP has found that unusual scenario, I don't know. Rounding plus order of operations producing that, slightly more likely, still unusual.

If I found the initial scenario OP reported, I'd run the order of operations that black box testing like the above seems to suggest they're using, doing it on a calculator. I'd also look at it in the new diary version to see if the error persists there. If I didn't get the same result doing the arithmetic by hand in the (bad) order, or the new diary version has the same problem, I'd report it as a bug. That's really all I'm saying.

If it looks right in the new web version, they already fixed that part, seems like.