Grade Resolution

Hi Dave! Yes, „mcinner1“ is my name on forums and simply „McInner“ as developer.

Today I did a testride using your Grade Calc, my own Grade (using my RadarOverlay datafield) and the native Garmin grade datafield on one screen. Your app works pretty good - much better than on a testride I did in the beginning of your release weeks ago.
I appreciate other dev‘s work and am interested to see what they do. 

Maybe there could be a user setting for the precision.

DaveBrillhart said:

But thinking maybe round it to the closest 0.5%? Think that might be better?

I know, that many users have asked Garmin to show one precision for grade. So, maybe flocsy🤠 is right, to let the user decide…

I lock GRADE to 0% if <= 0.6, and in the screen I show a rounded integer when <=2.5%. Above 2.5% I currently show one decimal place.

Are you rounding to the nearest integer or rounding towards 0? Bc if you round to the nearest integer, the user will see some funny behavior around 2.5

e.g.

2.4 => 2
2.5 => 3
2.6 => 2.6

In other words, here the grade is smoothly increasing but the displayed value would go up and down in a way that doesn't reflect the actual change in grade.

Otoh if you round towards 0, the user could still see sudden jumps in the displayed value in some cases where the grade is increasing smoothly.

e.g.

1.8 => 1
1.9 => 1
2.0 => 2
2.1 => 2
2.2 => 2
2.3 => 2
2.4 => 2
2.5 => 2
2.6 => 2.6
2.7 => 2.7

Why not just round all values consistently? Isn't your current system implying that 1 decimal place is too much precision (in some cases)? Why is one decimal of precision valid (or desired) for grades with magnitude greater than 2.5, but not for smaller grades? Seems counter-intuitive.

I've released 12.1 so I couldn't reply.

Are you not able to reply to reviews for old versions? I just replied to a review posted in 2021 (for an old version of a data field of mine), using the CIQ store website. (I have actually no idea whether devs can reply to reviews on the CIQ app haha).

Is the reply button not there? Or do you get an error when you try to reply?

Either way, I would file a bug report, as I don't think that would be intended behavior.

FYI: On the EDGE 1050, the GRADE is completely broken at least in beta 11.18. Strangely it seemed to work for about an hour and then goes haywire. Both the built-in native GRADE and my CIQ Grade Field. This is also being reported by others in the Beta Forum. On a sustained 3-5% climb, even the native Grade starts to report 0% or even -1%. I don't know if this is only the 1050 or also impacts other EDGE devices. I've added a User Setting to turn on advanced diagnostics metrics again (default is OFF), Which shows internal values like the feet climbed since the last sample, the various gradient working values, etc. That might help see what Garmin broke.

Garmin only shows integer values. What I've found, living in flat Florida is that the barometric noise riding on flats is annoying. So I show 0% if the abs() is under 0.4%. If over that I use Math.round().toNumber() up to abs() 2.5%... so we'll see 0%, 1%, 2%, and then they'll start to see single digit precision starting at 2.5%.... 2.5, 2.6, etc. Seems to be the best compromise for avoiding annoying noise when the slope is somewhat trivial, and more resolution once you exceed a grade threshold. I might adjust this, but it seems to work well for now.

Yeah, I get that Garmin only shows integer values.

What I've found, living in flat Florida is that the barometric noise riding on flats is annoying

This proves my point that even you agree sometimes displaying more than 0 decimal digits is not appropriate. Are you sure that your rule of thumb (to show 1 decimal digit above 2.5%) is logical and consistent for other users? If barometric noise makes the difference between 0.0 and 0.1 fairly meaningless, why doesn't the same logic also apply to 2.6 and 2.7, or 10.1 and 10.2, for example?

Who's to say that these tiny differences don't matter under 2.5% (and in fact they're "annoying") but they do matter at all other times (and I guess they're not annoying, either)? Why not put the threshold at 1%, 2%, 3%, or 5%? Seems kind of arbitrary.

So I show 0% if the abs() is under 0.4%. If over that I use Math.round[].toNumber[] up to abs() 2.5%... so we'll see 0%, 1%, 2%, and then they'll start to see single digit precision starting at 2.5%.... 2.5, 2.6, etc. 

The bolded part is not quite right, assuming what you said earlier is literally true.

I lock GRADE to 0% if <= 0.6, and in the screen I show a rounded integer when <=2.5%. Above 2.5% I currently show one decimal place.

I already tried to explain this, but:

(here, "round" is just a shorthand for rounding to the nearest integer as you've said you're doing)

round[2.0] => 2
round[2.1] => 2
round[2.2] => 2
round[2.3] => 2
round[2.4] => 2
round[2.5] => 3 !!!!!!!
2.6 => 2.6
2.7 => 2.7
2.8 => 2.8
2.9 => 2.9
3.0 => 3.0
...

See the problem now? Imagine that calculated grade is steadily increasing from 2.0 to 3.0 (at 0.1% every 10 seconds), and the user is watching the calculated grade data field like a hawk. Yeah it's a totally contrived example, but I'm trying to prove a certain point here.

They will see the data field hold steady at 2 for 50 seconds, then it will suddenly jump to 3, then the value will drop down to 2.6 and steadily climb to 3.0.

The calculated grade did not really jump from 2 to 3, then fall back to 2.6, and neither did the "real grade", probably. But that's what the user will observe.

Here's where one might say: well, why does it matter? It's just small differences in grade of 0.1%, 0.4% or even 1%? Well, the same logic can be applied to the question of displaying 1 decimal place of precision in the first place.

What I am trying to say is it doesn't seem right to apply this arbitrary rule for when 1 digit of decimal is being displayed. I could make an argument that the 1 decimal digit actually becomes more meaningless as your grade increases, not the other way around (as you've implemented it).

After all, if your grade goes from 0.1% to 0.2% (or .5% to 1%), we could at least say that the grade doubled (even though no human would notice, and the measurement error probably makes it meaningless - but again, why display the 1 decimal place in any case at all?)

But if your grade goes from 5.1% to 5.2%, that only represents a 1/50th change in grade.

For practical purposes, I would argue that a 0.1% difference in either case is not meaningful.

it's just me, but it seems that if an app were to display 1 decimal digit for grade, it would be a lot more intuitive if it always did so. Maybe this could be user-configurable (although in general, adding a setting bc we don't know what the user really wants is probably not the best solution imo).

Or maybe you could go back to your original idea of rounding to the nearest 0.5%. I think this is the best solution tbh. It's similar to what Garmin does with current pace (rounds to the nearest 5 seconds), although some users hate that and prefer to see pace to the nearest second.