Talk:Calculate

From OLPC
Revision as of 18:27, 6 December 2007 by 137.22.11.200 (talk) (Feature Requests)
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

Implementation Discussion