Progress Reports fail at simple addition

I have to agree with trux in this case. He's just stating facts here. (Before you accuse me of being a Garmin defender, I'm actually the biggest critic of Garmin and I get attacked by Garmin defenders because of it. I also agree that many posters love to defend Garmin and unfairly dismiss/minimize user complaints, which is especially annoying when it's a verifiable bug or a typical horrible Garmin user experience, but I don't think this is one of those cases)

Even ignoring the fractional values in the FIT file, note that Garmin always uses internal units of metres for elevation. 

From your own screenshot, one of your activities recorded 1306 metres of ascent to the FIT file (I'm ignoring any fractional amount of metres here, because it doesn't matter for my argument). 1306 metres is approximately 4284.777 feet (not a whole number). 

As you pointed out, elevation is always reported in Connect as a whole number, but I think it must be obvious from the fact the unit conversion is happening that fractional numbers must be used under the covers. If Garmin records a certain metric in metres, then even if that metric is always a whole number (which isn't necessarily true), the converted value in feet won't be.

Now let's go back to your assertion that when totals are calculated, it makes more sense to always use whole numbers in the calculations, since whole numbers are what's displayed in Connect.

Let's say I go for 10 runs in a single month, and I have *exactly* 100 metres of elevation gain for each one. (Nice, round, whole number).

But let's say my display units in Connect are feet. 100 metres is approximately 328.084 feet. 

We can all agree that Garmin will display a whole number for ascent in each of these activities, right? It will probably report 328 feet for each run.

Now what do you think the progress summary screen should show for total ascent for that month?

- By your logic, it should show 328 * 10 = 3280 feet

- By my logic, it should show 328.084 * 10 = 3280.84 -> 3281 feet (after rounding)

Here's a case where adding up rounded numbers actually cheats me of 1 foot in the total, but ofc I could make up an example where the opposite is the case.

Maybe now you will say that Garmin should show one or two decimal places in the per-activity numbers and the totals, to avoid this kind of issue. But the same issue will exist no matter how many decimals are shown, unless Garmin shows *all* the decimal places that it handles internally. And they're not going to do that because it would be a bad user experience.

I'll just finish this off by saying that it's basic high school science that you should *never* round intermediate values when you do calculations involving physical quantities / measurements, otherwise rounding errors will quickly accumulate. This is obviously worse when lots of numbers are involved. You're only supposed to round the final result.

It's also very important in finance. You realize that even though your bank account balance and other dollar amounts you deal (e.g. insurance premiums) are presented to you in dollars and cents (i.e. 2 decimal places), intermediate calculations are done with a much higher precision (e.g. when calculating interest)?

You think that your bank rounds to 2 places at every step when it calculates how much interest you owe on a loan, for example? Likely not, that would be insane because they could end up losing a lot of money that way (when you multiply the tiny rounding errors by the vast amounts of money they handle). No, they likely use maximum precision for all *intermediate values* in calculations, and only round the final result.

Although I understand what you're saying and I appreciate the lengthy response the logic still doesn't compute. 

Meters is only shown because it was the chosen value I can easily change it to feet. 

But also I think the most glaring thing you're notiasing is it's rounding DOWN my total. Explain a scenario where you would round down a whole number or even one with hidden hundredths? If something was 10.3 and 10.7 you have a total of 21. You wouldn't round down to 20? But they did.

So assuming there are these hidden tents or hundredths not shown in elevation (BUT which are shown in other numbers but just not elevation which is illogical)... How would you end up rounding down and stealing 1 foot from me?

By your own logic if they are collecting more than whole numbers - even though they don't show more than whole numbers for elevation - but okay... That could never lead you to rounding down. Where is that 1 foot? If what you say is true, how did I loose a foot in the final total? 

7,834 feet  is 3546 + 4288. So why do they report that as a 7,833 total?? If anything, they should show 7834 OR maybe 7835 (assuming these hidden hundredths exist). But 7833 is a round DOWN.

Don't you see.. that negates ALL of this fractional decimal talk. If decimal places exist then the total should be above and the error should be an added total amount, not a lost and reduced amount. 

No problem, but I don't think you're getting the whole picture yet.

Locked-N-Loaded said:

Meters is only shown because it was the chosen value I can easily change it to feet. 

You can easily change the display units for elevation to metres or feet. But internally the watch always records metres. The value in the FIT file will always be in metres.

I only brought that up to bring home the point that fractional values and rounding must be in effect for elevation in individual activities, even if the watch only records in whole numbers. Again, suppose I have exactly 100 metres of elevation for an activity. This is 328.084 feet (not a whole number), and will likely be displayed as 328 feet (a rounded number).

The point was to prove that fractional numbers must be in use if you use feet as your display units.

Besides, do you really want the result of your calculations to be substantially different based on your display units? Because that's what you're asking for when you say it only makes sense to use the rounded numbers that are displayed in calculations.

Let's say I have 10 runs of 10 metres elevation each.

Display units in metres:

- 10 x 10 = 100 metres total elevation (no rounding required). (this is 328.084 feet btw, or 328 after rounding)

Display units in feet

- 10 metres = 32.8084 -> 33 after rounding

- 10 x 33 = 330 feet

That's a 2 foot difference just based on changing your display units

Hopefully this example demonstrates why value which is displayed is not the same as the value that is internally used for calculations.

Locked-N-Loaded said:

So assuming there are these hidden tents or hundredths not shown in elevation (BUT which are shown in other numbers but just not elevation which is illogical)... How would you end up rounding down and stealing 1 foot from me?

By your own logic if they are collecting more than whole numbers - even though they don't show more than whole numbers for elevation - but okay... That could never lead you to rounding down.

"That could never lead you to rounding down"

Actually, it could.

"If decimal places exist then the total should be above and the error should be an added total amount, not a lost and reduced amount. "

That is not true.

"7,834 feet  is 3546 + 4288. So why do they report that as a 7,833 total?? If anything, they should show 7834 OR maybe 7835 (assuming these hidden hundredths exist). But 7833 is a round DOWN."

Very simple way this could've happened:

- What was displayed as 3546 was actually internally 3545.6 (for example) 

- What was displayed as 4288 was actually internally 4287.8 (for example)

- 3545.6 + 4287.8 = 7833.4 -> this rounds to 7833

To be clear, the most common rounding algorithm is:

- round to the nearest whole number

- tiebreaker: if the fractional part is 0.5, then round up [*]

This algorithm (or some variant of it) is used by most programming languages/libraries.

e.g. 

9.4 rounds to 9

9.6 rounds to 10

9.5 rounds to 10

[*] the tiebreaker rule varies with other algorithms like banker's rounding, which rounds to the nearest even whole number

For the next 2 examples, let's just ignore the feet-to-metres conversion, because it actually isn't important (I just brought it up to prove that your elevation gain in feet is probably fractional under the covers)

1) Imagine you have 20 runs of exactly 3545.6 feet. The total elevation is:

