You can use rational numbers instead of floating-point numbers. For example writing 7//10 * 5//100 yields the exact value 7//200.
-erik On Tue, Dec 29, 2015 at 12:20 AM, Yonghee Kim <[email protected]> wrote: > what I've been doing is kind of similar to tax problem (game economy > simulation) > for now,turning floating number to integer is enough to solve all my > headaches. > > But I will remember your recommendation when I ran into more complicated > case. > > Thank you > > > 2015년 12월 28일 월요일 오후 10시 38분 21초 UTC+9, Scott Jones 님의 말: >> >> 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? >>> >>> -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/
