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

[Federico Miyara]

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() function, which takes advantage of 
foating point capabilitties when the input argument is close to 1.

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)

where pi is the exact value of pi

> It has no sense to use 23 digits with a precision of 2.22E-16, the 7th 
> last digits are noise.

I've just reported the digits provided when using format(25)

Probably it is not proper to refer to it as noise, since the difference 
is deterministic as can be demonstrated by using the function nearfloat()

Regards,

Federico Miyara

>
>
>
>> --> sin(1e10*%pi)
>>   ans  =
>>    -0.0000022393627619559233
>>
>> --> sin(1e15*%pi)
>>   ans  =
>>    -0.2362090532517409080526
>
>
> All is consistent with the definition of the precision. A toy example:
> --> a=2;
> --> b=sqrt(2);
> --> a-b^2
>
> You expect zero because you do symbolic calculus, not Scilab.
>
>
>> The Wolfram Alpha site yields the correct value 0 in all cases (using 
>> their own pi).
>
>
> Because it uses symbolic calculus. So, if you want more precision with 
> Scilab you should change the standard used, but maybe some tricks in 
> your code can solve the problem... Or maybe you need symbolic calculus 
> tool.
>
> --Jean-Yves
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>
>


-- 
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus