# Why does Julia say 1/26=0.038461538461538464

julia> BigFloat(1/26)
0.0384615384615384636735058165868395008146762847900390625

julia> 1/26
0.038461538461538464

In fact, 1/26=0.0384615… 384615 as a decimal cycle section. So I doubt the value of BigFloat(1/26) and 1/26 giving by Julia are not correct. What happened？

What’s the problem/question here? Floating point numbers have limited precisions, they can’t losslessly represent all real numbers

10 Likes
``````julia> BigFloat(1)/BigFloat(26)
0.03846153846153846153846153846153846153846153846153846153846153846153846153846162
``````

The code `BigFloat(1/26)` first computes 1/26 which becomes a Float64 and then converts that to a BigFloat.

20 Likes

Yes or `BigFloat(1//26)` which takes the exact rational `1//26` and converts it to BigFloat.

I’m going to assume there are no bugs in the Intel/AMD chips etc, so the number it gives must be the closest 64 bit binary floating point number to the correct value. Let’s see:

``````julia> eps(1/26)
6.938893903907228e-18

julia> 1/26 + eps(1/26)
0.03846153846153847

julia> 1/26 - eps(1/26)
0.03846153846153846
``````

It looks like it was rounded right I guess.

7 Likes

You usually want to use `prevfloat`/`nextfloat`, `eps` is the maximum of the distances to the two adjacent floating point numbers, which is not always the same between the two of them (otherwise it’d be the same for all numbers)

5 Likes