Rounding

I am working on a cobble factory that uses turtles and a main computer. You type in the amount of cobble you want to have mined and the computer will divide that number by the amount of active turtles in the factory. I am having some trouble with dividing the amount of cobble between the turtles. If I want 1024 cobble and there are 5 active turtles then each one will be assigned to mine 204.8 cobble. This won't work with my code because the amount of cobble they have will never be equal to what they were assigned. I would like to know if there is a way I can round 204.8 to 205 to fix this problem.
Help is appreciated!
Thanks! :D/>

math.ceil(x) should work, it rounds whatever X is to the nearest integer greater or equal to it
Hope that helped :)/>

coolblockj, on 04 February 2013 - 12:44 PM said:

math.ceil(x) should work, it rounds whatever X is to the nearest integer greater or equal to it
Hope that helped :)/>/>

There is also math.floor() and math.round().

Just checked, math.round doesn't exist. True rounding can be done easily though, if you're rounding to the ones place.

math.floor(somenumber + .5)

Kingdaro, on 04 February 2013 - 05:01 PM said:

Just checked, math.round doesn't exist. True rounding can be done easily though, if you're rounding to the ones place.

math.floor(somenumber + .5)

:o/> really? I must be thinking of Java.

Yep, it's everywhere but lua. :lol:/>

Well, it's easy to make one…

function math.round(n)
	for i = 1, #tostring(n) do
		if string.sub(tostring(n), i, i) == "." then
			return tonumber(string.sub(tostring(n), i+1, i+1)) >= 5 and math.ceil(n) or math.floor(n)
		end
	end
	return n
end

Why does string.find(tonumber(n), ".") always return 1? :|

It's usually not best to use string functions to perform math.

There are a couple of rounding implementations on lua-users. Near the top are functions that round to decimal places, and below that are functions that round to specific counts (e.g. round(5, 7) = 7).

http://lua-users.org/wiki/SimpleRound (the one on the very bottom is mine ^^)

Well… It works, so a problem is one I don't see :P/>

It's just ludicrously expensive to convert a number to a string and then use string functions to do math on it before converting it back into a number.

Particularly when Kingdaro already posted a perfectly good solution…as in a solution simple and reliable enough to explain why Lua doesn't bother having a math.round() function.

Kingdaro, on 04 February 2013 - 05:54 PM said:

Yep, it's everywhere but lua. :lol:/>

You know, C and C++ don't have a round function in the standard library either. I've always found that a bit odd. :P/> I usually use your solution as well in C/C++. Except for when I need to round on the n-th digit.

rounding in c:

float f=1.5f
int i=(int)(f+.5f)

remiX, on 04 February 2013 - 06:11 PM said:

Why does string.find(tonumber(n), ".") always return 1? :|

Because you do not fully grok Lua string matching patterns. :)/>

GopherAtl, on 05 February 2013 - 09:36 AM said:

rounding in c:

float f=1.5f
int i=(int)(f+.5f)

That wouldn't work well for negative numbers. I always use:

#include <math.h>

double a = 3.14159f;
double rounded = floor( a + 0.5f );

or the same in C++:

#include <cmath>

double a = 3.14159f;
double rounded = std::floor( a + 0.5f );

Naturally floor should be called if you want the rounded value to still be used as a float; most commonly if I'm rounding a value in c, I'm converting to an int at the same time. I'm fairly sure this would behave as I would expect for negtive numbers - rounding -.5 to 0, -1.1 to -1, but I'm not 100% sure this is correct, as I don't remember dealing with this case before.

GopherAtl, on 05 February 2013 - 11:49 AM said:

Naturally floor should be called if you want the rounded value to still be used as a float; most commonly if I'm rounding a value in c, I'm converting to an int at the same time. I'm fairly sure this would behave as I would expect for negtive numbers - rounding -.5 to 0, -1.1 to -1, but I'm not 100% sure this is correct, as I don't remember dealing with this case before.

Well, let's take -1.1 . Thus, according to your example:

float f=-1.1f
int i=(int)(f+.5f)
// = (int)(-1.1f + .5f)
// = (int)(-0.6f)
// = 0

Casting to an integer will always round towards zero, so you get this problem. floor() will actually round towards negative infinity which makes it work.

ah, right. Floating-point values aren't signed the same way as integers, the mantissa is always stored unsigned.

GopherAtl, on 05 February 2013 - 11:59 AM said:

ah, right. Floating-point values aren't signed the same way as integers, the mantissa is always stored unsigned.

I'm not sure how that is relevant. Even if the significand would be signed under one's complement (not two's complement, floats have negative zero), it would be a matter of dropping the most significant bit like it wasn't there. The point is that you don't really round towards zero but just drop all decimals. It hardly even matters anyway.

jesus. Truncation would be the same as floor if the values were signed. Since the sign is separate from the mantissa, truncation is towards 0.

Half of my responses in this ridiculous back-and-forth have been clarifying things I said and the other half apologizing for omissions or mistakes I made. 100% of yours have been attacking me for what you apparently see as grevious errors. Carry on as long as you like, I'm done with this stupid tangent.

GopherAtl, on 05 February 2013 - 01:06 PM said:

jesus. Truncation would be the same as floor if the values were signed. Since the sign is separate from the mantissa, truncation is towards 0.

Half of my responses in this ridiculous back-and-forth have been clarifying things I said and the other half apologizing for omissions or mistakes I made. 100% of yours have been attacking me for what you apparently see as grevious errors. Carry on as long as you like, I'm done with this stupid tangent.

I've thought it through and you are right about the importance of signedness. Although you can expect correction when posting C code out of the blue, I admit that I was totally aggressive in my last post and I apologize for it.