GitLab

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

Bug: 22481292

This could result in display of an old result.

Factor out code to start a result evaluation.

Change-Id: I651d4386323c0abd7a86176b386072093345a1b1

Bug: 21470972

Support pasting of numbers using scientific notation with 'E'.  This
is intentionally very restricted to dodge ambiguities with the
constant e.  We only accept a scientific notation constant if it is

1) Contained within a single pasted text element.
2) Uses capital 'E' to introduce the exponent.
3) Does not contain an explicit '+' in the exponent.

We do currently use the same notion of 'digit' as elsewhere, i.e.
Character.isDigit(), which might be too general.

For consistency, and to make sure that we can recognize machine
generated output, this also adds a few more aliases for text input
of arithmetic operators.

For consistency, always use 'E' internally for scientific notation as
well.

We ensure that a pasted numeric string is not concatenated with
a pre-existing constant.  This is a judgment call, but it means
that pasting a previous calculator result gets similar treatment
whether or not we are still running the same calculator instance.

We support limited editing on exponents.  Once an exponent is deleted,
the only way to restore it is via pasting.  The 10^x button
produces similar results, though with different operator precedence
behavior.

Change-Id: I2d0f3dceb641cdad327fd3c3540b5eea38030146

Bug: 21048155
Bug: 19189356

Incrementally announce additions to the formula.

Explicitly announce result after hitting equals.

Announce when display is cleared.

Remove old FIXME comment after a bit more testing.

Change-Id: I836ff6672de3f891888b2724470290c8721d4fcf

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

Bug: 22206007

Some languages contain oversized glyphs which may inadvertently be
clipped when displayed by AlignedTextView. The updated text sizes and
padding values should ensure that enough room is always reserved for
these glyphs (even when font scaling is set to HUGE).

Change-Id: Ic62df3104d033b1eafcf7d83f7e91d5329c8be70

Bug: 22208425

Most of the mathematical operators/symbols (e.g. "π") cannot be encoded
using "ISO-8859-1" however they still should be aligned using the
default capital letter height ("H").

Change-Id: I4ca6674de6e6a96b0ce513ecd8acea775f2e7081

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

Bug: 20650813

This preserves fraction and "with leading digits" displays during
rotation.

It also turns out to easily support copy, which is a useful bonus,
since it was an obvious hole in the UI for the fraction display.
For the "with leading digits" display, this is similar to a
plain display copy, but it allows character-level selection.

Much of the code here was cloned from Justin's.

Change-Id: I4805280fa6a46f06833be0bde9563c3ce04dca45

Bug: 246391

Only ignore trailing BINARY operators when computing instant results.
We used to be much more aggressive.

Also ignore trailing binary operators when the user hits "=".

This makes us consistent with the L design and ensures that instant
results don't turn into errors when the user hits "=".

Change-Id: I260e95d152168b70774330ac95d5bc567cf79b3d

Bug: 20667245

Update calculator code to reflect the fact that CR Errors have
become exceptions, and they are now delcared local to CR.

Change-Id: Ie9c9e10cef2f98a23856aa9e49328ae7ba52c9bc

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

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

Bug: 21756459
Change-Id: Id8889c8a1f7cda255de2eeebedfbdc1fad7634b1

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

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

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

Bug: 21921280

Also some general refactoring of CalculatorText.

Change-Id: If10f7329f1bfb4c2967c1c85f160efe6d3d1390c

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

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

Bug: 21623405
Bug: 21603293

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

Change-Id: I75da9fcfb076cf74d095d3abef5312571607f0fe

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

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

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

Bug: 21405924
Bug: 21529236
Bug: 21534231

This limits the display of trailing zeroes to the case in which
they avoid the need for scientic notation, and to the case of
results we did not identify as rational.  This means that you
can use scrolling as an indicator of whether there may be more
digits.

The old code exhibited some misbehavior around this, the most
serious of which was probably the second bug listed above.

This now uses scientific notation more aggressively for small
numbers (b/21534231).

This patch unfortunately needs to deal with many odd corner cases
to make sure that we stop scrolling at just the right point, before
the first trailing zero appears, even if there are exponents
involved.  I tested as many corner cases as I could think of.
And the testing exposed other preexisting bugs.
I do not know of a good way to avoid this without reverting
to the old scroll-through-trailing-zeroes behavior.

This significantly changes the behavior on e.g.

10^30 (Previously allowed scrolling to the decimal point, now is
unscrollable.)
10^-20 (Weird initial display with trailing zeroes; which could not
be reproduced after scrolling.)

It turns out that formatResult() scientific notation formatting
could accidentally extend the input result by 1 or 2 characters.
Based on my testing, the one character case was actually a feature:
Since there was a decimal point in the result the extra ellipsis
space seems to always give us plenty of room.  The two character
case whoever sometimes resulted in wrapping, and is fixed here.
The one character case is now official.  Ideally we should check
that we actually have enough space; currently I just assume a
single additional character.

Disallow scrolling left of the default position.  This seems
more consistent with TextView scrolling and eliminates some
crufty code.

Fixed an off-by-one error in getPreferredPrec, which resulted in
positive results that were one character too short.

Change-Id: I13657377d098055def99e7a173f71f40d361fe3c

Bug: 21706513
Change-Id: I4646cd1d9a2d67e6e8241ecbb5b960b440c458d2

Bug: 21688370
Change-Id: I59b05d038f261f40893a025824355b19b0a2b249

Bug: 21692303
Change-Id: I5db0e28a60e4daa40117fee899037ac198de859e