julia> 0.14*300
42.00000000000001
julia> Int32(0.14*300)
ERROR: InexactError: Int32(42.00000000000001)
Stacktrace:
[1] Int32(x::Float64)
@ Base .\float.jl:791
[2] top-level scope
@ REPL[12]:1
Or for that matter, it seems like 0.14
has a bug with floating point math …
julia> 0.14*50
7.000000000000001
julia> 0.14*100
14.000000000000002
julia> 0.14*40
5.6000000000000005
julia> 0.13*40
5.2
julia> 0.14*2203
308.42
julia> 0.14*10040
1405.6000000000001
julia> 0.14*200
28.000000000000004
This is a known limitation with float point operations. There might be some degree of imprecision because the computer does not represent numbers exactly. You will find similar results in Python for example.
1 Like
So is it safest to always use Int32(round( math ))
if an integer is expected?
I suspect it depends on the amount of precision you need. You could use Int64
or BigInt
if you need more precision. But I am not really an expert at mitigating float point rounding errors. I think if you describe your needs, someone with more expertise might be able to provide sound guidance.
1 Like
It seems like rational numbers might help with division, but that exhausts my knowledge.
1 Like
round(Int32, math)
is better.
1 Like
For my error, it was just to go into an argument for an array initialization within a loop, e.g. zeros(Int32( x[i] * 300 ))
and when x[i]
was 0.14
, it was not happy.
Gotcha. That might be OK if you are not testing exact equalities in your code. Perhaps you could isapprox
, but there might be other or better options for such cases.
2 Likes