Unacceptably low precision in evaluation of sin(floating point #)..

[Gutow, Jonathan H]

I took a quick look at the code and decided I didn't have time to dig and figure out which package is actually being used to evaluate the trig functions like sine. So I would like somebody who knows to tell me where this bug should be reported. Here's the issue in Sage 5.5.

sage: sin(2*pi)
0
so that's OK

sage: sin(2.0*pi).n(digits = 3) #force numerical evaluation
0.0000178
That's way too far off, especially since 2.0 can be represented exactly and pi should be good to 18+ digits. To get an error that size on a calculator, I have to reduce pi to about 6 decimal places of precision or less.

Any idea where the problem lies? I cannot imagine this is too difficult a thing to fix.

Thanks,
Jonathan
Dr. Jonathan H. Gutow
Chemistry Department gu...@uwosh.edu
UW-Oshkosh Office:920-424-1326
800 Algoma Boulevard FAX:920-424-2042
Oshkosh, WI 54901
http://www.uwosh.edu/facstaff/gutow/

[Volker Braun]

The first three digits ("0.00") of your result are correct, this is the expected output.

On Tuesday, January 29, 2013 6:35:02 PM UTC, Jonathan wrote:

sage: sin(2.0*pi).n(digits = 3) #force numerical evaluation
0.0000178

Note that you can't magically compute the result digits, the computer needs to first compute (2.0*pi).n(digits=3) with guard digits and then plug it into sin() 

[Nils Bruin]

On Jan 29, 10:44 am, Volker Braun <vbraun.n...@gmail.com> wrote:
> The first three digits ("0.00") of your result are correct, this is the
> expected output.

Well ... I'm not so sure about THAT expectation, but the gist of it:

sage: (2*pi).n()
6.28318530717959
sage: sin(6.283)
-0.000185307178525578
sage: sin(6.284)
0.000814692730291418

illustrates that the answer is certainly within bounds of what you get
if you do your computations with 3 digits throughout, and that's what
I expect .n(digits=3) to mean. If you want GUARANTEED 3 digits
correct, you should probably use interval arithmetic and increase
number of working digits until your interval is small enough.

[Jonathan]

Thanks for the clarification.

Clearly, as a scientist I misunderstood what is meant by the n(digits = x) expression.  I assumed it actually meant the number of significant digits in the calculation.  I especially thought this because sin(2.0*pi).n(digits=3) = 0.0000178 is read in the scientific and engineering literature as meaning three significant digits and the significant digits are 1.78 x 10^-5.  But what Sage is doing is only doing the calculation to two decimal places, if I understand the arguments above correctly.  Sage certainly leaves the impression of actually doing the calculations to the precision implied by the significant digits shown as it always presents the number of significant figures that digits is set equal to.  Clearly this is the wrong interpretation.

I need to think about how this needs to be clarified.  I really do not think it can stay this way if Sage hopes to get used in more applied applications.

Jonathan

[Jonathan]

For the record as I think about this.  The way most scientists do this with a mixed number of significant digits (significant figures, SF) in the inputs is the following.  Please note that for functions like sine, cosine, log and so on this is a little bit sloppy and proper interval arithmetic will sometimes give a different answer.  In cases where we need to know the precision accurately, we will usually use statistical uncertainties in each parameter and propagate that through the calculation using the proper statistics (in most cases symmetric gaussian distributions are used).

sin(2.0*pi) to full precision then round to 2 SF to agree with the 2 SF on the 2.0.  Best equivalent I can come up with in Sage is:

sin(2.0*pi).n().n(digits = 2)

Note this example only worries about SF for multiplication and does not properly account for how SF propagate through the sine function.

Thinking out loud:  

Maybe a .n(SF=X) = .n().n(d=X) would be a good start on clarifying things.  It still requires the user to decide on the significant figures.

Better yet would be .n(SF), gives the proper number of significant figures using interval arithmetic.  Manual version of example above as I am not clear yet on how this is implemented in Sage...need to learn:

sin(2.1*pi).n().n(digits=3) =0.309
sin(1.9*pi).n().n(digits=3) =-0.309

So uncertain in the first decimal place.  Thus sin(2.0*pi).n(SF) = 0.0 ± 0.3 (although we would not usually provide the ±0.3).

Jonathan

[Robert Bradshaw]

On Tue, Jan 29, 2013 at 8:01 PM, Jonathan <gu...@uwosh.edu> wrote:
> For the record as I think about this. The way most scientists do this with
> a mixed number of significant digits (significant figures, SF) in the inputs
> is the following. Please note that for functions like sine, cosine, log and
> so on this is a little bit sloppy and proper interval arithmetic will
> sometimes give a different answer. In cases where we need to know the
> precision accurately, we will usually use statistical uncertainties in each
> parameter and propagate that through the calculation using the proper
> statistics (in most cases symmetric gaussian distributions are used).

Intervals work well, but it would be nice to propagate gaussians as
well. Also, when you write 2.0, I assume you mean 2.0000000, not 2.0
+/- 0.1, so the input is already ambiguous. Also, it's a bit ill-posed
because what is sin(2.0 * pi) to 3 digits of *relative* precision? How
much intermediate precision is needed to give the result?

sage: sin(2.0*pi).n(digits=300)
-2.50308811950890920759380853694117296639136107833060156907412891654218194458725365083409825978182567551756080480156467091775509964013759873633379261609983567926786122363484618232829973119909155267641397848002179036023558452211812394315755777568498955720109032866136031960197436308067649928573726528606e-301

which is correct to 300 absolute digits, but not 300 relative digits
of precision.

> sin(2.0*pi) to full precision then round to 2 SF to agree with the 2 SF on
> the 2.0. Best equivalent I can come up with in Sage is:
>
> sin(2.0*pi).n().n(digits = 2)
>
> Note this example only worries about SF for multiplication and does not
> properly account for how SF propagate through the sine function.
>
> Thinking out loud:
>
> Maybe a .n(SF=X) = .n().n(d=X) would be a good start on clarifying things.
> It still requires the user to decide on the significant figures.

Note that this still uses 53 bits to do the intermediate computation,
then at the end truncates to X digits. Of course if X > 15, this will
be wrong, and there's no tracking of the actual precision needed to
get the result to X digits of precision.

> Better yet would be .n(SF), gives the proper number of significant figures
> using interval arithmetic. Manual version of example above as I am not
> clear yet on how this is implemented in Sage...need to learn:
>
> sin(2.1*pi).n().n(digits=3) =0.309
> sin(1.9*pi).n().n(digits=3) =-0.309
>
> So uncertain in the first decimal place. Thus sin(2.0*pi).n(SF) = 0.0 ± 0.3
> (although we would not usually provide the ±0.3).

sage: a = RIF(2*pi); a
6.283185307179587?
sage: sin(RIF(2*pi))
0.?e-15
sage: sin(RIF(2*pi)) < 1e-100
False
sage: sin(RIF(2*pi)).endpoints()
(-2.44929359829471e-16, 6.43249059870655e-16)
sage: sin(RealIntervalField(10)(2*pi)) # 10 bits of prec
0.00?
sage: sin(RealIntervalField(10)(2*pi)).endpoints()
(-0.0020, 0.0059)

Note that intervals are provably correct at each step, but do not
represent a gaussian (there is zero chance that the value lies outside
the interval boundaries) and are thus often too inclusive (in an
iterative process, often you'll get that the result lies in
[-infinity, infinity], not so helpful).

- Robert