 |
TryIt: Using the following seven steps, let's set up a calculation with some actual fractions. In the mixed fraction mode of Main view:
|
Here's a more natural way to describe the above six steps:
Clear both fields, put 22/4 into F1, put 3/10 into F2, and stay in F2.
|
↓ Continued from above Calculate by hand to predict the sum of 22/4 and 3/10. With F2 still the active fraction, confirm your result by
|
Step 7 added 22/4 to 3/10 and put the result 5+4/5 (right?) into F2. (If you had moved the cursor to F1 before tapping the '+' key, the result would have instead gone into F1.) (If Main view had been in pure fraction mode instead of mixed fraction mode, the sum would have been presented as 29/5.)
The screen should look like this:
Oops. That's a different example on an archaic version of Frrraction whose name got overtaken by a different App that got to the App Store before Frrraction did. Never mind, you can see the current version below or on your own iThing.
Notice that the current version gives the result, maintains a ticker to remind you how it got it, and notes that the decimal value of the result is 5.8000000 (with other data it could have noted 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|R if necessary to display pure (not mixed) fractions. 2. Put 27,524 ⁄ 16,829 into F1, 3. put 91,722 ⁄ 106,386 into F2, 4. and tap '+' (add). 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) and you'll get one—or tap '−' and you'll get zero. There. Both approaches in Step 7 show that the original F2 and the result F2 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—but save yourself some nuisance by using STO and RCL this time. |
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 R#d into whichever fraction is active at RCL-time. |
|
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 B|O|Z (Blank|One|Zero) command as a quick way to put B = 0+0/0 or O = 0+1/1 or 1+0/1 or Z = 0+0/1 into a fraction.
The B|O|Z button works greenly, so to put Blank you y-tap, for One you just tap after the initial y-tap, and for Zero you just tap twice after the initial y-tap.
When you tap or y-tap anything other than B|O|Z the green reverts to normal yellow operation.
Key idea:
RCL Undo recalls the most-recently changed fraction.
UNDO restores the active fraction's previous value.
|
Do this TryIt after doing 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, y-tap RCL then tap Undo. See what happened? When you y-tapped RCL, all the keys on the bottom row turned white, and the decimal-point key changed into the Undo key. Tapping any of the digit keys would have recalled the contents of that fraction-storage register like normal, but tapping Undo recalls the immediately previous contents of the last fraction that changed. The UNDO can itself be "undone": Do RCL Undo again and 1/1 reappears in F1. Do RCL Undo again and 91,722/106,386 is back in F1. Point of information: Undo works by maintaining an 'Undo Register'. That special register is really just Register number 0. Whenever the contents of a fraction are about to be changed, Frrraction automatically saves the original fraction into register 0. Caveat: You should only use storage registers 1 through 9 for normal memory operations, because Register 0 is constantly undergoing automatic change to keep the Undo current. You can, of course, use the command 'RCL 0' wherever you might use 'RCL Undo'. |
Briefly:
Y-tap PROG 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.
use the keys within the editing border when writing Frrraction-applets.
tap the MAIN key to resume activity in Frrraction's MAIN view where you left off.
|
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. That same area is also used for the more persistent information we call frrrNotes. You can create and modify frrrNotes by using the yellow PROG function or a right-swipe touch gesture. yTapping PROG 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: As usual, the text-entry point in frrrNotes is marked by 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 MAIN key to close the editor and return to normal Frrraction operation. Tapping MAIN resumes normal operation with one temporary difference:
The normal Hints/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 only briefly cover them up, and the frrrNote reappears as soon as you move on to your 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:
Create a file command using the filePicker in PROG view.
ytap the created command button to execute the 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. 9a. Watch hShow and ytap GCD . See what happened? The first line of hShow says "GCD(91722,106383) is 6." Also, the yellow GCD key has changed into a green RDC key; green means you can execute the reduce-function by tapping the key without first tapping yellowkey. 9b. Now watch F1 and tap RDC (without first tapping yellowkey). See what hapened? F1's stack changed from 91,722/106,386 into 15,287/17,731, and Frrraction's comment at the top of hShow 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. The greatest common divisor of F1n and F1d was cancelled. Also, the green RDC key changed to a green GCD key, so you could (redundantly) recompute the GCD without first tapping yellowkey. Tapping any fCell or white key will terminate the green operation. |
As the hint by Y Y GCD will remind, the green-pair GCD and RDC (Greatest Common Divisor and Reduce) uses the common divisor to reduce the stack to lowest form (by canceling the common divisor from Fnum and Fden). It also hShows the common divisor for the active fraction, and displays the decimal value of both fractions in their respective H1den and H2den cells.
|
More background of GCD and 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. GCD,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. GCD 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, the cited Wiki is 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 ‑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 (via computers that naturally handle more digits) only pushes the issue back a bit (pardon the pun). For instance: In a 64-bit computer, the decimal representation of 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. |