GitLab

* commit '79ffb522':
  Improve logic for evaluation/animation interruption

* commit '15a853dd':
  Restore original scroll position on =

Bug: 22041219

Restore default scrolling position when hitting enter after scrolling
an instant display result.

We could instead preserve the position and fix the display logic to
no longer get confused by a non-default initial position.  But this
feels more natural to me.

Change-Id: I43bb936b5bb1b5af7a7befb90fdfc0f745fb7729

Bug: 21471857
Bug: 20819212

End rather than cancel() in-progress animation in the event of user
interaction.

Discard input that interrupted a computation only for delete,
and clear, where it seems to make sense.

Use similar interruption logic for physical keyboard input as for
touch.

Make integer exponentiation more interruptible.  This remains
imperfect; the latencies in a single BigInteger multiplication
can be high. Filed b/21957088 to track that.

Clear "instant" result before launching reevaluation.  Otherwise the
example from b/21957088 shows incorrect instant results for an
uncomfortably long time as it's being entered.

Correct some of the state maintenance operations in Calculator.java.
The ANIMATE state was not being used correctly.

Remove redundant cancelAll() and onCancelled() calls.

Add an option to cancel without a message.  Use it for clear.

Change-Id: Ibab90dca0cb894e7985642f212ff41030f2fc52d

* commit '6e8087f4':
  Correct off-by-1 errors in display formatting code.

Bug: 21986868
Bug: 21960281

Fix and restructure the formatting and scroll-limit-calculation
code.  This code is inherently tricky, and has had more bugs than
we would like to admit to.  Use the opportunity to clean up the
code a bit, renaming variables consistently.

The good news is that the code seems to be getting slightly
simpler with each bug fix.

This fixes several separate off-by-one errors related to result
formatting:

The expLen() exponent string length calculation was off by 1
for exact powers of 10.

The dropDigits calculation in the formatting code was off for
negative exponents just shorter than an exact power of 10.

The exponent space calculation for a few results like -1.2*10^-8
was off by one.

For a result like -10^-500 we did not reserve space for the leading
minus sign, since that's not computed until after scrolling.

[Less serious] The ellipses were omitted when we had just barely
scrolled a leading minus sign off the screen.  (This only occurred
in exactly one position, which could never be the default one.)

Change-Id: If1bfbbb70a624998be3d996592d129b16aade745

* commit '8b1efdb8':
  Persist radian/degree mode

Bug: 21756459
Change-Id: Id8889c8a1f7cda255de2eeebedfbdc1fad7634b1

* commit '7917a53c':
  Import translations. DO NOT MERGE

Change-Id: I056e6fc7b94b012c201482599fb72049fb5684b3
Auto-generated-cl: translation import

* commit 'aafeaa04':
  Fix "with leading digits" display.

* commit '7f83e36b':
  Improve copy/paste menu appearance

Bug: 20503008

Correctly provide content position information to the ActionMode so
that menues can be better positioned.

Highlight a result that's about to be copied.

Ensure that the end of the current formula becomes visible when
the paste menu appears.

Change-Id: I318985776e59175b827d5089c0ca4978f3a658cb

Bug: 21759654

Previously the number of displayed digits didn't quite match the
number of digits in the normal display, and results with positive
exponents always came out as inexact.  This fixes both.

Remove an obsolete FIXME comment.

Change-Id: I9aa0217d7804218c54fe929e59dfbc6bbf880db7

* commit '017de989':
  Rework the key insertion logic

Bug: 21495243

This changes the behavior to be much more compatible with L.

We generally do not allow consecutive binary operators to be inserted.
In the case of a minus operator however, the logic is more complicated.
We do allow a minus after multiplication, division and power.
When the minus is explicitly entered, so the user sees our corrections,
we do not allow a minus after additive operators.  In pasted text,
we do.

We no longer reject additions that would result in implicit
multiplications.  We do immediately reject binary operators in leading
contexts, e.g. after a left parenthesis, in which they must result in
a syntax error.

Change-Id: I1d35d74335371f6f113808d68a4f293b699d9bd0

* commit '3af9fdfc':
  Remove clickable flag from formula TextView

Bug: 21921280

Also some general refactoring of CalculatorText.

Change-Id: If10f7329f1bfb4c2967c1c85f160efe6d3d1390c

* commit '05252499':
  Fix digitsRequired() for negative denominators

* commit 'fb8a6542':
  Import translations. DO NOT MERGE

Change-Id: Ic085325ca1a9d961fd0523413fb32809bd1f06ed
Auto-generated-cl: translation import

* commit '640a0c95':
  Import translations. DO NOT MERGE

Change-Id: I8cc3950cd7b93664d23929ec37a46c592f4dd6fe
Auto-generated-cl: translation import

Bug: 21789679

Also adds some tests for digitsRequired(), including one that fails
without this CL.

Change-Id: Ib007e753f90c019c37666d71c1cfd02301dcd360

* commit 'b3f7278a':
  Update comments for shortcut button content descriptions

Bug: 21623405
Bug: 21603293

Make comments more descriptive for transalation.  The attached bugs
requested this for "10 to the power of".

Change-Id: I75da9fcfb076cf74d095d3abef5312571607f0fe

* commit 'd4de959b':
  Import translations. DO NOT MERGE

Change-Id: I31ef49f951ba3ec9e4ebb048962fca8aa9394377
Auto-generated-cl: translation import

* commit '187d3e93':
  Improve logic for when to display instant result

Bug: 21497671

Fix mChangedValue handling, so that it is only reset after an actual
evaluation, and is set when an expression is "collapsed".

Consistently produce instant results for solitary pre-evaluated
expressions if and only if they involve an abbreviation.

Change-Id: I4e1f824e2353cbe78b1827f3930c72666832cff4

* commit '7c07c19e':
  Show "INV" button's selected state

* commit '50ed320c':
  Fix getShortString(), tune evaluation heuristics.

Bug: 21708864
Change-Id: I837c7b768461ab065093c6ef6fbf0dec3acd1c2d

Bug: 21474616

Rewrite getShortString() to also look at the least significant digit
information when available, and try to mimic the display formatting
code wherever appropriate.  As a result, when the user hits "=",
followed by "+" transitions are now more frequently smooth.

Revise the evaluation heuristics so the we are more aggressive
with the initial evaluation precision, and try harder to discover
the leading digit in a near-zero number.  Some of this is necessary
to keep getShortString() happy.  This version should also now
guarantee that we are never worse than double precision floating
pointing in displaying very small nonzero numbers.  If we display
a number as zero, the old calculator would have, too.  (And now
you can scroll to see whether it really is.)

Up the BoundedRational bit limit to improve the chances of identifying
exact results.

In general, the incremental computation cost for operating on
larger BigIntegers appears relatively low, so it makes sense to
trade longer computations for fewer calls.

Change-Id: I33066845b832753c109fcaf27f883b48e7e119d2