Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Challenges

Comments on Display a Progress Bar

Parent

Display a Progress Bar

+5
−0

The goal of this challenge is simple: given a ratio of whole numbers, output a 50-character long progress bar representing the ratio.

Rules

Input

  • Your program must take two numbers as input. These numbers will be the numerator and denominator of the ratio, in that order. Your program cannot take the calculated result of the ratio as input. So, an input of $1/4$ is fine, but not $0.25$.
  • The numbers may be entered separately, or together with a / as a separator, whichever works best with your chosen language.
  • The numerator can be any integer greater than or equal to $0$, and the denominator can be any integer greater than $0$.
  • The ratio cannot be greater than 1, or less than zero. So $0 \le r \le 1$ where $r$ is the ratio. Thus, ratios like $12/3$ are not allowed.

Output

  • Your program must output a progress bar that is 50 characters in length, not counting the enclosing brackets.
  • The progress bar must fill from left to right.
  • The "filled" part of the progress bar must be made of pipes |, and the "empty" part of the progress bar must be made of dashes -.
  • The progress bar must be enclosed in square brackets [].
  • Whitespace is fine at the end of the output, but not anywhere else.
  • When calculating the number of "filled" characters to output, you may round in whichever direction your language supports. So a number of 33.1 can be rounded either up to 34 or down to 33, whichever you choose.

Scoring

This is a code-golf challenge, so the shortest code in bytes wins!

Examples

Example 1

Input: 1/2
Output: [|||||||||||||||||||||||||-------------------------]

Example 2

Input: 2/3
Output: [|||||||||||||||||||||||||||||||||-----------------]
or
Output: [||||||||||||||||||||||||||||||||||----------------]

Example 3

Input: 234/300
Output: [|||||||||||||||||||||||||||||||||||||||-----------]

Example 4

Input: 5/50
Output: [|||||---------------------------------------------]
History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

Rounding of 33.33 (2 comments)
Post
+3
−0

Uiua, 19 bytes

$"[_]"⊏⊙"-|">÷⟜⇡50÷

pad

$"[_]"⊏⊙"-|">÷⟜⇡50÷­⁡​‎⁠‎⁡⁠⁢⁡⁣‏‏​⁡⁠⁡‌⁢​‎‎⁡⁠⁤⁢‏⁠‎⁡⁠⁤⁣‏⁠‎⁡⁠⁤⁤‏⁠‎⁡⁠⁢⁡⁡‏⁠‎⁡⁠⁢⁡⁢‏‏​⁡⁠⁡‌⁣​‎‎⁡⁠⁤⁡‏‏​⁡⁠⁡‌⁤​‎‎⁡⁠⁢⁣‏⁠‎⁡⁠⁢⁤‏⁠‎⁡⁠⁣⁡‏⁠‎⁡⁠⁣⁢‏⁠‎⁡⁠⁣⁣‏⁠‎⁡⁠⁣⁤‏‏​⁡⁠⁡‌⁢⁡​‎‎⁡⁠⁡‏⁠‎⁡⁠⁢‏⁠‎⁡⁠⁣‏⁠‎⁡⁠⁤‏⁠‎⁡⁠⁢⁡‏⁠‎⁡⁠⁢⁢‏‏​⁡⁠⁡‌­
                  ÷  # ‎⁡divide arguments
             ÷⟜⇡50   # ‎⁢range from 0 to 1 in steps of 1/50
            >        # ‎⁣are greater than?
      ⊏⊙"-|"         # ‎⁤select using booleans: - if false and | if true
$"[_]"               # ‎⁢⁡format with square brackets
💎

Created with the help of Luminespire.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

2 comment threads

Correct rounding? (6 comments)
Off by one error (2 comments)
Correct rounding?
celtschk‭ wrote about 1 month ago

I don't know how to test this (in the linked web site, I don't see an execute button, nor a place to put the arguments), but from the description, I doubt that it gets the rounding right. Does 2/3 really give the output from Example 2, not one bar less?

trichoplax‭ wrote 26 days ago

I also couldn't see a way to run the code at the time the answer was posted, but there seem to have been some improvements to the interface since then. There is now a "Run" button to the lower right of the code, which displays the output for the 4 test cases.

One of the test cases is off by one, so I've added a separate thread (so that it is immediately clear from the thread title that something definitely needs to be fixed).

trichoplax‭ wrote 24 days ago

The challenge author has now edited to allow rounding of 33.33 to either 33 or 34, so there is now nothing to be fixed. This answer is correct on all test cases.

celtschk‭ wrote 14 days ago

I don't like the challenge terms to be changed after examples have been posted (except to clarify the task if the original text was unclear). Even if the change doesn't invalidate examples, it penalises those who took care to implement the previous specification correctly. Definitely in terms of time spent writing the solution, but potentially also in terms of score if the new specification allows a shorter implementation.

trichoplax‭ wrote 14 days ago

From my perspective, the new wording appears to be a change, which I'm uncomfortable with for the same reasons as you.

However, my impression is that from the challenge author's perspective, this is a clarification rather than a change. The wording in the comment on the challenge supports this:

The rule means that 33.x can be rounded either down to 33 or up to 34, no matter what digit x is. I can add second test cases if needed.

It's unfortunate that this was not caught at sandbox stage. I didn't suggest an additional test case output at that point because I was not yet aware of the ambiguity. I thought the single output for that test case was the only valid one. To me, "rounding" refers to the treatment of the half way point only, but the existence of several answers rounding 33.3 up to 33.4 suggests not everyone uses the word in the same way.

trichoplax‭ wrote 14 days ago

In general, I would much prefer to avoid rule changes. In this particular case, I can't see a way to have spotted this ambiguity before answers arrived, and now that answers have arrived, either way of resolving the ambiguity will disadvantage half of the answers (it was just a matter of choosing which half).