I have the same result with Julia 1.8.0 on Windows10 or with Julia 1.8.1 on Linux.
Is that the expected behavior?
Is there a well known way to manage these rounding errors or should I systematically make rounding adjustments in my code? Is the “Nearest” method of rounding the most appropriate?
Rational numbers seem to behave better than Float.
julia > p = Rational(8,10)
julia> q = Float64(1-p)
In the specific kind of problem I am working on, I will not use numbers with absolute value larger than 1.
Inserting rounding at intermediate steps of the calculation is likely to reduce accuracy, unless you have reason to believe all intermediate steps will be nice numbers in decimal. In which case you may want something like DecFP.jl or Decimals.jl or FixedPointNumbers.jl.
Is the speed of calculation for BigFloat the same as for Float64?
I am not so much looking for many decimals. But I’d like exact results when dealing with simple numbers.
As pointed, Rational numbers seem better for my case but I’m not sure speed is comparable to Float64. Further, since I am doing trigonometric functions on these numbers, I am not sure that these imply a hidden conversion to Float64.
This is the expected behaviour of floating point representations. The problem being that decimals 0.2 and 0.8 cannot be represented exactly in the binary float format of Float64 (IEEE 754 standard). The link provided by @mcabbott is a good starting point. For all the glorious details click on " What Every Computer Scientist Should Know About Floating-Point Arithmetic" on that page.
julia> rationalize(0.2; tol=0) # Convert to rational exactly (must be possible as Float64 precision is finite)
julia> rationalize(1 - 0.8; tol=0)
Rational numbers are exact using integers as numerator and denominator. Yet, analytic functions such as sin or exp are not necessarily rational on rational arguments, i.e., can only be approximated on a computer anyways.
In any case, computers are restricted to a countable subset of the real numbers, namely the computable numbers. Had once seen a Common Lisp implementation of such where each number was represented by a function that could be run to provide an approximation at the desired precision. Efficiency of such a representation is very low and not many use cases require such fine control about the precision of approximations.