Problems to calculate sin

[Tom McGlynn]

Perhaps Andreas may be thinking of the StrictMath class rather than
strictfp? This class duplicates the functionality of Math but
requires that the results be identical to the fdlibm results. [I
think somewhere else in this thread I also confused this with
strictfp].

It's a bit counterintuitive, but I believe the general effect of
either a strictfp block or use of the StrictMath class is a less
accurate calculation. They are all about consistency, not accuracy.

I think StrictMath can go either way. There are generally two
representable numbers that could be a valid Math.sin result for a given
angle, because each is within one ULP of the infinite precision answer.
Math.sin can return either. StrictMath.sin must return the one fdlibm
would pick, which may or may not be the closer of the two.

Patricia

You're certainly correct that it's possible in principle to build a
variant Math library which is legal but less accurate that
StrictMath. My sense, though is that it's not actually that easy
(e.g., see below). So in practice where Math and StrictMath differ
(I'm not aware of anyplace this has actually been done) my suspicion
would be that the Math library is likely to be the more accurate
overall.

Two items of interest that I came up in looking up some of the
background...

First, the problem with using sine hardware is that while it generally
provides accuracy to better than 10^-16, one needs to compute sines to
an absolute accuracy of 10^-32 when one considers the regions where
the sine crosses 0. That's not a problem at x=0, but it is at other
integral multiples of pi. E.g., Math.sin(Math.PI) is of order 10^-16,
but the Java requirement states that it needs to be within one ULP of
the correct answer, so it needs an absolute accuracy of 10^-32.

Second, the discussion of how to make trigonometric calculations
efficient in Java (e.g., to use FPU hardware), notes that an optimizer
is free to substitute an FPU sine call when it knows it will be within
the required accuracy. This suggested to me that it might be possible
for the value of the sine function to change during the execution of a
program that uses runtime optimization, like HotSpot, giving one
answer before the function was optimized and a different answer
(presumably 1 ULP away) afterwards. That sounds a bit weird, and
perhaps its forbidden somewhere... The explicit wiggle room given in
the definition of the Math libraries though makes them a bit different
from most functions though.

Regards,
Tom McGlynn

 

[Mark Thornton]

Second, the discussion of how to make trigonometric calculations
efficient in Java (e.g., to use FPU hardware), notes that an optimizer
is free to substitute an FPU sine call when it knows it will be within
the required accuracy. This suggested to me that it might be possible
for the value of the sine function to change during the execution of a
program that uses runtime optimization, like HotSpot, giving one
answer before the function was optimized and a different answer
(presumably 1 ULP away) afterwards. That sounds a bit weird, and

This sort of behaviour is readily observable on older JVM that do not
correctly reduce the arguments when using the x86 hardware FSIN
instruction. Much harder to notice now.

Mark Thornton

 

[Tom McGlynn]

This sort of behaviour is readily observable on older JVM that do not
correctly reduce the arguments when using the x86 hardware FSIN
instruction. Much harder to notice now.

Mark Thornton

Fascinating... I gather though that the older JVM's were incorrect
though in that they were giving FPU results that were far more than
one ULP off? Even so it's strange to think that the program:

public class Test {
public static void main(String[] args) throws Exception {
double x = ...;
double y = Math.sin(x);
Thread.sleep(100);
double z = Math.sin(x);
System.out.println("x=y:"+(x==y));
}
}

might legally print false if the sine function got optimized between
the two calls!

Tom

 

[Patricia Shanahan]

Andreas Leitgeb wrote:
...
My guess was, that if one needed math more exact than native
processor's arithmetics, he would use "strictfp", so while I
don't know for sure, I wouldn't bet on abovementioned information.
The minimum precision requirements in the Math.sin API documentation are
not dependent on strictfp.
Perhaps Andreas may be thinking of the StrictMath class rather than
strictfp? This class duplicates the functionality of Math but
requires that the results be identical to the fdlibm results. [I
think somewhere else in this thread I also confused this with
strictfp].
It's a bit counterintuitive, but I believe the general effect of
either a strictfp block or use of the StrictMath class is a less
accurate calculation. They are all about consistency, not accuracy.

I think StrictMath can go either way. There are generally two
representable numbers that could be a valid Math.sin result for a given
angle, because each is within one ULP of the infinite precision answer.
Math.sin can return either. StrictMath.sin must return the one fdlibm
would pick, which may or may not be the closer of the two.

Patricia

You're certainly correct that it's possible in principle to build a
variant Math library which is legal but less accurate that
StrictMath. My sense, though is that it's not actually that easy
(e.g., see below). So in practice where Math and StrictMath differ
(I'm not aware of anyplace this has actually been done) my suspicion
would be that the Math library is likely to be the more accurate
overall.

I agree with you about "overall".

First, the problem with using sine hardware is that while it generally
provides accuracy to better than 10^-16, one needs to compute sines to
an absolute accuracy of 10^-32 when one considers the regions where
the sine crosses 0. That's not a problem at x=0, but it is at other
integral multiples of pi. E.g., Math.sin(Math.PI) is of order 10^-16,
but the Java requirement states that it needs to be within one ULP of
the correct answer, so it needs an absolute accuracy of 10^-32.

The sine implementations I've seen all begin by normalizing the angle.
The problem you point out puts demands on the accuracy of the normalization.

Second, the discussion of how to make trigonometric calculations
efficient in Java (e.g., to use FPU hardware), notes that an optimizer
is free to substitute an FPU sine call when it knows it will be within
the required accuracy. This suggested to me that it might be possible
for the value of the sine function to change during the execution of a
program that uses runtime optimization, like HotSpot, giving one
answer before the function was optimized and a different answer
(presumably 1 ULP away) afterwards. That sounds a bit weird, and
perhaps its forbidden somewhere... The explicit wiggle room given in
the definition of the Math libraries though makes them a bit different
from most functions though.

Would changing the Math.sin, for a given input, during a run break the
semi-monotonicity requirement?

"Therefore, most methods with more than 0.5 ulp errors are required to
be semi-monotonic: whenever the mathematical function is non-decreasing,
so is the floating-point approximation, likewise, whenever the
mathematical function is non-increasing, so is the floating-point
approximation."

The mathematical sine of a given angle neither increases nor decreases
from call to call.

Patricia

 

[Tom McGlynn]

....

Would changing the Math.sin, for a given input, during a run break the
semi-monotonicity requirement?

"Therefore, most methods with more than 0.5 ulp errors are required to
be semi-monotonic: whenever the mathematical function is non-decreasing,
so is the floating-point approximation, likewise, whenever the
mathematical function is non-increasing, so is the floating-point
approximation."

The mathematical sine of a given angle neither increases nor decreases
from call to call.

Patricia

That's sounds good to me (coupled with the language that sine is one
of the functions to which this applies). It seems like there's still a
tiny bit of ambiguity at the minima and maxima. E.g., if we look at
the arguments with values just below and above 2 pi, between those two
values the sine both rises and declines, so I might be able to make an
argument that the exact function is neither non-increasing nor non-
decreasing at those two points and so I'm still allowed to select
either of my two possible values there, i.e., -1 and -1+ULP. In
practice I can't imagine any algorithm that's otherwise valid that
won't give -1 here.

It sounds like the implementations that Mark talked about are clearly
illegal though even had they met the standard of accuracy.

Regards,
Tom

 

[John W. Kennedy]

Oo-kaay.

Binariness is not relevant in the abstract, but since this community
uses Java on binary devices it is relevant in practice.

At present, the devices don't actually matter; Java uses binary by
definition. If (per impossibile) Java were to be implemented on an old
IBM 7080, it would still be required to /seem/ binary.

On the other hand, IEEE-754r is on the way. It's already available in
the latest versions of z/Architecture and POWER, and Java 6 already has
some slight support of it in BigDecimal.

 

[Roedy Green]

There are generally two
representable numbers that could be a valid Math.sin result for a given
angle, because each is within one ULP of the infinite precision answe

I think of the work I did early in my career designing high voltage
transmission lines. I would have happily given up a little accuracy
in computing sine for extra speed. I was computing positions of
swinging insulators to check for sufficient clearance. 3 digits of
precision would have been ample.

You might be tempted in such a situation to use a table lookup for
fast sine, but you probably would not buy you much since the overhead
for a JNI call is so high.

 

[Roedy Green]

Digital representation of numbers. Please
research IEEE 754.

see http://mindprod.com/jgloss/ieee754.html