Progress Reports fail at simple addition

Locked-N-Loaded said:

You're only accepted answer is it's doing math on hidden decimal places it doesn't show anywhere else in any other location despite the fact other numbers do show those decimal places

Other numbers show 1 or 2 decimal places but there are even more decimal places under the covers.

Again I gave you the example of my run which is displayed as 6.20 km but is recorded as 6202.73 m (6.20273 km) in the FIT file.

If you look in the FIT file, it proves that most numbers that Garmin records have hidden decimals, including elevation. 

Again you will see that your elevation was originally recorded in metres, and that when you convert that number to feet, it's not a whole number. This should prove that elevation was rounded for display in Connect, when it shows a whole number in feet.

Locked-N-Loaded said:

You just can't wrap your brain around the fact there might be a simple explanation here, Occam's razor, that this is the algorithm making a mathematical mistake.

How hard do you think it is to write an algorithm which adds up 2 or more numbers?

You can't explain how or why Garmin would fail to add up numbers, but you reject the explanation that everyone is giving you.

"occam's razor"

Just because you don't understand something, doesn't mean it isn't simple to others who do understand. Your simple explanation is that Garmin dun goofed adding numbers with elevation and only elevation?

The only thing that's different about elevation is Garmin rounds it to 0 decimal places for display, which causes you to assume it's being treated differently than all the other numbers when it comes to adding them up.

The simple explanation is that there are hidden decimal places everywhere.

"Next rest stop 10 miles" - no it's not exactly 10 miles, it's rounded for the freeway sign.

Garmin says your ascent for 2 activities is 3546 feet and 4288 feet - no it's not *exactly* those numbers, they're rounded for Connect.

Garmin says my run was 6.20 km, but it actually recorded 6.20273 km.

But when you wanna do calculations with those numbers, you're gonna use the *original number* with more decimal places, so that errors don't pile up, especially when you deal with lots of numbers, like a year's worth of activities.

"percentages may not add up to 100% due to rounding"

Similarly, distance/elevation for individual activities may not add up to total distance/elevation in the progress summary, due to rounding

Oh hey look I can make excel do the same thing

Wow I guess excel is making a mAtHeMaTiCaL mIsTaKe huh.

Oh but actually A1 is 3545.5 and A2 is 4287.6, I just asked excel to round A1, A2, and A3 to 0 decimal places for display.

Notice that even though excel displays rounded numbers like I told it to, when I ask it to add those numbers up, it uses the original unrounded numbers for its calculation.

Do you think excel is doing the right thing here? By your logic, it should use the numbers that are displayed for its calculations, otherwise it looks wrong to the user.

Google sheets does the same thing.

Wow they must be stupid.

See it's actually well-known and extremely simple for anyone who works in tech, science, engineering or any industry that deals with numbers that:

- you typically round numbers when you show them to the public / end user, for simplicity

- when you do calculations with those numbers, you typically use the original unrounded number, to avoid piling up errors

It's also well-known in tech that changing the display format of a value (like how many decimals are shown, or whether it's shown in feet or metres) should *not* affect any calculations with that numbers. So actually, no, Garmin should not be adding up the numbers that are displayed, it should be adding up the original numbers it keeps under the covers (like in the FIT file).

The only way Garmin could satisfy you is to show you *all* the decimal places for every metric like distance or elevation, but then Connect would look even worse than it does today.

You really want Connect to tell you you ran 32.52432 miles? That your elevation gain was 1356.4532 feet?

If you're able to accept that Connect rounds certain numbers for display, then it should be be an almost foregone conclusion that the totals in the progress summary won't necessarily match what you get when you add up the numbers that are displayed.

"percentages may not add up to 100% due to rounding"

If you can understand this statement, you should be able to understand what is happening here in Connect.

Locked-N-Loaded said:

There are 50 reportable values & of those 50 only 4 show decimals on their totals:

Miles has hundredths

Max speed has tenths 

Vertical oscillation has tenths

Average strode length has hundredths 

Elevation is... A whole number as are the remaining ±30 reported totals (except times & paces obviously).

The accuracy of the measured metrics is technically limited. In addition, only significant digits are shown.

You can easily develop a data field with CIQ that shows ascent/descent in ft with e.g. 12 decimal places. But the decimals are garbage because they are out of accuracy.

