Age | Commit message (Collapse) | Author |
|
am: 8079f08863
Change-Id: I56cbb4762b1aa2df0d4a536ea442cc8cc99bb8dc
|
|
am: b80dbf3b74
Change-Id: Iaff517d873f5e946f367a2ba4edd823609007ef6
|
|
Bug: 33166666
Test: gerrit uploader
Change-Id: I944df6d9b26af998ad2dc688586868966f732f88
|
|
ours
am: f38945fef1 -s ours
Change-Id: I4def28d0b17583d36ebdae00e43bd6a166e0e1e0
|
|
am: 723478fca1 -s ours
Change-Id: Id06a04c25fbf31933d75c2d2f3761f54be0fe82e
|
|
am: 9e6e7043bf -s ours
Change-Id: Iacbb8549996d3135feffcd845d5c81bdaa435641
|
|
Merge pie-platform-release (PPRL.181205.001, history only) into master
Bug: 120502534
Change-Id: Ide8e527af362dda9cde7f0c24753f912c4b1050f
|
|
am: a68492948b
Change-Id: I60b69b89ed9d59016ecef00a0e702577b711cf7c
|
|
am: 2e0a80b8e8
Change-Id: I004e9d972d2a6048130f59ce62470c69c94e219f
|
|
am: 6bf2e1b8f2
Change-Id: I3a805067939fb91476c58541b7465e35705a9906
|
|
max_msd + r could overflow. Don't believe the original comment.
Also fixed a couple of unused variable warnings discovered in the
process.
Test: Ran provided tests on Android device, and ran various
calculator-related tests.
Change-Id: I7de61a894267a80cbf3b561616fd8504afc247df
|
|
Change-Id: Ifbe967b66de58bc4099139d65548e5af6d29e651
|
|
am: 4383b03a02
Change-Id: Id3ef8a677400eb05580cca238ea6eb1da10d78b5
|
|
am: 41a06cabfc
Change-Id: I365ff8da49e5543bc8f1f99b556d0e57217d3aa6
|
|
am: 5ee5a59192
Change-Id: I46a83d0fb874a51d29a123b82350b9de2e955406
|
|
Bug: 71686706
This one actually fixes the above issue in AOSP.
Without this, sqrt() tended to force evaluation of the argument
to twice the the requested precision, which clearly didn't scale.
For some reason, that didn't seem to be reproducible for all
calculator versions.
Test: Calculator tests + CR tests
Change-Id: I2cc0053f5e27d5d0364c707fe580aa246bbf99d0
|
|
Change-Id: Ieb4932390bd149aeb074063509768d942bdd1f4c
|
|
8d8c9f82a4
am: dd41fd08d7
Change-Id: Ie5fade5ea1555362d2db51eb281a89fdccd911af
|
|
am: 8d8c9f82a4
Change-Id: I8588cbb390482bbcd7065003ce54b7f41e28469c
|
|
am: 568c8e610b
Change-Id: I10293a6dd97fa86e7a7a7cabe3c763e821448eb3
|
|
Bug: 71686706
Always set appr_valid when we set the approximation. The sqrt_CR
constructor used by the pi computation failed to do that.
Have square root evaluate the argument to full precision before
the recursion. That way we evaluate the argument only once and compute
the lesser approximations via simple shifts.
Fix the comment summarizing the Newton iteration computation.
Rename max_prec_needed, since the name confused me while trying to
understand this code again.
Test: Calculator tests + CR tests
Change-Id: I6d704f24579bae5a5edb4c42487acf1be8fdcee6
|
|
Change-Id: I2e769546c2a2c0fc2d3b1bc5d97640e09ca3b079
|
|
am: 0c9acfc0d1
am: c0ef89f21b
Change-Id: I6943aaed41937d6226347d40e3379da1f1cc0125
|
|
am: 0c9acfc0d1
Change-Id: I0f2d9fe2bd643603704084a40b108b6764a84e3a
|
|
am: 56d4e91360
Change-Id: I6215c90f65b1fb8d21161c5be340b83013d90046
|
|
|
|
Bug: 69318061
Test: Treehugger only.
Change-Id: I298adaa6104cd0255892b14ba10cfccbf6e2bef1
|
|
Change-Id: Ifbe05756db91c390921721f1fc780c1572278ffe
|
|
am: 8679561520
am: 6bb26c5c61
Change-Id: I73a674001589c8dc539c89e6e55d1e7f947669e4
|
|
am: 8679561520
Change-Id: I98c998c14e4d85208bef56b9da84b65777445519
|
|
am: a6692c0600
Change-Id: I4d75c1c2578450445c18080536fc708be9ed326b
|
|
Bug: 69318061
The former had bit-rotted a little, and was slightly inconsistent
with the information in the source files themselves.
The latter two are just copies of the former.
MODULE_LICENSE_APACHE2 is a slight oversimplification.
Test: Treehugger only.
Change-Id: I05237f34c41388f42606c87f280c554db5b34c12
|
|
Change-Id: Id1fd6878f86c8f2ddbdd72414d7cd8ee85e92c02
|
|
am: a26e89fbfa
Change-Id: I0343b546ded77fee85b15b0fa0992b7c367cb157
|
|
Change-Id: Ice53c32c4897dd033f286c26faf49aaa263bbd32
|
|
Change-Id: Id969e9b5d7bcf28a0346e95deae2ef9ec41b3477
|
|
Change-Id: I7d92c778617540fada101b6e852a6c432e97d559
|
|
am: 77576e6b59
Change-Id: Id56a3ef165ee7b365c6988f596b4e87c47e93442
|
|
am: 1cb39079c2
Change-Id: I63ede678c90485dab028681fca991817582f021b
|
|
am: 276a33a1b5
Change-Id: I9d4b9f92e680003f8f6938496e42a41066909295
|
|
Bug: 68670525
Unless we check for interrupts some comparisons will run forever
uninterruptibly.
If the client, for example, compares sqrt(11) - sqrt(11) to zero,
and then interrupts, it may still take quite a while for the interrupt
to be recognized, since each iteration of the compare loop can take
seconds. For the Android Calculator, this is usually not directly
visible, except that the compute thread will continue to use cpu
for several seconds.
Test: Ran Android calculator tests, manually exercised this case.
Change-Id: I0fe0922a8ee68bf0e08ce59c0d8c372ad10ef419
|
|
525 snap-temp-L60300000099762192
Change-Id: I1c26db5e7f1634de818fba3d7f02d2d470507de7
|
|
b1b34d2c8a
am: 181d62aea7
Change-Id: Id1d277a340a1049c805c1f0e74eeaafaeae52989
|
|
am: b1b34d2c8a
Change-Id: I0e00e8e29bd80ace7d459afa208ce56236c21296
|
|
am: dfed3c6d37
Change-Id: Ibb0cc667376d8b1971fc7247c15e1aa9905f1764
|
|
am: 533bb2355d
Change-Id: Ie98251343f7c7d9b00745371d5234b568c20a579
|
|
474 snap-temp-L95500000099150132
Change-Id: Ia5054f4fad0f712e936943b1ea324db9a37d3710
|
|
Bug: 64852569
Exp() on large negative arguments could be slow enough to make it
completely useless, as exposed by a new test.
Test: Ran external/crcalc tests.
Change-Id: Ibdbc0aff4c9854940b816751c052e469dd50d111
|
|
am: e35748b3c2
Change-Id: I8f7eb79825d3c68c22f84d3c8a1f6fe2e7c7f0ee
|
|
f37a3039bf
am: 5e665f4267
Change-Id: Id55a0fac5bf136de887d92b4ec879f39e0ff70c4
|