- Your way: 20 * 3546 = 70920 feet

- My way: 20 * 3545.6 = 70912 feet

Which answer do you think is closer to the truth? 

2) Similarly, say you run 100 times a year for 10 years, for 100.4 feet of elevation each time

- your way: total elevation for 10 years = 100 * 10 * 100 = 100,000 feet

- my way: total elevation for 10 years = 100 * 10 * 100.4 = 100,400 feet

Which answer do you think is closer to the truth?

Hopefully you can see that:

- the difference between my way and your way isn't just rounding the final answer up or down (the error gets bigger and bigger the more numbers are involved)

Again:

Rounding is only done in Connect immediately before the value is displayed. That's how it works in general. If calculations were done using rounded intermediate values, errors would quickly pile up.

Okay now we're getting somewhere. this is a legit explanation that I could maybe possibly get on board with. Because it's an actual explanation with details and examples that start to make some sense.

Now, I think the thing that really throws me is the fact that all of these other metrics are reported out to a tenth. So their totals even add up out to a tenth. They even show you the .1 tenth decimal. BUT in the fit file and on the watch and in The connect app and on the website in the progress reports elevation NEVER has a tenth. So there's an assumption here that somewhere this 10th does exist relative to elevation even though it's never shown. But it suddenly is used when determining just the total for elevation. Other places show it, use it, add up but elevation doesn't. But apparently it's (maybe, possibly, could be) using it? That's just so hard for me to accept logically. Why not just show the tenth in the file and on the website and on the watch and in the app like it does for everything else? That's a rhetorical question because I don't believe anybody has the answer but the technicians within Garmin because right now it's a lot of speculation about if it exists, if a m to f conversion or rounding is even being done, etc. I look at other numbers and I see a tenth and all of their totals have tenths. I see elevation which is only ever displayed as a whole number but suddenly there might be some hidden tenths.

