src.ppl = round((src.pl / src.maxpl * 100))
Problem description:
i want ppl to show up as 100.00 instead of 100. any ideas?
ID:146528
May 19 2005, 12:53 pm
|
|
Code:
src.ppl = round((src.pl / src.maxpl * 100)) Problem description: i want ppl to show up as 100.00 instead of 100. any ideas? |
Rob16 wrote:
Code: > src.ppl = round((src.pl / src.maxpl * 100)) Problem description: Here's one way to go about it: ppl = round(src.pl * 10000 / src.maxpl) Lummox JR |
In response to Lummox JR
|
|
Can't you just do this?
ppl = round(pl / maxpl * 100,0.01) |
In response to CaptFalcon33035
|
|
But what if it isn't as .00%? What if it's .05%?
|
In response to Fuuhaa
|
|
Fuuhaa wrote:
Can't you just do this? ppl = round(pl / maxpl * 100,0.01) Nope. For one thing, floating point doesn't handle decimals well. But besides that, rounding it isn't enough to force the two digits after the point. Lummox JR |
In response to Lummox JR
|
|
I see. The reference entry for round() shows an example of rounding to a decimal place so I thought it would work. I assumed it would show the extra digits cause that just seemed natural; should have tested it first.
Sorry for the misinfo, Rob. |
In response to Fuuhaa
|
|
Fuuhaa wrote:
I see. The reference entry for round() shows an example of rounding to a decimal place so I thought it would work. I assumed it would show the extra digits cause that just seemed natural; should have tested it first. round() only returns a slightly changed number as needed; it does not have anything to do with display. Lummox JR |
In response to Lummox JR
|
|
I'm aware of that. I expected those digits would be included in the return value. Like I said, it seemed only natural that they would be. Take for example a math test. You work out the answer to a problem to be 100, but the question states that your answer should be rounded to two decimal places. If you just answered 100, you'd be marked wrong, even though we all know 100 == 100.00
Just my fault for assuming... |
In response to Fuuhaa
|
|
Fuuhaa wrote:
I'm aware of that. I expected those digits would be included in the return value. Like I said, it seemed only natural that they would be. Take for example a math test. You work out the answer to a problem to be 100, but the question states that your answer should be rounded to two decimal places. If you just answered 100, you'd be marked wrong, even though we all know 100 == 100.00 Well the thing is, a number is just a number; it's abstract. How it displays is an entirely separate issue. For any given number BYOND will automatically display it a certain way unless you tell it differently. So really, rounding can't much affect the display because it's affecting the internal number. Now on the math test thing, first off 100 is still 100.00 so you wouldn't be marked wrong if the value was from 99.995 to just under 100.005. You'd only be marked wrong if the question said specifically to show those two decimal places. Or, if this was a science like physics where you need to preserve significant digits, that would matter; in regular math it doesn't. But when we manipulate digits ourselves, the appearance of the number is basically what we work with, so it's a little different than working with numbers in a more "raw" form. Lummox JR |
stat("[usr.pl].00")