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?
>>
>>