Locked-N-Loaded said:

Or how none of the other reported dozens of values... are rounded. But elevation is.

I think all values are rounded to a certain number of decimal digits. Time is rounded to seconds, distance is rounded to meters, speed is rounded to 2 decimal digits, pace is rounded to seconds, Cal is rounded, VO2max, training load, ...,

In my opinion, the number of decimal digits of a value generally depends on the accuracy of the sensor. Since the barometric sensor in the device used to measure ascent/descent can't measure a tenth of a foot (0.1 ft = 0.03048 m), it makes no sense to specify this value to a tenth of a digit, since this is measurement noise.

If you use the meters unit, GC will display 1 decimal digit for ascent/descent.

subra said:

I think all values are rounded to a certain number of decimal digits.

Exactly. Even when you see 1 or 2 decimals in Connect or your watch, the value is still rounded, because the original data usually has more precision, but normal humans don't need or want to see more than 2 decimals for the distance of their run (whether it's displayed as miles or km)

The other reason for rounding to 0, 1 or 2 decimals, as subra said, is that specifying a certain amount of decimals also implies that the value is that accurate.

If you asked me how far I ran and I say "5 miles", it's understood that it's not an exact value. Could be 4.8 or 5.2, for example. But if I say "5.00 miles" then it implies that it couldn't be 4.8 or 5.2. Maybe it could be 5.002 miles tho. This example is sort of informal and hand wavey, but in physics (and other hard sciences), there are actually strict rules about this kind of thing. 

Anyway, the other day I ran about 6 km. Connect and Strava both show this run as "6.20 km". But if I dig into the fit file, it actually says 6202.73 m, or 6.20273 km.

