aboutsummaryrefslogtreecommitdiff
path: root/src/math
AgeCommit message (Collapse)Author
2020-05-29math: fix dead link to springerlink (now link.springer)Alberto Donizetti
Change-Id: Ie5fd026af45d2e7bc371a38d15dbb52a1b4958cd Reviewed-on: https://go-review.googlesource.com/c/go/+/235717 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2020-05-19testing: clean up remaining TempDir issues from CL 231958Bryan C. Mills
Updates #38850 Change-Id: I33f48762f5520eb0c0a841d8ca1ccdd65ecc20c8 Reviewed-on: https://go-review.googlesource.com/c/go/+/234583 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-05-05math/big: add (*Int).FillBytesFilippo Valsorda
Replaced almost every use of Bytes with FillBytes. Note that the approved proposal was for func (*Int) FillBytes(buf []byte) while this implements func (*Int) FillBytes(buf []byte) []byte because the latter was far nicer to use in all callsites. Fixes #35833 Change-Id: Ia912df123e5d79b763845312ea3d9a8051343c0a Reviewed-on: https://go-review.googlesource.com/c/go/+/230397 Reviewed-by: Robert Griesemer <gri@golang.org>
2020-05-04math: implement Min/Max in riscv64 assemblyJoel Sing
Change-Id: If34422859d47bc8f44974a00c6b7908e7655ff41 Reviewed-on: https://go-review.googlesource.com/c/go/+/223561 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-05-02math: add function examples.kakulisen
The function Modf lacks corresponding examples. Change-Id: Id93423500e87d35b0b6870882be1698b304797ae Reviewed-on: https://go-review.googlesource.com/c/go/+/231097 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-05-01math/cmplx: handle special casesBrian Kessler
Implement special case handling and testing to ensure conformance with the C99 standard annex G.6 Complex arithmetic. Fixes #29320 Change-Id: Id72eb4c5a35d5a54b4b8690d2f7176ab11028f1b Reviewed-on: https://go-review.googlesource.com/c/go/+/220689 Reviewed-by: Robert Griesemer <gri@golang.org>
2020-04-30math: Add a function examplekakulisen
When I browsed the source code, I saw that there is no corresponding example of this function. I am not sure if there is a need for an increase, this is my first time to submit CL. Change-Id: Idbf4e1e1ed2995176a76959d561e152263a2fd26 Reviewed-on: https://go-review.googlesource.com/c/go/+/230741 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-04-27math/big: simplify hasVX checking on s390xRuixin(Peter) Bao
Originally, we use an assembly function that returns a boolean result to tell whether the machine has vector facility or not. It is now no longer needed when we can directly use cpu.S390X.HasVX variable. Change-Id: Ic1dae851982532bcfd9a9453416c112347f21d87 Reviewed-on: https://go-review.googlesource.com/c/go/+/230318 Reviewed-by: Michael Munday <mike.munday@ibm.com> Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-04-27math: simplify hasVX checking on s390xRuixin Bao
Originally, we use an assembly function that returns a boolean result to tell whether the machine has vector facility or not. It is now no longer needed when we can directly use cpu.S390X.HasVX variable. Change-Id: Ic3ffeb9e63238ef41406d97cdc42502145ddb454 Reviewed-on: https://go-review.googlesource.com/c/go/+/230319 Reviewed-by: Michael Munday <mike.munday@ibm.com> Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-04-25math/cmplx: fix typo in code commentTyson Andre
Everywhere else is using "cancellation" as of 2019 The reasoning is mentioned in 170060. > Though there is variation in the spelling of canceled, > cancellation is always spelled with a double l. > > Reference: https://www.grammarly.com/blog/canceled-vs-cancelled/ Change-Id: I933ea68d7251986ce582b92c33b7cb13cee1d207 GitHub-Last-Rev: fc3d5ada2bd0087ea9cfb3f105689876e7a2ee4f GitHub-Pull-Request: golang/go#38661 Reviewed-on: https://go-review.googlesource.com/c/go/+/230199 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2020-04-24math/big: rewrite subVW to use fast path on s390xRuixin(Peter) Bao
This CL replaces the original subVW implementation with a implementation that uses a similar idea as CL 164968. When we know the borrow bit is zero, we can copy the rest of words as they will not be updated. Also, since we are copying vector of a words, a faster implementation of copy is written in this CL to copy a word or multiple words at a time. Benchmarks: name old time/op new time/op delta SubVW/1-18 4.43ns ± 0% 3.82ns ± 0% -13.85% (p=0.000 n=20+20) SubVW/2-18 5.39ns ± 0% 4.25ns ± 0% -21.23% (p=0.000 n=20+20) SubVW/3-18 6.29ns ± 0% 4.65ns ± 0% -26.07% (p=0.000 n=16+19) SubVW/4-18 6.08ns ± 2% 4.84ns ± 0% -20.43% (p=0.000 n=20+20) SubVW/5-18 7.06ns ± 1% 4.93ns ± 0% -30.18% (p=0.000 n=20+20) SubVW/10-18 10.3ns ± 2% 7.2ns ± 0% -30.35% (p=0.000 n=20+19) SubVW/100-18 48.0ns ± 4% 17.6ns ± 0% -63.32% (p=0.000 n=18+19) SubVW/1000-18 448ns ±10% 236ns ± 1% -47.24% (p=0.000 n=20+20) SubVW/10000-18 4.83µs ± 5% 2.96µs ± 0% -38.73% (p=0.000 n=20+19) SubVW/100000-18 46.6µs ± 3% 30.6µs ± 1% -34.30% (p=0.000 n=20+20) [Geo mean] 56.3ns 37.0ns -34.24% name old speed new speed delta SubVW/1-18 1.80GB/s ± 0% 2.10GB/s ± 0% +16.16% (p=0.000 n=20+20) SubVW/2-18 2.97GB/s ± 0% 3.77GB/s ± 0% +26.95% (p=0.000 n=20+20) SubVW/3-18 3.82GB/s ± 0% 5.16GB/s ± 0% +35.26% (p=0.000 n=20+19) SubVW/4-18 5.26GB/s ± 1% 6.61GB/s ± 0% +25.59% (p=0.000 n=20+20) SubVW/5-18 5.67GB/s ± 1% 8.11GB/s ± 0% +43.12% (p=0.000 n=20+20) SubVW/10-18 7.79GB/s ± 2% 11.17GB/s ± 0% +43.52% (p=0.000 n=20+19) SubVW/100-18 16.7GB/s ± 4% 45.5GB/s ± 0% +172.61% (p=0.000 n=18+20) SubVW/1000-18 17.9GB/s ± 9% 33.9GB/s ± 1% +89.25% (p=0.000 n=20+20) SubVW/10000-18 16.6GB/s ± 5% 27.0GB/s ± 0% +63.08% (p=0.000 n=20+19) SubVW/100000-18 17.2GB/s ± 2% 26.1GB/s ± 1% +52.18% (p=0.000 n=20+20) [Geo mean] 7.25GB/s 11.03GB/s +52.01% Change-Id: I32e99cbab3260054a96231d02b87049c833ab77e Reviewed-on: https://go-review.googlesource.com/c/go/+/227297 Reviewed-by: Michael Munday <mike.munday@ibm.com> Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-04-24math/big: rewrite addVW to use fast path on s390xRuixin(Peter) Bao
Rewrite addVW to use a fast path and remove the original vector and non vector implementation of addVW in assembly. This CL uses a similar idea as CL 164968, where we copy the rest of words when we know carry bit is zero. In addition, since we are copying vector of words, a faster implementation of copy is written in this CL to copy a word or multiple words at a time. Benchmarks: name old time/op new time/op delta AddVW/1-18 4.56ns ± 0% 4.01ns ± 6% -12.14% (p=0.000 n=18+20) AddVW/2-18 5.54ns ± 0% 4.42ns ± 5% -20.20% (p=0.000 n=18+20) AddVW/3-18 6.55ns ± 0% 4.61ns ± 0% -29.62% (p=0.000 n=16+18) AddVW/4-18 6.11ns ± 2% 5.12ns ± 6% -16.19% (p=0.000 n=20+20) AddVW/5-18 7.32ns ± 4% 5.14ns ± 0% -29.77% (p=0.000 n=20+19) AddVW/10-18 10.6ns ± 2% 7.2ns ± 1% -31.47% (p=0.000 n=20+20) AddVW/100-18 49.6ns ± 2% 18.0ns ± 0% -63.63% (p=0.000 n=20+20) AddVW/1000-18 465ns ± 3% 244ns ± 0% -47.54% (p=0.000 n=20+20) AddVW/10000-18 4.99µs ± 4% 2.97µs ± 0% -40.54% (p=0.000 n=20+20) AddVW/100000-18 48.3µs ± 3% 30.8µs ± 1% -36.29% (p=0.000 n=20+20) [Geo mean] 58.1ns 38.0ns -34.57% name old speed new speed delta AddVW/1-18 1.76GB/s ± 0% 2.00GB/s ± 6% +14.04% (p=0.000 n=20+20) AddVW/2-18 2.89GB/s ± 0% 3.63GB/s ± 5% +25.55% (p=0.000 n=18+20) AddVW/3-18 3.66GB/s ± 0% 5.21GB/s ± 0% +42.25% (p=0.000 n=18+19) AddVW/4-18 5.24GB/s ± 2% 6.27GB/s ± 6% +19.61% (p=0.000 n=20+20) AddVW/5-18 5.47GB/s ± 4% 7.78GB/s ± 0% +42.28% (p=0.000 n=20+18) AddVW/10-18 7.55GB/s ± 2% 11.04GB/s ± 1% +46.09% (p=0.000 n=20+20) AddVW/100-18 16.1GB/s ± 2% 44.3GB/s ± 0% +174.77% (p=0.000 n=20+20) AddVW/1000-18 17.2GB/s ± 3% 32.8GB/s ± 1% +90.58% (p=0.000 n=20+20) AddVW/10000-18 16.0GB/s ± 4% 26.9GB/s ± 0% +68.11% (p=0.000 n=20+20) AddVW/100000-18 16.6GB/s ± 3% 26.0GB/s ± 1% +56.94% (p=0.000 n=20+20) [Geo mean] 7.03GB/s 10.75GB/s +52.93% Change-Id: Idbb73f3178311bd2b18a93bdc1e48f26869d2f6a Reviewed-on: https://go-review.googlesource.com/c/go/+/209679 Reviewed-by: Michael Munday <mike.munday@ibm.com> Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-04-22cmd/compile: clean up codegen for branch-on-carry on s390xMichael Munday
This CL optimizes code that uses a carry from a function such as bits.Add64 as the condition in an if statement. For example: x, c := bits.Add64(a, b, 0) if c != 0 { panic("overflow") } Rather than converting the carry into a 0 or a 1 value and using that as an input to a comparison instruction the carry flag is now used as the input to a conditional branch directly. This typically removes an ADD LOGICAL WITH CARRY instruction when user code is doing overflow detection and is closer to the code that a user would expect to generate. Change-Id: I950431270955ab72f1b5c6db873b6abe769be0da Reviewed-on: https://go-review.googlesource.com/c/go/+/219757 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-04-22math/big: clean up whitespace in arith_s390x.s fileRuixin(Peter) Bao
This CL looks big but it only does formatting changes to arith_s390x.s. The file was formatted using asmfmt(https://github.com/klauspost/asmfmt) , so there should not be any functional impact. I verified that the generated assembly of big.test file is identical. Change-Id: I8b4035ef082a4d0357881869327e25253f2d8be1 Reviewed-on: https://go-review.googlesource.com/c/go/+/229302 Reviewed-by: Michael Munday <mike.munday@ibm.com> Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-04-15math/big: remove Direct Sqrt computationAlberto Donizetti
The Float.Sqrt method switches (for performance reasons) between direct (uses Quo) and inverse (doesn't) computation, depending on the precision, with threshold 128. Unfortunately the implementation of recursive division in CL 172018 made Quo slightly slower exactly in the range around and below the threshold Sqrt is using, so this strategy is no longer profitable. The new division algorithm allocates more, and this has increased the amount of allocations performed by Sqrt when using the direct method; on low precisions the computation is fast, so additional allocations have an negative impact on performance. Interestingly, only using the inverse method doesn't just reverse the effects of the Quo algorithm change, but it seems to make performances better overall for small precisions: name old time/op new time/op delta FloatSqrt/64-4 643ns ± 1% 635ns ± 1% -1.24% (p=0.000 n=10+10) FloatSqrt/128-4 1.44µs ± 1% 1.02µs ± 1% -29.25% (p=0.000 n=10+10) FloatSqrt/256-4 1.49µs ± 1% 1.49µs ± 1% ~ (p=0.752 n=10+10) FloatSqrt/1000-4 3.71µs ± 1% 3.74µs ± 1% +0.87% (p=0.001 n=10+10) FloatSqrt/10000-4 35.3µs ± 1% 35.6µs ± 1% +0.82% (p=0.002 n=10+9) FloatSqrt/100000-4 844µs ± 1% 844µs ± 0% ~ (p=0.549 n=10+9) FloatSqrt/1000000-4 69.5ms ± 0% 69.6ms ± 0% ~ (p=0.222 n=9+9) name old alloc/op new alloc/op delta FloatSqrt/64-4 280B ± 0% 200B ± 0% -28.57% (p=0.000 n=10+10) FloatSqrt/128-4 504B ± 0% 248B ± 0% -50.79% (p=0.000 n=10+10) FloatSqrt/256-4 344B ± 0% 344B ± 0% ~ (all equal) FloatSqrt/1000-4 1.30kB ± 0% 1.30kB ± 0% ~ (all equal) FloatSqrt/10000-4 13.5kB ± 0% 13.5kB ± 0% ~ (p=0.237 n=10+10) FloatSqrt/100000-4 123kB ± 0% 123kB ± 0% ~ (p=0.247 n=10+10) FloatSqrt/1000000-4 1.83MB ± 1% 1.83MB ± 3% ~ (p=0.779 n=8+10) name old allocs/op new allocs/op delta FloatSqrt/64-4 8.00 ± 0% 5.00 ± 0% -37.50% (p=0.000 n=10+10) FloatSqrt/128-4 11.0 ± 0% 5.0 ± 0% -54.55% (p=0.000 n=10+10) FloatSqrt/256-4 5.00 ± 0% 5.00 ± 0% ~ (all equal) FloatSqrt/1000-4 6.00 ± 0% 6.00 ± 0% ~ (all equal) FloatSqrt/10000-4 6.00 ± 0% 6.00 ± 0% ~ (all equal) FloatSqrt/100000-4 6.00 ± 0% 6.00 ± 0% ~ (all equal) FloatSqrt/1000000-4 10.3 ±13% 10.3 ±13% ~ (p=1.000 n=10+10) For example, 1.02µs for FloatSqrt/128 is actually better than what I was getting on the same machine before the Quo changes. The .8% slowdown on /1000 and /10000 appears to be real and it is quite baffling (that codepath was not touched at all); it may be caused by code alignment changes. Change-Id: Ib03761cdc1055674bc7526d4f3a23d7a25094029 Reviewed-on: https://go-review.googlesource.com/c/go/+/228062 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-04-15math/big: add test that linker is able to remove unused codeBrad Fitzpatrick
(Follow-up to CL 228108.) Change-Id: Ia6d119ee19c7aa923cdeead06d3cee87a1751105 Reviewed-on: https://go-review.googlesource.com/c/go/+/228109 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-04-15math/big: fix typo in documentation for Int.ExpHanjun Kim
Fixes #38304 Also change `If m > 0, y < 0, ...` to `If m != 0, y < 0, ...` since `Exp` will return `nil` whatever `m`'s sign is. Change-Id: I17d7337ccd1404318cea5d42a8de904ad185fd00 GitHub-Last-Rev: 23995103000505dbf35aa29a717470c4da638fda GitHub-Pull-Request: golang/go#38390 Reviewed-on: https://go-review.googlesource.com/c/go/+/228000 Reviewed-by: Robert Griesemer <gri@golang.org>
2020-04-14math/big: don't use Float in init to help linker discard 162 KiBBrad Fitzpatrick
Removes 162 KiB from binaries that don't use math/big.Float: -rwxr-xr-x 1 bradfitz bradfitz 1916590 Apr 14 12:21 x.after -rwxr-xr-x 1 bradfitz bradfitz 2082575 Apr 14 12:21 x.before No change in deps (this package already used sync). No change in benchmarks: name old time/op new time/op delta FloatSqrt/64-8 1.06µs ±10% 1.03µs ± 6% ~ (p=0.133 n=10+9) FloatSqrt/128-8 2.26µs ± 9% 2.28µs ± 9% ~ (p=0.460 n=10+8) FloatSqrt/256-8 2.29µs ± 5% 2.31µs ± 3% ~ (p=0.214 n=9+9) FloatSqrt/1000-8 5.82µs ± 3% 5.87µs ± 7% ~ (p=0.666 n=9+9) FloatSqrt/10000-8 56.4µs ± 5% 57.0µs ± 6% ~ (p=0.436 n=10+10) FloatSqrt/100000-8 1.34ms ± 8% 1.31ms ± 3% ~ (p=0.447 n=10+9) FloatSqrt/1000000-8 106ms ± 5% 107ms ± 7% ~ (p=0.315 n=10+10) name old alloc/op new alloc/op delta FloatSqrt/64-8 280B ± 0% 280B ± 0% ~ (all equal) FloatSqrt/128-8 504B ± 0% 504B ± 0% ~ (all equal) FloatSqrt/256-8 344B ± 0% 344B ± 0% ~ (all equal) FloatSqrt/1000-8 1.30kB ± 0% 1.30kB ± 0% ~ (all equal) FloatSqrt/10000-8 13.5kB ± 0% 13.5kB ± 0% ~ (p=0.403 n=10+10) FloatSqrt/100000-8 123kB ± 0% 123kB ± 0% ~ (p=0.393 n=10+10) FloatSqrt/1000000-8 1.84MB ± 7% 1.84MB ± 5% ~ (p=0.739 n=10+10) name old allocs/op new allocs/op delta FloatSqrt/64-8 8.00 ± 0% 8.00 ± 0% ~ (all equal) FloatSqrt/128-8 11.0 ± 0% 11.0 ± 0% ~ (all equal) FloatSqrt/256-8 5.00 ± 0% 5.00 ± 0% ~ (all equal) FloatSqrt/1000-8 6.00 ± 0% 6.00 ± 0% ~ (all equal) FloatSqrt/10000-8 6.00 ± 0% 6.00 ± 0% ~ (all equal) FloatSqrt/100000-8 6.00 ± 0% 6.00 ± 0% ~ (all equal) FloatSqrt/1000000-8 10.9 ±10% 10.8 ±17% ~ (p=0.974 n=10+10) Change-Id: I3337f1f531bf7b4fae192b9d90cd24ff2be14fea Reviewed-on: https://go-review.googlesource.com/c/go/+/228108 Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-04-08math/big: correct off-by-one access in divBasicRémy Oudompheng
The divBasic function computes the quotient of big nats u/v word by word. It estimates each word qhat by performing a long division (top 2 words of u divided by top word of v), looks at the next word to correct the estimate, then perform a full multiplication (qhat*v) to catch any inaccuracy in the estimate. In the latter case, "negative" values appear temporarily and carries must be carefully managed, and the recursive division refactoring introduced a case where qhat*v has the same length as v, triggering an out-of-bounds write in the case it happens when computing the top word of the quotient. Fixes #37499 Change-Id: I15089da4a4027beda43af497bf6de261eb792f94 Reviewed-on: https://go-review.googlesource.com/c/go/+/221980 Reviewed-by: Robert Griesemer <gri@golang.org>
2020-03-25math: correct Atan2(±y,+∞) = ±0 on s390xBrian Kessler
The s390x assembly implementation was previously only handling this case correctly for x = -Pi. Update the special case handling for any y. Fixes #35446 Change-Id: I355575e9ec8c7ce8bd9db10d74f42a22f39a2f38 Reviewed-on: https://go-review.googlesource.com/c/go/+/223420 Run-TryBot: Brian Kessler <brian.m.kessler@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Munday <mike.munday@ibm.com> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-03-20math/big: document that Sqrt doesn't set AccuracyAlberto Donizetti
Document that the Float.Sqrt method does not set the receiver's Accuracy field. Updates #37915 Change-Id: Ief1dcac07eacc0ef02f86bfac9044501477bca1c Reviewed-on: https://go-review.googlesource.com/c/go/+/224497 Reviewed-by: Robert Griesemer <gri@golang.org>
2020-03-14math/cmplx: disable TanHuge test on s390xBrian Kessler
s390x has inaccurate range reduction for the assembly routines in math so these tests are diabled until these are corrected. Updates #37854 Change-Id: I1e26acd6d09ae3e592a3dd90aec73a6844f5c6fe Reviewed-on: https://go-review.googlesource.com/c/go/+/223457 Run-TryBot: Brian Kessler <brian.m.kessler@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2020-03-14math/cmplx: implement Payne-Hanek range reductionBrian Kessler
Tan has poles along the real axis. In order to accurately calculate the value near these poles, a range reduction by Pi is performed and the result calculated via a Taylor series. The prior implementation of range reduction used Cody-Waite range reduction in three parts. This fails when x is too large to accurately calculate the partial products in the summation accurately. Above this threshold, Payne-Hanek range reduction using a multiple precision value of 1/Pi is required. Additionally, the threshold used in math/trig_reduce.go for Payne-Hanek range reduction was not set conservatively enough. The prior threshold ensured that catastrophic failure did not occur where the argument x would not actually be reduced below Pi/4. However, errors in reduction begin to occur at values much lower when z = ((x - y*PI4A) - y*PI4B) - y*PI4C is not exact because y*PI4A cannot be exactly represented as a float64. reduceThreshold is lowered to the proper value. Fixes #31566 Change-Id: I0f39a4171a5be44f64305f18dc57f6c29f19dba7 Reviewed-on: https://go-review.googlesource.com/c/go/+/172838 Reviewed-by: Rob Pike <r@golang.org>
2020-02-25math/big: initial vector arithmetic in riscv64 assemblyJoel Sing
Provide an assembly implementation of mulWW - for now all others run the Go code. Change-Id: Icb594c31048255f131bdea8d64f56784fc9db4d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/220919 Reviewed-by: Robert Griesemer <gri@golang.org>
2020-02-25math: implement Sqrt in assembly for riscv64Joel Sing
Change-Id: I9a5dc33271434e58335f5562a30cc131c6a8332c Reviewed-on: https://go-review.googlesource.com/c/go/+/220918 Reviewed-by: Robert Griesemer <gri@golang.org>
2020-02-05math/big: reintroduce pre-Go 1.14 mention in GCD docsFilippo Valsorda
It was removed in CL 217302 but was intentionally added in CL 217104. Change-Id: I1a478d80ad1ec4f0a0184bfebf8f1a5e352cfe8c Reviewed-on: https://go-review.googlesource.com/c/go/+/217941 Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-31math/big: simplify GCD docsFilippo Valsorda
We don't usually document past behavior (like "As of Go 1.14 ...") and in isolation the current docs made it sound like a and b could only be negative or zero. Change-Id: I0d3c2b8579a9c01159ce528a3128b1478e99042a Reviewed-on: https://go-review.googlesource.com/c/go/+/217302 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-01-30math/big: update comment on Int.GCDRobert Griesemer
Per the suggestion https://golang.org/cl/216200/2/doc/go1.14.html#423. Updates #28878. Change-Id: I654d2d114409624219a0041916f0a4030efc7573 Reviewed-on: https://go-review.googlesource.com/c/go/+/217104 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-01-15math, math/big: add support for riscv64Joel Sing
Based on riscv-go port. Updates #27532 Change-Id: Id8ae7d851c393ec3702e4176c363accb0a42587f Reviewed-on: https://go-review.googlesource.com/c/go/+/204633 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-12-04math/rand: update comment to avoid use of ^ for exponentiationBrad Fitzpatrick
Fixes #35920 Change-Id: I1a4d26c5f7f3fbd4de13fc337de482667d83c47f Reviewed-on: https://go-review.googlesource.com/c/go/+/209758 Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
2019-11-15all: fix a bunch of misspellingsVille Skyttä
Change-Id: I5b909df0fd048cd66c5a27fca1b06466d3bcaac7 GitHub-Last-Rev: 778c5d21311abee09a5fbda2e4005a5fd4cc3f9f GitHub-Pull-Request: golang/go#35624 Reviewed-on: https://go-review.googlesource.com/c/go/+/207421 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-11-13math/big: fix out-of-bounds panic in divRecursiveRémy Oudompheng
The bounds in the last carry branch were wrong as there is no reason for len(u) >= n+n/2 to always hold true. We also adjust test to avoid using a remainder of 1 (in which case, the last step of the algorithm computes (qhatv+1) - qhatv which rarely produces a carry). Change-Id: I69fbab9c5e19d0db1c087fbfcd5b89352c2d26fb Reviewed-on: https://go-review.googlesource.com/c/go/+/206839 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2019-11-12math/big: ensure correct test inputRobert Griesemer
There is a (theoretical, but possible) chance that the random number values a, b used for TestDiv are 0 or 1, in which case the test would fail. This CL makes sure that a >= 1 and b >= 2 at all times. Fixes #35523. Change-Id: I6451feb94241249516a821cd0066e95a0c65b0ed Reviewed-on: https://go-review.googlesource.com/c/go/+/206818 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-11-12math/big: implement recursive algorithm for divisionRémy Oudompheng
The current division algorithm produces one word of result at a time, using 2-word division to compute the top word and mulAddVWW to compute the remainder. The top word may need to be adjusted by 1 or 2 units. The recursive version, based on Burnikel, Ziegler, "Fast Recursive Division", uses the same principles, but in a multi-word setting, so that multiplication benefits from the Karatsuba algorithm (and possibly later improvements). benchmark old ns/op new ns/op delta BenchmarkDiv/20/10-4 38.2 38.3 +0.26% BenchmarkDiv/40/20-4 38.7 38.5 -0.52% BenchmarkDiv/100/50-4 62.5 62.6 +0.16% BenchmarkDiv/200/100-4 238 259 +8.82% BenchmarkDiv/400/200-4 311 338 +8.68% BenchmarkDiv/1000/500-4 604 649 +7.45% BenchmarkDiv/2000/1000-4 1214 1278 +5.27% BenchmarkDiv/20000/10000-4 38279 36510 -4.62% BenchmarkDiv/200000/100000-4 3022057 1359615 -55.01% BenchmarkDiv/2000000/1000000-4 310827664 54012939 -82.62% BenchmarkDiv/20000000/10000000-4 33272829421 1965401359 -94.09% BenchmarkString/10/Base10-4 158 156 -1.27% BenchmarkString/100/Base10-4 797 792 -0.63% BenchmarkString/1000/Base10-4 3677 3814 +3.73% BenchmarkString/10000/Base10-4 16633 17116 +2.90% BenchmarkString/100000/Base10-4 5779029 1793808 -68.96% BenchmarkString/1000000/Base10-4 889840820 85524031 -90.39% BenchmarkString/10000000/Base10-4 134338236860 4935657026 -96.33% Fixes #21960 Updates #30943 Change-Id: I134c6f81a47870c688ca95b6081eb9211def15a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/172018 Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-11-08Revert "math/cmplx: handle special cases"Ian Lance Taylor
This reverts CL 169501. Reason for revert: The new tests fail at least on s390x and MIPS. This is likely a minor bug in the compiler or runtime. But this point in the release cycle is not the time to debug these details, which are unlikely to be new. Let's try again for 1.15. Updates #29320 Fixes #35443 Change-Id: I2218b2083f8974b57d528e3742524393fc72b355 Reviewed-on: https://go-review.googlesource.com/c/go/+/206037 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-11-07math/cmplx: handle special casesBrian Kessler
Implement special case handling and testing to ensure conformance with the C99 standard annex G.6 Complex arithmetic. Fixes #29320 Change-Id: Ieb0527191dd7fdea5b1aecb42b9e23aae3f74260 Reviewed-on: https://go-review.googlesource.com/c/go/+/169501 Run-TryBot: Brian Kessler <brian.m.kessler@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2019-11-07math: test portable FMA even on system with hardware FMARuss Cox
This makes it a little less likely the portable FMA will be broken without realizing it. Change-Id: I7f7f4509b35160a9709f8b8a0e494c09ea6e410a Reviewed-on: https://go-review.googlesource.com/c/go/+/205337 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-11-07math, cmd/compile: rename Fma to FMARuss Cox
This API was added for #25819, where it was discussed as math.FMA. The commit adding it used math.Fma, presumably for consistency with the rest of the unusual names in package math (Sincos, Acosh, Erfcinv, Float32bits, etc). I believe that using an idiomatic Go name is more important here than consistency with these other names, most of which are historical baggage from C's standard library. Early additions like Float32frombits happened before "uppercase for export" (so they were originally like "float32frombits") and they were not properly reconsidered when we uppercased the symbols to export them. That's a mistake we live with. The names of functions we have added since then, and even a few that were legacy, are more properly Go-cased, such as IsNaN, IsInf, and RoundToEven, rather than Isnan, Isinf, and Roundtoeven. And also constants like MaxFloat32. For new API, we should keep using proper Go-cased symbols instead of minimally-upper-cased-C symbols. So math.FMA, not math.Fma. This API has not yet been released, so this change does not break the compatibility promise. This CL also modifies cmd/compile, since the compiler knows the name of the function. I could have stopped at changing the string constants, but it seemed to make more sense to use a consistent casing everywhere. Change-Id: I0f6f3407f41e99bfa8239467345c33945088896e Reviewed-on: https://go-review.googlesource.com/c/go/+/205317 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-11-07math/big: allow all values for GCDBrian Kessler
Allow the inputs a and b to be zero or negative to GCD with the following definitions. If x or y are not nil, GCD sets their value such that z = a*x + b*y. Regardless of the signs of a and b, z is always >= 0. If a == b == 0, GCD sets z = x = y = 0. If a == 0 and b != 0, GCD sets z = |b|, x = 0, y = sign(b) * 1. If a != 0 and b == 0, GCD sets z = |a|, x = sign(a) * 1, y = 0. Fixes #28878 Change-Id: Ia83fce66912a96545c95cd8df0549bfd852652f3 Reviewed-on: https://go-review.googlesource.com/c/go/+/164972 Run-TryBot: Brian Kessler <brian.m.kessler@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2019-10-25math/big: use nat pool to reduce allocations in mul and sqrRémy Oudompheng
This notably allows to reuse temporaries across the karatsubaSqr recursion. benchmark old ns/op new ns/op delta BenchmarkNatMul/10-4 227 228 +0.44% BenchmarkNatMul/100-4 8339 8589 +3.00% BenchmarkNatMul/1000-4 313796 312272 -0.49% BenchmarkNatMul/10000-4 11924720 11873589 -0.43% BenchmarkNatMul/100000-4 503813354 503839058 +0.01% BenchmarkNatSqr/20-4 549 513 -6.56% BenchmarkNatSqr/30-4 945 874 -7.51% BenchmarkNatSqr/50-4 1993 1832 -8.08% BenchmarkNatSqr/80-4 4096 3874 -5.42% BenchmarkNatSqr/100-4 6192 5712 -7.75% BenchmarkNatSqr/200-4 20388 19543 -4.14% BenchmarkNatSqr/300-4 38735 36715 -5.21% BenchmarkNatSqr/500-4 99562 93542 -6.05% BenchmarkNatSqr/800-4 195554 184907 -5.44% BenchmarkNatSqr/1000-4 286302 275053 -3.93% BenchmarkNatSqr/10000-4 9817057 9441641 -3.82% BenchmarkNatSqr/100000-4 390713416 379696789 -2.82% benchmark old allocs new allocs delta BenchmarkNatMul/10-4 1 1 +0.00% BenchmarkNatMul/100-4 1 1 +0.00% BenchmarkNatMul/1000-4 2 1 -50.00% BenchmarkNatMul/10000-4 2 1 -50.00% BenchmarkNatMul/100000-4 9 11 +22.22% BenchmarkNatSqr/20-4 2 1 -50.00% BenchmarkNatSqr/30-4 2 1 -50.00% BenchmarkNatSqr/50-4 2 1 -50.00% BenchmarkNatSqr/80-4 2 1 -50.00% BenchmarkNatSqr/100-4 2 1 -50.00% BenchmarkNatSqr/200-4 2 1 -50.00% BenchmarkNatSqr/300-4 4 1 -75.00% BenchmarkNatSqr/500-4 4 1 -75.00% BenchmarkNatSqr/800-4 10 1 -90.00% BenchmarkNatSqr/1000-4 10 1 -90.00% BenchmarkNatSqr/10000-4 731 1 -99.86% BenchmarkNatSqr/100000-4 19687 6 -99.97% benchmark old bytes new bytes delta BenchmarkNatMul/10-4 192 192 +0.00% BenchmarkNatMul/100-4 4864 4864 +0.00% BenchmarkNatMul/1000-4 57344 49224 -14.16% BenchmarkNatMul/10000-4 565248 498772 -11.76% BenchmarkNatMul/100000-4 5749504 7263720 +26.34% BenchmarkNatSqr/20-4 672 352 -47.62% BenchmarkNatSqr/30-4 992 512 -48.39% BenchmarkNatSqr/50-4 1792 896 -50.00% BenchmarkNatSqr/80-4 2688 1408 -47.62% BenchmarkNatSqr/100-4 3584 1792 -50.00% BenchmarkNatSqr/200-4 6656 3456 -48.08% BenchmarkNatSqr/300-4 24448 16387 -32.97% BenchmarkNatSqr/500-4 36864 24591 -33.29% BenchmarkNatSqr/800-4 69760 40981 -41.25% BenchmarkNatSqr/1000-4 86016 49180 -42.82% BenchmarkNatSqr/10000-4 2524800 487368 -80.70% BenchmarkNatSqr/100000-4 68599808 5876581 -91.43% Change-Id: I8e6e409ae1cb48be9d5aa9b5f428d6cbe487673a Reviewed-on: https://go-review.googlesource.com/c/go/+/172017 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2019-10-24math/big: make Rat.Denom side-effect freeRobert Griesemer
A Rat is represented via a quotient a/b where a and b are Int values. To make it possible to use an uninitialized Rat value (with a and b uninitialized and thus == 0), the implementation treats a 0 denominator as 1. Rat.Num and Rat.Denom return pointers to these values a and b. Because b may be 0, Rat.Denom used to first initialize it to 1 and thus produce an undesirable side-effect (by changing the Rat's denominator). This CL changes Denom to return a new (not shared) *Int with value 1 in the rare case where the Rat was not initialized. This eliminates the side effect and returns the correct denominator value. While this is changing behavior of the API, the impact should now be minor because together with (prior) CL https://golang.org/cl/202997, which initializes Rats ASAP, Denom is unlikely used to access the denominator of an uninitialized (and thus 0) Rat. Any operation that will somehow set a Rat value will ensure that the denominator is not 0. Fixes #33792. Updates #3521. Change-Id: I0bf15ac60513cf52162bfb62440817ba36f0c3fc Reviewed-on: https://go-review.googlesource.com/c/go/+/203059 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-10-24math/big: normalize unitialized denominators ASAPRobert Griesemer
A Rat is represented via a quotient a/b where a and b are Int values. To make it possible to use an uninitialized Rat value (with a and b uninitialized and thus == 0), the implementation treats a 0 denominator as 1. For each operation we check if the denominator is 0, and then treat it as 1 (if necessary). Operations that create a new Rat result, normalize that value such that a result denominator 1 is represened as 0 again. This CL changes this behavior slightly: 0 denominators are still interpreted as 1, but whenever we (safely) can, we set an uninitialized 0 denominator to 1. This simplifies the code overall. Also: Improved some doc strings. Preparation for addressing issue #33792. Updates #33792. Change-Id: I3040587c8d0dad2e840022f96ca027d8470878a0 Reviewed-on: https://go-review.googlesource.com/c/go/+/202997 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-10-21math: add guaranteed-precision FMA implementationAkhil Indurti
Currently, the precision of the float64 multiply-add operation (x * y) + z varies across architectures. While generated code for ppc64, s390x, and arm64 can guarantee that there is no intermediate rounding on those platforms, other architectures like x86, mips, and arm will exhibit different behavior depending on available instruction set. Consequently, applications cannot rely on results being identical across GOARCH-dependent codepaths. This CL introduces a software implementation that performs an IEEE 754 double-precision fused-multiply-add operation. The only supported rounding mode is round-to-nearest ties-to-even. Separate CLs include hardware implementations when available. Otherwise, this software fallback is given as the default implementation. Specifically, - arm64, ppc64, s390x: Uses the FMA instruction provided by all of these ISAs. - mips[64][le]: Falls back to this software implementation. Only release 6 of the ISA includes a strict FMA instruction with MADDF.D (not implementation defined). Because the number of R6 processors in the wild is scarce, the assembly implementation is left as a future optimization. - x86: Guards the use of VFMADD213SD by checking cpu.X86.HasFMA. - arm: Guards the use of VFMA by checking cpu.ARM.HasVFPv4. - software fallback: Uses mostly integer arithmetic except for input that involves Inf, NaN, or zero. Updates #25819. Change-Id: Iadadff2219638bacc9fec78d3ab885393fea4a08 Reviewed-on: https://go-review.googlesource.com/c/go/+/127458 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-10-18math/bits: add Rem, Rem32, Rem64Alberto Donizetti
The Div functions in math/bits (Div, Div32, and Div64) compute both quotients and remainders, but they panic if the quotients do not not fit a 32/64 uint. Since, on the other hand, the remainder will always fit the size of the divisor, it is useful to have Div variants that only compute the remainder, and don't panic on a quotient overflow. This change adds to the math/bits package three new functions: Rem(hi, lo, y uint) uint Rem32(hi, lo, y uint32) uint32 Rem64(hi, lo, y uint64) uint64 which can be used to compute (hi,lo)%y even when the quotient overflows the uint size. Fixes #28970 Change-Id: I119948429f737670c5e5ceb8756121e6a738dbdc Reviewed-on: https://go-review.googlesource.com/c/go/+/197838 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-10-15math/big: make Rat accessors safe for concurrent useRobert Griesemer
Do not modify the underlying Rat denominator when calling one of the accessors Float32, Float64; verify that we don't modify the Rat denominator when calling Inv, Sign, IsInt, Num. Fixes #34919. Reopens #33792. Change-Id: Ife6d1252373f493a597398ee51e7b5695b708df5 Reviewed-on: https://go-review.googlesource.com/c/go/+/201205 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-10-10all: remove nacl (part 3, more amd64p32)Brad Fitzpatrick
Part 1: CL 199499 (GOOS nacl) Part 2: CL 200077 (amd64p32 files, toolchain) Part 3: stuff that arguably should've been part of Part 2, but I forgot one of my grep patterns when splitting the original CL up into two parts. This one might also have interesting stuff to resurrect for any future x32 ABI support. Updates #30439 Change-Id: I2b4143374a253a003666f3c69e776b7e456bdb9c Reviewed-on: https://go-review.googlesource.com/c/go/+/200318 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-10-09all: remove the nacl port (part 2, amd64p32 + toolchain)Brad Fitzpatrick
This is part two if the nacl removal. Part 1 was CL 199499. This CL removes amd64p32 support, which might be useful in the future if we implement the x32 ABI. It also removes the nacl bits in the toolchain, and some remaining nacl bits. Updates #30439 Change-Id: I2475d5bb066d1b474e00e40d95b520e7c2e286e1 Reviewed-on: https://go-review.googlesource.com/c/go/+/200077 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-09-30math/rand: devirtualize interface call in ReadCarlo Alberto Ferraris
This allows to inline the common case in which the Source is a rngSource. On linux/amd64 in a VM: name old time/op new time/op delta Read3-4 33.8ns ± 8% 18.5ns ± 8% -45.38% (p=0.000 n=10+10) Read64-4 371ns ± 8% 70ns ± 7% -81.00% (p=0.000 n=10+10) Read1000-4 5.33µs ± 5% 0.86µs ± 3% -83.85% (p=0.000 n=9+9) Change-Id: Ibf47b0e9ecdfe62ffcb66d6a92f191800bdc740e Reviewed-on: https://go-review.googlesource.com/c/go/+/191539 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-29math/rand: devirtualize interface in lockedSourceCarlo Alberto Ferraris
Avoid interface calls, enable inlining, and store the rngSource close to the Mutex to exploit better memory locality. Also add a benchmark to properly measure the threadsafe nature of globalRand. On a linux/amd64 VM: name old time/op new time/op delta Int63Threadsafe-4 36.4ns ±12% 20.6ns ±11% -43.52% (p=0.000 n=30+30) Int63ThreadsafeParallel-4 79.3ns ± 5% 56.5ns ± 5% -28.69% (p=0.000 n=29+30) Change-Id: I6ab912c1a1e9afc7bacd8e72c82d4d50d546a510 Reviewed-on: https://go-review.googlesource.com/c/go/+/191538 Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-18math/big: avoid MinExp exponent wrap-around in 'x' Text formatRobert Griesemer
Fixes #34343. Change-Id: I74240c8f431f6596338633a86a7a5ee1fce70a65 Reviewed-on: https://go-review.googlesource.com/c/go/+/196057 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
generated by cgit v1.3-5-g9baa (git 2.53.0) at 2026-04-17 16:00:27 +0000