2011-10-31 12:26:05 -06:00
|
|
|
// Copyright 2011 The Go Authors. All rights reserved.
|
2008-03-28 14:56:47 -06:00
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
2008-06-27 18:06:23 -06:00
|
|
|
package math
|
2008-03-28 14:56:47 -06:00
|
|
|
|
2010-01-11 13:38:31 -07:00
|
|
|
/*
|
|
|
|
Floating-point sine and cosine.
|
|
|
|
*/
|
|
|
|
|
2011-10-31 12:26:05 -06:00
|
|
|
// The original C code, the long comment, and the constants
|
|
|
|
// below were from http://netlib.sandia.gov/cephes/cmath/sin.c,
|
|
|
|
// available from http://www.netlib.org/cephes/cmath.tgz.
|
|
|
|
// The go code is a simplified version of the original C.
|
|
|
|
//
|
|
|
|
// sin.c
|
|
|
|
//
|
|
|
|
// Circular sine
|
|
|
|
//
|
|
|
|
// SYNOPSIS:
|
|
|
|
//
|
|
|
|
// double x, y, sin();
|
|
|
|
// y = sin( x );
|
|
|
|
//
|
|
|
|
// DESCRIPTION:
|
|
|
|
//
|
|
|
|
// Range reduction is into intervals of pi/4. The reduction error is nearly
|
|
|
|
// eliminated by contriving an extended precision modular arithmetic.
|
|
|
|
//
|
|
|
|
// Two polynomial approximating functions are employed.
|
|
|
|
// Between 0 and pi/4 the sine is approximated by
|
|
|
|
// x + x**3 P(x**2).
|
|
|
|
// Between pi/4 and pi/2 the cosine is represented as
|
|
|
|
// 1 - x**2 Q(x**2).
|
|
|
|
//
|
|
|
|
// ACCURACY:
|
|
|
|
//
|
|
|
|
// Relative error:
|
|
|
|
// arithmetic domain # trials peak rms
|
|
|
|
// DEC 0, 10 150000 3.0e-17 7.8e-18
|
|
|
|
// IEEE -1.07e9,+1.07e9 130000 2.1e-16 5.4e-17
|
|
|
|
//
|
|
|
|
// Partial loss of accuracy begins to occur at x = 2**30 = 1.074e9. The loss
|
|
|
|
// is not gradual, but jumps suddenly to about 1 part in 10e7. Results may
|
|
|
|
// be meaningless for x > 2**49 = 5.6e14.
|
|
|
|
//
|
|
|
|
// cos.c
|
|
|
|
//
|
|
|
|
// Circular cosine
|
|
|
|
//
|
|
|
|
// SYNOPSIS:
|
|
|
|
//
|
|
|
|
// double x, y, cos();
|
|
|
|
// y = cos( x );
|
|
|
|
//
|
|
|
|
// DESCRIPTION:
|
|
|
|
//
|
|
|
|
// Range reduction is into intervals of pi/4. The reduction error is nearly
|
|
|
|
// eliminated by contriving an extended precision modular arithmetic.
|
|
|
|
//
|
|
|
|
// Two polynomial approximating functions are employed.
|
|
|
|
// Between 0 and pi/4 the cosine is approximated by
|
|
|
|
// 1 - x**2 Q(x**2).
|
|
|
|
// Between pi/4 and pi/2 the sine is represented as
|
|
|
|
// x + x**3 P(x**2).
|
|
|
|
//
|
|
|
|
// ACCURACY:
|
|
|
|
//
|
|
|
|
// Relative error:
|
|
|
|
// arithmetic domain # trials peak rms
|
|
|
|
// IEEE -1.07e9,+1.07e9 130000 2.1e-16 5.4e-17
|
|
|
|
// DEC 0,+1.07e9 17000 3.0e-17 7.2e-18
|
|
|
|
//
|
|
|
|
// Cephes Math Library Release 2.8: June, 2000
|
|
|
|
// Copyright 1984, 1987, 1989, 1992, 2000 by Stephen L. Moshier
|
|
|
|
//
|
|
|
|
// The readme file at http://netlib.sandia.gov/cephes/ says:
|
|
|
|
// Some software in this archive may be from the book _Methods and
|
|
|
|
// Programs for Mathematical Functions_ (Prentice-Hall or Simon & Schuster
|
|
|
|
// International, 1989) or from the Cephes Mathematical Library, a
|
|
|
|
// commercial product. In either event, it is copyrighted by the author.
|
|
|
|
// What you see here may be used freely but it comes with no support or
|
|
|
|
// guarantee.
|
|
|
|
//
|
|
|
|
// The two known misprints in the book are repaired here in the
|
|
|
|
// source listings for the gamma function and the incomplete beta
|
|
|
|
// integral.
|
|
|
|
//
|
|
|
|
// Stephen L. Moshier
|
|
|
|
// moshier@na-net.ornl.gov
|
|
|
|
|
|
|
|
// sin coefficients
|
|
|
|
var _sin = [...]float64{
|
|
|
|
1.58962301576546568060E-10, // 0x3de5d8fd1fd19ccd
|
|
|
|
-2.50507477628578072866E-8, // 0xbe5ae5e5a9291f5d
|
|
|
|
2.75573136213857245213E-6, // 0x3ec71de3567d48a1
|
|
|
|
-1.98412698295895385996E-4, // 0xbf2a01a019bfdf03
|
|
|
|
8.33333333332211858878E-3, // 0x3f8111111110f7d0
|
|
|
|
-1.66666666666666307295E-1, // 0xbfc5555555555548
|
|
|
|
}
|
2011-12-16 16:43:06 -07:00
|
|
|
|
2011-10-31 12:26:05 -06:00
|
|
|
// cos coefficients
|
|
|
|
var _cos = [...]float64{
|
|
|
|
-1.13585365213876817300E-11, // 0xbda8fa49a0861a9b
|
|
|
|
2.08757008419747316778E-9, // 0x3e21ee9d7b4e3f05
|
|
|
|
-2.75573141792967388112E-7, // 0xbe927e4f7eac4bc6
|
|
|
|
2.48015872888517045348E-5, // 0x3efa01a019c844f5
|
|
|
|
-1.38888888888730564116E-3, // 0xbf56c16c16c14f91
|
|
|
|
4.16666666666665929218E-2, // 0x3fa555555555554b
|
|
|
|
}
|
|
|
|
|
2013-10-07 17:32:47 -06:00
|
|
|
// Cos returns the cosine of the radian argument x.
|
2011-10-31 12:26:05 -06:00
|
|
|
//
|
2011-12-05 12:01:24 -07:00
|
|
|
// Special cases are:
|
2011-10-31 12:26:05 -06:00
|
|
|
// Cos(±Inf) = NaN
|
|
|
|
// Cos(NaN) = NaN
|
math: regularize build
This will be nicer to the automatic tools.
It requires a few more assembly stubs
but fewer Go files.
There are a few instances where it looks like
there are new blobs of code, but they are just
being copied out of deleted files.
There is no new code here.
Suppose you have a portable implementation for Sin
and a 386-specific assembly one. The old way to
do this was to write three files
sin_decl.go
func Sin(x float64) float64 // declaration only
sin_386.s
assembly implementation
sin_port.go
func Sin(x float64) float64 { ... } // pure-Go impl
and then link in either sin_decl.go+sin_386.s or
just sin_port.go. The Makefile actually did the magic
of linking in only the _port.go files for those without
assembly and only the _decl.go files for those with
assembly, or at least some of that magic.
The biggest problem with this, beyond being hard
to explain to the build system, is that once you do
explain it to the build system, godoc knows which
of sin_port.go or sin_decl.go are involved on a given
architecture, and it (correctly) ignores the other.
That means you have to put identical doc comments
in both files.
The new approach, which is more like what we did
in the later packages math/big and sync/atomic,
is to have
sin.go
func Sin(x float64) float64 // decl only
func sin(x float64) float64 {...} // pure-Go impl
sin_386.s
// assembly for Sin (ignores sin)
sin_amd64.s
// assembly for Sin: jmp sin
sin_arm.s
// assembly for Sin: jmp sin
Once we abandon Makefiles we can put all the assembly
stubs in one source file, so the number of files will
actually go down.
Chris asked whether the branches cost anything.
Given that they are branching to pure-Go implementations
that are not typically known for their speed, the single
direct branch is not going to be noticeable. That is,
it's on the slow path.
An alternative would have been to preserve the old
"only write assembly files when there's an implementation"
and still have just one copy of the declaration of Sin
(and thus one doc comment) by doing:
sin.go
func Sin(x float64) float64 { return sin(x) }
sin_decl.go
func sin(x float64) float64 // declaration only
sin_386.s
// assembly for sin
sin_port.go
func sin(x float64) float64 { portable code }
In this version everyone would link in sin.go and
then either sin_decl.go+sin_386.s or sin_port.go.
This has an extra function call on all paths, including
the "fast path" to get to assembly, and it triples the
number of Go files involved compared to what I did
in this CL. On the other hand you don't have to
write assembly stubs. After starting down this path
I decided that the assembly stubs were the easier
approach.
As for generating the assembly stubs on the fly, much
of the goal here is to eliminate magic from the build
process, so that zero-configuration tools like goinstall
or the new go tool can handle this package.
R=golang-dev, r, cw, iant, r
CC=golang-dev
https://golang.org/cl/5488057
2011-12-13 13:20:12 -07:00
|
|
|
func Cos(x float64) float64
|
|
|
|
|
|
|
|
func cos(x float64) float64 {
|
2009-10-06 20:40:35 -06:00
|
|
|
const (
|
2011-10-31 12:26:05 -06:00
|
|
|
PI4A = 7.85398125648498535156E-1 // 0x3fe921fb40000000, Pi/4 split into three parts
|
|
|
|
PI4B = 3.77489470793079817668E-8 // 0x3e64442d00000000,
|
|
|
|
PI4C = 2.69515142907905952645E-15 // 0x3ce8469898cc5170,
|
|
|
|
M4PI = 1.273239544735162542821171882678754627704620361328125 // 4/pi
|
2009-01-15 20:11:32 -07:00
|
|
|
)
|
2011-10-31 12:26:05 -06:00
|
|
|
// special cases
|
|
|
|
switch {
|
2012-02-01 08:08:31 -07:00
|
|
|
case IsNaN(x) || IsInf(x, 0):
|
2011-10-31 12:26:05 -06:00
|
|
|
return NaN()
|
|
|
|
}
|
|
|
|
|
|
|
|
// make argument positive
|
|
|
|
sign := false
|
2009-06-24 21:12:50 -06:00
|
|
|
if x < 0 {
|
2009-12-15 16:35:38 -07:00
|
|
|
x = -x
|
2008-03-28 14:56:47 -06:00
|
|
|
}
|
2011-10-31 12:26:05 -06:00
|
|
|
|
|
|
|
j := int64(x * M4PI) // integer part of x/(Pi/4), as integer for tests on the phase angle
|
|
|
|
y := float64(j) // integer part of x/(Pi/4), as float
|
|
|
|
|
|
|
|
// map zeros to origin
|
|
|
|
if j&1 == 1 {
|
2016-10-24 14:40:31 -06:00
|
|
|
j++
|
|
|
|
y++
|
2011-10-31 12:26:05 -06:00
|
|
|
}
|
|
|
|
j &= 7 // octant modulo 2Pi radians (360 degrees)
|
|
|
|
if j > 3 {
|
|
|
|
j -= 4
|
|
|
|
sign = !sign
|
|
|
|
}
|
|
|
|
if j > 1 {
|
|
|
|
sign = !sign
|
2008-03-28 14:56:47 -06:00
|
|
|
}
|
|
|
|
|
2011-10-31 12:26:05 -06:00
|
|
|
z := ((x - y*PI4A) - y*PI4B) - y*PI4C // Extended precision modular arithmetic
|
|
|
|
zz := z * z
|
|
|
|
if j == 1 || j == 2 {
|
|
|
|
y = z + z*zz*((((((_sin[0]*zz)+_sin[1])*zz+_sin[2])*zz+_sin[3])*zz+_sin[4])*zz+_sin[5])
|
|
|
|
} else {
|
|
|
|
y = 1.0 - 0.5*zz + zz*zz*((((((_cos[0]*zz)+_cos[1])*zz+_cos[2])*zz+_cos[3])*zz+_cos[4])*zz+_cos[5])
|
2008-03-28 14:56:47 -06:00
|
|
|
}
|
2011-10-31 12:26:05 -06:00
|
|
|
if sign {
|
2009-11-09 13:07:39 -07:00
|
|
|
y = -y
|
2008-03-28 14:56:47 -06:00
|
|
|
}
|
2011-10-31 12:26:05 -06:00
|
|
|
return y
|
2008-03-28 14:56:47 -06:00
|
|
|
}
|
|
|
|
|
2013-10-07 17:32:47 -06:00
|
|
|
// Sin returns the sine of the radian argument x.
|
2011-10-31 12:26:05 -06:00
|
|
|
//
|
2011-12-07 12:52:17 -07:00
|
|
|
// Special cases are:
|
2011-10-31 12:26:05 -06:00
|
|
|
// Sin(±0) = ±0
|
|
|
|
// Sin(±Inf) = NaN
|
|
|
|
// Sin(NaN) = NaN
|
math: regularize build
This will be nicer to the automatic tools.
It requires a few more assembly stubs
but fewer Go files.
There are a few instances where it looks like
there are new blobs of code, but they are just
being copied out of deleted files.
There is no new code here.
Suppose you have a portable implementation for Sin
and a 386-specific assembly one. The old way to
do this was to write three files
sin_decl.go
func Sin(x float64) float64 // declaration only
sin_386.s
assembly implementation
sin_port.go
func Sin(x float64) float64 { ... } // pure-Go impl
and then link in either sin_decl.go+sin_386.s or
just sin_port.go. The Makefile actually did the magic
of linking in only the _port.go files for those without
assembly and only the _decl.go files for those with
assembly, or at least some of that magic.
The biggest problem with this, beyond being hard
to explain to the build system, is that once you do
explain it to the build system, godoc knows which
of sin_port.go or sin_decl.go are involved on a given
architecture, and it (correctly) ignores the other.
That means you have to put identical doc comments
in both files.
The new approach, which is more like what we did
in the later packages math/big and sync/atomic,
is to have
sin.go
func Sin(x float64) float64 // decl only
func sin(x float64) float64 {...} // pure-Go impl
sin_386.s
// assembly for Sin (ignores sin)
sin_amd64.s
// assembly for Sin: jmp sin
sin_arm.s
// assembly for Sin: jmp sin
Once we abandon Makefiles we can put all the assembly
stubs in one source file, so the number of files will
actually go down.
Chris asked whether the branches cost anything.
Given that they are branching to pure-Go implementations
that are not typically known for their speed, the single
direct branch is not going to be noticeable. That is,
it's on the slow path.
An alternative would have been to preserve the old
"only write assembly files when there's an implementation"
and still have just one copy of the declaration of Sin
(and thus one doc comment) by doing:
sin.go
func Sin(x float64) float64 { return sin(x) }
sin_decl.go
func sin(x float64) float64 // declaration only
sin_386.s
// assembly for sin
sin_port.go
func sin(x float64) float64 { portable code }
In this version everyone would link in sin.go and
then either sin_decl.go+sin_386.s or sin_port.go.
This has an extra function call on all paths, including
the "fast path" to get to assembly, and it triples the
number of Go files involved compared to what I did
in this CL. On the other hand you don't have to
write assembly stubs. After starting down this path
I decided that the assembly stubs were the easier
approach.
As for generating the assembly stubs on the fly, much
of the goal here is to eliminate magic from the build
process, so that zero-configuration tools like goinstall
or the new go tool can handle this package.
R=golang-dev, r, cw, iant, r
CC=golang-dev
https://golang.org/cl/5488057
2011-12-13 13:20:12 -07:00
|
|
|
func Sin(x float64) float64
|
|
|
|
|
|
|
|
func sin(x float64) float64 {
|
2011-10-31 12:26:05 -06:00
|
|
|
const (
|
|
|
|
PI4A = 7.85398125648498535156E-1 // 0x3fe921fb40000000, Pi/4 split into three parts
|
|
|
|
PI4B = 3.77489470793079817668E-8 // 0x3e64442d00000000,
|
|
|
|
PI4C = 2.69515142907905952645E-15 // 0x3ce8469898cc5170,
|
|
|
|
M4PI = 1.273239544735162542821171882678754627704620361328125 // 4/pi
|
|
|
|
)
|
|
|
|
// special cases
|
|
|
|
switch {
|
2012-02-01 08:08:31 -07:00
|
|
|
case x == 0 || IsNaN(x):
|
2011-10-31 12:26:05 -06:00
|
|
|
return x // return ±0 || NaN()
|
2012-02-01 08:08:31 -07:00
|
|
|
case IsInf(x, 0):
|
2011-10-31 12:26:05 -06:00
|
|
|
return NaN()
|
|
|
|
}
|
|
|
|
|
|
|
|
// make argument positive but save the sign
|
|
|
|
sign := false
|
2009-03-05 14:31:01 -07:00
|
|
|
if x < 0 {
|
2009-11-09 13:07:39 -07:00
|
|
|
x = -x
|
2011-10-31 12:26:05 -06:00
|
|
|
sign = true
|
2008-03-28 14:56:47 -06:00
|
|
|
}
|
|
|
|
|
2011-10-31 12:26:05 -06:00
|
|
|
j := int64(x * M4PI) // integer part of x/(Pi/4), as integer for tests on the phase angle
|
|
|
|
y := float64(j) // integer part of x/(Pi/4), as float
|
|
|
|
|
|
|
|
// map zeros to origin
|
|
|
|
if j&1 == 1 {
|
2016-10-24 14:40:31 -06:00
|
|
|
j++
|
|
|
|
y++
|
2011-10-31 12:26:05 -06:00
|
|
|
}
|
|
|
|
j &= 7 // octant modulo 2Pi radians (360 degrees)
|
|
|
|
// reflect in x axis
|
|
|
|
if j > 3 {
|
|
|
|
sign = !sign
|
|
|
|
j -= 4
|
|
|
|
}
|
|
|
|
|
|
|
|
z := ((x - y*PI4A) - y*PI4B) - y*PI4C // Extended precision modular arithmetic
|
|
|
|
zz := z * z
|
|
|
|
if j == 1 || j == 2 {
|
|
|
|
y = 1.0 - 0.5*zz + zz*zz*((((((_cos[0]*zz)+_cos[1])*zz+_cos[2])*zz+_cos[3])*zz+_cos[4])*zz+_cos[5])
|
|
|
|
} else {
|
|
|
|
y = z + z*zz*((((((_sin[0]*zz)+_sin[1])*zz+_sin[2])*zz+_sin[3])*zz+_sin[4])*zz+_sin[5])
|
|
|
|
}
|
|
|
|
if sign {
|
|
|
|
y = -y
|
|
|
|
}
|
|
|
|
return y
|
|
|
|
}
|