# BigFloat wrong

Why BigFloat(10^(1/4) is wrong?
julia> BigFloat(10^(1/4))
1.778279410038922758729995621251873672008514404296875

exact: 1.77827941003892280122542119519…

Thanks

Perhaps you want to convert before the operation:

``````julia> BigFloat(10)^(1/4)
1.778279410038922801225421195192684844735790526402255358011830722776301881539489
``````

To elaborate more on the previous answer, when `x` is a `Float64`, `BigFloat(x)` doesn’t give you extra precision compared to the original `x`, it just represents `x`, which has 53 bits of precision, as a `BigFloat`. To construct a `BigFloat` you want either to start from an integer (like in the example above) or use the `big"..."` string literal

Oh, Thanks. What you mean with “convert”?

Try:

``````julia> 10^(1/BigFloat(4))
1.778279410038922801225421195192684844735790526402255358011830722776301881539489
``````

You must make sure that already the first operation, the division is done with high accuracy.

`BigFloat(10)` will convert `10::Int` to a `BigFloat`.

The key point is that `^` already happens with `BigFloat`s, which can be achieved by either argument being one.

It’s often more convenient to just write `big(n)` to get either a `BigFloat` or a `BigInt` depending on the argument type:

``````julia> big(10)^(1/4)
1.778279410038922801225421195192684844735790526402255358011830722776301881539489

julia> 10^(1/big(4))
1.778279410038922801225421195192684844735790526402255358011830722776301881539489
``````

Note that for `1/4` these are the same because `1/4` is exactly representable in binary but for other fractions, as @ufechner7 pointed out, you’ll want to make sure the division is done in high precision by doing the latter version. Here’s an example where they differ:

``````julia> big(10)^(1/5)
1.584893192461113525718041298089470305609734784375671350368393872884966550887179

julia> 10^(1/big(5))
1.584893192461113485202101373391507013269442133825039068316296812316656863668456
``````
4 Likes

Thank You for this tip.
Sincerely

Albert Gächter