Talk:Calculate
Feature Requests
RPN mode needed for scientific calculations.--Mokurai 22:01, 19 May 2007 (EDT) (not sure whether this still applies to the new version Rwh 10:27, 15 July 2007 (EDT))
I suggest that a better solution would be to allow multistep calculations with saved 'variables'. This can do everything that RPN enables, but is easier to teach to children, closer to the global standard language of mathematics, and it leads directly to programming as a logical outgrowth of multistep calculations.
Integrate material from and link to Derivations of Applied Mathematics. -- Jpritikin 07:52, 9 September 2007 (EDT)
6 December 2007
The essential operational model (user interface) underlying RPN is an implicit stack with postfix operator application. Both of these conceptual models much more closely resemble typical programming paradigms in actual use, both at the machine level and higher levels of abstraction, than simplistic multistep variable saving scripts, which remind me of infantile "languages" like Basic or Cobol or similar such.
Keeping in mind that the goal is to provide a useful numerical tool for children, and bearing in mind that children, contrary to historical habit, are not imbeciles who need to be coddled, but rather intelligent conscious beings who simply have an unprejudiced blank slate to be filled, would it not be better to devise a calculator which fills that blank slate with the very best the world has to offer, in an intuitive compelling manner, and avoids dumping the same old trash that most of us have had to endure, sift through, and ultimately jettison?
With that in mind, and remembering that the physical limitations of commodity calculators are not in play, but rather a high resolution display with multiple megabytes of memory are at our disposal, I make the following suggestions:
1) Separate the keypad, display, and mode selection function keys into three separate windows which may be independently positioned (or hidden), and opened in multiple instances.
2) By all means, have a rudimentary operating mode suitable for the very youngest of children where the keypad displays only ten digits and four functions with the ancillary keys necessary to formulate an infix operator paradigm using a single display.
3) Provide a mode selection key to convert the key pad into optional prefix and postfix operator paradigms, after all, the goal is education and enlightenment, not sheltering, confining, and hiding the great diversity of truth.
4) When I work with typical calculator programs, I typically use three of four instances of the program to compute along three or four threads, and then cut and paste to merge the calculations in a fourth (or fifth) instance of the program. The point here is the singleton memory of typical calculator programs is inadequate for complex calculations, and the cheat I use quickly clutters the screen, apart from being inefficient, although it does obviate the need to use pencil and paper as an auxiliary memory.
With a separate display window, one need not replicate the keypad and mode keys. By including a mode key to create a new display, and by connecting a particular display to the keypad by clicking on it and highlighting the display, the cheat I use can be much more efficiently and elegantly implemented. As for memory, the stack paradigm can be intuitively and graphically mimicked and extended by imagining the display to be a single numeric window on a virtual "paper tape" connected in a loop under the window (a circular buffer implemented by a dynamic doubly linked list in programmer parlance). By putting a toggle widget on the side of the display, the window can be moved backward and forward to navigate previous intermediate results on the "tape". Better still, show one or two of those other results grayed out above and below the window. The keypad intuitively obviously only operates on the contents of the current window, and a visual model of stack, queue, and buffer operations is intuitively made available. In postfix mode (RPN) the value above the window can be colored instead of shaded, indicating it can also be operated upon, as well as eliminating the need to remember what the "entered" (stack) values are.
Beyond the intuitive appeal, the "paper tape" paradigm eliminates the need to define, name, and remember variables, making the whole interface easier to use for complex computations.
5) Finally, the same paper tape paradigm can be used in a keystroke window, which logs keystrokes, so that a complex calculation may be rerun with different data, once the first sequence is worked out.
6) Needless to say, there should be mode keys to expand the keypad for various more specialized computations, e.g. scientific, hexadecimal, statistical, complex numbers, or even quaternions, octonions, or vector operations.
Obviously all this can't be done in the first cut, but by using multiple windows to start with, a modular design paradigm is established which can easily accommodate future directions that none of us now can even imagine. Moreover, the design paradigm is intrinsically conceptually hierarchical, so a child can work at his or her own level, but always have the opportunity to grow and learn, and perhaps ultimately even customize the calculator for his or her own purposes.
To conclude, my main point here is to please, please avoid patronizing children. They are imaginative, extremely capable beings, and they will mirror whatever you show them. Give them mediocrity and that is what they will give in return, give them your best, and they will take that places no stodgy adult could ever imagine.
6 December 2007
- This is my own feelings about the above:
- RPN: my first exposure to RPN was in 1975-6 when the first HP pocket calculator appeared with it. It is okay for us engineers, but my wife hates it. It's totally natural for the technologist and absolutely not the way folks write equations. I believe that the TI graphing pocket calculators you see in classrooms (that my kids used, as a matter of fact) enter formulas the "normal" way.
- Graphing activity: What you do want is a graphing function, so the kids can learn about X-Y coordinates
- Spreadsheet activity: I'm not a developer. But I've been doing a lot of writing for wikipedia (see next post, too). I would suggest the simple "pocket calculator", but also a spreadsheet using relations/functions as well as typical non-RPN, somewhat akin to Excel. Apparently a simple spreadsheet is an activity to be designed for the future. I strongly encourage this. Most kids (e.g. my own and my nephews etc etc) in our schools by 7th grade if not earlier have encountered simple spreadsheet work.
- Request to change "square" to "exponent" or add a new exponent function : i.e. 3^3 = 27 rather than "square" causing 3^2 and the kid having to change the "2" to "3". (I had to discover that 3^3 would indeed evaluate correctly). I do understand that simple work around the Pythagorean theorem etc uses ^2 so there is an advantage to having a separate function "square".
- What's going on with the "Label" in the "algebra" function?: I don't see how this works, yet. I entered "x=3" in the "label" box, and 3+x into where the formula appears to go. It returns this into the box:
- x=3: 3+x Error at 2: Variable 'x' not defined.
- My guess all of this will evolve/resolve as developers set their minds to it. But perhaps some feedback such as this will be useful. Bill Wvbailey 17:21, 21 December 2007 (EST)
Boolean operations: request NOT
(3) I have some suggestions for the activity's functionality, but am not sure they should be here. I will enter them here anyway. The philosophy behind this is to provide the kids with the same symbolism and functionality that they will find on wikipedia.
(3a) The symbol | (stroke): Why use the "Sheffer stroke" for OR? this symbol was classically used for NAND (NOT AND). Why not use V for "von", the more classical symbol? I've never seen | used for OR.
(3b) Logical NOT: I was rather ... stunned shall we say ... to see XOR rather than NOT (i.e. ~ or "bent bar" 2-shift-alt, or whatever). XOR would be an okay addition but not without NOT; NOT is virtually mandatory. I am quite aware that the three functions chosen (AND, OR, XOR) are sufficient, but hey, so is NAND (stroke) by itself or NOR by itself or implication by itself -- and using them by themselves is ugly.
(3c) What happens when we plug in numbers not { 0, 1 }? The numerical results such as 3&4 => 4, and 3|4 => 3 are rather peculiar; they seem reversed (from a Venn-diagram point-of-view). For example, as "4" contains "3" we would expect that 3|4 might be "4". I will pursue this with my wikipedia cohorts to get their opinions. Usually Boolean functions have to do with predicates in particular "equality" that evaluate to { TRUE, FALSE } or values { 1, 0 }, e.g. =AND(3,4) yields TRUE in Excel.
Bill Wvbailey 14:19, 21 December 2007 (EST)
- I'm not sure about the other issues, but I assume the reason they chose the vertical bar for "or" is that a single vertical bar is traditionally used as the (binary, not logical!) "or" operator in a number of computer languages (C/C++, Java, and Python, among others). Using a keyboard symbol rather than a letter or more complex symbol has the advantage that it can be easily entered into formulas without being confused for variable names (e.g. "V"). —Joe 15:07, 21 December 2007 (EST)
- The "and" and "or" operators seem to be using the Python short-circuiting interpretation for logical operators, which I agree makes little sense in a calculator application. If the first operand of an "or" operator is true (i.e. non-zero), then the value of the expression is the value of the first operand, otherwise it is the second. Likewise, if the first operand of an "and" operator is false, then the value of the expression is the value of the second operand, otherwise it is the first. This means that "3|4" will not give the same value as "4|3", for instance. The behavior gives the expected result when using zero and one, but I agree it is confusing with other values. (I note the activity also interprets "True" and "False" as variables rather than boolean values...) —Joe 21:23, 21 December 2007 (EST)
Here is my wikipedia correspondent's take on the above:
- The output when the inputs aren't 0 or 1 do seem strange, but somehow I have become accustomed to software implementations using strange notation and conventions. Including NOT would certainly be a good idea. — Carl (User:CBM|CBM · User talk:CBM|talk) 23:35, 21 December 2007 (UTC)
Bill Wvbailey 10:28, 22 December 2007 (EST)