For the purpose of showing me my run distance, 6.20 is just fine. (We know that GPS ain't all that accurate anyway.)

But for the purposes of calculating my total mileage for the year or for all time, it's probably best to use the original value of 6.20273. Over 100s or 1000s of runs, those little differences add up.

Locked-N-Loaded said:

I see elevation which is only ever displayed as a whole number but suddenly there might be some hidden tenths.

Again, the fact that elevation is measured and recorded as metres means that even if only whole numbers of metres where recorded, the elevation in feet will have more than 1 "hidden" decimal place

Say I go for a run and record exactly 10 metres of elevation gain. 10 metres = 32.8084 feet. If I set Connect to display feet, then it will probably display 33 feet of elevation gain for that run. That's not just "hidden tenths", but 4 "hidden" decimal places: tenths, hundredths, 1000ths, and 10000ths.

But even though I see 2 decimal places for my run distance - e.g. 6.20 km - there are "hidden decimal places" too: Garmin actually recorded 6.20273, so that's 3 extra decimal places that I normally don't see.

You will just have to take our word for it that this kind of thing happens all the time, in many different situations. If you're driving on the freeway and you see a sign that says "Next Rest Stop 10 miles", do you really think it's *exactly* 10 miles? Would it be helpful for the sign to be more precise, like say "10.094345 miles to next rest stop"? Probably not.

But if you're expecting it to be exactly 10 miles to next rest stop, and if you expect that your total mileage will increase by exactly 10 miles, you will be disappointed.

subra said:

If you use the meters unit, GC will display 1 decimal digit for ascent/descent.

The Connect website does do this, but it always shows x.0 for total ascent and total descent, whereas max and min elevation can have a non-zero decimal digit.

It's almost like the totals are rounded to 0 decimals, but displayed with 1 decimal digit anyway, which is kinda misleading. This is a case where I def think Garmin messed up.

The Connect app shows no decimal places for any of those 4 things, which I think is more reasonable.

Believe me I understand the concept of the expectation of perfection in these devices. 

I'm at 400,000 ft of vertical gain already this year. Hundreds of cumulative hours and workouts. I travel the world and race I've already been to Europe three times this year and I had back to Switzerland for two days of racing in 3 weeks. I regularly do back-to-back weekends where I live in Colorado doing 4 to 6 hour runs up and down from 13,000 ft. Blah blah. So I get the expectation and I understand the variations. I understand that my watch can show a completely different amount of altitude gain than my wahoo bike computer. For the fact I will get varying heart rate readings from one device to the next. I understand these nuances. 

But as a guy who's made a goal of over 500,000 ft of vertical gain in one year, when I noticed this discrepancy, it makes me wonder how many more other feet am I missing? And when I see whole numbers that add up perfectly to another whole number but then contradicts a whole number it shows in a different location, it is a fair & obviously natural question to ask and try to find the answer to.

I appreciate your effort though. These are the kinds of interactions I like because they are more detailed complete have reason have example and aren't just nebulous statements.

Locked-N-Loaded said:

And when I see whole numbers that add up perfectly to another whole number but then contradicts a whole number it shows in a different location, it is a fair & obviously natural question to ask and try to find the answer to.

Idk what else to tell you dude. We have tried to answer your question over and over again.

Garmin is rounding numbers at the very last moment (before they're displayed to you), just like everyone else. This mostly done because normal people don't want or need a ton of decimals, and also because those decimals aren't very significant even for people who want more precision. For intermediate calculations, they use the original numbers which have more decimals than what's displayed to you. If they didn't do that, then errors would pile up very quickly when they do calculations with lots of data (like adding up your total elevation for a whole year or something.)

Even when you see other numbers that have 1 or 2 decimals in Connect, under the covers they have more decimals than what you see.

It may be a natural question, but we've tried to answer it as best as we can. You can either accept it or not.

Btw, it's not about "perfection" by any means. Garmin is the last company I would describe as being perfectionist. It is just a very normal thing in the tech industry, science, math, physics, statistics, etc.,etc. In pretty much any field that deals with numbers and also deals with the general public, the numbers which are shown to the average Joe or Jane on the street are rounded. But behind the scenes, they are not.

This is also a very basic idea in high school math and science.

I already gave you an example where your idea of working with the whole numbers that are displayed to the user would be a disaster.

Let's say I have 10 runs of 10 metres elevation each.

Display units in metres:

- 10 x 10 = 100 metres total elevation (no rounding required). (this is 328.084 feet btw, or 328 after rounding)

Display units in feet

- 10 metres = 32.8084 -> 33 after rounding

- 10 x 33 = 330 feet

That's a 2 foot difference just based on changing your display units

Can't you see changing the display units shouldn't give you 2 different answers (328 feet vs 330 feet)? By using unrounded intermediate values, this kind of problem is avoided.

Locked-N-Loaded said:

But as a guy who's made a goal of over 500,000 ft of vertical gain in one year, when I noticed this discrepancy, it makes me wonder how many more other feet am I missing?

I have tried to explain over and over and over again that Garmins (correct) method of adding up numbers doesn't just result in lower numbers than you'd expect ("missing feet"), it can also result in higher numbers than you'd expect ("extra feet"). I gave you multiple examples of this.

Let's say you run 100 times with an elevation gain of 100.4 feet each time.

Your way: 100 * 100 feet = 10,000

Garmin's way: 100 * 100.4 feet = 10,040 (higher)

Ofc it could also go the other way. Let's s say you run 100 times with an elevation gain of 99.6 feet each time.

Your way: 100 * 100 feet = 10,000 (higher)

Garmin's way: 100 * 99.6 feet = 9,960

See, the point of doing it Garmin's way isn't to punish you by taking away your feet or reward you by giving you feet. The point is to get the answer that's as close to being mathematically correct as possible. If it sometimes looks wrong to the user, there isn't really much they can do about that.

Actually, if Garmin were using rounded intermediate values for calculations like total elevation, they would have just as much chance of giving you extra feet as they would of cheating you out of feet.

Locked-N-Loaded said:

when I see whole numbers

I tried to explain this already, but the fact that Garmin records elevation in metres means that even if the original recorded measurements were in whole numbers, they're not anymore once they're converted to feet, which means that they were rounded for display if you're seeing whole numbers in feet.