0% / 100% vs 0.00% / 100.00%

[yakra]

Sometimes stats percentages are displayed with trailing zeros, sometimes not. For example,
http://travelmapping.net/user/system.php?units=miles&u=duke87&sys=usari
Distance Traveled is displayed as 100%.
Routes Traveled & Clinched are displayed as 100.00%.

Why, how?
Sometimes the percentages are rounded right in the SQL queries themselves. These get trailing 0s.
Sometimes the percentages are calculated & rounded by a PHP function. These don't get trailing 0s.

Do we want to standardize on the one, or the other? Do we care enough about this to even bother making the changes to standardize?

My opinion:
I like the cleaner look of 0%, 100%, etc.
If in the future we add more info to state stats tables & make them wider, 100% vice 100.00% will save us a wee bit of room.

Efficiency:
Rounding via PHP will in many cases allow us to simplify our SQL queries in many cases, eliminating LEFT JOINs, etc.
The fact that the trailing zeros are included when rounded via SQL suggests to me that these values are being stored/manipulated as strings rather than floats, which would be a bit less efficient, innit?

[Jim]

I'd prefer to make the 0 and 100 display without the decimal places consistently.  My only argument against changes that affect log files is that I like using diff to see changes and this would cause a whole bunch of "false positive" changes that would make it harder to find the real ones.

[michih]

I also think that there should always be the same number of decimal places.
However, I prefer 2, especially because "almost 100" might be rounded to 100% and one might think having a route or even system clinched. For instance, I've clinched 99.89% of auts and 99.82% of deua system. I don't wanna miss "almost clinched" routes or systems.

[Jim]

I think the idea is that the 0% and 100% would only be shown as such when it's legitimately 0 or 100.  All values in between would continue to have 2 digits after the decimal.

[yakra]

Trailing zeros would be truncated, i.e. 5.9 instead of 5.90.
Almost-0 or almost-100 values are still at risk of being rounded if they're off by 1/200 of a percent or less; this is already the case.
I'm not considering any changes to log files here; this thread was just about the web front end.

[michih]

We've recently changed log file output to 2 digits so that the same figures are output than on the site.

[si404]

Could 100% or 100.00% be 100.0% if column width is the issue here?

[yakra]

I'm not sure I've made it clear enough what I'm on about here.
All stats (AFAIK) are rounded to 2 decimal places. I don't propose going to any smaller number. Just that some functions will show us trailing zeros all the way out to 2 decimal places, and some functions will drop them.
So while in some cases we may have fewer sig figs in the strictest sense, less precision... we still have 2 decimal places. Same information, different presentation.
Compare
http://travelmapping.net/user/region.php?units=miles&u=duke87&rg=RI
http://tmtest.teresco.org/user/region.php?units=miles&u=duke87&rg=RI
There's the obvious difference in Duke87's stats right up top -- "100%" vs "100.00%".
Scroll all the way down to the bottom; tikester has 0.10% on the production site & 0.1% on tmtest; therealcu2010 has 0.50% on the production site & 0.5% on tmtest.
Other travelers will have the exact same stats, out to 2 decimal places, aside from a few others also affected by a trailing zero.

Recent changes (currently on tmtest) zapped a few trailing zeros: On one table because the info wasn't available from the SQL query (I've only just now learned about the existence of IFNULL, and don't yet have a handle on how it works, or if it even would here) meaning I had to calculate percentage via PHP, and on another table because I saw an opportunity to simplify an SQL query while in the process of making the other changes, and just PHP instead.
I decided to go ahead and submit these changes anyway; since we've had some of this inconsistency around since probably the birth of TM, switching around some of exactly what is inconsistent where won't kill us. If we even have noticed the inconsistency before now, there's not been much loud & sustained call to make it consistent -- not enough for me to remember if there'd been a forum thread, at least. If it's something we do want to sort out, we can probably continue to kick that can down the road a bit.

[Duke87]

It looks like the trailing zeroes are now being dropped on both the test and the production site.

