Round a floating-point number down to the nearest integer?

Question

I want to take a floating-point number and round it down to the nearest integer. However, if it's not a whole, I always want to round down the variable, regardless of how close it is to the next integer up. Is there a way to do this?

Solution 1

Simple

int(x)

will work as well.

Solution 2

One of these should work:

import math
math.trunc(1.5)
> 1
math.trunc(-1.5)
> -1
math.floor(1.5)
> 1
math.floor(-1.5)
> -2

Solution 3

x//1

The // operator returns the floor of the division. Since dividing by 1 doesn't change your number, this is equivalent to floor but no import is needed. Notes:

1. This returns a float
2. This rounds towards -∞

Solution 4

To get floating point result simply use:

round(x-0.5)

It works for negative numbers as well.

Solution 5

I think you need a floor function :

math.floor(x)

View more solutions

Comments

[dmckee --- ex-moderator kitten]

A possible difficulty is that IEEE floating point formats can represent numbers so large that the grandularity is larger than 1. So that, while you can round x down rounding x+1 down will not give you the result you expect.

[Ashwini Chaudhary]

Please post some examples.

[Mr. Clear]

"Round down" and "round to the nearest integer" are two different things.

[voidMainReturn]

in python 2 it returns a float while in python 3 it returns int

[Helin Wang]

int(0.6) = 0 rather than 1

[Petr Peller]

@HelinWang That's exactly what OP asked for.

[evedovelli]

The output from math.trunc is an integer, while the output of math.floor is a float.

[Geoff]

Thanks for your answer. Next time you'll get a better reception if you write proper code (close parenthesis), and give some documentation.

[Adam Smith]

round was already discussed and rejected as an answer when this question was asked a year ago. OP wants math.floor.

[Pascal Cuoq]

This gives the wrong answer for whole integers. For instance, 2.0 rounded up is 2, and if you subtract 1 you get the incorrect result 1.

[Gyan Veda]

This seems like the most Pythonic approach.

[Jeff]

int(math.floor(x)) or float(math.floor(x))

[Alex Riley]

This works well for positive numbers, but negative numbers will be rounded up: int(-23.3) == 23

[bad_keypoints]

@PascalCuoq I don't understand your problem. Do you want 1.0 as the result? Because OP clearly wanted to round then number off to the nearest integer.

[Pascal Cuoq]

@bad_keypoints I don't think that the OP wants to round 2.0 to 1.

[bad_keypoints]

@PascalCuoq sorry, I just looked back at the answer in comment thread of which we are.

[blubberdiblub]

That is because 1.9999999999999999 is actually equal to 2.0 in the internal float64 representation. I. e. it's already rounded as soon as it is parsed into a float, as a 64 bit float cannot represent that many significant digits. You can verify that with evaluating 1.9999999999999999 == 2.0. And if you suspect that the equals operation does some rounding on floats, you can compare the binary representation with struct.pack("d", 1.9999999999999999) == struct.pack("d", 2.0), which is also equal.

[blubberdiblub]

And if that's exactly your point, then I don't see what's wrong with int(). The value is already 2.0 and it will convert it happily into 2.

[Muyide Ibukun]

and does not work for number beyond the integer range such as 600851475143, it will basically flag a memory error.

[lokilindo]

If OP's (or whomever reads this in the future) intention is to use the nearest integer ( and not the round-up value) for whatever reason, then it would be something to keep in mind.

[SKPS]

@evedovelli: Not really anymore. type(math.floor(1.51)) -> int and type(math.trunc(1.51)) -> int as of python 3.6.0

[Alon]

extremely sophisticated that is

[Antony Hatchkins]

@MuyideIbukun python? beyond the integer range?

[Tino]

@lokilindo But this has nothing to do with int(), it solely has to do with an improper use of float, as 1.9999999999999999 is rounded up to 2.0 at compile time (while int() is called on execution time). If you use the right data type for the variable, everything works as expected: int(decimal.Decimal('1.9999999999999999999999999999999999999‌​999999999999999999')‌​) gives 1

[Tino]

Nice addition. int(-1.1) == -1 while -1.1//1 == -2.0 however decimal.Decimal('-1.1')//1 == decimal.Decimal('-1') (as documented, claim 2 isn't true for decimal), so relying on how // behaves is not fully stable, even today.

[Tino]

@MuyideIbukun int(-1E99) gives (at my side) -99999999999999996733616880411669127384953318580655547291796‌​17794712958459217278‌​62608739868455469056‌​L which looks pretty ok to me.

[Tino]

@AlexRiley While you are mathematically correct, usually the "nearest lower integer" a human wants is towards 0 and not towards -inf. If your account balance is -23.3M$ you will rather think of having -23M than having -24M, right? Same is true if you have -23.9M; You will still pretend it's only -23M as long as you can ;)

[xskxzr]

What's the difference from this existed answer?

[Tristan]

These options are more explicit than "int(x)" and hence are more Pythonic.

[HosseyNJF]

@Tino But if you had $23.1M, you would definitely want to round it up to $24; so I don't think your example applies here:)

[Mikhail Gerasimov]

I like this solution much less than math.floor: one should know how int function works to see rounding down happens. The solution also relies on a detail of implementation of int function (even though it's unlikely to change). math.floor on the other hand is explicit: just looking at it is enough to be sure rounding down will happen.

[AlGiorgio]

As Mikhail said in accordance with Python Zen: Explicit is better than implicit. That's it about using int for rounding values.

[inyutin]

but it's wrong for already rounded numbers like 1: 1 - 0.5 = 0.5 and round(0.5) = 0, so 1 will be transformed to 0