Math::Trig defines many trigonometric functions not defined by the
core Perl which defines only the sin() and cos(). The constantpi is also defined as are a few convenience functions for angle
conversions, and great circle formulas for spherical movement.
acoth
acsc
acsch
asec
asech
atanh
cot
coth
csc
csch
sec
sech
tan
tanh
cannot be computed for all arguments because that would mean dividing
by zero or taking logarithm of zero. These situations cause fatal
runtime errors looking like this
cot(0): Division by zero.
(Because in the definition of cot(0), the divisor sin(0) is 0)
Died at ...
or
atanh(-1): Logarithm of zero.
Died at...
For the csc, cot, asec, acsc, acot, csch, coth,
asech, acsch, the argument cannot be 0 (zero). For the
atanh, acoth, the argument cannot be 1 (one). For the
atanh, acoth, the argument cannot be -1 (minus one). For the
tan, sec, tanh, sech, the argument cannot be pi/2 + k *
pi, where k is any integer. atan2(0, 0) is undefined.
Please note that some of the trigonometric functions can break out
from the real axis into the complex plane. For example
asin(2) has no definition for plain real numbers but it has
definition for complex numbers.
perldoc2tree.cgi: /usr/lib/perl5/5.8.8/Math/Trig.pm: cannot resolve L in paragraph 117.
In Perl terms this means that supplying the usual Perl numbers (also
known as scalars, please see perldata) as input for the
trigonometric functions might produce as output results that no more
are simple real numbers: instead they are complex numbers.
The Math::Trig handles this by using the Math::Complex package
which knows how to handle complex numbers, please see the Math::Complex manpage
for more information. In practice you need not to worry about getting
complex numbers as results because the Math::Complex takes care of
details like for example how to display complex numbers. For example:
print asin(2), "\n";
should produce something like this (take or leave few last decimals):
1.5707963267949-1.31695789692482i
That is, a complex number with the real part of approximately 1.571
and the imaginary part of approximately -1.317.
The full circle is 2 pi radians or 360 degrees or 400 gradians.
The result is by default wrapped to be inside the [0, {2pi,360,400}[ circle.
If you don't want this, supply a true second argument:
Cartesian coordinates are the usual rectangular (x, y, z)-coordinates.
Spherical coordinates, (rho, theta, pi), are three-dimensional
coordinates which define a point in three-dimensional space. They are
based on a sphere surface. The radius of the sphere is rho, also
known as the radial coordinate. The angle in the xy-plane
(around the z-axis) is theta, also known as the azimuthal
coordinate. The angle from the z-axis is phi, also known as the
polar coordinate. The North Pole is therefore 0, 0, rho, and
the Gulf of Guinea (think of the missing big chunk of Africa) 0,
pi/2, rho. In geographical terms phi is latitude (northward
positive, southward negative) and theta is longitude (eastward
positive, westward negative).
BEWARE: some texts define theta and phi the other way round,
some texts define the phi to start from the horizontal plane, some
texts use r in place of rho.
Cylindrical coordinates, (rho, theta, z), are three-dimensional
coordinates which define a point in three-dimensional space. They are
based on a cylinder surface. The radius of the cylinder is rho,
also known as the radial coordinate. The angle in the xy-plane
(around the z-axis) is theta, also known as the azimuthal
coordinate. The third coordinate is the z, pointing up from the
theta-plane.
Conversions to and from spherical and cylindrical coordinates are
available. Please notice that the conversions are not necessarily
reversible because of the equalities like pi angles being equal to
-pi angles.
The great circle distance is the shortest distance between two
points on a sphere. The distance is in $rho units. The $rho is
optional, it defaults to 1 (the unit sphere), therefore the distance
defaults to radians.
If you think geographically the theta are longitudes: zero at the
Greenwhich meridian, eastward positive, westward negative--and the
phi are latitudes: zero at the North Pole, northward positive,
southward negative. NOTE: this formula thinks in mathematics, not
geographically: the phi zero is at the North Pole, not at the
Equator on the west coast of Africa (Bay of Guinea). You need to
subtract your geographical coordinates from pi/2 (also known as 90
degrees).
(Alias 'great_circle_bearing' is also available.)
The result is in radians, zero indicating straight north, pi or -pi
straight south, pi/2 straight west, and -pi/2 straight east.
You can inversely compute the destination if you know the
starting point, direction, and distance:
Where the $way is a value from zero ($theta0, $phi0) to one ($theta1,
$phi1). Note that antipodal points (where their distance is pi
radians) do not have waypoints between them (they would have an an
``equator'' between them), and therefore undef is returned for
antipodal points. If the points are the same and the distance
therefore zero and all waypoints therefore identical, the first point
(either point) is returned.
The thetas, phis, direction, and distance in the above are all in radians.
Notice that the resulting directions might be somewhat surprising if you are looking at a flat worldmap: in such map projections the great
circles quite often do not look like the shortest routes-- but for
example the shortest possible routes from Europe or North America to
Asia do often cross the polar regions.
# Notice the 90 - latitude: phi zero is at the North Pole.
sub NESW { deg2rad($_[0]), deg2rad(90 - $_[1]) }
my @L = NESW( -0.5, 51.3);
my @T = NESW(139.8, 35.7);
my $km = great_circle_distance(@L, @T, 6378); # About 9600 km.
The direction you would have to go from London to Tokyo (in radians,
straight north being zero, straight east being pi/2).
The answers may be off by few percentages because of the irregular
(slightly aspherical) form of the Earth. The errors are at worst
about 0.55%, but generally below 0.3%.
Saying use Math::Trig; exports many mathematical routines in the
caller environment and even overrides some (sin, cos). This is
construed as a feature by the Authors, actually... ;-)
The code is not optimized for speed, especially because we use
Math::Complex and thus go quite near complex numbers while doing
the computations even when the arguments are not. This, however,
cannot be completely avoided if we want things like asin(2) to give
an answer instead of giving a fatal runtime error.
