I first prototyped this change in Sept 2011, and I discarded it
because it made no difference in the obvious benchmark loop.
It still makes no difference in the obvious benchmark loop,
but in a less obvious one, doing some extra computation
around the calls to Sqrt, not making the call does have a
significant effect.
benchmark old ns/op new ns/op delta
BenchmarkSqrt 4.56 4.57 +0.22%
BenchmarkSqrtIndirect 4.56 4.56 +0.00%
BenchmarkSqrtGo 69.4 69.4 +0.00%
BenchmarkSqrtPrime 4417 3647 -17.43%
This is a warmup for using hardware expansions for some
calls to 1-line assembly routines in the runtime (for example getg).
Change-Id: Ie66be23f8c09d0f7dc4ddd7ca8a93cfce28f55a4
Reviewed-on: https://go-review.googlesource.com/8356
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
NaNs make the API more complicated for no real good reasons.
There are few operations that produce NaNs with IEEE arithmetic,
there's no need to copy the behavior. It's easy to test for these
scenarios and avoid them (on the other hand, it's not easy to test
for overflow or underflow, so we want to keep +/-Inf).
Also:
- renamed IsNeg -> Signbit (clearer, especially for x == -0)
- removed IsZero (Sign() == 0 is sufficient and efficient)
- removed IsFinite (now same as !IsInf)
Change-Id: I3f3b4445c325d9bbb1bf46ce2e298a6aeb498e07
Reviewed-on: https://go-review.googlesource.com/8280
Reviewed-by: Alan Donovan <adonovan@google.com>
- fix bounds checks for exponent range of denormalized numbers
- use correct rounding precision for denormalized numbers
- added extra tests
Change-Id: I6be56399afd0d9a603300a2e44b5539e08d6f592
Reviewed-on: https://go-review.googlesource.com/8096
Reviewed-by: Alan Donovan <adonovan@google.com>
To use a pure Go implementation of the low-level arithmetic
functions (when no platform-specific assembly implementations
are available), set the build tag math_big_pure_go.
This will make it easy to vendor the math/big package where no
assembly is available (for instance for use with gc which relies
on 1.4 functionality for now).
Change-Id: I91e17c0fdc568a20ec1512d7c64621241dc60c17
Reviewed-on: https://go-review.googlesource.com/7856
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Float.Cmp used to return a value < 0, 0, or > 0 depending on how
arguments x, y compared against each other. With the possibility
of NaNs, the result was changed into an Accuracy (to include Undef).
Consequently, Float.Cmp results could still be compared for (in-)
equality with 0, but comparing if < 0 or > 0 would provide the
wrong answer w/o any obvious notice by the compiler.
This change wraps Float.Cmp results into a struct and accessors
are used to access the desired result. This prevents incorrect
use.
Change-Id: I34e6a6c1859251ec99b5cf953e82542025ace56f
Reviewed-on: https://go-review.googlesource.com/7526
Reviewed-by: Rob Pike <r@golang.org>
Also:
- Implemented NewFloat convenience factory function (analogous to
NewInt and NewRat).
- Implemented convenience accessors for Accuracy values returned
from Float.Cmp.
- Added test and example.
Change-Id: I985bb4f86e6def222d4b2505417250d29a39c60e
Reviewed-on: https://go-review.googlesource.com/6970
Reviewed-by: Alan Donovan <adonovan@google.com>
This is a fairly significant _internal_ representation change. Instead
of encoding 0, finite, infinite, and NaN values with special mantissa
and exponent values, a new (1 byte) 'form' field is used (without making
the Float struct bigger). The form field permits simpler and faster
case distinctions. As a side benefit, for zero and non-finite floats,
fewer fields need to be set. Also, the exponent range is not the full
int32 range (in the old format, infExp and nanExp were used to represent
Inf and NaN values and tests for those values sometimes didn't test
for the empty mantissa, so the range was reduced by 2 values).
The correspondence between the old and new fields is as follows.
Old representation:
x neg mant exp
---------------------------------------------------------------
+/-0 sign empty 0
0 < |x| < +Inf sign mantissa exponent
+/-Inf sign empty infExp
NaN false empty nanExp
New representation (- stands for ignored fields):
x neg mant exp form
---------------------------------------------------------------
+/-0 sign - - zero
0 < |x| < +Inf sign mantissa exponent finite
+/-Inf sign - - inf
NaN - - - nan
Client should not be affected by this change.
Change-Id: I7e355894d602ceb23f9ec01da755fe6e0386b101
Reviewed-on: https://go-review.googlesource.com/6870
Reviewed-by: Alan Donovan <adonovan@google.com>
This is a pure code move without any semantic change.
Change-Id: I2c18efc858955d07949b1241e793232f2cf1deb9
Reviewed-on: https://go-review.googlesource.com/6821
Reviewed-by: Alan Donovan <adonovan@google.com>
Shifts are trivially implemented by combining
Float.MantExp and Float.SetMantExp.
Change-Id: Ia2fb49297d8ea7aa7d64c8b1318dc3dc7c8af2f7
Reviewed-on: https://go-review.googlesource.com/6671
Reviewed-by: Alan Donovan <adonovan@google.com>
This change represents Accuracy as a bit pattern rather than
an ordered value; with a new value Undef which is both Below
and Above.
Change-Id: Ibb96294c1417fb3cf2c3cf2374c993b0a4e106b3
Reviewed-on: https://go-review.googlesource.com/6650
Reviewed-by: Alan Donovan <adonovan@google.com>
This change introduces NaNs (for situations like Inf-Inf, etc.).
The implementation is incomplete (the four basic operations produce
a NaN if any of the operands is an Inf or a NaN); and some operations
produce incorrect accuracy for NaN arguments. These are known bugs
which are documented.
Change-Id: Ia88841209e47930681cef19f113e178f92ceeb33
Reviewed-on: https://go-review.googlesource.com/6540
Reviewed-by: Alan Donovan <adonovan@google.com>
MinPrec returns the minimum precision required to represent a Float
without loss of precision. Added test.
Change-Id: I466c8e492dcdd59fae854fc4e71ef9b1add7d817
Reviewed-on: https://go-review.googlesource.com/6010
Reviewed-by: Alan Donovan <adonovan@google.com>
Some rounding modes are affected by the sign of the value to
be rounded. Make sure the sign is set before round is called.
Added tests (that failed before the fix).
Change-Id: Idd09b8fcbab89894fede0b9bc922cda5ddc87930
Reviewed-on: https://go-review.googlesource.com/4876
Reviewed-by: Rob Pike <r@golang.org>
Also: remove NewFloat - not needed anymore. Work-around for places
where has been used so far:
NewFloat(x, prec, mode) === new(Float).SetMode(mode).SetPrec(prec).SetFloat64(x)
However, if mode == ToNearestEven, SetMode is not needed. SetPrec
is needed if the default precision (53 after SetFloat64) is not
adequate.
TBR adonovan
Change-Id: Ifda12c479ba157f2dea306c32b47c7afbf31e759
Reviewed-on: https://go-review.googlesource.com/4842
Reviewed-by: Robert Griesemer <gri@golang.org>
Also:
- make representation more flexible (no need to store trailing 0 digits to match precision)
- simplify rounding as a consequence
- minor related fixes
TBR adonovan
Change-Id: Ie91075990688b506d28371ec3b633b8267397ebb
Reviewed-on: https://go-review.googlesource.com/4841
Reviewed-by: Rob Pike <r@golang.org>
This avoids surprises.
Change-Id: Iaae67da2d12e29c4e797ad6313e0895f7ce80cb1
Reviewed-on: https://go-review.googlesource.com/4480
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
- Frexp, Ldexp are equivalents to the corresponding math functions.
- Set now has the same prec behavior as the other functions
- Copy is a true assignment (replaces old version of Set)
- Cmp now handles infinities
- more tests
Change-Id: I0d33980c08be3095b25d7b3d16bcad1aa7abbd0f
Reviewed-on: https://go-review.googlesource.com/4292
Reviewed-by: Alan Donovan <adonovan@google.com>
- better and more consistent documentation
- more functions implemented
- more tests
Change-Id: If4c591e7af4ec5434fbb411a48dd0f8add993720
Reviewed-on: https://go-review.googlesource.com/4140
Reviewed-by: Alan Donovan <adonovan@google.com>
- clarified representation of +/-Inf
- only 0 and Inf values can have 0 precision
- a zero precision value used as result value takes the max precision
of the arguments (to be fine-tuned for setters)
- the zero precision approach makes Float zero values possible
(they represent +0)
- more tests
Missing: Filling in the blanks. More tests.
Change-Id: Ibb4f97e12e1f356c3085ce80f3464e97b82ac130
Reviewed-on: https://go-review.googlesource.com/4000
Reviewed-by: Alan Donovan <adonovan@google.com>
Only documentation / comment changes. Update references to
point to golang.org permalinks or go.googlesource.com/go.
References in historical release notes under doc are left as is.
Change-Id: Icfc14e4998723e2c2d48f9877a91c5abef6794ea
Reviewed-on: https://go-review.googlesource.com/4060
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(For zero values the strconv %b format prints the bias-adjusted exponent;
there's no bias in Float.)
Change-Id: I6f4dda9c3a50d02eac375cfe2c927c1540aae865
Reviewed-on: https://go-review.googlesource.com/3841
Reviewed-by: Alan Donovan <adonovan@google.com>
No other functional changes.
Change-Id: I7e0bb7452c6a265535297ec7ce6a629f1aff695c
Reviewed-on: https://go-review.googlesource.com/3674
Reviewed-by: Alan Donovan <adonovan@google.com>
No other functional changes.
Change-Id: I8be1fc488caa4f3d4c00afcb8c00475bfcd10709
Reviewed-on: https://go-review.googlesource.com/3673
Reviewed-by: Alan Donovan <adonovan@google.com>
No other functional changes.
Change-Id: If0d9e6208d53478e70d991b6926ea196b2cccf2e
Reviewed-on: https://go-review.googlesource.com/3672
Reviewed-by: Alan Donovan <adonovan@google.com>
Also:
- use io.ByteScanner rather than io.RuneScanner internally
- minor simplifications in Float.Add/Sub
Change-Id: Iae0e99384128dba9eccf68592c4fd389e2bd3b4f
Reviewed-on: https://go-review.googlesource.com/3380
Reviewed-by: Rob Pike <r@golang.org>
Implemented:
- +, -, *, /, and some unary ops
- all rounding modes
- basic conversions
- string to float conversion
- tests
Missing:
- float to string conversion, formatting
- handling of +/-0 and +/-inf (under- and overflow)
- various TODOs and cleanups
With precision set to 24 or 53, the results match
float32 or float64 operations exactly (excluding
NaNs and denormalized numbers which will not be
supported).
Change-Id: I3121e90fc4b1528e40bb6ff526008da18b3c6520
Reviewed-on: https://go-review.googlesource.com/1218
Reviewed-by: Alan Donovan <adonovan@google.com>
The comment says to use (y-1), but then we did add(y.abs, natOne). We meant sub.
Fixes#9609
Change-Id: I4fe4783326ca082c05588310a0af7895a48fc779
Reviewed-on: https://go-review.googlesource.com/2961
Reviewed-by: Robert Griesemer <gri@golang.org>
Originally it used r.Int63() to show "Uint32", and now we use the correct r.Uint32() method.
Fixes#9429
Change-Id: I8a1228f1ca1af93b0e3104676fc99000257c456f
Reviewed-on: https://go-review.googlesource.com/2069
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fix include paths that got moved in the great pkg/ rename. Add
missing runtime/arch_* files for power64. Port changes that
happened on default since branching to
runtime/{asm,atomic,sys_linux}_power64x.s (precise stacks,
calling convention change, various new and deleted functions.
Port struct renaming and fix some bugs in
runtime/defs_linux_power64.h.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/161450043
This brings dev.power64 up-to-date with the current tip of
default. go_bootstrap is still panicking with a bad defer
when initializing the runtime (even on amd64).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/152570049
This also removes pkg/runtime/traceback_lr.c, which was ported
to Go in an earlier commit and then moved to
runtime/traceback.go.
Reviewer: rsc@golang.org
rsc: LGTM
The inverse is defined whenever the element and the
modulus are relatively prime. The code already handles
this situation, but the spec does not.
Test that it does indeed work.
Fixes#8875
LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/155010043
The documentation states that Exp(x, y, m)
computes x**y mod |m| for m != nil && m > 0.
In math.big, Mod is the Euclidean modulus,
which is always >= 0.
Fixes#8822.
LGTM=agl, r, rsc
R=agl, r, rsc
CC=golang-codereviews
https://golang.org/cl/145650043
The extra-clever code in Sincos is trying to do
if v&2 == 0 {
mask = 0xffffffffffffffff
} else {
mask = 0
}
It does this by turning v&2 into a float64 X0 and then using
MOVSD $0.0, X3
CMPSD X0, X3, 0
That CMPSD is defined to behave like:
if X0 == X3 {
X3 = 0xffffffffffffffff
} else {
X3 = 0
}
which gives the desired mask in X3. The goal in using the
CMPSD was to avoid a conditional branch.
This code fails when called from a PortAudio callback.
In particular, the failure behavior is exactly as if the
CMPSD always chose the 'true' execution.
Notice that the comparison X0 == X3 is comparing as
floating point values the 64-bit pattern v&2 and the actual
floating point value zero. The only possible values for v&2
are 0x0000000000000000 (floating point zero)
and 0x0000000000000002 (floating point 1e-323, a denormal).
If they are both comparing equal to zero, I conclude that
in a PortAudio callback (whatever that means), the processor
is running in "denormals are zero" mode.
I confirmed this by placing the processor into that mode
and running the test case in the bug; it produces the
incorrect output reported in the bug.
In general, if a Go program changes the floating point math
modes to something other than what Go expects, the math
library is not going to work exactly as intended, so we might
be justified in not fixing this at all.
However, it seems reasonable that the client code might
have expected "denormals are zero" mode to only affect
actual processing of denormals. This code has produced
what is in effect a gratuitous denormal by being extra clever.
There is nothing about the computation being requested
that fundamentally requires a denormal.
It is also easy to do this computation in integer math instead:
mask = ((v&2)>>1)-1
Do that.
For the record, the other math tests that fail if you put the
processor in "denormals are zero" mode are the tests for
Frexp, Ilogb, Ldexp, Logb, Log2, and FloatMinMax, but all
fail processing denormal inputs. Sincos was the only function
for which that mode causes incorrect behavior on non-denormal inputs.
The existing tests check that the new assembly is correct.
There is no test for behavior in "denormals are zero" mode,
because I don't want to add assembly to change that.
Fixes#8623.
LGTM=josharian
R=golang-codereviews, josharian
CC=golang-codereviews, iant, r
https://golang.org/cl/151750043