I run with HRM and have found that the cadence on the watch often differs by 1 step/min from the cadence displayed in Connect Web. Since the difference is only about 0.5%, I don't care.

subra said:

The accuracy of the measured metrics is technically limited. In addition, only significant digits are shown.

That is true, but I would argue it's not 100% relevant here.

Another reason to round metrics is because end users simply don't want or need to deal with numbers like 5.458234 miles.

Also, you could have a number with 0 decimals of precision like 100 m, but when you convert that to feet (for display), it's about 328.084 feet. I would argue that those 3 decimal places are actually significant [*] here, but Garmin will round it to 328 (or 328.1) nonetheless, for cosmetic purposes.

Similarly, if I run 10.56 km and I accept a precision of 2 decimal places (even though more were recorded), that's roughly 6.5616798 miles. I would argue those 7 decimal places in the miles number are just as significant [*] as the 2 decimals in the km number, but if I set my display units to miles, obviously Garmin will not display "6.5616798 miles", it will display "6.56 miles".

[*] I mean - kind of. I realize that's not strictly true. It's more like, a number in metres with 0 decimals of accepted precision means that every difference of 1 m is significant, but if you convert that to feet, then every difference of roughly 3.28084 feet is significant. Similarly, if you have a value in km with 2 decimal places of accepted precision, then every difference of 0.01 km is significant, but if you convert that to miles, then every difference of roughly 0.006213712 miles is significant. 

But ofc that's extremely hard (or impossible) to convey. Saying "this number is accurate to 2 decimal places" makes sense (and is implied by displaying 2 decimal places). Saying "this number is accurate to roughly 3.28084 feet" is more of a headscratcher.

Probably easiest to say that if you want more precision, you either have to see *all* the decimal places or you need to look at the values in their original units (or units that scale to the original units by integer powers of 10 - e.g. km and m)

Still, converting a number with X decimals from km to miles or metres to feet and rounding the result to X decimals does result in a loss of precision. Showing more decimal places doesn't really help as it leads to a false sense of additional precision (see above)

So actually, changing your display units also affects the precision of your displayed data. Which is another reason that Garmin should *not* used the displayed numbers for calculations. You would certainly get different results based on your choice of display units if Garmin used displayed numbers for calculations.

My point is numbers can be rounded (or converted) for display for several reasons, but it's doesn't matter what the reasons are.

The only thing that matters is that - in general - even if numbers are rounded (or otherwise converted) for display, the original unrounded numbers should be used for calculations. If you use the displayed numbers for calculations, you will introduce an error in each calculation - these errors pile up when you deal with lots of numbers. As we can see, this error could be due to either rounding alone or units conversion + rounding (which is even worse, since those extra digits might be actually meaningful in this case). 

This is true regardless of why they are rounded, and to how many places (e.g. 0, 1 or 2). This is such a basic concept, and I wish I had the ability to explain this in a convincing way. But we can see that excel and google sheets do the same thing. I think we can criticize Garmin for a lot things, but they're doing the right thing here.

On a funny side note, I changed my units to statute (imperial/feet) in the Connect website and opened a running activity. In the Stats > Elevation section, my elevation is shown with 1 decimal place (and it's not always 0): e.g. 98.4 ft

But on the activity summary (near the top) and in the activity list, it's shown with 0 decimal places. 98 ft. Ofc we know that elevation is always rounded to 0 places in the Connect app.

So Garmin is kind of all over the map here. But that's kind of a side topic.

Again I will point out that it doesn't matter if Connect shows 1 or 2 decimal places. As long as the underlying data has even more decimals than what's displayed, it's possible you're gonna see the same apparent discrepancy when you look at the totals in the progress summary and compare them to what you get when you add up the individual values. I already showed this with my run distance for July, but I'm sure that will be ignored just like every other logical argument in this thread.

And once again speaking of rounding numbers for display, but using unrounded numbers for calculation, everyone does it, one way or another.

(click to enlarge)

Doesn't strava know that 6 + 10.2 doesn't equal 16.31? Are they stupid?

And if I open the details for each of those activities, the first one is shown as 6.02 and the second as 10.28.

6.02 + 10.28 is still not 16.31.

I guess strava also made a "mathematical mistake" in their algorithm. Because as we all know, computers are really bad at adding numbers. 

Nope, couldn't be that they are actually adding up activity distances with more than two decimals under the covers, but rounding them to zero, one or two decimal places for display. I think the training log rounds to one decimal place, but drops the decimal if it's zero, so it looks nicer. The activity detail always show two decimals. Strava also seems to prefer rounding down (10.28 -> 10.2) as opposed to rounding to nearest, but that doesn't really matter.

So let's apply Occam's razor here.

What's the simplest explanation? Both Garmin and Strava don't know how to add numbers? Or both Garmin and Strava display rounded numbers but use unrounded numbers for calculations.

So you see it's not simple conjecture (guessing). I work with numbers all the time, I use websites and apps that deal with numbers all the time, and I took math and science in high school.

I have also seen the phrase "percentages may not add up to 100% due to rounding" and I understand what it means.

Speaking of Occam's razor, you have been proven wrong multiple times in this thread already:

1) when you said that if Garmin's total was calculated using unrounded numbers, that could only result in a bigger total than what you'd calculate by adding up the displayed (rounded) numbers.

