1
0
mirror of https://github.com/golang/go synced 2024-11-19 16:34:49 -07:00
go/src/math/sqrt.go

144 lines
4.6 KiB
Go
Raw Normal View History

2008-03-28 14:56:47 -06:00
// Copyright 2009 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package math
2008-03-28 14:56:47 -06:00
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
// The original C code and the long comment below are
// from FreeBSD's /usr/src/lib/msun/src/e_sqrt.c and
// came with this notice. The go code is a simplified
// version of the original C.
//
// ====================================================
// Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
//
// Developed at SunPro, a Sun Microsystems, Inc. business.
// Permission to use, copy, modify, and distribute this
// software is freely granted, provided that this notice
// is preserved.
// ====================================================
//
// __ieee754_sqrt(x)
// Return correctly rounded sqrt.
// -----------------------------------------
// | Use the hardware sqrt if you have one |
// -----------------------------------------
// Method:
// Bit by bit method using integer arithmetic. (Slow, but portable)
// 1. Normalization
// Scale x to y in [1,4) with even powers of 2:
// find an integer k such that 1 <= (y=x*2**(2k)) < 4, then
// sqrt(x) = 2**k * sqrt(y)
// 2. Bit by bit computation
// Let q = sqrt(y) truncated to i bit after binary point (q = 1),
// i 0
// i+1 2
// s = 2*q , and y = 2 * ( y - q ). (1)
// i i i i
//
// To compute q from q , one checks whether
// i+1 i
//
// -(i+1) 2
// (q + 2 ) <= y. (2)
// i
// -(i+1)
// If (2) is false, then q = q ; otherwise q = q + 2 .
// i+1 i i+1 i
//
// With some algebraic manipulation, it is not difficult to see
// that (2) is equivalent to
// -(i+1)
// s + 2 <= y (3)
// i i
//
// The advantage of (3) is that s and y can be computed by
// i i
// the following recurrence formula:
// if (3) is false
//
// s = s , y = y ; (4)
// i+1 i i+1 i
//
// otherwise,
// -i -(i+1)
// s = s + 2 , y = y - s - 2 (5)
// i+1 i i+1 i i
//
// One may easily use induction to prove (4) and (5).
// Note. Since the left hand side of (3) contain only i+2 bits,
// it does not necessary to do a full (53-bit) comparison
// in (3).
// 3. Final rounding
// After generating the 53 bits result, we compute one more bit.
// Together with the remainder, we can decide whether the
// result is exact, bigger than 1/2ulp, or less than 1/2ulp
// (it will never equal to 1/2ulp).
// The rounding mode can be detected by checking whether
// huge + tiny is equal to huge, and whether huge - tiny is
// equal to huge for some floating point number "huge" and "tiny".
//
//
// Notes: Rounding mode detection omitted. The constants "mask", "shift",
// and "bias" are found in src/math/bits.go
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
// Sqrt returns the square root of x.
//
// Special cases are:
// Sqrt(+Inf) = +Inf
// Sqrt(±0) = ±0
// Sqrt(x < 0) = NaN
// Sqrt(NaN) = NaN
func Sqrt(x float64) float64
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 sqrt(x float64) float64 {
// special cases
switch {
case x == 0 || IsNaN(x) || IsInf(x, 1):
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
return x
case x < 0:
return NaN()
}
ix := Float64bits(x)
// normalize x
exp := int((ix >> shift) & mask)
if exp == 0 { // subnormal x
for ix&1<<shift == 0 {
ix <<= 1
exp--
}
exp++
}
exp -= bias // unbias exponent
ix &^= mask << shift
ix |= 1 << shift
if exp&1 == 1 { // odd exp, double x to make it even
ix <<= 1
}
exp >>= 1 // exp = exp/2, exponent of square root
// generate sqrt(x) bit by bit
ix <<= 1
var q, s uint64 // q = sqrt(x)
r := uint64(1 << (shift + 1)) // r = moving bit from MSB to LSB
for r != 0 {
t := s + r
if t <= ix {
s = t + r
ix -= t
q += r
}
ix <<= 1
r >>= 1
}
// final rounding
if ix != 0 { // remainder, result not exact
q += q & 1 // round according to extra bit
}
ix = q>>1 + uint64(exp-1+bias)<<shift // significand + biased exponent
return Float64frombits(ix)
}
func sqrtC(f float64, r *float64) {
*r = sqrt(f)
}