# Calculating cos(0.9528) in BigFloat

#1

So I (incited by some others) calculated the following

``````setprecision(15*10^5)
x=big(9528)/10000;
y=cos(x);
ys=string(y);
ys[306890:306931]
"459423813195289597370437889596885962619893..."
``````

Now this is somehow wrong…The correct sequence is:
“459423813195289597370437889596885917728725…”

In fact doing one newton-iteration with the first wrong number:

``````yn=y;
yn=yn+(acos(yn)-x)*sqrt(1-yn^2);
``````

gives the desired result above, which I would have assumed however to be correct in the first place…
So what is going wrong here?

#2

is not a good way to build a `BigFloat`.

``````julia> x=big(9528.0)/10000;

julia> y=cos(x);

julia> ys=string(y);

julia> ys[306890:306931]
"459423813195289597370437889596885917728725"

``````

Edit: Ouch, I stand corrected; promotion should work here.

#3

These should be exactly the same. If you’re using 0.6.0 (or earlier) on Windows, you might be hitting:

Try using 0.6.1, as this includes MPFR 3.1.5 which fixes the issue.

#4

Also, an easier way to do this is to use the `big` string macro:

``````x = big"0.9528"
``````

#5

Blockquote is not a good way to build a BigFloat.
I first tried
big(0.9528) but this was completely giving me the wrong number…

Actually: x=big(9528.0)/10000
like Ralph did still gives me the wrong answer…
I’m using v0.5

So I need at least v0.6.1 ? I will try…

#6

On `v0.6.1`,

``````julia> big(9528.0)/10000
9.527999999999999999999999999999999999999999999999999999999999999999999999999998e-01
``````

which is the same as `big"0.9528"`.

#7

You shouldn’t be doing something like `big(9528.0)`, because that first creates a `Float64` `9528.0`, which means it may have already lost information, before converting it to a `BigFloat`.

#8

Integers (up to 2^53) are represented exactly in floating-point arithmetic, so converting an exactly representable `Float64` like 9528.0 to `BigFloat` is perfectly safe.

#9

Why is big(9528)/10000 not a good way then to build a big float?

#10

In that particular case, yes. I was talking about the general case, where one shouldn’t do `big(<some float literal>)` to create a `BigFloat`.
(I was aware that in that particular case, it didn’t lose information, but you shouldn’t be encouraging a poor programming practice, that’s confused a lot of people already)

#11

I was wrong; `big(9528)` makes a `BigInt` and I mistakenly thought that your problem was division not done in full `BigFloat` precision.

#12

#13

Presumably they were aware of that, since they wrote `big(9528.0)/10000` instead of `big(0.9528)`

#14

So now that I installed 0.6.1 I tried again, but I get the same wrong answer?
Wasn’t it fixed with MPFR 3.1.5 which was implemented in 0.6.1?

#15

What does

``````unsafe_string(ccall((:mpfr_get_version,:libmpfr), Ptr{Cchar}, ()))
``````

give?

#16

Hmm, looks like it wasn’t fixed.

#17

Ah, never mind. It was fixed in the 3.1.6 release of MPFR. We need to upgrade…

#18

It gives 3.1.5

#19

Apologies: it wasn’t fixed in 3.1.5, only 3.1.6. Unfortunately, this hasn’t made it’s way into the releases yet.

#20

When will it be out?