- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
What's worse is that it displays all the circles if you are 90.001% complete. That should happen only at 100%.
Admin
And again, like Monday's post, they are confusing "percentage" with "fraction".
Admin
And of course
percentage
contains a fraction rather than an actual percentage...Admin
That's alright. Actual percentage should be for display only; using fractions internally is good. So just a slight misnomer.
What bothers me more is that instead of hard-coding all the cases, this could be done algorithmically. Not exactly rocket since and it would make it easier to fix the rounding (cf. gnasher's comment), change the character (when the boss decides we need the green circle rather than the blue one), or the width of the bar.
Admin
No they aren't. If percentage is ever computed as negative, that's a WTF somewhere else in the code and otherwise if it's close-but-not-quite-equal to 0, it's going to hit the (percentage > 0.0 && percentage <= 0.1) case. There's a bit of a WTF in that all the > checks are redundant, but that's minor.
Admin
I am glad somebody else made the same observation. The Real WTF is people confidently asserting things based on flawed virtual execution of source code.
(I once got a resume with a few self-descriptions right below the candidate's name. The first self-description was "human compiler". I was not curious enough about why they thought that was a selling point to do a phone screen.)
Admin
I'm confused, this code is perfectly fine.
The second line covers everything above 0. There is nothing wrong with checking against zero, 0D is in fact a concrete binary representation of double, no rounding issues whatsoever.
You never ever use Equals in C# with keyword types; the operators are the primary implementation, Equals is just an overwrite in case the ValueType is boxed. This includes strings. A very common mistake Java developers make.
So yeah, this code is actually best practice how to handle floating point numbers in .net; it uses correct operators, follows correct binary representations (.net is after all ISO standardized open source, so those representations are clearly defined compared to other non-standardized proprietary languages like Java) and the code will even be optimized by Roslyn.
The only thing is the mix-up between logic and representation, but maybe this is part of a view, so then this code is pretty much perfectly following best practices.
Admin
You can check the rest of the code for yourself. It's been made public: https://github.com/MinBZK/woo-besluit-broncode-digid-app
Admin
All the percentage > X comparisons are unnecesary unless you can have negative values. Also can be converted to a nice little pattern matching:
return percentage switch { < 0 => "FILE_NOT_FOUND", 0 => "⚪⚪⚪⚪⚪⚪⚪⚪⚪⚪", <= 0.1 => "🔵⚪⚪⚪⚪⚪⚪⚪⚪⚪", <= 0.2 => "🔵🔵⚪⚪⚪⚪⚪⚪⚪⚪", <= 0.3 => "🔵🔵🔵⚪⚪⚪⚪⚪⚪⚪", <= 0.4 => "🔵🔵🔵🔵⚪⚪⚪⚪⚪⚪", <= 0.5 => "🔵🔵🔵🔵🔵⚪⚪⚪⚪⚪", <= 0.6 => "🔵🔵🔵🔵🔵🔵⚪⚪⚪⚪", <= 0.7 => "🔵🔵🔵🔵🔵🔵🔵⚪⚪⚪", <= 0.8 => "🔵🔵🔵🔵🔵🔵🔵🔵⚪⚪", <= 0.9 => "🔵🔵🔵🔵🔵🔵🔵🔵🔵⚪", _ => "🔵🔵🔵🔵🔵🔵🔵🔵🔵🔵", };
Spacing and negatives handling added for your convenience.
Addendum 2023-01-18 08:05: EDIT: Sorry about the formatting.
Admin
I always like it when one (wo)men's WTF is another (wo)men's fine code :)
Admin
This isn't a WTF at all. This code is fine. Very easy to read, understand and maintain. Is it more verbose and explicit than it needs to be? Sure, you could compute the number of circles to output, but then the code would be much harder to understand at first glance. The only minor improvement I would suggest is to remove the redundant
>
checks.Admin
Sure, it makes it much easier to change it inconsistently. Change a number here and there, and suddenly you have a bar that runs slower and faster at different points, or a bar that jumps from blue to green circles if you change the character and overlook some. Fixing the rounding (so 90.1% is not shown as 100%, cf. gnasher's comment) properly involves changing about 20 numbers rather than one. And let's not talk about widening the bar to say 20 characters wide. Yeah, so easy to maintain!
Come on, if simple multiplication and rounding is "much harder to read", you shouldn't be calling yourself a programmer.
Admin
Use a switch expression with pattern matching... common, aren't C# programmers using C# 8.0 yet?
Admin
I don't see anything wrong with displaying a full row when it's 90.01% complete. that depends on the customer's requirement. If the display disappears when it gets to actual 100%, then it makes a lot of sense to display all the dots when it gets to > 90
Admin
This code is terrible, where are the other 90 lines to check each percentage point?
Admin
If you only display all the circles at 100%, you would probably never actually see it with all the circles and thus have to modify the code to do some sort of sleep once it is done just so the user can see all the circles lit up.
Admin
I wouldn't have trouble understanding what the code does, but it would definitely take longer than in its current form. And I'm just giving an opinion, no need to insult me...
Admin
I tend to think of percentages as integers, not doubles. If you need precision then showing percentages is not the right way
For progress meters I would just round to integers as first step then display a string like (in Python)
def GetPercentageRounds(progress): percentage = int(progress) return "🔵" * (percentage // 10) # between 1 and 10 progress characters - unicode round blue circles for reasons
print(string_val)
Admin
The article author doesn't seem to understand how floating point works on computers.
When you or I do floating point operations on paper or in our heads, if we use numbers with no end like pi or 0.3333.... we won't use the whole number but will cut it off at some reasonable poin, with the understanding the result can only be trusted to a certain number of decimal points.
PCs work exactly the same way. Floating point numbers are stored in a binary form of scientific notation (base * 2 ^ exp) with a limited number of bits for the base and exponent. The bits in exponent determine the range possible. The bits in base determine the precision possible. So if the number gets cut off inthe base bits you get rounding error.
Guess what? 0 can be perfectly represented with no rounding error.
Admin
They're in the PaulaBean.
Admin
Hmm, as a more flexible loop: (This should be C#)
Admin
Regarding the
== 0
controvery: I was originally also agreeing, that the article is taking issue with the wrong thing here, as== 0.0
comparisons are actually reliable in floating point. However, it is forgetting to ask "how is the zero calculated".If the form is something like
where all variables on the right-hand side are integers? The result will be exactly 0.0. All is fine. But if instead "total" and "current" are already floating point variables, things get ickier.
Let's say you have a list of tasks with assigned weights. Then you might have something like
and I wouldn't trust the result to be exactly 0.0 any more.
That said, I'm also taking issue with the
of "percent" when really it is "fraction". Calling the parameter "percent" is misleading in a way that can easily lead to bugs.
Admin
This is code for my national ID system. It is absolutely fundamental to all digital interactions with my government and allied agencies. This is not your employer's Scrummy move-fast-and-break-things sales app. Nobody is going to "change a number here and there".
Admin
@Nutster I haven't done anything with C# so I was sufficiently intrigued to try out your snippet as my "Hello Paula" plunge into the .NET pool ("When the dot-net comes around, you must whip it...") ...
I found that your code didn't quite work as intended; I had to move that bar_size divisor over to the other side and divide
percentage
by it to get it starting to behave correctly.I also tweaked your function thusly to get it to scale for bar_size other than 10 (I tested for bar_size of 5 to 30 using an online C# compiler):
Admin
I don't know why there are so many people here actively trying to kill the planet by generating multiple reference objects in an iteration instead of simply returning one out of 10 string literals. Must be Java developers, they really hate the planet :-)
Admin
It keeps us warm in a brutal East Coast winter. We warm ourselves and cook our food in the heat generated by these computations. Instead of casting aspersions on our survival tactics, why don't you go funroll a loop?
Addendum 2023-01-19 08:08: 😛
Admin
Usually, when hitting 100% the progress bar disappears and we can start to do something else. Similarly, as a user, I would like to see if anything is happening. So only displaying nothing when at zero percent is maybe not mathematically correct, but for the user it probably is more informative than still displaying zero.
I'm not sure which programmers voted that as informative, but you should do some rethinking around the actual use case.
Admin
Not displaying the full 100% is fine. Think about the actual user. They hit full circles and then the process stalls. That's not very nice, you give them a hint that they are there and then they get stuck anyway (Windows used to do this while installing things, although it might be that they just didn't expect the next operation to take a long time).
You could maybe consider showing all circles when hitting 100% (or 1.0) but in that case you'd update the GUI only for it to immediately disappear, if it appears at all. There is a reason why we nowadays often see a circle going around, progress bars are often deceptive.
Admin
They missed an opportunity to make a spinning ball.
Admin
Admin
Ha. Well done!