Le 09/01/2021 à 13:04, Samuel Gougeon a écrit :
Hello Federico,
Le 09/01/2021 à 01:32, Federico Miyara a écrit :
Jean-Yves,
sin(x - n*pi)
So now the problem can be how these large numbers are obtained
--> a=1e16+1
--> a-1e16
of course equals zero.
Yes, I've thought about it and you are
Hello Federico,
Le 09/01/2021 à 01:32, Federico Miyara a écrit :
Jean-Yves,
sin(x - n*pi)
So now the problem can be how these large numbers are obtained
--> a=1e16+1
--> a-1e16
of course equals zero.
Yes, I've thought about it and you are right, above 1e16 x is so
sparse, cycle-wise
Stéphane,
Thanks for your comments, I didn't know bitstring().
Regards,
Federico Miyara
On 08/01/2021 10:48, Stéphane Mottelet wrote:
Le 08/01/2021 à 13:28, Jean-Yves Baudais a écrit :
- Original Message -
From: "Stéphane Mottelet"
--> bitstring(%pi)
ans =
"0 100
Jean-Yves,
sin(x - n*pi)
So now the problem can be how these large numbers are obtained
--> a=1e16+1
--> a-1e16
of course equals zero.
Yes, I've thought about it and you are right, above 1e16 x is so sparse,
cycle-wise speaking, that my original intention doesn't make much sense.
Le 08/01/2021 à 13:28, Jean-Yves Baudais a écrit :
- Original Message -
From: "Stéphane Mottelet"
--> bitstring(%pi)
ans =
"0 100 1001001110110101010001000110110100011000"
[...]
- Original Message -
> From: "Stéphane Mottelet"
> --> bitstring(%pi)
> ans =
>
> "0 100 1001001110110101010001000110110100011000"
> [...]
> https://www.exploringbinary.com/binary-converter/
Thank you for the recall on floating point representation and for the link
But, of course, we have
--> bitstring(3.141592653589793) == bitstring(%pi)
ans =
T
which means that 3.141592653589793 and
3.141592653589793115997963468544185161590576171875 have the same
internal IEEE754 representation.
S.
Le 08/01/2021 à 12:20, Stéphane Mottelet a écrit :
The nearest
The nearest double-precision IEEE-754 binary floating-point number for
the decimal number PI
3.141592653589793 23846264338327950288419716939937510582097494459230
78164 06286
is
3.141592653589793 115997963468544185161590576171875
It can be shown this way: its internal base 2
Hello,
- Original Message -
> The function could be sinpi() or similar, with two arguments: the main
> argument x and an integer argument n, being its result equivalent to
>
> sin(x - n*pi)
So now the problem can be how these large numbers are obtained
--> a=1e16+1
--> a-1e16
of course
Stéphane,
This would be great if it worked for any x. When x is close to 1e16
there are few valid numbers per cycle. For instance
x(1) = 1e16
for k=1:5
x(k+1) = nearfloat("succ",x(k));
end
x
yields (with format(25))
1.
10002.
10004.
Antoine,
Thanks for the link, very interesting.
Regards,
Federico Miyara
On 06/01/2021 05:22, Antoine Monmayrant wrote:
Hello Frederico,
Like Christophe, I am not sure this has anything to do with the
implementation of sin().
It seems to be a known limitation of numerical calculations
Jean-Yves,
Thanks for your answer.
You face the limited precision of all numerical calculus. See --> help
%eps
Yes, I'm aware of this limitation, but I think an improved version of
the sine function could be provided for its use in certain cases, in a
similar fashion as the log1p()
Of course, this does only work for integer multiples of %pi. This plot
illustrates well Antoine's remark:
x=(10^15*%pi)+(0:0.001:2*%pi);
plot(sin(x));
error
I like new year's jokes !
S.
Le 06/01/2021 à 09:49, Stéphane Mottelet a écrit :
I do not agree with your answer. Doing *by hand* the
Hello Frederico,
Like Christophe, I am not sure this has anything to do with the
implementation of sin().
It seems to be a known limitation of numerical calculations using
floating numbers.
In particular, even with en hypothetical ideal value of %pi, because of
the conversion to a double,
Hello,
Le 05/01/2021 à 09:19, Federico Miyara a écrit :
--> sin(%pi)
ans =
0.0001224647
You face the limited precision of all numerical calculus. See
--> help %eps
It has no sense to use 23 digits with a precision of 2.22E-16, the 7th
last digits are noise.
-->
15 matches
Mail list logo
