Author Topic: 0% / 100% vs 0.00% / 100.00%  (Read 11098 times)

0 Members and 1 Guest are viewing this topic.

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4234
  • Last Login:February 13, 2024, 07:19:36 pm
  • I like C++
0% / 100% vs 0.00% / 100.00%
« on: July 22, 2019, 11:57:44 am »
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?
Sri Syadasti Syadavaktavya Syadasti Syannasti Syadasti Cavaktavyasca Syadasti Syannasti Syadavatavyasca Syadasti Syannasti Syadavaktavyasca

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2732
  • Last Login:Today at 02:09:10 pm
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #1 on: July 22, 2019, 09:18:25 pm »
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.
« Last Edit: July 23, 2019, 01:59:54 pm by Jim »

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4555
  • Last Login:Yesterday at 04:04:16 pm
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #2 on: July 23, 2019, 01:43:01 pm »
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.

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2732
  • Last Login:Today at 02:09:10 pm
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #3 on: July 23, 2019, 02:00:44 pm »
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.

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4234
  • Last Login:February 13, 2024, 07:19:36 pm
  • I like C++
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #4 on: July 23, 2019, 11:16:10 pm »
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.
Sri Syadasti Syadavaktavya Syadasti Syannasti Syadasti Cavaktavyasca Syadasti Syannasti Syadavatavyasca Syadasti Syannasti Syadavaktavyasca

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4555
  • Last Login:Yesterday at 04:04:16 pm
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #5 on: July 24, 2019, 11:21:57 am »
We've recently changed log file output to 2 digits so that the same figures are output than on the site.

Offline si404

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1948
  • Last Login:Today at 01:42:46 pm
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #6 on: July 24, 2019, 11:36:22 am »
Could 100% or 100.00% be 100.0% if column width is the issue here?

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4234
  • Last Login:February 13, 2024, 07:19:36 pm
  • I like C++
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #7 on: July 24, 2019, 10:02:50 pm »
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.
Sri Syadasti Syadavaktavya Syadasti Syannasti Syadasti Cavaktavyasca Syadasti Syannasti Syadavatavyasca Syadasti Syannasti Syadavaktavyasca

Offline Duke87

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 938
  • Last Login:Yesterday at 04:26:16 pm
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #8 on: August 16, 2019, 03:28:18 pm »
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.

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4555
  • Last Login:Yesterday at 04:04:16 pm
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #9 on: August 17, 2019, 02:55:25 am »
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!

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4234
  • Last Login:February 13, 2024, 07:19:36 pm
  • I like C++
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #10 on: August 19, 2019, 06:12:54 pm »
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.
Sri Syadasti Syadavaktavya Syadasti Syannasti Syadasti Cavaktavyasca Syadasti Syannasti Syadavatavyasca Syadasti Syannasti Syadavaktavyasca

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4234
  • Last Login:February 13, 2024, 07:19:36 pm
  • I like C++
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #11 on: August 27, 2019, 05:18:43 pm »
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?
Sri Syadasti Syadavaktavya Syadasti Syannasti Syadasti Cavaktavyasca Syadasti Syannasti Syadavatavyasca Syadasti Syannasti Syadavaktavyasca

Offline Duke87

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 938
  • Last Login:Yesterday at 04:26:16 pm
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #12 on: August 27, 2019, 07:28:00 pm »
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.
« Last Edit: August 27, 2019, 07:30:19 pm by Duke87 »

Offline Eth

  • Jr. Member
  • **
  • Posts: 70
  • Last Login:March 26, 2024, 04:01:53 pm
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #13 on: August 27, 2019, 07:54:12 pm »
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.

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4234
  • Last Login:February 13, 2024, 07:19:36 pm
  • I like C++
Re: 0% / 100% vs 0.00% / 100.00%
« Reply #14 on: September 03, 2019, 12:23:13 am »
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?)
Sri Syadasti Syadavaktavya Syadasti Syannasti Syadasti Cavaktavyasca Syadasti Syannasti Syadavatavyasca Syadasti Syannasti Syadavaktavyasca