silly Math question from Fortran programmer

G

Guest

I am a scientist with a background in Fortran programming which
occasionally works in Java. I recently had the need to make some
trigonometric computations like :

x=(pxy[0]-crpix1)*cdelt1 ;
y=(pxy[1]-crpix2)*cdelt2 ;
phi =Math.PI-Math.atan2(y,x) ;
theta=Math.atan(1./(Math.sqrt(x*x+y*y)*Math.PI/180.)) ;
cv1=Math.toRadians(crval1) ;
cv2=Math.toRadians(crval2) ;
radec[1]=Math.asin(Math.sin(theta)*Math.sin(cv2)-Math.cos(theta)*Math.cos(phi)*Math.cos(cv2)) ;
radec[0]=cv1+Math.asin(Math.cos(theta)*Math.sin(phi)/Math.cos(radec[1])) ;
radec[0]=Math.toDegrees(radec[0]);
radec[1]=Math.toDegrees(radec[1]);

I have import java.lang.Math ; at the beginning of my program.

Is it really necessary that I prefix all invocation of trigonometric
functions with "Math." ? It there any way to do that implicitly like in
the following (not working) example ?

I won't care about specifying numeric constants as Math.PI, but the
notation above seems rather heavy to me.

x=(pxy[0]-crpix1)*cdelt1 ;
y=(pxy[1]-crpix2)*cdelt2 ;
phi =Math.PI-atan2(y,x) ;
theta=atan(1./(sqrt(x*x+y*y)*Math.PI/180.)) ;
cv1=toRadians(crval1) ;
cv2=toRadians(crval2) ;
radec[1]=asin(sin(theta)*sin(cv2)-cos(theta)*cos(phi)*cos(cv2)) ;
radec[0]=cv1+asin(cos(theta)*sin(phi)/cos(radec[1])) ;
radec[0]=toDegrees(radec[0]);
radec[1]=toDegrees(radec[1]);
 
D

Daniel Dyer

I have import java.lang.Math ; at the beginning of my program.

This is not necessary, since the classes of the java.lang package are
imported implicitly.
Is it really necessary that I prefix all invocation of trigonometric
functions with "Math." ? It there any way to do that implicitly like in
the following (not working) example ?

Assuming that you are using Java 5 or later, then you can use a static
import:

import static java.lang.Math.*;

Dan.
 
S

Stefan Ram

LC's No-Spam Newsreading account said:
I am a scientist with a background in Fortran programming which
occasionally works in Java. I recently had the need to make
some trigonometric computations

That is a good choice, because Java takes special care
to give correct results.

»x87 fsin/fcos use a particular approximation to pi, which
effectively means the period of the function is changed,
which can lead to large errors outside [-pi/4, pi/4]. [...]

instead of getting the full 15-17 digit accuracy of
double, the returned result is only correct to about 5
decimal digits. In terms of ulps, the error is about
1.64e11 ulps, over *ten billion* ulps. [...]

What we do in the JVM on x86 is moderately obvious: we
range check the argument, and if it's outside the range
[-pi/4, pi/4] we do the precise range reduction by hand,
and then call fsin. So Java is accurate, but slower.«

http://blogs.sun.com/jag/entry/transcendental_meditation
 
S

Stefan Ram

Daniel Dyer said:
This is not necessary, since the classes of the java.lang package are
imported implicitly.

If there is a class »Math« (a file »Math.class«) in the class
path (in an unnamed package), an import declaration »import
java.lang.Math;« at the start of another compilation unit will
make »Math« refer to »java.lang.Math« in that compilation unit.

Also, the compilation of the compilation unit
»import java.lang.Math; class Math {}« will report an error.
But it will compile without the import declaration.
 
L

Lew

Stefan said:
If there is a class »Math« (a file »Math.class«) in the class
path (in an unnamed package), an import declaration »import
java.lang.Math;« at the start of another compilation unit will
make »Math« refer to »java.lang.Math« in that compilation unit.

Also, the compilation of the compilation unit
»import java.lang.Math; class Math {}« will report an error.
But it will compile without the import declaration.

While this is true, these pathological situations are avoided by *not using
the unnamed package*.

A conflict between (unnamed-package) Math and java.lang.Math is a deployment
problem, not a programming problem. There had better not be *any* classes in
the unnamed package in the classpath, much less ones with the same names as
standard API classes.

Go ahead and omit "java.lang." from your programs, kiddies.

Spank whoever turns that into a problem for you.
 
R

Roedy Green

Is it really necessary that I prefix all invocation of trigonometric
functions with "Math." ?

see the new import static feature

import static java.lang.Math.*;

and you can leave off the Math.
 
D

Dr J R Stockton

In comp.lang.java.programmer message <trigonometric-Java-
(e-mail address removed)-berlin.de>, Thu, 3 Jan 2008 15:03:25,
Stefan Ram said:
›x87 fsin/fcos use a particular approximation to pi, which
effectively means the period of the function is changed,
which can lead to large errors outside [-pi/4, pi/4]. [...]
What we do in the JVM on x86 is moderately obvious: we
range check the argument, and if it's outside the range
[-pi/4, pi/4] we do the precise range reduction by hand,
and then call fsin. So Java is accurate, but slower.‹


Where does the argument commonly come from?

The only case I know of in which arguments of many times pi appear is in
calculating the phase of a waveform using something like
2 pi J / N

In that case one should, ISTM, first subtract from J whichever multiple
of N gives a result in [0, 1) or (-0,5, +0.5] or similar.

Of course, that needs an intelligent application programmer, rather than
an intelligent system programmer.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top