Progress Reports fail at simple addition

Look at these 3 screenshots from the Progress Reports.

If you add up total ascent from my Saturday & Sunday workouts, you'll get 7,834 feet (3546 + 4288)

BUT, Garmin is crediting me with 7,833 feet.

Where did that 1 foot go??

I'm on track to surpass 500,000' of vertical gain in 1 year (at 399,273' currently). But seeing this makes me wonder, am I missing feet for my total? How is this simple addition error happening?

Top Replies

All Replies

  • For the fact I will get varying heart rate readings from one device to the next. I understand these nuances. 

    But we are not talking about the nuances of sensor measurements. That's kind of a secondary thing here.

    There are two main things at play here:

    - numbers that Garmin measured are rounded for display (numerous examples have already been given)

    - when Garmin does calculations on these numbers, they use the original unrounded numbers, to avoid piling up a ton of errors

    If you had a magic Garmin watch that made perfect elevation measurements, it wouldn't make a difference. The question isn't the quality of the incoming data, the question is how does Garmin display those numbers in a nice way for the users while still doing accurate calculations behind the scenes.

  • Have you not ever looked at a survey on a news site with a bunch of percentages?

    Ever read the fine print: "numbers may not add up to 100% due to rounding"?

    You really think Garmin is the only one who does this?

  • 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.

    For me Connect website shows 1 decimal digit (x.0...x.9) and Connect App shows rounded to a whole number.

  • I hope everyone doing self comparisons is looking at

    Reports > Progress Summary

    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).

    To much conjecture (it could be, it might be, it's possible) revolving around IF despite only showing whole numbers, elevation is actually using hidden decimals on its final total calculation that it never shows you elsewhere. No other numbers do this, what they show is what they use in their totals. All except eelevation is. With that one total, they did something different. Meh.

  • 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).

    Do you understand that numbers which have 1 or 2 decimal places can also be rounded?

    All of the values are being rounded for display, it's just that Garmin chooses to round elevation to 0 decimal places, but choose to round other numbers to 1 or 2 places.

    Also, just because those other numbers have 1 or 2 decimal places, doesn't mean that you won't find the same kind of discrepancy when you add them up yourself as opposed to looking at the total in the progress summary.

    Elevation is... A whole number

    Elevation is always recorded in metres, therefore it can't be a whole number under the covers.

    Do you understand that if Garmin records an elevation gain if 100 metres (for example), then in fact that is about the same as 328.084 feet. We all agree that Garmin would display that as 328 feet.

    It's 100% certain that there are hidden decimals for elevation, at least when it's displayed as feet. 

    To much conjecture (it could be, it might be, it's possible) revolving around IF despite only showing whole numbers, elevation is actually using hidden decimals on its final total calculation that it never shows you elsewhere. No other numbers do this, what they show is what they use in their totals. All except eelevation is. With that one total, they did something different. Meh.

    "No other numbers do this, what they show is what they use in their totals."

    First of all, you haven't proven that. You are only guessing that based on the fact that Garmin shows 1 or 2 decimal places for the other numbers, which isn't logical. How do you know that those numbers don't have more than 1 or 2 decimal places under the covers. I already gave the example of my 6.20 km run which was actually recorded as 6.20273 km under the covers. I can't be sure, but I would guess that it's 6.20273 which is used for totals, not 6.20. 

    If you manually added up the displayed distances for an entire year of activities, it's very likely that the answer would not match what's displayed in the progress summary, for the exact same reason as elevation gain.

    You probably don't even need an entire year, but you're more likely to see a discrepancy with more data.

    "what they show is what they use in their totals"

    I already explained why this would be a bad idea in general. You don't want to use the number which is shown for calculations, you want to use the original number which likely has more precision.

    Again, a simple example.

    I run 10 times with an elevation gain of 100 metres (328.084 feet) each time. If my display units are metres, this is shown as 100 metres. If my display units are feet, this shown as 328 feet.

    If we used your way of calculating totals (add up displayed numbers), then we'd get wildly different results depending on whether the display units were metres or feet.

    (display as metres) 10  x displayed number = 10 x 100 metres = 1,000 metres (3280.84 feet which rounds to 3281 feet): display as 1000 metres

    (display as feet) 10 x display number = 10 x 328 feet = 3280 feet: display as 3280 feet

    Can you understand that it doesn't make sense that changing the display units would result in a discrepancy of 1 foot in the totals? But that is what you are asking for.

    Now let's use Garmin's (and everyone else's) way of calculating totals (add up original numbers, only round and convert at the end):

    (display as metres) 10 x original number = 10 x 100 metres = 1,000 metres (3280.84 feet which rounds to 3281 feet): display as 1000 metres

    (display as feet) 10 x  original number = 10 x 100 metres = 1,000 metres  (3280.84 feet which rounds to 3281 feet): display as 3281 feet

    Your way displays 1000 metres and 3330 feet for the same data, but 1000 metres is equal to 3280.84 feet which isn't close.

    Garmin's way displays 1000 metres and 3281 feet for the same data. 3281 is just 3280.84 rounded, so it's close enough.

    --

    You also completely ignored this:

    Have you not ever looked at a survey on a news site with a bunch of percentages?

    Ever read the fine print: "numbers may not add up to 100% due to rounding"?

    Can you not see this is exactly the same situation? (Actually, the phrase is typically "percentages may not add up to 100% due to rounding", but my point stands)

    In Garmin's case, it's "individual activity elevation may not add up to total activity elevation due to rounding)

    --

    But I'm just repeating myself. You haven't understood a single thing in this thread bro. I give up. You ask for explanations but you ignore us when we try to explain.

  • Lol.... "I haven't understood a single thing in this thread" what a laughable thing to say. 

    What you really want is for me to admit that you're right and you have the exact answers and you don't. You're making certain assumptions to come to your conclusions & acting as though they are fact. 

    And in the process of this you seem to ignore the most glaring point I've been making from the start. You're so badly looking for the answer to prove to me you're on track that you're missing and can't focus on the glaring inconsistency of the data reporting. 

    So you talk about being repetitive I don't know how many times I can explain this and you kind of just gloss over and can't even admit the one issue I'm trying to point out so I'm going to do it for you one last time here. 

    OTHER NUMBERS USE DECIMALS. OTHER NUMBERS REPORTS DECIMALS. ELEVATION SHOWS NO DECIMALS. AND THE 2 PLACES THAT SHOW ELEVATION SHOW ONLY WHOLE NUMBERS. AND THOSE WHOLE NUMBERS DO NOT ADD UP TO THE 3RD PLACE THAT SHOWS A TOTAL.

    I know you badly want to believe this is all about these hidden decimals. Despite the fact they exist nowhere else for elevation other than in your conclusion they must be used and you are 100% for sure they are being used. 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. 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. Elevation is the one number of every single number shown that is using these hidden magic decimals. OR... Is there an error in the mathematical total. 3546 + 4288 = 7834 not 7833 and you claim conclusively you know this because the fact is there are hidden decimal places for elevation that nobody can see and that aren't reported anywhere else in any of the other reports it shows you.

    Clearly by my responses, I understand exactly what's going on. But I don't agree with you on everything, so don't insult tell me & say I don't understand or that I'm unable to understand or comprehending. I am this isn't rocket science. you're not making some sort of amazing points I can't wrap my brain around. But I'm not buying everything you're selling & you need to accept that because everything you're saying is based on assumptions that you cannot prove but you decided must be the answer to the problem. 

    You don't need to respond there's nothing more to say I get it you get it I'm not going to insult your intelligence and say you don't get it I merely saying you're glossing over some glaring inconsistencies and how numbers are shown and reported and conclusively saying... I know it's because of hidden decimals. No, you don't know if that's what's going on and in fact all of the other numbers it shows contradict what you're saying but since you believe in your hypothesis about these hidden decimals that's the answer you've gone with. You can't fathom it could just be a simple air in the mathematical algorithm behind the scenes that's adding up the total.

  • No other numbers do this, what they show is what they use in their totals

    Actually I can prove that this is also done for running distance. 

    Here's my anemic running numbers for July.

    If you add up all the distance numbers in the activity list, you get 103.95 km.

    But the progress summary says 103.97 km for total distance.

    According to you, this should not be happening.

    According to me, it's exactly what's happening with elevation and every other metric on the progress summary screen. 

  • But don't my word for it, try it with your own activity distance. If you pick a large enough range (say a month to a year), it's very likely you'll see the same kind of discrepancy.

  • Btw some of us work with numbers and logic for a living. Like working with systems that both display and calculate numbers.

    Kind of ignorant for you to assume that we're all just guessing and we have no idea what we're talking about. Yeah we are guessing, but it's educated guesses based on knowledge and experience.

  • OTHER NUMBERS USE DECIMALS. OTHER NUMBERS REPORTS DECIMALS. ELEVATION SHOWS NO DECIMALS. AND THE 2 PLACES THAT SHOW ELEVATION SHOW ONLY WHOLE NUMBERS. AND THOSE WHOLE NUMBERS DO NOT ADD UP TO THE 3RD PLACE THAT SHOWS A TOTAL.

    I JUST GAVE YOU AN EXAMPLE WHERE THE SAME THING HAPPENS WITH RUNNING DISTANCE.

    In most cases, whether a value is displayed with 0, 1 or 2 decimals, Garmin is still rounding for display but using the original value (with more decimals) for calculations.