|Re: What is the smallest full trig calculator in production?|
Message #81 Posted by Bill Triplett on 29 Oct 2008, 8:24 p.m.,
in response to message #79 by DaveJ
Our old Millenium PC did not turn up the original sketches, yet, but that is not surprising. Years have passed, and that old machine has a fantastic array of files and folders. It would seem that the "delete" button on that machine still has all of the original paint.
I can probably draw the calculator again fairly simply from memory, if it comes to that. I will be busy for a few days first finishing a research project that is time sensitive.
I would be especially interested in seeing what people here would like to have included on the function key menu structure for the machine. I would like to keep the physical hardware to a style as described already, with just a horizontal row of numbered keys as function keys. I would like to change the leftmost label to [quit] instead of [esc] because the word "quit" has four letters like the [menu] button on the rightmost side of the function key row. This is what Adrian Monk would say, I know.
The row of buttons along the hinge would be as follows:
[quit] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 0 ] [menu]
There are dozens of possible ways to arrange the remaining keys, and placement is not as important for this unique system as the general idea of using buttons that only have one label on each button. The remaining keys under the topmost row of menu/number keys would only be alphabet keys, arrow keys, and a few simple buttons for typing arithmetic input in either RPN or algebraic notation, such as:
[ + ] [ - ] [ * ] [ / ] [ ( ] [ ) ] [enter] [backspace] [delete]
The up and down arrow keys can move up into a history area when in algebraic mode, or up into a stack when in RPN mode.
When editing characters on a command entry line, we could benefit from having a dedicated [highlight] button, along with a [control] button that would allow [cut] [copy] and [paste] to be performed as [control] followed by X or C or V. Most people are familiar with this convention for editing text, and it allows using fewer buttons than having dedicated cut copy and paste buttons. It also allows other keyboard shortcuts that a user can learn if desired as a way to jump quickly to some functions, instead of using the function key menu.
The [highlight] button could also signal uppercase for the alphabet button that is pressed next. If the [highlight] button is followed by a right or left arrow key, or held down while pressing the right or left arrow keys, the result will be dragging the selection of text characters.
By arranging the function key menus neatly, we will not need dedicated buttons for equality or inequality operators, or other logic and math symbols. It would be convenient to have each line of text input processed in the command entry line in such a way that it will not be necessary to have a separate [change sign] button, or two different kinds of [ - ] button. I can see how this can be easy to accomplish with formula entry, but it could be difficult to meet this requirement when using RPN stack entry. Everyone please think about this carefully, and remember that what works perfectly in the context of an already existing favorite calculator architecture might not be convenient to use with this simplified physical interface style. In any case, as a system requirement, I would like to have only one negative symbol on the keypad.
Let's give it a go, and see whether the interface can be kept simple and convenient to use while having only one type of negative symbol on the keypad. If no one can make this work simply for both RPN and algebraic input methods, then we might break down and add an extra negation button or a [change sign] button on the keypad. Give it careful thinking.
Try considering ways to place all other functions and symbols on the dynamic function key menu so that the function key menu would change labels depending upon which function key has been pressed immediately prior.
We can accomplish this last requirement with no thinking at all by using menus that spring up into vertical lists, and cover large areas of the display screen. In that case, a user would need to arrow up and down within various lists of menu options, or use the right arrow key to move into and expand submenu lists similar to how it is done with a PC. A more challenging, but visually simpler method would be to keep the menu structure only as a straight horizontal line of key labels that change dynamically. This second approach would require a great deal of abbreviating, and careful thinking in order to keep everything simple enough, but it can be done this way if it is considered carefully. This would result in a clean and simple looking user interface.
We can try thinking about a menu system using the pop up vertical scroll list method first, because it is easier to shovel in tons of functions, and get them organized into categories of like functions this way. Ideally, it would only be necessary to press an average of about three keys or less in a sequence in order to move through the menu levels and activate a function. Later, we can try the more challenging job of compacting the menu structure to fit into a one line horizontal set of function key labels that change dynamically. We can call this second approach the "compact" menu layout.
The HP-50g and similar machines allow a user to change between vertical menu lists and compact horizontal function key list method as a configurable mode option. This is such a beautiful idea that it should be kept, and built upon.
In any case, have fun brainstorming. I would like to start by suggesting that the first set of function key labels that appear after a user presses the [menu] button should be called the main menu, and the main menu should have a button called [trig]. When a user presses the [trig] button, the function key menu should change and produce a submenu of function keys that include these new button labels:
[hyp] [inverse] [sin] [cos] [tan]
In RPN mode these buttons should cause evaluation of X row of the stack immediately. In algebraic mode, these buttons should result in a function statement being inserted into the line of text in the command entry line. The function statement should appear with a set of parenthesis, and automatically place the user's cursor inside the new set of parenthesis, similar to how it is done with the HP-50g.
In many cases, a dedicated function key menu level will not contain a full set of ten button labels. With ten function keys available at each point of the menu tree, it might be possible to create sets of choices that are always smaller than ten items each, so there would not be a need to spend time stepping across pieces of a menu level that has too many items to display at one time. This would save user effort. In cases where a menu list is greater than ten items, button number ten can be [next] and button number one can be [back] in the same way it is done with other machines. This would allow subgroups of eight menu items at a clutch for a related group of menu items.
Enough brainstorming for now. I must do other work and come back to this.
We kinda stepped away from figuring out the smallest existing production machine that can do all of the trig functions with complex numbers. My bet is on the little uWatch, for now. I was only teasing about Star Trek. That cute little thing could make an excellent vest pocket slide rule, if the ROM includes all of the trig functions with complex numbers.