Multiple examples were given where the sum of unrounded numbers could be smaller than the sum of rounded numbers.

What you said could only be true if Garmin always rounded down, but in fact it's standard to round to nearest 

2) when you said that Garmin's math is only broken (from your POV) for total elevation (across activities) and not any other metric. You said that for every other metric, the numbers that are shown are the numbers that are used for the total.

I showed you an example from my total run distance in Garmin for July where the math "looks wrong" (the numbers which are shown are *not* what's used for the total). And now I showed that Strava does the same thing.

--

Maybe the simplest explanation is that you're wrong overall?

Notice how in this case, if strava used displayed numbers in its calculations [6 + 10.2 = 16.2 or 6.02 + 10.28 = 16.30], it would actually be cheating me out of a tiny amount of distance. If it did the same for 100s or 1000s of runs, that would add up to much bigger errors than 0.11 or 0.01 km.

Not only that, but they would get different results based on whether they chose to add up numbers displayed in the training log (0/1 decimal place) or numbers added in the activity detail (2 decimals).

Can't you see this is another reason that sites and apps shouldn't be using displayed numbers for calculations? In some cases the user can change the display format (units and/or number of decimals). In other cases, the display format is not the same across the entire app. 

Algorithms need to use a single source of truth when doing calculations, which means they should be using the original unrounded numbers that are stored under the covers. It's not about perfection, it's just about trying to calculate a consistent answer which doesn't change significantly based on the display format and is as close to the right answer as possible. It's actually the minimum standard that should be expected from any computer program that deals with numbers, not some crazy high standard of perfection.

Excel, google sheets, and strava all do the same thing as Garmin (they use original unrounded numbers for calculations, not displayed rounded numbers). Are they all stupid?

One final simple example.

I run 5.6 miles on Monday but I tell my buddy I ran "6 miles". (I rounded up to keep things simple)

I run 10.6 miles on Tuesday but I tell my buddy I ran "11 miles". 

I don't run for the rest of the week. 

At the end of the week, when I decide to tell my buddy how long I ran for the whole week, I have 2 choices:

1) "I ran 16 miles for the whole week" (5.6 + 10.6 = 16.2, which rounds to 16)

or

2) "I ran 17 miles for the whole week" (6 + 11 = 17)

--

Which statement is closest to the truth? If I pick 1), my buddy may question my ability to do math. But 1) is actually closer to my real mileage for the whole week.

2) "sounds right" but is actually further from the right answer than 1).

--

1) is how Garmin, Strava, Excel, Google Sheets, and every other app and website in the world work

2) is how you think they should work

Now extend the above example to months or years of running. That 1 mile discrepancy can turn into 10s or 100s of miles.

What you're not accepting is that when an app or a website shows you a number, it's often not exact. Just because it has 0 decimal places, doesn't mean it's an exact number - in many cases, there are decimal places you aren't seeing. And just because it has 1 or 2 decimal places, doesn't mean there aren't more decimal places under the covers. We've already showed examples where the numbers in the FIT file have more decimals than what's on the screen. 

And when an app or website does calculations on numbers it displays, it often doesn't use the displayed numbers. Just because you think it does, doesn't mean it's true. I already showed examples with both strava and connect where they show total distance which is not the same as adding up all the displayed numbers.