 |
TryIt: Using the following six steps, let's actually calculate some fractions:
|
Here's a more natural way to describe those five steps:
Put 22/4 into F1,
put 3/4 into F2, and
stay in F2.
|
↓ Continued from above Calculate by hand to predict the sum of 22/4 and 3/4. With F2 still the active fraction, confirm your result by
|
Step 6 added 22/4 to 3/4 and put the result 25/4 (right?) into F2. (If you had moved the cursor to F1 before tapping the '+' key, the result would have instead gone into F1.)
The screen should look like this:
Oops. That's an earlier version, with a name that got overtaken by a different App that got to the App Store before I did. Never mind, you can see the current version below or on your own iThing.
Notice that the current version gives the result, reminds you how it got it, and notes that the result is simply a pure fraction (it could have been a special value like Infinity, or something could have gone wrong due to limitations of exact arithmetic on iPhones—see the topic OVF later in this guide.
|
Try some nontrivial arithmetic: 1. Use M|P if necessary to display pure fractions. 2. Put 27,524 ⁄ 16,829 into F1, 3. put 91,722 ⁄ 106,386 into F2, 4. and tap '+' (add). Wow. Big numbers, eh? The sum is 745,292,967 ⁄ 298,394,999. 5. Tap '−' (subtract). Result is 15,287 ⁄ 17,731. Subtraction is the inverse of addition, so Step 5 should have restored the original F2. It did, but doesn't look like it. Why? Cancelled factors masked it, as you can see this way: 6. Put F2's original 91,722 ⁄ 106,386 into F1, 7. then tap ÷ (divide). There. The original F2 divided by the present F2 is one, showing that they were indeed were indeed the same number, just as we expected: Add, followed immediately by Subtract, did restore the original. |
|
Do some more nontrivial arithmetic: The operations × and ÷ are inverses just as + and − are inverses, so you can see action similar to the previous TryIt by starting with the same original fractions but using the other pair of inverse operators. |
Key idea:
ytap STO , tap d stores the active fraction to Register #d.
ytap RCL , tap d recalls Register #d to the active fraction,
where d' is any digit key from 0 through 9.
Note that digit 0 is special: See UNDO, in the following section.
 |
More Info: We'll just say things like STO 3 or RCL 6 from now on. The entire active fraction gets saved by STO or loaded by RCL. No note is made by STO about which of F1 or F2 was the original source of the stored fraction, and RCL doesn't care—it just copies Rd into whichever fraction is currently active. If, at STO time, the active fraction holds a decimal value then that's what gets stored and later recalled—including the indeterminate 0/0 stack. Frrraction F2 cannot hold a decimal value, so if it's the active fraction when a decimal is recalled, all it receives is the integer part of the decimal; while the F2 stack receives the indeterminate 0/0. |
|
TryIt on the non-trivial arithmetic of the preceding section: 1. Use M|P again, if necessary to display pure fractions. 2. Put 27,524 ⁄ 16,829 into F1, then do STO 1. 3. Put 91,722 ⁄ 106,386 into F2, then do STO 2. 4. Now tap '+' (add). So far, it's exactly like before. 5. Tap '−' (subtract). The result is 15,287 ⁄ 17,731. As it did before, Step 5 restored the original F2, but it's not obvious. You can confirm it easier than last time, though: 6. Tap F1 then do RCL 2 to put the original of F2 into F1 (a lot easier than re-entering all those digits) 7. then (with F1 still active) use ÷ (divide). The quotient is again one, of course: '+' (add) and '−' (subtract) are inverse operations, just as × (multiply) and ÷ (divide) are inverse operations. |
When Frrraction starts a new session, the storage registers R1 through R9 all initially contain Zero 0 + 0/1, which remains in each until-or-unless you store something different. R0 changes all the time, of course, staying ready for its UNDO role (see next Section).
Frrraction provides the yellow ONE command as a quick way to put 1/1 or 1 + 0/1 into a fraction. I generally leave register R9 unused unless a calculation absolutely needs me to use all nine registers. This preserves RCL 9 as a stand-in for Frrraction's missing ZERO command. That's easy to remember, because ONE (for 1) and 9 (for 0) are on the same button.
Key idea:
RCL 0 recalls the most-recently changed fraction.
UNDO restores the active fraction's previous value.
|
Do this TryIt after Step 7 of the previous TryIt when F1 contains 1/1 and F2 contains 15,287/17,731 and F1 is active. 8. With one eye on F1, do RCL 0. See what happened to F1? Frrraction's UNDO gesture restored the value F1 had before the most recent operation (the divide that surprisingly produced the quotient 1/1). The UNDO can itself be "undone": Do RCL 0 again and 1/1 reappears in F1. Do RCL 0 one last time and 91,722/106,386 is back in F1. |
Briefly:
ytap EDIT or use a swipe-right touch-gesture to open the frrrNotes editor.
Use the keyboard to type your notes,
drag the cursor by touch, and
use the cursor arrow-keys for fine adjustment of its position.
tap the Return-to-Frrr key (where ÷/FILE usually is) to resume the active fraction.
|
Details: As you've seen, the lower left quadrant of Frrraction's screen is used by the HINT gesture to give brief descriptions of the yellow functions and for Comments about ongoing operations. That same area is also used for the more persistent information we call frrrNotes. You can create and modify frrrNotes by using the yellow EDIT function or a right-swipe touch gesture. yTapping EDIT or performing a right-swipe gesture in the Notes quadrant brings up the iThing keypad and editor, a facility you're familiar with from using standard Apple apps like Notes and Mail: Marking the text-entry point in frrrNotes there's a blinking cursor that can be dragged around within the text by touch; the familiar Select-Select All-Cut-Copy-Paste functionality; a keyboard that can do ABC alphabetic, 123 numeric, and #+= symbol entry; and Frrraction adds left- and right-cursor keys that move the cursor one character per tap, for fine adjustment of the cursor position. Use the Return-to-Frrr key to close the editor and return to normal Frrraction operation. The normal Hints/Comments/Notes area is visually the same height as the editing area, but you can scroll the editing area up and down. This means that part of the end portion of a note may not be visible until you enter the editor and scroll down to it. Frrraction only changes frrrNotes when and how you tell it to. Hints and Comments only briefly cover them up, and they reappear as soon as you move on to the next operation. |
 |
Background: When you use the editor's Select and Copy commands, a copy of the selected portion goes into the system's paste-buffer; from there it can be Pasted wherever you want — somewhere else in the same frrrNote or into another app entirely after you close Frrraction, such as an eMail or a note in Apple's Note app for example. |
In brief:
Plant a file command in frrrNotes.
ytap FILE to execute the file command.
Frrraction's file system can create named files that store all the essentials about the current status of the work you're doing: F1, F2, R1-R9, and frrrNotes. It can display a list showing the first line of frrrNotes of some of the files. It can later restore a complete filed status by filename. And it can delete a file when you no longer need it.
|
Details: Filenames can be any that Apple computers can use, but files whose names are simple integers have an advantage: At the tap of the Files button in the frrrNotes editor, the file system can list the first line of the frrrNote in seven consecutive integer-named files. This is a great help when you're trying to remember what you stored where. The file system gets its cues about your intentions by looking in the current frrrNote for the presence of a file command:
|
|
Background: The files are stored on your iThing in a special area reserved for Frrraction. They get saved on your main computer when you Sync with iTunes, and will be restored if you do the iTunes Restore operation. They are not readily accessible by your computer's Finder. |
|
Do this TryIt after Step 8 of the previous TryIt when F1 contains 91,722/106,386 and F2 contains 15,287/17,731 and F1 is active. 9. ytap GCD. See what happened to F1? It changed from 91,722/106,386 into 15,287/17,731, and Frrraction's Comment is "GCD(F1num,F1den) was 6, Now it is 1." This means that the numerator and denominator of F1 were both divisible by 6, which was then removed and cancelled. |
As the hint by Y Y GCD will remind, GCD (Greatest Common Divisor) uses the common divisor to reduce the stack to lowest form (by canceling the common divisor from Fnum and Fden). GCD also shows the common divisor for the active fraction, and displays the decimal value of both fractions in their respective F1flt and F2flt cells.
|
Background of RDC: There are infinitely many fractions that can exactly represent any given number. If you start with any one of them and multiply its numerator and denominator by some nonzero integer, you generate another of them. For example, 1/3 and (1/3)x(5/5) = 5/15 represent the same number. Among this plethora of ways to express the same numeric value, the reduced form is unique, uses the smallest integers, and is thus something of a universal standard. After all, there is surely universal agreement about which of 359,161/65,302 or 11/2 is the simpler way to represent the same number. RDC will always find the simpler form of a stack. |
|
Background of GCD: Fortunately there is an ancient and spiffy method called Euclid's Algorithm for calculating the GCD—way, way easier than finding all the divisors. For many of you it would be worth your time to give it a Google. Once you have the GCD, it's a simple matter to divide that into the numerator and again into the denominator, replacing each by the quotient. The above GCD writeup may be a bit stuffy but, for good understanding, the notion is important. RDC is a friend. Frrraction uses it frequently during its internal operations to help keep all the fraction parts small enough to work with. A decent web reference is: http://en.wikipedia.org/wiki/Greatest_common_divisor |
|
A wiki mistake: (This is about a misfire I spotted in the Wiki linked above. It mentions a nonexistent thing that it called "Greatest Common Denominator". That is nonsense because, while there is surely an LCD or "Least Common Denominator" and a GCD or "Greatest Common Divisor", there is no such thing as a "Greatest Common Denominator". If 10 is a common denominator for 1/2 and 2/5 that means we can express those two fractions over the shared or "common" denominator 10, the way 5/10 and 4/10 share 10. But we can do exactly the same with any integer multiple of 10, say 3x10: 1/2 and 2/5 can equally well be expressed as 15/30 and 12/30. So where's the "Greatest"? Other than that, it's a good reference.) |
|
Proper form cannot always be reached: The closest thing to a proper mixed display of the pathological number nMAX over -1 might be pMAX + 1/1 which is almost but not quite proper (the numerator is the same size as the denominator, not smaller). At the core of that oddity, nMAX is itself pathological: If you tell an iThing to (a) multiply nMAX by -1, or (b) do the CHS "change sign" operation on nMAX, or (c) subtract nMAX from 0: iThing's answer is always obstinately the still negative nMAX. But if you tell an iThing to divide nMAX by minus 1? The App that tells it to do that is subjected to the most drastic punishment known in AppWorld: It is immediately shut down and its users find themselves back at the Home screen! Frrraction carefully avoids making that faux pas. All modern computers are subject to such an nMAX foible because it's a consequence of the way they represent numbers: 2's complement. Essentially, a single bit-pattern tries to do the work of three: nMAX is also minus nMAX and it tries also to be 1+pMAX. |
|
TryIt: put pMAX into F1, and 1 into F2 ( ytapping ONE is a quick way to get the one), then tap '+' to see 1 + pMAX in F2. The result is nMAX. Next, put nMAX into F1 and ytap CHS. No change: nMAX is its own negative! While we've got nMAX in F1 and 1+pMAX in F2, tap '+' and what do you get? Sure enough, nMAX plus1+pMAX is 0, so they are indeed each other's negative! Also nMax and nMax add to zero, so nMax is its own negative. Peculiar, very peculiar. And wrong everywhere except in computerland. With nMAX still in F1, put -1 into F2 (ONE,CHS), then multiply to form ‑1 times nMAX in F2. It's nMAX all over again! That's another way to see that the computer considers nMAX to be its own negative. One 32-bit-long bitcode, three numeric values. |
|
nMAX is its own Grandpaw: Technically, overflow (OVF) is the culprit behind this strangeness. Going to wider numbers (computers that naturally handle more digits) only pushes the issue back a bit (pardon the pun). For instance: In a 64-bit computer, nMAX is around -9 followed by 18 zeros instead of being about -2 followed by 9 zeros—but other than that it's just like our little iThing's nMAX. This leads nicely into the next topic: Arithmetic overflow. |
Mixed fractions can hold any number that pure fractions can, but the reverse is not true.
|
Try this eye-opener:
Set the fractions as follows: Put 1 into F1int and F1den, and use MAX to put pMAX into F1num; then put 1 into F2int and F2den and ytap MAX again to get nMAX into F2num. (MAX is an unusual yellow function, as it alternates between pMAX (the largest positive number that iThings can handle—see it in the numerator of F1 in the screenshot Fig. OVF1) and see nMAX (the largest negative number that iThings can handle) as F2's numerator in the screenshot. |
|
TryIt, continued from above: Now ytap M|P in an attempt to purify both fractions. Fig. OVF2 shows the outcome. |
Why did Frrraction have trouble purifying F1 but not F2? The problem with F1 is that the pure form would need to be 1 + pMAX which is one larger than the largest iPhone integer. The mixed combination of Integer + Stack can hold larger numbers than Integer alone or Stack alone. (In fact the largest either form can hold by itself is nMAX.) Purifying F2 worked because it made F2num be 1 + nMAX, which is smaller than nMAX, i.e. it is within the range from nMax to pMAX.
|
Computing can be planned: Sometimes in the course of exact computation, as in the above example, numbers are encountered beyond the size that can be handled by the system. That can occur even if the final result is itself within range. Sometimes, with better planning, OVF in such cases can be avoided. For example, consider multiplying pMAX/500 times 1000/pMAX. An attempt to use the usual approach — first multiplying numerator times numerator then multiplying denominator times denominator — will fail: pMAX times 1000 is clearly out of range. So is 500 times pMAX. But if you first reduce pMAX/pMAX to get 1/1, and 1000/500 to get 2/1, then no overflow occurs and the product is 2/1. Frrraction knows about this, and often gets it right. Of course, overflow is not always avoidable. When the result being sought is actually out of range, as in F1 in Fig. OVF2, it's just a fact. |