DragginMath: Integers Only

By design, DragginMath only does integer arithmetic. The complications of radix fractions, whether decimal or binary or any other base, are too great to deal with here. This is a surprise to many people, as arithmetic with decimal fractions is usually taught in elementary school. But it is better to say this kind of arithmetic is introduced in elementary school, to be taken up again only in upper-division college courses that are unpopular even among math majors. Beyond what you learned in fifth grade, the learning curve is gruesome and steep, and algebraic results readily tread in that territory. Beginning algebra students already have enough to think about, so let’s not go there.

Furthermore, students all too often want to equate an impressively long string of digits with the idea of an accurate result, and we cannot allow them to do that. They must understand why representations such as 4๐›‘รท3 or โˆš2รท2 are good results in algebra. In those rare instances where one might want to know a numeric equivalent, use a calculator. This is not what DragginMath is for.

Internally, DragginMath works with 64-bit signed integers, with range a little less than ยฑ1019. These are big numbers, but they are nowhere near infinite. If an arithmetic result is finite but greater than this range, DragginMath returns the expression you asked it to evaluate. For example, double-tapping โ†‘ in 10โ†‘18 returns 1000000000000000000, but the result of 10โ†‘19 is 10โ†‘19. It is up to you to recognize what DragginMath has told you here. No information has been lost, but the app is unable to transform the expression into an integer result.

DragginMath evaluates division, roots, and logarithms by factoring the operands, then grouping and canceling common factors. Results are presented on that basis. For example, evaluating โˆš50 does not give 7.07106… here. Instead, DragginMath gives the proper algebraic result: 5โˆ—โˆš2.

Factoring large numbers is no easier for a computer than it is for you: it must go through the same process. To do this factor-based arithmetic efficiently, DragginMath maintains a factorization cache. Instead of factoring operands for each evaluation, factors are computed only when a number has not been factored before. Then the result of this factorization is remembered for the next time it is needed. So if you cold-start DragginMath, then evaluate 10โ†‘8รท5, you may be aware of a short delay in obtaining the result the first time, but the same evaluation thereafter is instantaneous.

A factorization cache can easily become quite large, perhaps larger than the memory available on your device. There are different ways a software designer might handle this problem, none of them pleasant. To maximize performance for problems you are actually likely to encounter, DragginMath takes a risky approach: if you need the factorization of a number that makes the factorization cache too large, the app will die suddenly and without warning. This is not what we might wish for, but it is nevertheless intentional. It is a risk, not a bug. The alternative design choices would probably annoy you much more than this one will. If you set out to crash DragginMath this way, you will easily succeed. But if you limit yourself to problems presented by typical math books, or by life, you will probably never see this issue in practice.

How large is too large? On our unremarkable test machines, the cache crash happens when performing a division, root, or log operation on numbers greater than somewhere between 108 and 109. Your results may differ.

How do you recover from a cache crash? Just start DragginMath again. Yes, some of your work will be lost. Yes, if you try to do the same evaluation again, you will have the same result. Yes, we do think about this issue from time to time, hoping for a better solution. No, we haven’t found one yet.