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 »
Sandbox

Comments on Display a Progress Bar [FINALIZED]

Post

Display a Progress Bar [FINALIZED]

+3
−0

Now finalized: Display a Progress Bar

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.

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: [|||||||||||||||||||||||||||||||||-----------------]

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.

1 comment thread

Rounding from half (7 comments)
Rounding from half
trichoplax‭ wrote 20 days ago

Since you mention rounding, it might be worth mentioning the behaviour expected for decimals ending in 5. Some places always round up (2.5 rounds to 3, 3.5 rounds to 4), but other places (particularly statistical or scientific settings) have other rules, such as round to even (2.5 rounds down to 2, 3.5 rounds up to 4).

You could specify one, or leave this open if you are happy for people to choose, but it's worth being explicit about that decision.

Sylvester‭ wrote 19 days ago

Thanks for catching that! I edited the post and chose rounding up since that's simpler.

Shaggy‭ wrote 19 days ago

I would suggest instead allowing solutions to round .5 to whatever the built-in they're using defaults to. The crux of the challenge here is constructing the progress bar; requiring the numbers be rounded in a way that may not be a language's native way of doing so adds, I think, an unnecessary potential overhead.

trichoplax‭ wrote 19 days ago

That's a good point.

Sylvester‭ wrote 19 days ago

True, I'll change it.

celtschk‭ wrote 15 days ago

I think it is too restricting: You might not use a built-in rounding (and there might not be any defined to begin with; for example, C always truncates on converting to int; esoteric programming languages may not even have floating point to begin with). I think the challenge should just allow for any rounding direction in this case. That way solutions that use a language-provided rounding and solutions that implement rounding themselves are valid.

Sylvester‭ wrote 15 days ago

Alright, I'll update it haha