That is simply because you are using binary floating point (Float64 in
Julia), instead of decimal floating point. There is a very nice package,
DecFP.jl, (kudos to Steven Johnson, @stevengj on GitHub), that wraps the
Intel decimal arithmetic library.
You can do `Pkg.add("DecFP") ; using DecFP` (you may get a lot of
deprecation warnings, esp. on v0.5, you can also do a
`Pkg.checkout("DecFP") ; Pkg.build("DecFP")` to eliminate all but one
warning on v0.5), and then you can do:
julia> a = d"0.2"
+2E-1
julia> for i in 1:10 ; println(a * i) ; end
+2E-1
+4E-1
+6E-1
+8E-1
+10E-1
+12E-1
+14E-1
+16E-1
+18E-1
+20E-1
The output is a bit funny, but the answers are exact, unlike most of the
answers in the binary floating point case you showed.
Note: the most heavily used language in the world (at least up to the early
2000s, I'm not sure what the stats would be like now), which was the 2nd
ANSI standardized language, Cobol,
originally only had decimal arithmetic (Modern Cobols also support IEEE
binary floating point).
A number of other heavily used (but not much talked about) languages, such
as M/MUMPS, which happened to be the 3rd language standardized by ANSI,
even before ANSI C.
The most used version of M/MUMPS these days is Caché ObjectScript - which
adds many things, including objects and IEEE binary floats.
The Pick/MultiValue family of database languages also use decimal floating
point.
There is now the IEEE 754-2008 standard for decimal floating point, which
the DecFP.jl package conforms to (implementing 3 of the formats - there are
some more formats which I'm trying to write a package for, which are also
implemented in hardware on IBM POWER architecture processors).
There are a number of cases where it really is better to use decimal
arithmetic, in order to not get in trouble with the tax man! (Lots of
currency operations have this same issue)
Here's a real simple example: you have a store, where you sell something
for 70 cents, and there is a 5% sales tax. How much do tax to you charge
the customer?
*julia>tax = *
> *.7 * 0.05*
> *0.034999999999999996**julia> *
> *round(tax,2)*
> *0.03**julia> tax = *
> *d".70" * d"0.05"*
> *+350E-4**julia> *
> *round(tax,2)**+4E-2*
As you can see, with binary floating point, you get the wrong answer
(0.03), but with decimal floating point, you get the correct answer (the
one the tax authorities will want you to give them).
Depending on your particular use case, you can either use the default IEEE
binary floating point numbers in Julia, or the DecFP.jl package.
Scott
On Monday, December 28, 2015 at 4:59:24 AM UTC-5, Yonghee Kim wrote:
>
> I wrote simple code like this
>
> ----------------------
> a = 0.2
>
> for i in 1:10
> println(a * i)
> end
> ---------------------------
>
>
> and what I got is not 0.2, 0.4, 0.6, 0.8, 1.0 ....
>
> but this.
>
> 0.2
> 0.4
> 0.6000000000000001
> 0.8
> 1.0
> 1.2000000000000002
> 1.4000000000000001
> 1.6
> 1.8
> 2.0
>
>
>
> println(0.2 * 3) does the same thing. not 0.6 but 0.6000000000000001
>
> does anyone know why this happens?
>
>
