Progress Reports fail at simple addition

Rounding. The original values can be for example 3545.6 and 4287.7 feet (rounded to 3546 and 4288) which gives the sum of 7833.3 (rounded to 7833)

It's highly unlikely and the reason why is elevation is never reported in tenths.

Speed is, mileage (distance) is, training effects are. Elevation is not. So if rounding was done, I'd see it in other report numbers.

For example, total distance is clearly reported as 64.93 mi not 65 miles. Max speed is 48.2 not 48. Even total time goes out to seconds, 9hr 31min 33sec not 9hr 32min. So other numbers that are reported out to tenths are not rounded in totals. Elevation is not reported out to tenths, so why would it be rounded.

Locked-N-Loaded said:

It's highly unlikely and the reason why is elevation is never reported in tenths.

The elevation is recorded in the activity file in tenth of meters. It means with the accuracy of 0.3 feet. Open any of your activity files with the FitFileViewer, and you'll see the unrounded values

Ok that's admittedly interesting and I will do it to verify what you're saying.

But why are other numbers reported in tenths NOT rounded in totals or in reporting. But elevation is? Where's the logic in showing the tenths in numerous numbers, reporting them in totals, not rounding them BUT not report them in elevation & yet round them? AND they report the full numbers and only round in the total?

That's still a reporting error & disconnect.

Ok that's admittedly interesting and I will do it to verify what you're saying.

But why are other numbers reported in tenths NOT rounded in totals or in reporting. But elevation is? Where's the logic in showing the tenths in numerous numbers, reporting them in totals, not rounding them BUT not report them in elevation & yet round them? AND they report the full numbers and only round in the total?

That's still a reporting error & disconnect.

UPDATE; In neither a FIT file download (using the online tool you suggested) or CSV download are elevation tenths shown as you claim. it's all whole numbers.

Locked-N-Loaded said:

UPDATE; In neither a FIT file download (using the online tool you suggested) or CSV download are elevation tenths shown as you claim. it's all whole numbers.

You are looking at the wrong place. The unrounded values are available here:

It is actually recorded with the accuracy of 2 decimal places (1cm), hence ~0.03 feet. The accuracy of 0.1m is in the Splits table.

How are those "unrounded values"? They are reported values IN the same file. It's as though you're conflating the accuracy that they report (0.95 to 0.99 for believability that 8000ft is accurate, it's a confidence level) for elevation as meaning they go out 2 decimal points BUT don't show you said decimal points on any part of the file?? Yet they show them in other reported numbers?

"Aaccuracy" (which isn't the final elevation value, accuracy is how accurate the elevation value is, not a method to then offset the total calculation by). BUT the fact is, the whole number ascent IS shown in whole numbers as I've been saying. The same file is showing the whole number but you're claiming it's not actually using the whole number in it's calculation. 

So what you're saying is so convoluted if you think about it.... The online reports shows elevation as a whole number, the CSV shows a whole number, the FIT file shows a whole number, my watch shows a whole number BUT it's doing its "total" calculation on a non whole number??? Even while not tweaking other numbers that are shown, reported & totaled out to tenths (like speed which shows tenths and calculates totals in tenths). Nothing actually shows any elevation as say 4287.7.ft. But you're claiming these 0.95 (mine is 0.99)  fractional ascent numbers (which is ACCURACY of the reported amount NOT an unadjusted elevation amount) suddenly means that behind the scenes total calculations on JUST elevation (& no other reported numbers mind you) are not done on the reported whole number, but on this fractional accuracy. "accuracy" isn't a reported stat, it's the believability & accuracy of the reported stat. And every single thing relative to elevation is being shown as.. whole numbers.

This logic doesn't compute. Especially when compared to how other numbers are reported & tallied. All apparently done the same way BUT elevation is the 1 tallied different than it's reported number??

Locked-N-Loaded said:

This logic doesn't compute.

The logic of summing up the most accurate available data to get the total result is perfectly reasonable, and correct. If you wish that Garmin sums the rounded values, although not everyone would agree with it, you can always suggest the change to Garmin at Share Ideas | Garmin

You're writing, but you're not saying anything. You're not even addressing the very obvious points I'm spending copious amounts of time making that aren't deniable. For example you just sidestep the fact that you're claimed "fractional accuracy" explains hidden decimal points not seen & rounded wholes when all its actually doing is explaining the accuracy of the obtained value (that was a pretty wild stretch). Or how none of the other reported dozens of values... are rounded. But elevation is. Despite showing no tenths or hundredths. In fact, you've done nothing to prove in any way shape or form that elevation is a rounded whole based on not reported decimal places. Nothing. 

I remember you.. I've been around the block with you before here. It's like you're the great defender of Garmin, but can't bring yourself to acknowledge issues. Just like I raised the issue about "lux hours" being a meaningless term that translates to nothing any human can use. I think you like to just respond to add street cred, but you never really have any answers.

Ps - yes, I know I can suggest issues to Garmin I've done it before and even had them respond that they agreed about the nebulous of the lux hours.