Fix getShortString(), tune evaluation heuristics.
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
diff --git a/src/com/android/calculator2/CalculatorExpr.java b/src/com/android/calculator2/CalculatorExpr.java
index 6771b52..c5ad301 100644
--- a/src/com/android/calculator2/CalculatorExpr.java
+++ b/src/com/android/calculator2/CalculatorExpr.java
@@ -233,7 +233,7 @@
final BoundedRational mRatValue;
private final CalculatorExpr mExpr;
private final EvalContext mContext;
- private final String mShortRep;
+ private final String mShortRep; // Not internationalized.
PreEval(CR val, BoundedRational ratVal, CalculatorExpr expr,
EvalContext ec, String shortRep) {
mValue = val;
@@ -302,7 +302,7 @@
}
@Override
String toString(Context context) {
- return mShortRep;
+ return KeyMaps.translateResult(mShortRep);
}
@Override
TokenKind kind() { return TokenKind.PRE_EVAL; }