| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Upstream AOSP change doesn't have a newline at the location
this change addresses, causing a merge conflict
Test: Build, presubmit
Bug: 159464174
Merged-In: I957dfe35aacc3e397611d8ab0b9ad19a1130a3dd
Change-Id: I7614d420ad55129b04e0dfa9310e39d715ed2da7
|
| |
|
|
|
|
|
|
|
|
|
| |
Update the GeomagneticField coefficients according to the World
Magnetic Model 2020-2025 values and specify the base time in UTC since
calls to System.currentTimeMillis() will return a UTC based time.
Test: CTS test passes
Signed-off-by: Cory Hockenbury <chockenbury@gmail.com>
Merged-In: I7614d420ad55129b04e0dfa9310e39d715ed2da7
Change-Id: Ica9182053359e5387da57bb0b3b93347040160ed
|
| |
|
|
|
|
| |
Bug: 149865957
Test: atest CtsHardwareTestCases:GeomagneticFieldTest (passes)
Change-Id: I98423f6cceb0026289c10d4adc8b8675f4b41bda
|
| |
|
|
|
|
|
|
|
| |
Test: make ds-docs
Bug: 72929620
Change-Id: Ie6e5d3b8c0770ffb4ffb58b3e484e5cf30a9126f
Exempt-From-Owner-Approval: Docs-only change
|
| |
|
|
|
|
| |
Test: compiles and corresponding cts test pass
Bug: 31216311
Change-Id: I36f26086b1e2f62f81974d81d90c9a9c315a3445
|
| |\
| |
| |
| | |
Change-Id: I2588c65b7a9fa43f968151a206924a804f0595a7
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The motivation is an API change: FloatMath is going to be
deprecated and/or removed. Performance is not the goal of
this change.
That said...
Math is faster than FloatMath with AOT compilation.
While making the change, occurances of:
{Float}Math.sqrt(x * x + y * y) and
{Float}Math.sqrt({Float}Math.pow(x, 2) + {Float}Math.pow(y, 2))
have been replaced with:
{(float)} Math.hypot(x, y)
Right now there is no runtime intrinsic for hypot so is not faster
in all cases for AOT compilation:
Math.sqrt(x * x + y * y) is faster than Math.hypot(x, y) with
AOT, but all other combinations of FloatMath, use of pow() etc.
are slower than hypot().
hypot() has the advantage of being self documenting and
could be optimized in future. None of the behavior differences
around NaN and rounding appear to be important for the cases
looked at: they all assume results and arguments are in range
and usually the results are cast to float.
Different implementations measured on hammerhead / L:
AOT compiled:
[FloatMath.hypot(x, y)]
benchmark=Hypot_FloatMathHypot} 633.85 ns; σ=0.32 ns @ 3 trials
[FloatMath.sqrt(x*x + y*y)]
benchmark=Hypot_FloatMathSqrtMult} 684.17 ns; σ=4.83 ns @ 3 trials
[FloatMath.sqrt(FloatMath.pow(x, 2) + FloatMath.pow(y, 2))]
benchmark=Hypot_FloatMathSqrtPow} 1270.65 ns; σ=12.20 ns @ 6 trials
[(float) Math.hypot(x, y)]
benchmark=Hypot_MathHypot} 96.80 ns; σ=0.05 ns @ 3 trials
[(float) Math.sqrt(x*x + y*y)]
benchmark=Hypot_MathSqrtMult} 23.97 ns; σ=0.01 ns @ 3 trials
[(float) Math.sqrt(Math.pow(x, 2) + Math.pow(y, 2))]
benchmark=Hypot_MathSqrtPow} 156.19 ns; σ=0.12 ns @ 3 trials
Interpreter:
benchmark=Hypot_FloatMathHypot} 1180.54 ns; σ=5.13 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtMult} 1121.05 ns; σ=3.80 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtPow} 3327.14 ns; σ=7.33 ns @ 3 trials
benchmark=Hypot_MathHypot} 856.57 ns; σ=1.41 ns @ 3 trials
benchmark=Hypot_MathSqrtMult} 1028.92 ns; σ=9.11 ns @ 3 trials
benchmark=Hypot_MathSqrtPow} 2539.47 ns; σ=24.44 ns @ 3 trials
Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: I06c91f682095e627cb547d60d936ef87941be692
|
| |/
|
|
| |
Change-Id: I5a84e8e93ac99b5ed0212b37bf66efa5e53864be
|
| |
|
|
| |
Change-Id: I03cae5bdb7b806e81cc6c983a014de212cb80c73
|
| |
|
|
| |
Change-Id: I5937eed4a8775eae044500552ec81030b93acb18
|
| | |
|
| | |
|
| |
|