# Incorrect result from \`floor\` function
**URL:** https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262
**Category:** General Usage
**Created:** [November 29, 2021, 11:55pm UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262 "2021-11-29T23:55:46Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@eshanuniyal](https://discourse.julialang.org/u/eshanuniyal)
#### Post date: [November 29, 2021, 11:55pm UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262/1 "2021-11-29T23:55:46Z")
I was working on a Project Euler problem and discovered what looks like a bug in the `floor` function; with some large numbers `d`, `floor(Int, d/9)` seems to round up instead of down. I haven’t looked into it too much, but one example of this behaviour is with `d = 37889062372043916`:
```julia
julia> d = 37889062372043916;
julia> floor(Int, d/9), d÷9
(4209895819115991, 4209895819115990)
julia> floor(Int, d/9) - d÷9
1
```
Of course, for what I want to do, I should probably have used the ÷ operator instead of the `floor` function with an `Int` argument from the get-go. I’m curious though as to whether this is a real bug or just something that should be flagged in the documentation, which currently says
> floor(T, x) converts the result to type T, throwing an InexactError if the value is not representable."
making no promises the converted value will be the true floor.
Thanks!
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [November 30, 2021, 12:09am UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262/2 "2021-11-30T00:09:55Z")
weird, bug fixed at some point? On 1.7.0-rc2
```julia
julia> 37889062372043916÷9
4209895819115990
julia> floor(Int, 37889062372043916/9)
4209895819115990
```
---
### Author:  [@simeonschaub](https://discourse.julialang.org/u/simeonschaub)
#### Post date: [November 30, 2021, 12:14am UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262/3 "2021-11-30T00:14:14Z")
The issue here is that `Float64` only has 53 mantissa bits, so not every `Int` can be represented exactly. `d/9` converts `d` to a `Float64`, which involves some rounding:
```julia
julia> d = 37889062372043916
37889062372043916
julia> Float64(d)
3.788906237204392e16
julia> Int(ans)
37889062372043920
```
The documentation of floor is not actually the issue here, since the rounding is introduced by the conversion from `Int` to `Float64`, not `floor`.
---
### Author:  [@simeonschaub](https://discourse.julialang.org/u/simeonschaub)
#### Post date: [November 30, 2021, 12:20am UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262/4 "2021-11-30T00:20:47Z")
I can not reproduce this. What does `Float64(d)` return for you? Perhaps this is an openlibm issue?
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [November 30, 2021, 12:22am UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262/5 "2021-11-30T00:22:13Z")
> [@jling](#):
>
> `37889062372043916/9`
ah yes…SafeREPL was used and I didn’t start a new session…
---
### Author:  [@jzr](https://discourse.julialang.org/u/jzr)
#### Post date: [November 30, 2021, 12:55am UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262/6 "2021-11-30T00:55:57Z")
> floor(T, x) converts the result to type T, throwing an InexactError if the value is not representable.
is rather unclear. That seems like it should be the documentation of `convert(T, x)`, not `floor(T, x)`.
---
### Author:  [@eshanuniyal](https://discourse.julialang.org/u/eshanuniyal)
#### Post date: [November 30, 2021, 3:45am UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262/7 "2021-11-30T03:45:35Z")
I see, thanks for explaining this! I’ll be more careful about implicit type conversions in the future.
---
### Author:  [@eshanuniyal](https://discourse.julialang.org/u/eshanuniyal)
#### Post date: [November 30, 2021, 3:48am UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262/8 "2021-11-30T03:48:24Z")
I agree, though I’m not sure what a better version of this documentation would look like. Perhaps it could be more explicit in specifying that `floor(T, x)` is simply defined as `convert(T, x)`, so one can refer to the documentation for the latter for more information on how that’s implemented.
---
### Author:  [@jzr](https://discourse.julialang.org/u/jzr)
#### Post date: [November 30, 2021, 5:40am UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262/9 "2021-11-30T05:40:57Z")
The `convert(T, x)` docs say
> If T is an Integer type, an InexactError will be raised if x is not representable by T, for example if x is not integer-valued, or is outside the range supported by T.
but
> If T is a AbstractFloat or Rational type, then it will return the closest value to x representable by T.
What is the rationale behind this “sometimes lossy, sometimes error” API? Is it that `AbstractFloat` and `Rational` are considered inherently lossy?
---
### Author:  [@gustaphe](https://discourse.julialang.org/u/gustaphe)
#### Post date: [November 30, 2021, 6:22am UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262/10 "2021-11-30T06:22:10Z")
> [@jzr](#):
>
> Is it that `AbstractFloat` and `Rational` are considered inherently lossy?
I think that’s exactly it. People working with floats will (if they know what they are doing) expect there to be some rounding involved. You don’t use `==` with floats, for instance.
There’s also the fact that integers have the rounding functions available, but you can’t, for instance, use `round(Float64, x)` to get the closest representable float.
---
### Author:  [@jzr](https://discourse.julialang.org/u/jzr)
#### Post date: [November 30, 2021, 7:05am UTC](https://discourse.julialang.org/t/incorrect-result-from-floor-function/72262/11 "2021-11-30T07:05:33Z")
[https://docs.julialang.org/en/v1/manual/conversion-and-promotion/#Conversion-vs.-Construction](https://docs.julialang.org/en/v1/manual/conversion-and-promotion/#Conversion-vs.-Construction)
> It is also usually lossless; converting a value to a different type and back again should result in the exact same value.
I guess float and rational are why it says “usually”.