The engineer in me finds it tidier and more reassuring to always have the same number of decimal places and isn't really a fan... though it is good to know that dropping trailing zeroes is all the code is doing, and that therefore it can be safely assumed that any instance of "0.5%" would be "0.50%" if you bumped the decimal out.

[michih]

It looks like the trailing zeroes are now being dropped on both the test and the production site.

I think that nothing has changed on the production server. User stats still show 2 digits and in HB 'user traveled' is 100%, rest is 100.00%.

The engineer in me finds it tidier and more reassuring to always have the same number of decimal places and isn't really a fan...

Me too!

[yakra]

It looks like the trailing zeroes are now being dropped on both the test and the production site.

I think that nothing has changed on the production server. User stats still show 2 digits and in HB 'user traveled' is 100%, rest is 100.00%.

The changes linked above only affected region.php & system.php. The focus there was only on fixing stat tables in untraveled regions & systems, not "solving" anything mentioned in this thread. The changes to the trailing zeros were just what it most convenient to do in the process at the time.

Personally, the inconsistency doesn't bother me enough to make a fix more than a low priority; this thread was intended as more of a "Hey, whadda y'all think about..." thread.

The engineer in me finds it tidier and more reassuring to always have the same number of decimal places and isn't really a fan...

Me too!

The sprintf function, which behaves similar to its C namesake, is used in user/index.php, user/system.php, and user/mapview.php. This is an option if we want to standardize on 2 sig figs, including places where our values are rounded by PHP rather than SQL.

[yakra]

Currently testing out some changes for an HB bug fix.
Per some of the comments here, I decided to try things out with the full 2 sig figs, i.e. "100.00%".
Looks OK in Chromium, but I primarily use Firefox, which looks yecchy (click images to enlarge):

Based on this, I'm inclined to emphasize this...

The engineer in me finds it tidier and more reassuring to always have the same number of decimal places and isn't really a fan... though it is good to know that dropping trailing zeroes is all the code is doing, and that therefore it can be safely assumed that any instance of "0.5%" would be "0.50%" if you bumped the decimal out.

...part of Duke87's quote, and lean toward Jim's preference:

I'd prefer to make the 0 and 100 display without the decimal places consistently.

Thoughts?

[Duke87]

I'm noting that dropping the decimal points after 100 doesn't necessarily eliminate the yecchy text wrapping in Firefox:


It looks like it only stops kicking to a second line for routes I've clinched that are <10 miles long.

So fixing that will require doing something else.

[Eth]

Either remove the space between the number and the % symbol, or replace it with a non-breaking space ( ) (&nbsp; in HTML). If your viewport is narrow enough, it may still unavoidably wrap onto a second line, but at least the % symbol won't be hanging out there by itself on that second line.

[yakra]

I'm noting that dropping the decimal points after 100 doesn't necessarily eliminate the yecchy text wrapping in Firefox:
It looks like it only stops kicking to a second line for routes I've clinched that are <10 miles long.

Even under 10 mi is a no go if I use the full 2 sig figs:

Either remove the space between the number and the % symbol, or replace it with a non-breaking space ( ) (&nbsp; in HTML). If your viewport is narrow enough, it may still unavoidably wrap onto a second line, but at least the % symbol won't be hanging out there by itself on that second line.

Just adding &nbsp we're still wrapping, but looking much nicer in the process.


I never quite liked the space between the number & the %, and no other pages use it. Getting rid of it, we're still wrapping.


We can minimize wrapping by dropping the trailing zeros, but not completely prevent it.

In these mockups, I've not dropped the trailing 0s for mileages, or the Total Drivers/Clinched percentages yet. These are a bit more deeply embedded in the code. For the mileages, we can re-round a variable that's already been formatted, or rework the tm_convert_distance function. Percentages, we can create extra variables to round our data after extraction from the SQL tables, or rework how the HTML is output (the former probably being simpler).

Even it we still have to wrap sometimes, I still prefer dropping trailing 0s. The cleanliness, the idea of chasing the goal of using minimal real estate, even if not reaching it... 100%. (Is that a pun?)