Re: [Scilab-users] Problems arising from truncation of %pi

2021-01-08 Thread Federico Miyara
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 100100

Re: [Scilab-users] Problems arising from truncation of %pi

2021-01-08 Thread Federico Miyara
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. Besides,

Re: [Scilab-users] Problems arising from truncation of %pi

2021-01-08 Thread Stéphane Mottelet
Le 08/01/2021 à 13:28, Jean-Yves Baudais a écrit : - Original Message - From: "Stéphane Mottelet" --> bitstring(%pi) ans = "0 100 1001001110110101010001000110110100011000" [...] https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.exploringbinary.com

Re: [Scilab-users] Problems arising from truncation of %pi

2021-01-08 Thread Jean-Yves Baudais
- 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 (

Re: [Scilab-users] Problems arising from truncation of %pi

2021-01-08 Thread Stéphane Mottelet
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

Re: [Scilab-users] Problems arising from truncation of %pi

2021-01-08 Thread Stéphane Mottelet
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 representat

Re: [Scilab-users] Problems arising from truncation of %pi

2021-01-08 Thread Jean-Yves Baudais
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 e