# what is "1.2+0.21" in Julia?
**URL:** https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085
**Category:** General Usage
**Tags:** question
**Created:** [August 9, 2018, 12:36pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085 "2018-08-09T12:36:01Z")
**Posts on this page:** 16
**Page:** 1
### Author:  [@askuyue](https://discourse.julialang.org/u/askuyue)
#### Post date: [August 9, 2018, 12:36pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/1 "2018-08-09T12:36:01Z")
Julia\>1.2 + 0.12
1.3199999999999998
---
### Author:  [@mauro3](https://discourse.julialang.org/u/mauro3)
#### Post date: [August 9, 2018, 12:40pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/2 "2018-08-09T12:40:30Z")
Excellent news, it’s within floating point precision of the true result. And welcome to Julia!
---
### Author:  [@austinbean](https://discourse.julialang.org/u/austinbean)
#### Post date: [August 9, 2018, 12:40pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/3 "2018-08-09T12:40:44Z")
> **[Floating-point arithmetic | Accuracy problems](https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems)**
>
> The fact that floating-point numbers cannot accurately represent all real numbers, and that floating-point operations cannot accurately represent true arithmetic operations, leads to many surprising situations. This is related to the finite precision with which computers generally represent numbers.
> For example, the decimal numbers 0.1 and 0.01 cannot be represented exactly as binary floating-point numbers. In the IEEE 754 binary32 format with its 24-bit significand, the result of attempting to ...
---
### Author:  [@mcarpe](https://discourse.julialang.org/u/mcarpe)
#### Post date: [August 9, 2018, 12:50pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/4 "2018-08-09T12:50:20Z")
…and just to be clear: this happens with any programming language that uses floating point arithmetic… and that pretty much covers them all.
---
### Author:  [@bernhard](https://discourse.julialang.org/u/bernhard)
#### Post date: [August 9, 2018, 1:13pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/5 "2018-08-09T13:13:10Z")
Also you may want to consider
[https://github.com/JuliaMath/Decimals.jl?files=1](https://github.com/JuliaMath/Decimals.jl?files=1)
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [August 9, 2018, 1:28pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/6 "2018-08-09T13:28:32Z")
This is the post you should read to get a quick overview of floating point issues: [PSA: floating-point arithmetic](https://discourse.julialang.org/t/psa-floating-point-arithmetic/8678)
---
### Author:  [@gdkrmr](https://discourse.julialang.org/u/gdkrmr)
#### Post date: [August 9, 2018, 1:41pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/7 "2018-08-09T13:41:43Z")
Julia should probably cover this up by rounding the printed results, this behaviour can be pretty confusing for beginners.
---
### Author:  [@askuyue](https://discourse.julialang.org/u/askuyue)
#### Post date: [August 9, 2018, 1:41pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/8 "2018-08-09T13:41:45Z")
Thanks very much. But I am worried that the error accumulation is serious.
---
### Author:  [@gdkrmr](https://discourse.julialang.org/u/gdkrmr)
#### Post date: [August 9, 2018, 1:44pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/9 "2018-08-09T13:44:09Z")
you can use `BigFloat` with arbitrary precision to check if your algorithm looses precision.
---
### Author:  [@bernhard](https://discourse.julialang.org/u/bernhard)
#### Post date: [August 9, 2018, 1:44pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/10 "2018-08-09T13:44:40Z")
To the best of my understanding it is as serious as in other languages. If you need exact results, use the decimal package mentioned above
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [August 9, 2018, 1:56pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/11 "2018-08-09T13:56:34Z")
> [@bernhard](#):
>
> If you need exact results, use the decimal package mentioned above
Decimals.jl (and similar packages like the more full-featured [DecFP.jl](https://github.com/JuliaMath/DecFP.jl)) only eliminate rounding errors in converting human decimal inputs into their computer representations. Arithmetic operations can still yield a result that has to be rounded, and hence can still incur roundoff errors.
But this is true for all computer languages: it is intrinsic to the available ways for computers to represent numbers.
Understanding roundoff accumulation is a complicated subject, but a quick test is to repeat your calculations in different precisions to see how sensitive your answer is to roundoff errors. You can also use something like [IntervalArithmetic.jl](https://github.com/JuliaIntervals/IntervalArithmetic.jl), but this will often give overly pessimistic error estimates.
---
### Author:  [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [August 9, 2018, 2:29pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/12 "2018-08-09T14:29:06Z")
```julia
julia> round(1.2 + 0.12, digits=4)
1.32
```
---
### Author:  [@Non-Contradiction](https://discourse.julialang.org/u/Non-Contradiction)
#### Post date: [August 9, 2018, 2:56pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/13 "2018-08-09T14:56:57Z")
As other people have said, this is same with any programming languages using floating point arithmetic, and in the low level, they actually use same or similar commands to carry out the computation and they follow the same rules.
This is the result from python 3.6 on my mac:
```julia
Python 3.6.3 |Anaconda custom (64-bit)| (default, Oct 6 2017, 12:04:38)
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 1.2+0.12
1.3199999999999998
>>>
```
And this is the result from R:
```julia
> 1.2+0.12
[1] 1.32
## Great! Isn't this the true result? But wait.... Let's try to print more decimal points...
> sprintf("%.15f",1.2+0.12)
[1] "1.320000000000000"
> sprintf("%.16f",1.2+0.12)
[1] "1.3199999999999998"
> sprintf("%.17f",1.2+0.12)
[1] "1.31999999999999984"
```
The reason why the original result in `R` seems “correct” is only because `R` uses a lower default precision to show the result, but under the hood, it is still the same.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [August 10, 2018, 1:03pm UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/14 "2018-08-10T13:03:20Z")
> [@gdkrmr](#):
>
> Julia should probably cover this up by rounding the printed results, this behaviour can be pretty confusing for beginners.
I disagree; I hate when languages do this. If someone finds it surprising, perhaps they will use it as an opportunity to learn about floating point arithmetic. I don’t mind seeing this question over and over.
---
### Author:  [@ascetic168](https://discourse.julialang.org/u/ascetic168)
#### Post date: [April 10, 2019, 6:10am UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/15 "2019-04-10T06:10:21Z")
The keyword is: “accumulation error”.
You are right, if your calculation takes hours, the error may become too big to accept. Using the calculation with “No error” or BigFloat may be too slow, And Float64 also can not satisfy your requirement, I suggest you can try:
[https://github.com/JuliaMath/DoubleFloats.jl](http://DoubleFloats.jl)
---
### Author:  [@sagartewari01](https://discourse.julialang.org/u/sagartewari01)
#### Post date: [April 10, 2019, 6:26am UTC](https://discourse.julialang.org/t/what-is-1-2-0-21-in-julia/13085/16 "2019-04-10T06:26:26Z")
Fixed point numbers should be used if one wants the results to be accurate. You don’t always need to use a library for this task. If you’re dealing with money, using cent count (integer) instead of dollar value for internal calculations can solve the precision issue.