Talk:Calculate

From OLPC
Revision as of 16:07, 21 December 2007 by Leejc (talk | contribs) (Boolean operations: request NOT)
Jump to: navigation, search

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

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)

Implementation Discussion