HP Forum Archive 18

[ Return to Index | Top of Index ]

What is the smallest full trig calculator in production? Message #1 Posted by Bill Triplett on 28 Oct 2008, 11:47 p.m. In a few discussion threads, people have noted here that some math functions are not built into some of the high end calculators. I was just wondering which calculator would be the smallest machine in the world that would be capable of directly evaluating all of the trig functions and their inverses, both circular and hyperbolic, plus logarithms, and powers, and roots, with complex numbers? I think it is likely that you can do all of the listed complex number functions with an antique HP-15C without needing to add any custom functionality with user programs. Of course, you can carry along a large machine like the HP-50g, and you can perform all of the listed functions, but I would prefer to see all of the functions available in a machine that I would not mind carrying along in a vest pocket. Strangely, you can perform all of the listed math functions with a "vector" slide rule from yesteryear. Pickett even made a tiny 1/10 inch thick six inch long pocket version of their N4 that would perform all of the mentioned functions with complex numbers. I was looking at the beautiful HP-35s, and I was shocked to see that it does not include all of the listed functions. It has memory for user programs, so work-arounds can be constructed by brute force, but the machine is not exactly tiny enough to be a replacement for my HP-15C, or my pocket-sized vector slide rule. A simple one line display would have been fine in a machine, as long as the machine would still perform all of the math functions. I think I understand why the HP-35s has two lines of display, due to extensive use of menus. The HP-35s seems like a step in a good direction. It just needs a bit more bang for math, and a bit less mass. The only Casio calculator I could spot with full support for the math functions of interest would be their ginormous ClassPad. The TI-Nspire is an equally effective weapon that might be just as useful for knocking out a mugger. For now, it looks as if it is either the HP-15C or the Pickett slide rule for a small machine that can do all math. The problem is that neither vest pocket sized machine is in production any more. Did I mention that the tiny HP-15C also would invert a matrix? I don't think we need that exact machine to go back into production, but something tiny and complete would be appreciated.

Re: What is the smallest full trig calculator in production? Message #2 Posted by Karl Schneider on 29 Oct 2008, 12:11 a.m., in response to message #1 by Bill Triplett Bill -- Quote: I was just wondering which calculator would be the smallest machine in the world that would be capable of directly evaluating all of the trig functions and their inverses, both circular and hyperbolic, plus logarithms, and powers, and roots, with complex numbers? I think it is likely that you can do all of the listed complex number functions with an antique HP-15C ... The HP-15C will do all of the above, other than roots (except square root). 1/x followed by yx is the workaround. And yes, the HP-15C is probably the smallest model that does what it does. THe HP-42S isn't much larger, and does much more. -- KS

Re: What is the smallest full trig calculator in production? Message #3 Posted by DaveJ on 29 Oct 2008, 1:10 a.m., in response to message #1 by Bill Triplett The uWatch of course would have to be the smallest platform available to do this. The current firmware does not support all those functions, but it's open source, so you could add your own directly as menu options. Dave.

Re: What is the smallest full trig calculator in production? Message #4 Posted by Bill Triplett on 29 Oct 2008, 8:23 a.m., in response to message #3 by DaveJ EEEEEP. That would be the opposite of a thing to carry inconspicuously in a vest pocket. It shouts (in a tiny voice, I imagine) "here I am, look at me!" I think that Sir Sinclair tried to market a wrist calculator at some point. I have no idea how many were sold. It looked like something a Star Trek villian would have used for controlling a weapon, or a teleport system. I might get me one of these little wrist machines, along with some wrinkly flesh colored makeup for my forehead, so I can be a new kind of alien.

Re: What is the smallest full trig calculator in production? Message #5 Posted by Jeff O. on 29 Oct 2008, 12:41 p.m., in response to message #4 by Bill Triplett One is not required to wear the uWatch as a wristwatch. If you leave the watchband off, it is a perectly fine, very small, stand-alone calculator.

Re: What is the smallest full trig calculator in production? Message #6 Posted by DaveJ on 29 Oct 2008, 5:35 p.m., in response to message #5 by Jeff O. Quote: One is not required to wear the uWatch as a wristwatch. If you leave the watchband off, it is a perectly fine, very small, stand-alone calculator. Yes, many people use it without the watch band, as a "pocket" calculator. It in fact fits inside one of my *fob* pocket! I've got a pocket clip attachment version too: Dave. Edited: 29 Oct 2008, 5:37 p.m.

uWatch Message #7 Posted by Bill Triplett on 30 Oct 2008, 8:54 a.m., in response to message #6 by DaveJ Most of all, I just think it is beautiful to see someone take the matter into their own hands, so to speak, instead of just writing about what should exist. Many congratulations Dave. For finding answers to trig functions where inputs are complex numbers, the microcontroller in the uWatch would have enough memory to handle the necessary equations. I will cast about, and see whether I can put the needed equations together in one place. I am not a PIC processor user, at least not yet. I have always used the ATMELs when doing embedded system design, so we would need someone smarter than me to put the equations into the watch. Thanks again for being so creative. When I can afford the time, I will definitely want to construct one of the little watches, and add it to my assortment of curiosity machines.

Re: uWatch Message #8 Posted by DaveJ on 1 Nov 2008, 6:19 p.m., in response to message #7 by Bill Triplett Quote: Most of all, I just think it is beautiful to see someone take the matter into their own hands, so to speak, instead of just writing about what should exist. Many congratulations Dave. Thanks. Yes, rather than complain about it, I simply took the matter into my own hands and created something real. Quite a few people have complained that it's not a professional enough looking product etc. But hey, you've got to start somewhere, and many people have gotten a lot of pleasure and use out of the current design. Quote: For finding answers to trig functions where inputs are complex numbers, the microcontroller in the uWatch would have enough memory to handle the necessary equations. I will cast about, and see whether I can put the needed equations together in one place. I am not a PIC processor user, at least not yet. I have always used the ATMELs when doing embedded system design, so we would need someone smarter than me to put the equations into the watch. There is very little real practical difference between Atmel and PIC, or any other processor these days if you keep your software abstract enough using a high level language like C. We have tried to do this with the uWatch software, so anyone with some basic C experience can modify the watch to their own needs. The tools are pretty easy to use, just install, load the project, and hit compile. So you don't have to really know about the processor internals or peripheral interfacing because all that stuff is already taken care of for you. If you examine the code you should find it's pretty trivial to change your own menu items for instance. Full complex number support on the other hand is not so trivial due to the nature of it. Quite a lot would need to change of course. The problem of course with a platform like this, is maintaining a "generic" version of the firmware that pleases the most number of people. i.e. many people may not care about complex number support, and if other features were tampered with to add it then they won't be happy. Still others want base mode support, full unit conversion support, better programming loop support, RPL instead of RPN, different keyboard layouts, and the list goes. That's not to mention hardware changes either! I can now imagine what the designers at HP must go through to please as many people as possible! Dave.

Complex number arithmetic for trig functions Message #9 Posted by Bill Triplett on 30 Oct 2008, 9:37 a.m., in response to message #6 by DaveJ 1: (a + i b) + (c + i d) = (a + c) + i (b + d) 2: (a + i b) - (c + i d) = (a - c) + i (b - d) 3: (a + i b) * (c + i d) = (a * c – b * d) + i (a * d + b * c) 4: (a + i b) / (c + i d) = (a*c + b*d) / (c*c + d*d) + i (b*c – a*d) / (c*c + d*d) 5: ln(a + i b) = ln(sqrt(a*a + b*b)) + i (2*arctan(signum(b)) - arctan(a/b)) 6: signum(b) = 1 if b>0, 0 if b=0, -1 if b<0 7: (a + i b)^(c + i d) = alpha * cos(beta) + i * alpha * sin(beta) 8: alpha = (a*a + b*b)^(c/2)*e^(d*(arctan(a/b) - 2*arctan(signum(b)))) 9: beta = ln(a*a + b*b)*d/2 - c*(arctan(a/b) - 2*arctan(signum(b))) 10: sin(a + i b) = sin(a) cosh(b) + i cos(a) sinh(b) 11: cos(a + i b) = cos(a) cosh(b) - i sin(a) sinh(b) 12: tan(a + i b) = (sin(a) cosh(b) + i cos(a) sinh(b)) / (cos(a) cosh(b) - i sin(a) sinh(b)) 13: arcsin(a + i b) = -i ln(i(a + i b) + sqrt(1 - (a + i b)(a + i b))) 14: arccos(a + i b) = -i ln((a + i b) + sqrt((a + i b)(a + i b) - 1)) 15: arctan(a + i b) = (i/2)(ln(1 - i(a + i b)) - (ln(1 + i(a + i b))) 16: sinh(a) = (e^(a) - e^(-a))/2 17: cosh(a) = (e^(a) + e^(-a))/2 18: tanh(a) = sinh(a) / cosh(a) 19: arcsinh(a) = ln(a + sqrt(a^2 +1)) 20: arccosh(a) = ln(a + sqrt(a^2 -1)) ; a>=1 21: arctanh(a) = (1/2)ln((1+a)/(1-a)) ; abs(a)<1 22: sinh(a + i b) = sinh(a) cos(b) + i cosh(a) sin(b) 23: cosh(a + i b) = cosh(a) cos(b) + i sinh(a) sin(b) 24: tanh(a + i b) = (tanh(a) + i tan(b))/(1 + i tanh(a) tan(b)) 25: arcsinh(a + i b) = ln((a + i b) + sqrt((a + i b) (a + i b) + 1) 26: arccosh(a + i b) = ln((a + i b) + sqrt((a + i b) (a + i b) - 1) 27: arctanh(a + i b) = (1/2)*ln((1 + (a + i b))/(1 - (a + i b))) Edited: 30 Oct 2008, 5:41 p.m.

Re: Complex number arithmetic for trig functions Message #10 Posted by hughsteers on 30 Oct 2008, 9:29 p.m., in response to message #9 by Bill Triplett hi guys, It wouldn’t be difficult to put all of those into the base system. The CPU on the PIC has amazed me in what it can achieve. The _really_ tempting part is the two line display which would be excellent for complex numbers. The main issue would be the usability. There would need to be an “i” key somewhere that’s not hidden inside a menu. Could part of the number entry be hijacked for i? maybe that would be too confusing. on the display front, I was thinking either use both lines for one complex number or, keep it as is an fit the number into the 16 chars (which should be enough). This might have to be a mode/option. On the computational front, I have the biggest problem with item (3) on your list. Ie ordinary multiplication of complex numbers. This is something that has bugged me for years and I think has not been properly addressed by any calculator. Ok (a + i b) * (c + i d) = (a * c – b * d) + i (a * d + b * c) The first term of the result (real part) is unstable. one of the problems inherent in complex numbers is that you need internally twice the precision for operations as simple as multiplication. for example (1.00001+i)*(1.00001+i) = 2.00001e-5 + i*2.00002, is correctly given by most machines and is just within limits because the 0.00001 is half the precision. going one stage further;(1.000001+i)*(1.000001+i) gives 2e-6+i*2.000002 which is only approximate. the correct 10 digit answer being2.000001e-6+i*2.000002. so im saying that a ten digit non-complex calculator is no longer a ten digit complex calculator, but it could be if it made a bit more effort. A while back, i developed a way to extract double precision from a single precision library. I think I would use that here for the internals of the complex number calculations to give precision results matching the machine reals. There’s about a 4x cost for each operator to get the double precision version, but I’ve found processors like the pic24 in the uwatch amazingly fast. I can forgive the old HPs for not going the extra precision, but not the calculators of today. But it looks like things are going backwards, because there’s been nothing to rival the 15c even after all these years!!

Re: Complex number arithmetic for trig functions Message #11 Posted by Bill Triplett on 31 Oct 2008, 12:39 a.m., in response to message #10 by hughsteers An i button makes sense. I have seen some calculators interpret two consecutive numbers inside a pair of parenthesis as being a complex number, where it is assumed that the second number is the imaginary part of a pair. I am not familiar enough with the uWatch overall interface to think of ways how this could work and still allow all of the other basic functionality for the unique machine. You make an excellent point calling attention to the need for extra internal digits when working with complex numbers. This would be especially true when dealing with some of the larger identity functions on the list. Number 7 was originally one single (gigantic) expression, but I broke it into segments to avoid killing anyone.

Re: Complex number arithmetic for trig functions Message #12 Posted by Jeff O. on 31 Oct 2008, 7:57 a.m., in response to message #10 by hughsteers For entry of complex numbers on the uWatch, I have two suggestions: 1. In RPN mode, the right parenthesis key is not used, so it could become the "i" key. 2. Use a second press of the "." key to signal that a complex number is being entered and the imaginary part is about to be keyed in. For display, I think I prefer using both lines of the display. It would be difficult to fit both parts into only 16 characters. There is a lot of "overhead" that would eat up characters, including four signs, two e's for exponents of 10, and an "i" or angle symbol. For example, -1.23e-123-i1.23e-123 takes 21 characters and displays only 3 significant figures.

Re: Complex number arithmetic for trig functions Message #13 Posted by Bill Triplett on 31 Oct 2008, 9:04 a.m., in response to message #12 by Jeff O. If the button interface has no comma, space character, or semicolon to use as a means of separating two numbers inside a set of parenthesis, then Jeff's idea using ".." seems like the most visually elegant solution. First, look at an example not using scientific notation. The complex number a + ib where a = 1.23 and b = 2.34 could be entered as follows: (1.23..2.34)[enter] Does the uWatch use the minus button as a negation button at the beginning of a number? Some machines have two different buttons, one for subtraction, and one for negation. I would love to work out a way to eliminate the need for having more than one negative button. For example, if a = -3.45 and b = -4.53 a complex number could be typed in as follows: (-3.45..-4.53)[enter] When the first minus button is pressed before "3.45" is typed, the input interpreter would have already been alerted by the opening parenthesis so it would interpret the first "-" button as the beginning negation symbol of an upcoming sequence of digits. The same thing would happen immediately after the ".." pattern is seen, so the machine would not immediately try to perform a subtraction when the "-" button is pressed before 4.53 is typed. The closing parenthesis should be optional, and not cause an error if included. In RPN mode, sometimes a user has already entered several items into the stack, and needs to press the "-" button to command a subtraction immediately after having already pressed some other operator button such as [multiply]. If no opening parenthesis is seen at the beginning of an input text sequence, the minus button would command an immediate RPN subraction operation. The uWatch needs to keep a pair of parenthesis buttons, so it can function equally well in both RPN mode and in algebraic mode. It might also be possible to allow a user to input an algebraic expression as a single line of input before pressing "enter" in RPN mode. For example: (1.23..3.45)*(-4.53..-6.78)[enter] This line of text entry would command the uWatch to take two complex numbers, multiply them together, and place the result on the stack. There would be no need for the user to keep track of a separate algebraic mode, or stop working to switch modes. RPN mode would always be there, and any time a user wants to enter an algebraic expression for evaluation, just start a new entry line with an opening parenthesis. Now for trig functions. In RPN mode, when no opening parenthesis has been typed, selecting a trig function from the menu should have the effect of immediately causing the trig function to be evaluated. If it is the first thing on the entry line, the input for the trig function would be the lowest level of the stack. Still in straight RPN entry mode, with no opening parenthesis as the starting character of a new line, another possibility is as follows: 3.14[sin] This would be processed postfix, in classic RPN fashion, so immediately after the [sin] softkey is chosen from a soft button menu, the machine would evaluate the sine function with 3.14 as the input angle. On the other hand, if a user decides to type in a trig function as a part of an algebraic expression, it should work differently. Starting with an opening parenthesis: (3.14*[sin]1.59)[enter] This would be interpreted to mean that the machine should evaluate the sine of 1.59 first, multiply that result by 3.14 and then place the result in the display register, at the very least, and possibly pushed into the stack without needing to press the [enter] button a second time after evaluating the algebraic expression. A fine point would be to think about what should happen when the final closing parenthesis is pressed in the most recent example above. One way would be to have the machine immediately evaluate the algebraic expression, keep the result in the display, and not enter the result into the stack until the user presses the [enter] button the first time. This might seem like it would be good enough, but it might create a difficulty when entering an algebraic expression like the following: (3.14*[sin]1.59)*(123.4/567.8)[enter] If the first part of the expression is evaluated and replaced by a single number when the right parenthesis is pressed after "1.59" the user would not be able to look at the display and proof read the expression before pressing [enter]. Therefore, I would like to suggest that the machine should wait until the [enter] button is pressed before deciding what to do with each complete expression. If it is done in this way, then we could either have the evaluated algebraic expression automatically pushed onto the stack, or we could keep the evalutated algebraic expression in the display only, waiting a second press of the [enter] button before being pushed into the stack. I like this second approach best, because we would have the freedom to use the evaluated algebraic expression as if we had typed it into the display in the middle of a sequence of RPN operations. Truly, this would be the best of both worlds, without needing to type quote characters. It would also be nice if a user could arrow left and right to edit a line of text before pressing [enter]. If no arrow key option is available, then everything can work the same, but with proof reading only. If an entry is a mistake, a user could be required to just clear the entry, and type it in again. Edited: 31 Oct 2008, 10:59 a.m.

Re: Complex number arithmetic for trig functions Message #14 Posted by Jeff O. on 31 Oct 2008, 1:28 p.m., in response to message #13 by Bill Triplett Bill, First, let me confess to having not attempted to fully digest your ideas. So if I say anything that you already said, or ascribe something to you that you didn’t really say, or say something that doesn’t really make sense as a response to anything you said in your post, please accept my apologies. To begin, I feel strongly that one should not have to use parentheses to enter complex numbers. It should be an easy, natural extension of entering a real number. Upon further thought, I'd suggest that a single press of the decimal point key would signify that you were entering a complex number in rectangular form. A second press would signify that you were entering a complex number in polar form. The complex number a + ib, where a = 1.23 and b = 2.34, would be entered as follows: 1.23.2.34 (enter) As soon as you press the second decimal point, an "i" would appear at the beginning of the second line of the display. (There would be no impact on stack level y, it just would not be displayed anymore.) You would then enter the "2.34" and it would appear after the "i". As for sign changing, pressing +/- anytime before pressing the second decimal point would change the sign of the real part (or magnitude, if entering polar). Pressing it anytime after pressing the second decimal point would change the sign of the imaginary part (or angle.) The complex number a /b where a = 5.6 and b = 67.89 would be entered as follows: 5.6..67.89 (enter) Whenever a complex value is in stack level x, it would be displayed as real or magnitude in the bottom line of the display, imaginary or angle in the top line: value in stack y: 3.45 value in stack x: 5.67 + i 6.78 Top line of display: i6.78 Bottom line of display: 5.67 If a real is in stack level x, both stack level x and y would be displayed in the bottom and top display lines, respectively. If there is a real in x and a complex in y, a truncated version of the complex y value would be displayed in the top line of the display: value in stack y: 5.678901 + i 6.789012 value in stack x: 7.89 Top line of display: 5.678901+i6.78.. Bottom line of display: 7.89

Re: Complex number arithmetic for trig functions Message #15 Posted by V-PN on 1 Nov 2008, 1:01 a.m., in response to message #14 by Jeff O. hmmm...seems like preseding zero has to be entered 1.23.0.123 but what about 0 + i1 0.1 ooops! so .. for complex, perhaps ... for angle

Re: Complex number arithmetic for trig functions Message #16 Posted by Jeff O. on 3 Nov 2008, 7:20 a.m., in response to message #15 by V-PN 0 + i1 would be entered: 0..1, or maybe just ..1 It is not a perfect system, just trying to find something that might work.

Re: Complex number arithmetic for trig functions Message #17 Posted by Bill Triplett on 1 Nov 2008, 1:03 a.m., in response to message #14 by Jeff O. Jeff, The idea for using an opening parenthesis would be for the purpose of telling the input interpreter that an inline algebraic expression is being typed while in RPN mode. This is independent from representing the separation between real and imaginary components of a complex number. A machine following the convention that I described would always be in RPN mode, and if no opening parenthesis is typed as the first character of an input line, then the input interpreter would accept the plain entry of a bare number or a bare complex number without any parentheses. The point of the opening parenthesis is to arrange the interface so that users can have the freedom of expression to use RPN as much as they want (always present), but also the freedom to arbitrarily type an inline algebraic expression, and then have the evaluated result of that inline algebraic expression pushed onto the stack as if the user had simply typed in the result of that expression and hit [enter]. I will come back to the utility of having both kinds of input always available as options without needing to switch modes. Separately, I am concerned about the other independent question about the usefulness of using two dots as a way to separate the two components when typing a bare complex number into the input interpreter. If the convention would be to enter a number with only a single dot as the separator between the real and complex component, then that convention would create an ambiguous situation. For example, suppose a user wanted to enter the complex number a + ib where a = 12 and b = 34 and both components of the complex number are integers. 12.34[enter] If the separator is a single dot, then the input would look exactly like what a user would type when entering a real number with value = 12.34 with no imaginary component. If, on the other hand, the convention is to use two dots as a separator, there is no ambiguity. 12..34[enter] This would be a complex number with no confusion. So, we have two independent things to choose in the user interface. First, some users will be happy to have the freedom of typing an inline algebraic expression while the machine is in RPN mode, and in fact never take the machine out of RPN mode. The presence of an opening parenthesis as the first character of an expression input line would be a simple way to represent the fact that an inline algebraic expression is following. The other independent convention to choose is to choose from among the many possible ways of telling the input interpreter where the real part of a complex number ends, and where the imaginary part begins. We could do that with two dots in sequence, as described, and it would work fine, with no ambiguity. If the machine can also recognize and accept an inline algebraic expression, then by no means would you be forced to enter algebraic expressions. If you hate doing that, then you can just not place any finger upon either of the two available parenthesis buttons. Just type in a value, and press [enter] to make it work exactly like a machine that is only capabe of doing RPN without inline algebraic expression being an option. Beyond the niceness of not needing to place the machine into one of two exclusive modes before starting to input expressions, another nice advantage of arranging the interface to accept input in this way is that it completely eliminates any need for an extra negation button on the keyboard. Also, there would be no need for a [change sign] button. I can explain why the interface would not need either of these two buttons after I get some sleep. BTW, you are a model of diplomacy. Thanks, and I shall try to do as well. Bill

Re: Complex number arithmetic for trig functions Message #18 Posted by hughsteers on 1 Nov 2008, 12:41 p.m., in response to message #17 by Bill Triplett Hi Guys, I like a lot of these suggestions. I might have a go and see if I can modify the input parsing to accommodate this. I’m going to try the “..” idea (ie TWO dots) because of the ambiguity problems otherwise. Also, I’m against overloading parentheses for complex numbers, partly because this will also cause problems in algebraic mode. In an aside note, I was independently thinking of making right bracket perform a single backspace (ie delete) in RPN mode. This would be easy since the input processor works by constructing the number as a string before entering it. Of course, this backspace would not be available in ALG mode (ha ha!)

Re: Complex number arithmetic for trig functions Message #19 Posted by Bill Triplett on 1 Nov 2008, 10:00 p.m., in response to message #18 by hughsteers An adaptation for handling inline algebraic expressions in RPN mode should not be a first item of effort. As a first step, it would be nice to have a small machine that can do all of the math functions that I can accomplish by using a six inch pocket vector slide rule. The vector versions of slide rules are different from garden variety slide rules in that they allow a user to evaluate hyperbolic functions with complex numbers. In slide rule catalogs of yesteryear, these were the top of the line, most expensive slide rules. It amazes me that after all these decades, a person who understands the usefulness of hyperbolic functions cannot find anything in production that supports the math functions, except by purchasing a large graphing calculator. Yes, small PDAs with enormous speed and memory can emulate the graphing calculators, but a real calculator usually has much better battery run time. You can take your time, and never worry about needing to hook up a charger. A small calculator that can do all of the work of the best slide rule would be very conspicuous, because it would be the only thing of its kind, other than the venerable HP-15C which could do everything except knock out a mugger. For now, my itsy bitsy six inch vector slide rule is still king of the hill for maximum trig functionality, and minimum size. Edited: 1 Nov 2008, 10:10 p.m.

Re: Complex number arithmetic for trig functions Message #20 Posted by V-PN on 2 Nov 2008, 1:35 a.m., in response to message #19 by Bill Triplett [pre]Quota: "Yes, small PDAs with enormous speed and memory can emulate the graphing calculators, but a real calculator usually has much better battery run time. You can take your time, and never worry about needing to hook up a charger" And you still do that with your mobile phone, which is usually much more vital to people than a calculator. This is why I have suggested that HP iPaq Phone Edition with a REAL calculator slide-in keyboard should be released. EMU48 would be easy to use in a large touch sensitive LCD, but the full power of the PDA using RPL/2 and xCas is what is really needed! While it is also a phone - and a VGA camera + FM-radio this woul make it ideal for 2010-decade student and professional as well.

Re: Complex number arithmetic for trig functions Message #21 Posted by Bill Triplett on 1 Nov 2008, 10:39 p.m., in response to message #18 by hughsteers "In an aside note, I was independently thinking of making right bracket perform a single backspace (ie delete) in RPN mode. This would be easy since the input processor works by constructing the number as a string before entering it. Of course, this backspace would not be available in ALG mode (ha ha!)" You are onto something really important for user comfort, thinking about ways to allow editing of input. If the input interpreter is geared to recognize a special case when an opening parenthesis is the very first character of an input string, as described in the earlier suggestions, then the result would be a complete lack of need for a dedicated [change sign] button. In that case, the uWatch keyboard would have an extra button that could be labeled differently, or mapped to a different position on the keyboard as a [delete] button. If it is done in this way, the delete button will be equally available for users who are typing input with or without parentheses. In other words, all of the same functionality would be available for a user, whether a user happens to be using no parenthesis at all, and strictly typing numbers into the stacks one at a time, or whether the user happens to be entering a small inline algebraic expression of several numbers as a single line of horizontally scrolling input while the machine is still in RPN mode, in which case the machine would evaluate the finished inline algebraic expression, and push the result onto the RPN stack. Just a thought. Anyway, it would be nice to have something as basic as input editing, or a single character deletion button work in exactly the same way whether or not an inline algebraic expression is being typed. This would avoid confusion. The machine should be the servant of the user, friendly, patient, forgiving, and accepting of input in consistently the same fashion, as much as possible, in every mode. Again, I am sorry I don't have a uWatch to work with, and I don't know exactly how it presently can allow editing of an input line before [enter] is pressed. Even if a [change sign] button is not strictly needed with the suggested method of inline algebraic input available some day, it still might be mighty convenient to keep the change sign button where it is. Allowing more than one way to do this gives freedom to the user. I was noticing that the upper circuit board with buttons might not need to have the same notch that is present for the watch band attachment on the lower circuit card. If the top circuit board is a complete rectangle, then there will be room for three more buttons in a clean rectangular array. We could keep the [change sign] button where it is, and add [left arrow] and [right arrow] and [delete character] buttons. If so, then they should work the same way when algebraic expressions are typed. Edited: 1 Nov 2008, 10:41 p.m.

Re: Complex number arithmetic for trig functions Message #22 Posted by DaveJ on 1 Nov 2008, 11:14 p.m., in response to message #21 by Bill Triplett Quote: You are onto something really important for user comfort, thinking about ways to allow editing of input. It must be remembered of course that not everyone wants nor needs an easy way to edit a number entered. When I first wrote the firmware I thought about what the C key should do. Should it clear the last character or simply clear the entire line. Or perhaps it would do both depending upon how you held it down. Given that the watch is not really designed to be a formula or complex line entry device, I went with simply using C to clear the line completely. The C key operation could be programmable though I guess. Quote: If the input interpreter is geared to recognize a special case when an opening parenthesis is the very first character of an input string, as described in the earlier suggestions, then the result would be a complete lack of need for a dedicated [change sign] button. In that case, the uWatch keyboard would have an extra button that could be labeled differently, or mapped to a different position on the keyboard as a [delete] button. If it is done in this way, the delete button will be equally available for users who are typing input with or without parentheses. In other words, all of the same functionality would be available for a user, whether a user happens to be using no parenthesis at all, and strictly typing numbers into the stacks one at a time, or whether the user happens to be entering a small inline algebraic expression of several numbers as a single line of horizontally scrolling input while the machine is still in RPN mode, in which case the machine would evaluate the finished inline algebraic expression, and push the result onto the RPN stack. Just a thought. Anyway, it would be nice to have something as basic as input editing, or a single character deletion button work in exactly the same way whether or not an inline algebraic expression is being typed. This would avoid confusion. The machine should be the servant of the user, friendly, patient, forgiving, and accepting of input in consistently the same fashion, as much as possible, in every mode. Again, I am sorry I don't have a uWatch to work with, and I don't know exactly how it presently can allow editing of an input line before [enter] is pressed. It doesn't, C simply clears the entire line at present. Quote: Even if a [change sign] button is not strictly needed with the suggested method of inline algebraic input available some day, it still might be mighty convenient to keep the change sign button where it is. Allowing more than one way to do this gives freedom to the user. I was noticing that the upper circuit board with buttons might not need to have the same notch that is present for the watch band attachment on the lower circuit card. If the top circuit board is a complete rectangle, then there will be room for three more buttons in a clean rectangular array. We could keep the [change sign] button where it is, and add [left arrow] and [right arrow] and [delete character] buttons. If so, then they should work the same way when algebraic expressions are typed. There is no upper circuit board, just the one board with the buttons mounted on it. The "upper" board you see is simply a stick-on front panel with the key labels, although it happens to be made from 0.5mm PCB material. There is no room for any more keys, as the main circuit board needs the cutout for the watch band attachment. Dave.

Re: Complex number arithmetic for trig functions Message #23 Posted by V-PN on 2 Nov 2008, 1:41 a.m., in response to message #22 by DaveJ [pre] QUOTA: "There is no room for any more keys, as the main circuit board needs the cutout for the watch band attachment." Then a different method to attach that band is in order... VPN HP release the "HP 42"

Re: Complex number arithmetic for trig functions Message #24 Posted by DaveJ on 2 Nov 2008, 1:02 a.m., in response to message #23 by V-PN Quote: [pre] QUOTA: "There is no room for any more keys, as the main circuit board needs the cutout for the watch band attachment." Then a different method to attach that band is in order... Sure. If you know of anything better that actually works then let me know. IMO the watch doesn't need more buttons, it needs to be *smaller*. My CFX-400 had 16 buttons plus 4 side keys, and that worked a treat. The uWatch has 5 more keys - what a luxury! I can fit 7 more keys if I squish them together a bit more and make the board a bit bigger. But where do you stop? Two extra right angle buttons will fit on the top edge of the board, but then how do you label them? Dave.

Re: Complex number arithmetic for trig functions Message #25 Posted by V-PN on 2 Nov 2008, 3:31 p.m., in response to message #24 by DaveJ Let them be left and right arrow shaped edit keys!!

Re: Complex number arithmetic for trig functions Message #26 Posted by DaveJ on 2 Nov 2008, 3:36 p.m., in response to message #25 by V-PN Quote: Let them be left and right arrow shaped edit keys!! Ok. You got a link where I can buy those? :-> Dave.

Yowser! Message #27 Posted by hughsteers on 2 Nov 2008, 4:59 p.m., in response to message #26 by DaveJ Hi Guys, check this out. i got the basic complex number going with input using the ".." method. also you only need 1 dot if you already have an exponent. also some other fixes well overdue. changes so far, 1.3.7 - fix for AM/PM indicator wrong during noon to 1pm. - removed Conversions BASE-N (was incomplete and superseded by Rob's BASE mode). - stack lift missing for; a ENT b OP '.' or 'e'. ie non-digit number entry. - stack lift missing for; a ENT OP, then enter a number - fixed: the +/- key does not properly negate a negative result from a previous calculation - fixed: OP then +/- followed by number went back to entry. - fixed after OP then clear +/- shows -0 - fixed: recalling values from storage registers overwrites the x register. - removed delays from STO/RCL to avoid slowing down macro programs. -- Experimental complex number support - base 4 ops - complex; X<>Y, ROLL, STO, RCL, 1/x, x^2, PI - entry of complex number using repeated '.' ie a second '.' is re-interpreted as the start of the imaginary part, unless an exponent exists, in which case a single '.' starts the i part. i've only put in the basic support for the 4 ops and things like 1/x, x^2 so far, but the full set is feasible. when i get a chance, i'll put them all in for the next proper release. also, i have to implement my own idea with the extended precision :-) right now, it's trying to display each complex number in a single line. i agree that this isn't really the best way, but it was easiest to get working at first. i try to fit as much as possible, but once exponents are there too, there's very little room.

Re: Yowser! Message #28 Posted by David Dyte on 2 Nov 2008, 5:46 p.m., in response to message #27 by hughsteers Very, very impressive! But you really shouldn't be tempting me to buy one of these when I just bought a whole bunch of HP stuff...

Re: Yowser! Message #29 Posted by Walter B on 2 Nov 2008, 6:17 p.m., in response to message #27 by hughsteers Congratulations! I think I should assemble mine the next rainy weekend ;) How about reducing the number of decimals when a complex number is displayed? Going back to SCI 2 would solve a bit.

Read it and beep. Message #30 Posted by Bill Triplett on 3 Nov 2008, 12:23 a.m., in response to message #29 by Walter B I am not sure SCI 2 can always allow both real and imaginary components to be displayed on one line. There are only sixteen digits on one of the display lines. Consider this example: 0.0000000001234[+/-]..0.0000000002233[+/-][enter] The line of input above would be equivalent to the following algebraic expression: -1.234E-10 - i * 2.233E-10 If all of the digits of this complex numbers are kept internally, but the number sequence is cut back to display only two significant digits, then the compact version of the display will look like this: -1.2E-10-i2.2E-10 I am assuming that the [+/-] button works as a change sign button, and it operates on the number component that has just been entered. The problem here is that this particular number would require seventeen display characters in the compact form. What to do?

Re: Read it and beep. Message #31 Posted by V-PN on 3 Nov 2008, 3:49 a.m., in response to message #30 by Bill Triplett [pre] As I have already suggested quite fitting to this nerdy thing: a new way to express exponent: F for negative Also negative imaginary part should be j, instead of -i Thus giving you a really compact display: -1.2E-10-i2.2E-10 => -1.234F10j2.22F10 The fact that decimal point eats up a whole digit annoys me, so I would not mind the font being smaller - 6*4 VPN HP should bring back the HP-42S

Re: Fitting number on one line Message #32 Posted by Bill Triplett on 3 Nov 2008, 8:44 a.m., in response to message #29 by Walter B I slept on it. Now, I can see that Walter is right. 0.0000000001234[+/-]..0.0000000002233[+/-][enter] If a user types the entry in this example, the uWatch can be made to successfully display the entire complex number with sixteen characters on one line, as follows: -1.2E-10-2.2E-10 The user would need to get used to the idea that there is no reason for the display to have two scientific notation numbers back to back on one line like this, except that it means a complex number is being displayed. All of this is assuming that there is no set of left and right arrows available for scrolling a number across the display. I am still not sure that this is the best of the available options, but it can indeed be made to work. A minor point of inquiry is that I still don't see how a user can be given a means of going back, and looking at the full set of input digits after the display is in this compact format. The 1.2 would still be 1.234 and the 2.2 would still be 2.2233 internally. I see a "menu" button. In the most recent photograph, I see what seems to be two complex numbers. One is displayed on the top line, and a second is displayed on the bottom line. These probably are the x and y registers in RPN mode. Yes? When the menu button is pressed, I assume that the bottom line becomes the button soft key menu, so when that happens, what happens to the bottom number in the display? Does it jump up to be displayed on the top line, causing the display of the stack to be shifted up a line? Or else, does the menu simply appear on the bottom line, and replace the bottom line of display while leaving the top line as it was? Sorry to be asking such basic questions about the existing user interface, when I could go figure it by looking at the source code. In any case, it is awesome to see a tiny machine displaying imaginary numbers in any format.

Re: Fitting number on one line Message #33 Posted by DaveJ on 3 Nov 2008, 3:16 p.m., in response to message #32 by Bill Triplett Quote: I see a "menu" button. In the most recent photograph, I see what seems to be two complex numbers. One is displayed on the top line, and a second is displayed on the bottom line. These probably are the x and y registers in RPN mode. Yes? Correct. Normally the X and Y registers are displayed, both in RPN and algebraic mode. Quote: When the menu button is pressed, I assume that the bottom line becomes the button soft key menu, so when that happens, what happens to the bottom number in the display? Does it jump up to be displayed on the top line, causing the display of the stack to be shifted up a line? Or else, does the menu simply appear on the bottom line, and replace the bottom line of display while leaving the top line as it was? No, it's a dual line soft key mapping system using the F1 to F6 keys below the screen. The menu uses both lines. The "Modes and Menus" video here explains it: http://www.calcwatch.com/what.htm Dave.

Re: Fitting number on one line Message #34 Posted by Bill Triplett on 3 Nov 2008, 3:42 p.m., in response to message #33 by DaveJ Got it. Thanks.

Re: Fitting number on one line Message #35 Posted by David Dyte on 3 Nov 2008, 3:46 p.m., in response to message #32 by Bill Triplett Quote: A minor point of inquiry is that I still don't see how a user can be given a means of going back, and looking at the full set of input digits after the display is in this compact format. The 1.2 would still be 1.234 and the 2.2 would still be 2.2233 internally. Perhaps some key could be made to alter the display to show X over both lines of the display, just while the key is held: 1.234E-10 +i2.2233E-10 - David

uWatch firmware Message #36 Posted by DaveJ on 2 Nov 2008, 7:15 p.m., in response to message #27 by hughsteers Nice work Hugh! 1.3.7? I can only see 1.3.4 on Sourceforge and that's what shipped with the current batch of watches. What happened to the other versions? One thing I found with 1.3.4 trig functions was that it doesn't display the current trig mode on the menu. So unless you remember what mode you last selected, you have to select the appropriate mode first. Also, when you do change trig modes it exits from the menu, so you have to go back in to select your trig function. Dave.

Re: uWatch firmware Message #37 Posted by hughsteers on 2 Nov 2008, 7:35 p.m., in response to message #36 by DaveJ On the display issue, you’re absolutely right. I have a plan to replace the built-in number formatting with something that we can customise more precisely. For example 0.123 could be .123 and save a digit. Also, right now it won’t display more than 10 digits even if there is room. Why not use the whole 16 digit display for, for example 2 SQRT. Also, looks like I never actually made a proper release package after 1.3.4. here is my changelog: 1.3.5 - eprom erase should use unsigned to display number. - moon phase correction. yeah. back when we had that lunar eclipse the other month, i found out my method was slightly out and improved it. 1.3.6 (merged with Rob F's code) - Branch for base display modes ( binary, decimal, hex ) - Added a "Base" menu option to select base display mode - displays up to 16 bit binary numbers - displays up to 64 bit hex numbers - non decimal modes are truncated for display; internal representation is untouched. - EXP key in hex mode shows hex key menu Rob F, contributed a completely re-worked BASE mode. it's pretty good. he uses EXP as a hex number entry prefix. it works quite well, rather than using the menu entry. I’ll get around to making 1.3.7 the next “good” release. Also, I'll take a look into those trig function issues. I’m actually quite liking the “..” complex input method. It’s quick and works fairly well. I have arranged that +/- will change the sign of the mantissa, and then the exponent and then once a complex is input, changes the +/- of the ipart and finally the exponent of the ipart (if present). So basically you can input the signs as you go but can’t go back. Otherwise you have to clear and re-enter. If I do the backspace key in RPN mode, this will help too. Happy Hacking!

Re: uWatch firmware Message #38 Posted by DaveJ on 2 Nov 2008, 7:49 p.m., in response to message #37 by hughsteers Quote: On the display issue, you’re absolutely right. I have a plan to replace the built-in number formatting with something that we can customise more precisely. For example 0.123 could be .123 and save a digit. Also, right now it won’t display more than 10 digits even if there is room. Why not use the whole 16 digit display for, for example 2 SQRT. The digit limitation was made in order to to guarantee fitting of the largest possible number with negative exponent into the string. Worst case your number could be -1.23456789e-100 and that's 16 characters. The display routines could be modified to check the number first and then maximise the use of digits, so 2 SQRT could display 14 decimal places. The absolute maximum could of course be 15 digits for positive numbers below 1 if you drop the zero. Doing this is a bit of kludge I think, so for simplicity I didn't add this. How many digits does one need anyway? :-> Quote: Rob F, contributed a completely re-worked BASE mode. it's pretty good. he uses EXP as a hex number entry prefix. it works quite well, rather than using the menu entry. BASE N mode is rather exciting! Many people have asked for that, but hardly anyone has asked for complex number support. The most asked for features are BASE-N, stopwatch, timer, and better unit conversion support. Dave.

Re: uWatch firmware Message #39 Posted by Bill Triplett on 3 Nov 2008, 9:48 p.m., in response to message #38 by DaveJ I just took another look at the HP-35S. It actually has fewer block characters available than the uWatch! In the HP-35S, it looks as if each line of the display has 14 character blocks that are hard-coded into the LCD panel. Even so, it manages to display complex numbers with both the real and the imaginary component on one line of display. I don't have one to play with. Perhaps a display line can scroll horizontally. It looks as if they tuck the decimal point onto the corner of a character block instead of using an entire character block for the decimal point. I don't see how they could display scientific notation versions of complex numbers with such a limited nubmer of characters. I will need to look at this more closely.

Re: uWatch firmware Message #40 Posted by DaveJ on 3 Nov 2008, 10:07 p.m., in response to message #39 by Bill Triplett The 35S uses a true full dot matrix display for the two lines, so you are free to display anything you want. Not so with the character based LCD modules as used in the uWatch, they are two entirely different systems. It's easy to horizontally scroll each line though. Dave.

Re: uWatch firmware Message #41 Posted by Bill Triplett on 2 Nov 2008, 11:20 p.m., in response to message #37 by hughsteers Random stuff, in almost no particular order. First, I am amazed by how quickly you are updating code. I really must begin by saying "congratulations!" This is exciting creativity. I understand about the circuit board now. I did not mean to cause any confusion when I was wondering about the possibility of arrow keys. Those are not strictly needed, and a [clear] button that just wipes out the entire input line will get the job done. At this point, I am just excited that the tiny little thing can fit complex number support into memory, at all. "I’m actually quite liking the “..” complex input method. It’s quick and works fairly well." It is good that a user only needs to press the dot button one time if an exponent has already been entered. If a user forgets that the entry will work OK with only one dot as a separator, a user may type two dots after an exponent, by force of habit. It would be nice if the input interpreter would accept the input either way. If so, then the input separation could be used consistently with double dots by some users, but if a user happens to understand that the second dot is not needed under special circumstances, then they can be "in the know" and save a key press, optionally. I keep thinking, a machine should be the servant of the user, friendly, and accepting of input in consistent ways while often allowing freedom for the user to do things in more than one way. It is beginning to look as if some day I will be able to find a replacement for my six inch vector slide rule, one that can also do all of the trig functions, circular and hyperbolic, with complex numbers, and still be physically compact. I think it is nice to use the "i" character, as shown. It is probably plenty good enough. Electrical Engineers only use the "j" character as a means of avoiding confusion where the "i" character might sometimes be seen as a smybol for current. There is no reason to believe that the watch is displaying current, so using the "i" symbol can cause no confusion.

Re: Yowser! Message #42 Posted by V-PN on 2 Nov 2008, 8:24 p.m., in response to message #27 by hughsteers [pre]Since this is a very nerdy watch/calc indeed, what do you think of this proposition: to compress the complex numbers an reals as well use no + in jooining the imaginary part use j instead of i when the sign is negative E is positive exponent, but F is a negative one With these very nerdy new markings you could fit -1.23E99j1.23F99 in one 16 character line If you coul only use minifont you could squeeze 22 characters on a line if I read the dot matrix correctly there are two separate lines not continuous dot matrix, so three lines is not a possibikity.

Re: Yowser! Message #43 Posted by DaveJ on 2 Nov 2008, 8:50 p.m., in response to message #42 by V-PN You could even have scrolling lines if necessary and/or use one of the keys to toggle between a "compact (limited digits) display which would be the default, and the full digit display that scrolls. Dave.

Re: Yowser! Message #44 Posted by V-PN on 3 Nov 2008, 3:53 a.m., in response to message #43 by DaveJ Nice idea! A MANTissa key

Re: Yowser! Message #45 Posted by DaveJ on 3 Nov 2008, 5:58 a.m., in response to message #42 by V-PN Quote: If you could only use minifont you could squeeze 22 characters on a line if I read the dot matrix correctly there are two separate lines not continuous dot matrix, so three lines is not a possibikity. Unfortunately the LCD is block character based, it is not individually dot addressable. You can get around this partially by defining custom characters each time the display is updated, but that's rather complicated and messy. Dave.

Re: Yowser! Message #46 Posted by hughsteers on 3 Nov 2008, 8:03 a.m., in response to message #45 by DaveJ On the idea of the compact displays: This would indeed save space, but not enough to totally solve the problem. Also, there would be a difference in the representation during number entry compared to the result display. Someone already mentioned a MANT key, this is what I’ve been thinking of. If I understand correctly, what we could do is temporarily display the Xreg using _both_ lines, eg whilst held down, or maybe frozen until another key is pressed. Im now thinking of trying to continue the idea of one number per line, because in simple cases, you can actually see X & Y both complex at the same time and this is useful. Providing there is some way to zoom or expand the xreg then we are sorted. On the “..” entry method: My optimisation to accept a single “.” to start the ipart after exp would indeed result in the wrong entry if you inadvertently pressed it twice. For example “1.2e6..” appears on the screen as “1.2e6+i0.” Accepting the second dot as the start of a number for the ipart. So far, though this hasn’t been a problem for me with the uwatch because the buttons are so small that you don’t press them very fast. This could, however, been a lot more problematic for a hand-held device with a bigger keyboard. [note to self: implement backspace and everyone will be happy!] The other point, I might not have mentioned, is that I do the same trick after a decimal is entered. For example “1.2.” displays as “1.2+i” ready for the ipart. This is the same deal as with the Exp key. Im going to leave it this way for a bit and see how I get on with actual use, and see if it “works”. However, I’m always open to others’ ideas and suggestions. For example anyone got any ideas for the MANT key? Also, im hoping to get the 1.3.7 "good" :-) release out this week. If anyone wants to flash their watch with my current 1.3.7 "bleeding edge" for testing, please contact me. i'll email you a .HEX file. cheers, -- hugh.

Re: Yowser! Message #47 Posted by Marcus von Cube, Germany on 3 Nov 2008, 8:38 a.m., in response to message #46 by hughsteers A few ideas on display formatting: If the display has redefinable characters, you can easily create smaller superscripted incarnations of the digits in order to denote the exponent. This saves a position for the "E". The next step could be to define special characters for "+i" and "-i" which saves another position in case of complex numbers. Marcus

Re: Yowser! Message #48 Posted by hughsteers on 3 Nov 2008, 11:13 a.m., in response to message #47 by Marcus von Cube, Germany I like the idea of the superscript exponent, but it would take some on-the-fly LCD char redefinitions and presumably the definitions would have to be consistent for both lines at the same time. The +/-i is a neat one, because this would save a char and only cost 2 user definable chars. The max is only 8 unfortunately. Right now I made some small improvements to the complex display. These aren’t so impressive as some of the suggestions here. Currently im removing truly wasted chars such as “1.2e+13” -> “1.2e13” and “1.2e-08” -> “1.2e-8” etc. Ive also now added SQRT, LOG and EXP complex support and also added ABS to the main menu which performs mod for complex. latest HEX file here

Re: Yowser! Message #49 Posted by V-PN on 3 Nov 2008, 12:20 p.m., in response to message #48 by hughsteers If 8 user definable chars exist and you accept these: +i -i then perhaps just E is positive and e is negative for exponent Otherwise consider one more special character: e-

Re: Yowser! Message #50 Posted by DaveJ on 3 Nov 2008, 3:21 p.m., in response to message #49 by V-PN Quote: If 8 user definable chars exist and you accept these: +i -i then perhaps just E is positive and e is negative for exponent Otherwise consider one more special character: e- I don't like the idea of big and small E for positive and negative exponent, very confusing. I think if E is kept it should always be lower case for improved readability. You could have a redefinable "e" character with a negative sign over the top of it for negative exponents too. Plus is assumed of course. The subscript exponent is a great idea though, if it works in practice. Dave.

Re: Yowser! Message #51 Posted by Bill Triplett on 3 Nov 2008, 3:39 p.m., in response to message #48 by hughsteers For the problem of seeing extra internal digits, I like the solution of allowing a user to press and hold the [enter] button as a way to temporarily trigger an expanded display. If this is done while two complex numbers are in the display, and no soft menu labels are active, then the machine could temporarily switch to displaying what had been the bottom complex number on two lines. If so, then it might be best not to require a user to continue holding down the [enter] button to see the expanded display, because the user might want to write down what is visible. When any button is pressed, the temporarily expanded display can go back to the original condition with two compact complex numbers visible in the display, with one on each line. The machine has a button for exchanging x and y, so if a user has a compact complex number presently on the top line of the display, and wants to temporarily expand that number and see all of the digits, then a user could press the [x exchange y] button first to put the object of interest down on the bottom line, and then press and hold [enter] to temporarily switch the display into expanding the complex number onto two lines. After doing this, the user could press any key, and have the display return to the compact form. At this point, pressing the [x exchange y] button again would put everything back as it had been. This would allow a uWatch user an option for temporarily reviewing the full set of digits for either the x or y register, but for rapid calculations the display could stay in the compact form while displaying both the real and imaginary parts of two complex numbers. The machine only needs a few more digits to make this a non-problem, but I suspect that even a slightly wider display would reduce the nerd value of this tiny curiosity. Edited: 3 Nov 2008, 3:41 p.m.

Re: Yowser! Message #52 Posted by V-PN on 4 Nov 2008, 4:12 p.m., in response to message #51 by Bill Triplett [pre] [ENTER] does DUP, not avoidable Use [MODE] or [MENU] or rigth parenthesis

Re: Press and hold for two seconds before release. Message #53 Posted by Bill Triplett on 5 Nov 2008, 12:36 a.m., in response to message #52 by V-PN "[ENTER] does DUP, not avoidable" It is avoidable, easily. I did not clearly describe how, perhaps. I have been studying the microcontroller. The PIC has the ability to use timers. The uWatch OS could be set to process the [enter] key normally, and do what is normally done when a user has pressed and released the [enter] button within a short period of time. In a second case, if a user has held the [enter] button down for more than two seconds before releasing the button, the software can be set to recognize that this is a different command, and respond by switching the display mode to fully display all of the digits of one complex number - without doing any other operations, and without pushing anything onto the stack. The software would then go back to the compact display mode after any other button is pressed. This way of temporarily zooming the display so that one complex number is expanded to use both lines of the display until another button is pressed, this could be done with the [enter] button, or any other button. The trick would be in timing how long the button is pressed, and then deciding what action to perform after the button is released. Theoretically, this could be used with several different buttons, and each could be made to produce different actions depending upon how long the button is pressed before it is released. The point is to avoid a situation where a user would need to press and hold a button, and only see a detailed display while holding the button down. The alternative that I have described would free the user's right hand to write down the temporarily expanded number before pressing any other button as a signal to return to the compact display. I am searching for something similar to use as an example, so the idea will be easier to see. I suppose the nearest thing I can see as a similar example is in a PC program called "Corel Draw." In that program, a user can press the F9 key and see one of many vector objects temporarily become the only object on the display, and view fine details. The display can jump back to the usual display of multiple objects, but no other operation can be performed while the display is in this temporarily expanded view. This allows a way of temporarily expanding one of multiple drawing objects for a closer inspection. Anyway, to make this idea work for the uWatch user interface, the software of the uWatch would also need to include some logic for starting a timer and keeping track of how long the [enter] button is pressed before it is released. A short duration press would be handled as a usual press of the [enter] button. A longer press would switch to the temporarily expanded display without causing anything to be pushed onto the stack. In the temporarily expanded display mode, the uWatch would wait for any other button to be pressed before exiting the expanded display. All of this assumes that the software is required to display more than one stack object at a time on the normal display. Personally, I would be happier to see this problem solved in a completely different way, without trying to display numbers in a compact form. Instead of seeing two stack objects at one time, and trying to put both the real and imaginary parts of two separate complex numbers on the display concurrently, I would be happy if the display would automatically change to a mode where only one stack object is displayed at a time, if any of the stack objects is a complex number. If one complex number is displayed on two lines, with the real part on the top line, and the imaginary part on the bottom line, then the software can use two characters at the far left of the display as a label to identify which stack element is presently in the display. The user would need some way to arrow up and down while reviewing the contents of different stack levels. Going up through the stack would change which stack item is in the display. It would change the label from "X:" to "Y:" or "Z:" or "T:" or others. The left side labels for the different stack levels could be numbers like "1:" and "2:" as an alternative. This numbered stack method would be nice if more than four stack levels are provided for the user. While using this two line display strategy, with one complex number on two lines of display, if a user would begin to type a new number, the display would jump from where it is in the stack, and immediately begin displaying the newly typed input item. A single up or down button would be good enough to allow a user to review stack items. The display could go around in a circle when reviewing stack levels. For me, I think the two line approach would be nicer than sometimes having only two significant figures available, but it is worth considering both methods of solving the problem. Each method has different advantages. I hope this helps. Bill Edited: 5 Nov 2008, 12:44 a.m.

Re: Press and hold for two seconds before release. Message #54 Posted by V-PN on 5 Nov 2008, 11:24 a.m., in response to message #53 by Bill Triplett It's a "mode"! => MODE long hold to set, a click to release

Re: Press and hold for two seconds before release. Message #55 Posted by Bill Triplett on 6 Nov 2008, 1:55 a.m., in response to message #54 by V-PN Yes. It is a temporary display mode, one that would not be needed if the display had more characters on each line, or if complex numbers were displayed using two lines. I sure wish I had an HP-35s for testing and comparison. With fewer than 16 charaters on each line, the HP-35s would be a source of inspiration for user interface ideas for the uWatch. I hear the OS for the HP-35s is still buggy, but the machine is probably still worth studying. Edited: 6 Nov 2008, 8:37 a.m.

Re: Yowser! Message #56 Posted by Bill Triplett on 3 Nov 2008, 1:50 p.m., in response to message #42 by V-PN It is nice to keep brainstorming all possibilities. I am keeping the alternate letter idea on my short list of possible ways of producing a compact display. I must confess that I am not very fond of displaying numbers in a way that would not be immediately obvious to people who are used to everyday symbology, but please don't let my asthetic preference rule out considering the alternate letter idea. For me, if I design a human/machine interface that a person cannot use without needing to learn a growing list of special secrets, then I feel as if I am proving that I am not smart enough to make the machine simple and obvious, instead of proving that some people are too stupid to make the machine work as well as I can while I know special secrets. The machine is to be the servant of the users, not the other way around. Of greater interest to me at this point is the question of how to get back to full display of all digits. If you display two components of a complex number on one line, and do this in any particular compact form that fits the two number components into 16 characters, then how can we make it simple for a person to later view all of the internal digits of both components of the complex number? There is no one general anwser that would always be the best way to accomplish this user interface function in a way that would be perfect for all calculators. Choosing ways to do this will require considering how the soft menu keys are used on this particular machine, while thinking about the context of the existing user interface.

Re: Yowser! Message #57 Posted by Jeff O. on 3 Nov 2008, 7:33 a.m., in response to message #27 by hughsteers Awesome! Absolutely awesome! Did I say how awesome it is?

Re: Complex number arithmetic for trig functions Message #58 Posted by V-PN on 1 Nov 2008, 12:57 a.m., in response to message #13 by Bill Triplett With suggested [<-] line edit keys [->] one could then have a single key for both parenthesis [ () ] One can go past the autoinserted right ) using the operation [->] To make life even simpler you don-t need that [->] System could jump over the next closing parenthesus via [ENTER] When there is no more parenthesis it would execute [ENTER] If you say it takes so many [ENTER] presses when you just want to {ENTER] I say let's use long keypress for that unless you want USER mode and "NULL" :-)

Re: Complex number arithmetic for trig functions Message #59 Posted by htom trites jr on 31 Oct 2008, 12:39 p.m., in response to message #10 by hughsteers I have to point out that both parts (the real and the imaginary) are unstable, because the signs of the multiplicands can eventually produce canceling subtractions.

Re: Why not need change sign button or negation button Message #60 Posted by Bill Triplett on 1 Nov 2008, 11:08 a.m., in response to message #59 by htom trites jr On any calculator, it would be possible for a user to type in an input that cannot be evalutated. For example: 1/(3-3) When entering complex numbers, an expression can explode when it might not seem so obvious. For example, if a user would try to divide by the following expression, there should be an explosion: (1 + 2i)*(3 + 4i) - (-5 + 10i) The expression above evalutes to zero, so any line of input that divides by the above expression would force the calculator to display an error. One possible way of representing the same sequence as an inline algebraic expression would be as follows: (1..2)*(3..4)-(-5..10)[enter] This should evaluate to zero. Now, on the same machine, without changing modes, a user could decide to enter the exact same expression without typing it all on one line, and process it as follows: 1..2[enter] 3..4[multiply] [negation]5..10 [subtract] The problem for the uWatch user interface is that in this case with absolutely no usage of the available parenthesis buttons, the keyboard would need to include an additional negation button that would not be interpreted as a command to perform an immediate RPN subtraction. --------------------------------------------------------- Edit ... include this next example using [change sign]. --------------------------------------------------------- The uWatch has a [change sign] button instead of a [negation] button, so another alternative for an input method for the same example would be as follows: 1..2[enter] 3..4[multiply] 5[change sign]..10 [subtract] Now, we are still stuck with needing an extra button on the keyboard, and the minus sign is still not capable of handling everything we might want to do with a minus sign. --------------------------------------------------------- End of edit ... inclusion of example using [change sign]. --------------------------------------------------------- The uWatch has a perfectly good set of parenthesis buttons available, so the machine can also be capable of accepting algebraic input, so as an alternative, the exact same sequence could be represented in a simpler way as follows: 1..2[enter] 3..4[multiply] (-5..10) [subtract] In this way, there would be no need for a [change sign] button, and there would be no need for a [negation] button. The single [minus sign] button would be good enough to handle all three ideas. Notice that the user in this last example would still be doing all of the thinking in RPN mode, and making full use of the utility of the stacks. I would like to suggest that the input processor using this convention should not require a closing parenthesis to be present at the end of the third line before the user would press the [subtract] button. There should be no error if the user decides to include the closing parenthesis. The same thing should be true when entering longer inline algebraic expressions with missing closing parenthesis. Instead of smartly announcing that a closing parenthesis is missing, and refusing to evalutate the expression, the machine should simply add a closing parenthesis for the user,if it is not typed, and proceed to provide a useful numeric result. The machine exists to serve the user, not the other way around. I know, I know. It can seem the other way in too many cases. Edited: 1 Nov 2008, 10:58 p.m.

Re: Complex number arithmetic for trig functions Message #61 Posted by hughsteers on 4 Nov 2008, 5:58 a.m., in response to message #59 by htom trites jr Yes, that’s true. In fact, I had a go at implementing the temporary doubled precision for the cross product parts of the complex multiply, and have run into trouble already. I’m getting problems from the usual binary non-representability. Something like (1.00005+i)^2 is ok, but (1.00001+i)^2 is not because the “1” of the latter is not extended into double precision _before_ the multiply. Example (on the current uWatch code): 1.0000001 + i ENTER X^2 REAL gives 2.000000101e-7 Should be (2.0000001e-7) Which annoyingly is the same result from single precision. This is due to the fact that the recurrent “1” is lost in the extended low order double of the double-double precision and results in no actual improvement. Hurumph!

Re: What is the smallest full trig calculator in production? Message #62 Posted by Walter B on 29 Oct 2008, 2:44 a.m., in response to message #1 by Bill Triplett Bill, Quote: Did I mention that the tiny HP-15C also would invert a matrix? I don't think we need that exact machine to go back into production, but something tiny and complete would be appreciated. Do you mean something like this?

Re: What is the smallest full trig calculator in production? Message #63 Posted by Rodger Rosenbaum on 29 Oct 2008, 5:28 a.m., in response to message #62 by Walter B Thou most unkind person, to torture me with visions of what I cannot have! The HP15C had its hour upon the stage, and those of us who watched it there can only say: When comes such another?

Re: What is the smallest full trig calculator in production? Message #64 Posted by Bill Triplett on 29 Oct 2008, 8:09 a.m., in response to message #62 by Walter B That is beautiful, and it certainly has the smallest mass, being composed of virtual mass particles. I was just looking at the 42s, and I see that it has not been in production since 1995. Thus, I am still stuck with nothing small that is currently in production while being capable of fully replacing my vector slide rule's math functionality, straight out of the box.

Re: What is the smallest full trig calculator in production? Message #65 Posted by Mark Edmonds on 29 Oct 2008, 8:27 a.m., in response to message #62 by Walter B Quote: Bill, Do you mean something like this? Have you defined the menu structure for how such a beast would work? That is a great looking design - very comprehensive. My only criticism would be the area taken up by the HP15S badge which is ~central (and should be at an edge) so swapping it with the display would make the display more central and solve the design continuity of the badge always being at an edge/corner. I'd also love to see something like this design but with assembler mnemonics, similar to the old M6800 which had such an elegant and simple design. Having a pocket device which emulated a M6800 and produced by HP would be a match made in heaven! :) Mark

Re: What is the smallest full trig calculator in production? Message #66 Posted by Mark Edmonds on 29 Oct 2008, 8:28 a.m., in response to message #65 by Mark Edmonds Also, would it be possible to write a KML script to emulate your calculator using EMU48 and the 48GX ROM? Mark

Re: What is the smallest full trig calculator in production? Message #67 Posted by Walter B on 29 Oct 2008, 8:48 a.m., in response to message #66 by Mark Edmonds Sure, if you teach me how to do it :)

Re: What is the smallest full trig calculator in production? Message #68 Posted by Walter B on 29 Oct 2008, 8:46 a.m., in response to message #65 by Mark Edmonds Mark, Quote: Have you defined the menu structure for how such a beast would work? Yes, you find it published in DATAFILE V27N3 for a similar calculator of my design shop. An earlier version was presented to the board of HHC 2007, and was given to HP then. Quote: That is a great looking design - very comprehensive. Thank you for your kind words. Quote: My only criticism would be the area taken up by the HP15S badge which is ~central (and should be at an edge) so swapping it with the display would make the display more central and solve the design continuity of the badge always being at an edge/corner. The reason for the display being left-aligned is having 6 soft keys. IF you swap badge and display THEN two soft keys would lay on "7" and "8". Form follows function ;) I don't need a badge anyway, but understand HP wanting one. Ceterum censeo: HP, launch a 43s (or 15s). Walter Edited: 29 Oct 2008, 11:58 a.m.

Re: What is the smallest full trig calculator in production? Message #69 Posted by V-PN on 1 Nov 2008, 9:43 a.m., in response to message #65 by Mark Edmonds I suggest a radical thing: using F for negative exponents -1.234E-123-i1.23E-321 would become (131 pixels ~22 character) : -1.2345F123-i1.23eF321 in minifont: (131 pixels ~33 characters) : -1.23456789E-123-i1.23456789E-321 would be -1.234567890F123-i1.234567890F321 Actually, if one would suppress the sign in complex numbers and in the same way use j as a negative imaginary part signal we could have: (22 chars) -1.234E-123-i1.23E-321 -1.2345F123-i1.23eF321 -1.2345F123j1.234eF321 in minifont: (131 pixels ~33 characters) : -1.23456789E-123-i1.23456789E-321 would be -1.234567890F123-i1.234567890F321 -1.2345678901F123j1.234567890F321 For the display hight I think of the old Saturn 28,18,19 models with 4 level stack (in minifont 5 levels or 4 + menu or 4 + LastX) What do you think?

Re: What is the smallest full trig calculator in production? Message #70 Posted by Dave Shaffer (Arizona) on 1 Nov 2008, 11:16 a.m., in response to message #69 by V-PN I don't think this is a good idea: The rest of the world already considers us a bunch of wierdos. With your F and j notation, anybody not in the know who picked up the calculator would have no idea what was going on = NO SALE! I think you better stick with convention (and maybe hope for a more-pixel display becoming available!).

Re: What is the smallest full trig calculator in production? Message #71 Posted by V-PN on 1 Nov 2008, 2:57 p.m., in response to message #70 by Dave Shaffer (Arizona) You just described RPN... ;-)

Re: What is the smallest full trig calculator in production? Message #72 Posted by David Dyte on 29 Oct 2008, 8:24 a.m., in response to message #1 by Bill Triplett Perhaps Nonpareil 15C could be ported to the iPhone...? I have pcalc on my iPhone which does a fine job with roots and trig, although there is no handling of complex numbers that I know of.

Re: What is the smallest full trig calculator in production? Message #73 Posted by PeterP on 29 Oct 2008, 11:01 a.m., in response to message #72 by David Dyte All Voyagers are available on the iPhone in fabulous implementations. Search for SCI-15 for the 15c and prg-16 for 16c, fin-12 for the 12C. There also is an 11c from the same author, but I don't know the name for it. From personal experience, it is quite fabulous to have a 16C, 15C and 41cx with you at all times in your phone... Cheers Peter

Re: What is the smallest full trig calculator in production? Message #74 Posted by David Dyte on 29 Oct 2008, 12:03 p.m., in response to message #73 by PeterP On my way to the app store now... thanks!

Re: What is the smallest full trig calculator in production? Message #75 Posted by Don Shepherd on 29 Oct 2008, 10:22 a.m., in response to message #1 by Bill Triplett Bill, have you checked out the Casio fx9860G Slim? It is very compact, has a backlit screen, and I think it offers the features you mention.

Re: What is the smallest full trig calculator in production? Message #76 Posted by Bill Triplett on 29 Oct 2008, 11:26 a.m., in response to message #75 by Don Shepherd Many years ago, I drew up a design for a calculator. I described it on a few message boards, but nothing came of it. My design was thin, with a folding dot matrix display, and function keys were situated in a single row along the top of the keyboard, near the base of the display hinge. I worked out a menu idea for the function keys where there would be a "menu" button at the top right of the keyboard, and an "esc" button at the top left of the keyboard. The Casio 9860G Slim that appeared a few years afterward is a similar idea. My daughter thinks it is too similar to be a coincidence, but I have no idea whether the Casio designers were influenced by my draft sketches, or whether it might have been parallel evolution. Anyway, their machine does not perform hyperbolic functions with complex numbers as arguments, and they did not arrange the machine's display screen so that it would take up almost all of the folding cover the way I had hoped. If they had used a bigger display, then the bottom edge of the display screen could have had dynamic function key labels located physically near each associated function key. I strongly disliked the way the Texas Instruments Voyage 200 always wasted a part of the display area with menu tabs at the top of the display, and their menu tabs would continue to waste part of the display area even while presenting a graph of a function. I wanted the entire display to be available for the graph while in graphing mode, so I presented the alternate menu system idea to TI, Casio, and HP. This might have influenced TI to put a "menu" button on the right, and an "esc" button on the left of their new TI-Nspire. Again, it could have been parallel evolution of thinking, probably was since they did nothing with function keys. At least they now have the menu tabs go away when not needed. Other than the small display with a large frame border, the Casio 9860G slim system looks virtually the same as my menu key design. Their machine even exactly duplicates the hinge mechanism that I had pictured because I had thought it would be the strongest and cheapest to build. Functionally, their machine does not use the streamlined menu system that I had suggested, and it leaves out several math functions I had documented as menu items. Complex number support would not have been terribly difficult to support in functions like hyperbolics, so I have no idea why it was skipped. It would not have cost them any more to include the functions, other than a tiny bit more ROM space for the necessary internal equations.

Re: What is the smallest full trig calculator in production? Message #77 Posted by Walter B on 29 Oct 2008, 12:06 p.m., in response to message #76 by Bill Triplett Bill, I'd be very interested in your old design. If you want, you may mail it to me as well.

Re: What is the smallest full trig calculator in production? Message #78 Posted by Bill Triplett on 29 Oct 2008, 3:34 p.m., in response to message #77 by Walter B The files are probably still on the data hard disk of the old Millennium PC I gave to my daughter back when she was a baby. It may take a few days, but I will be curious to find the files. When I do, I will forward. I remember I put the number keys in a single horizontal row directly under the bottom edge of the display hinge. When the user pressed the "memu" button at the top right of the keypad, the number keys became the function keys. Their functional labels would appear on the bottom edge of the display, right above each number button. The keypad had a small qwerty set of buttons, along with arrow keys, and a bare minimum set of math operator buttons. The keyboard could be neat and clean, because there was no need for multiple labels on any of the buttons. Greek symbols, math function symbols, and everything else had been organized into categories under the main function key menu that would appear initially when a user would press the "menu" button. After a user navigated the menu and selected a function, the menu would go away. I used a similar idea when organizing the function key menu for controlling an airborne radar system back in the 1980's. The radar operators could press two or three logically connected buttons in a sequence and produce hundreds of different operations using only a few function keys. The operators could not afford to have multiple tiny labels printed on shifted buttons all over a dimly lit keyboard, but they could see the bottom edge of a display screen. Everything had to be ultra simple and neat in that environment, in order to reduce the possibility of errors that would have had disastrous consequences.

Re: What is the smallest full trig calculator in production? Message #79 Posted by DaveJ on 29 Oct 2008, 5:40 p.m., in response to message #76 by Bill Triplett Quote: Many years ago, I drew up a design for a calculator. I described it on a few message boards, but nothing came of it. My design was thin, with a folding dot matrix display, and function keys were situated in a single row along the top of the keyboard, near the base of the display hinge. I worked out a menu idea for the function keys where there would be a "menu" button at the top right of the keyboard, and an "esc" button at the top left of the keyboard. The Casio 9860G Slim that appeared a few years afterward is a similar idea. My daughter thinks it is too similar to be a coincidence, but I have no idea whether the Casio designers were influenced by my draft sketches, or whether it might have been parallel evolution. That format is not new, it's been around for a very long time (like 25 years) in pocket computers, PDA's, and games. We'd love to see your sketches though. Dave. Edited: 29 Oct 2008, 5:43 p.m.

Re: What is the smallest full trig calculator in production? Message #80 Posted by Bill Triplett on 29 Oct 2008, 5:43 p.m., in response to message #79 by DaveJ No one said the format was new. How it is used, that would be different.

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.

Re: What is the smallest full trig calculator in production? Message #82 Posted by Norris on 29 Oct 2008, 9:08 p.m., in response to message #1 by Bill Triplett Unfortunately, there is no market for small powerful calculators anymore -- just as there is no market for small powerful slide rules. There is still a market for powerful calculators, but in the 21st Century it is taken for granted that a high-end calculator will have a large display, capable of graphing. And a graphing calculator with a large display won't be small. It's not just complex functionality that has disappeared from small calculators. The 15C was programmable too, and that's another feature that is now largely extinct, except in large graphing calculators. In the US, the only non-graphing programmable calculators that are readily available are the 33S and the 35S. And they probably hang on for just one reason: they are the most powerful calculators allowed on the NCEES licensing exams for engineers and surveyors. Graphing calculators are banned on NCEES exams, and this ban has created a small, but dependable, market niche for scientific programmables. If you look up the 33S or 35S on Amazon.com, you will see a list of "Customers Who Bought This Item Also Bought...". The list will be full of NCEES exam study manuals.

Re: What is the smallest full trig calculator in production? Message #83 Posted by DaveJ on 29 Oct 2008, 10:12 p.m., in response to message #82 by Norris Quote: Unfortunately, there is no market for small powerful calculators anymore -- just as there is no market for small powerful slide rules. There is still a market for powerful calculators, but in the 21st Century it is taken for granted that a high-end calculator will have a large display, capable of graphing. And a graphing calculator with a large display won't be small. It's not just complex functionality that has disappeared from small calculators. The 15C was programmable too, and that's another feature that is now largely extinct, except in large graphing calculators. In the US, the only non-graphing programmable calculators that are readily available are the 33S and the 35S. Casio make a whole range of non-graphing programmables, they list 8 of them at present. But you are correct, for sale almost everywhere except the US. Dave.

Re: What is the smallest full trig calculator in production? Message #84 Posted by Walter B on 30 Oct 2008, 2:36 a.m., in response to message #83 by DaveJ Quote: Casio make a whole range of non-graphing programmables, they list 8 of them at present. But you are correct, for sale almost everywhere except the US. Which proves clearly a calculator range can live well covering 95% of the world instead of only 5%, and the latter decreasing. Ceterum censeo: HP, launch a 43s (think (!) of the world). Walter

Re: What is the smallest full trig calculator in production? Message #85 Posted by Norris on 30 Oct 2008, 5:32 p.m., in response to message #83 by DaveJ Quote: Casio make a whole range of non-graphing programmables, they list 8 of them at present. But you are correct, for sale almost everywhere except the US. My perspective is from the US, but from what I can tell, the rest of the world is not exactly awash in Casio scientific programmables. The Casio Worldwide Education Website does list a total of eight programmable scientifics. But it appears to me that there are two caveats: First, most of these models have rather marginal programming capabilities, such as small program memories (< 1 kb) or "programming" by formula storage. Second, while none of these models are offered in the US, they aren't necessarily all available in all overseas markets either. For example, the Casio UK website shows only one of these models, the FX-50FPLUS (which can store only 4 progams over 680 bytes of memory). The newest and best of the Casio models seems to be the FX-5800P, which seems comparable to a 33S or 35S (it even has built-in matrix support, which the HPs lack). At amazon.de, the 5800P is 52 euros, vs. 65.15 for the 35S (they don't list the 33S). The 5800P has a 4-line display, obviously larger than that of a 33S/35S. But not surprisingly, the overall length of the 5800P is even greater. The 5800P has another feature that the HPs lack: an output port, which is designed to connect via cable to other calculators. This feature would likely be frowned on by NCEES, which is very paranoid about calculators with any sort of communications capability. It seems unlikely that the 5800P would be allowed on NCEES exams (although other non-programmable Casios are). This could possibly explain why Casio does not bother to market the 5800P here. Edited: 30 Oct 2008, 5:32 p.m.

Re: What is the smallest full trig calculator in production? Message #86 Posted by Bill Triplett on 30 Oct 2008, 6:05 p.m., in response to message #85 by Norris The PDF user's manual for the Casio 5800P does not seem to say definitively whether the machine will accept complex numbers as inputs to the trig functions. It seems unlikely, since none of the examples of using complex numbers provided in the user's manual depict anything other than four function arithmetic.

Re: What is the smallest full trig calculator in production? Message #87 Posted by Norris on 31 Oct 2008, 2:04 p.m., in response to message #86 by Bill Triplett I agree. And even if the 5800P had full complex functionality, it still wouldn't meet your desire for a "small" trig calculator. I've only seen photos, but my impression is that the 5800P, with its 4-line display, isn't much smaller than a full-blown graphing calculator like the 50G.

Re: What is the smallest full trig calculator in production? Message #88 Posted by Bill Triplett on 1 Nov 2008, 12:20 p.m., in response to message #87 by Norris It still astounds me that I can do everything with complex numbers using my six inch hyperbolic slide rule, and it fits neatly into a vest pocket. At least the HP-15C was a serious attempt to create something almost as complete and compact.

Re: What is the smallest full trig calculator in production? Message #89 Posted by Rodger Rosenbaum on 1 Nov 2008, 7:42 p.m., in response to message #88 by Bill Triplett Why do you say "almost"? What can the slide rule do that the HP-15C can't do?

Re: What is the smallest full trig calculator in production? Message #90 Posted by Bill Triplett on 2 Nov 2008, 2:43 p.m., in response to message #89 by Rodger Rosenbaum The HP-15C is not the smallest full trig calculator. As far as I know, a properly designed pocket vector slide rule is the smallest machine that can do hyperbolic trig functions with complex numbers as inputs while operating with virtually unlimited battery run time. So I believe the HP-15C fills the requirement of being an inexhaustible ultra light portable trig machine almost as well as my six inch long one tenth inch thin pocket hyperbolic slide rule. Of course, the HP does much more, and it is worth carrying along even though it is considerably larger in a vest pocket. It might not be the smallest machine that can do all trig functions, but it is considerably lighter than any other bulky electronic hyperbolic calculator that I have seen. I still have not quite figured out which machine is the smallest electronic device on the planet that meets the stated requirements, while being presently in production. With proper firmware, the uWatch could meet the requirement list, but it is not in production, except in kit form. Loads of small machines support hyperbolic and circular trig functions, but do not perform the trig functions with complex numbers as inputs. For this, no electronic machine with long battery life has come close to providing the combination of small size and full trig functionality that had been mass produced long ago in the HP-15C. I like my HP-15C almost as much as my pocket hyperbolic rule. I just can't afford to risk breaking either one of the little super machines, because nothing can be had off-the-shelf as a fully featured replacement of the same physical size.

Re: What is the smallest full trig calculator in production? Message #91 Posted by Norris on 3 Nov 2008, 1:14 p.m., in response to message #90 by Bill Triplett Quote: I still have not quite figured out which machine is the smallest electronic device on the planet that meets the stated requirements, while being presently in production. How about a Palm handheld (presently in production) loaded with RootM calculator software (also presently in production)? Complete RootM documentation is here. Seems like it can do anything a vector slide rule or 15C can do, including RPN, and a whole lot more besides. You could get a Palm Z22 for $99 from Palm.com (possibly for less from other sources), and RootM for $25. Total weight: 3 ounces. Dimensions: 4.06 inches long (smaller than 15C), 2.7 inches wide (also smaller than 15C), 0.6 inches thick (about 0.1 inches more than 15C). Edited: 3 Nov 2008, 1:19 p.m.

Re: What is the smallest full trig calculator in production? Message #92 Posted by Bill Triplett on 3 Nov 2008, 9:32 p.m., in response to message #91 by Norris Thanks. This might be the existing world record holder, at least presently. Any idea how much battery run time the little palm can provide? It is a minor nit, I know, but the ideal would be to have the freedom of working anywhere without needing to rush, and without needing a charger. I have a couple of iPAQs with several nice calculator emulators installed, but my six inch vector slide rule can still win at being small, and inexhaustible.

Re: What is the smallest full trig calculator in production? Message #93 Posted by Norris on 3 Nov 2008, 9:46 p.m., in response to message #92 by Bill Triplett Battery life is regarded as good by handheld standards. This reviewer tested a Z22 by setting it to continuously run a "slide show" of color pictures at 50% contrast. The slide show ran for 9.5 hours before the battery ran out. The reviewer concluded that "under normal use, the Z22 could very well run for a few weeks without needing a re-charge." The Z22 comes with a conventional charger, but it can also "trickle charge" when plugged into a PC via a USB cable. ******** And needless to say, the color picture slide show feature is a killer app not available on slide rules or the HP-15C. The Z22 not only fits easily in your shirt pocket -- it stores your family pictures, so you no longer have to keep photos in your wallet, which means that it *also* frees up space in your pants pocket. Edited: 3 Nov 2008, 10:14 p.m.

Re: What is the smallest full trig calculator in production? Message #94 Posted by Norris on 4 Nov 2008, 12:48 p.m., in response to message #88 by Bill Triplett Quote: It still astounds me that I can do everything with complex numbers using my six inch hyperbolic slide rule, and it fits neatly into a vest pocket. Everything? Can you add or subtract complex numbers with your slide rule? Edited: 4 Nov 2008, 12:49 p.m.

Re: What is the smallest full trig calculator in production? Message #95 Posted by Bill Triplett on 5 Nov 2008, 1:33 a.m., in response to message #94 by Norris Good point, but adding is simple enough to do mentally, which is why linear number lines for addition have too little appeal to be included on most slide rules. There were almost no exceptions in four hundred years. The point is that the advanced trig functions that you cannot do in a few moments with a scrap of paper are fully supported by very few small machines, and the ones that do this are not as comfortable to carry along as a well made six inch vector slide rule. Thanks for poking me to restate the point. All of this just makes me appreciate my HP-15C more. It is pretty small for what it does.

Re: What is the smallest full trig calculator in production? Message #96 Posted by Don Jennings on 3 Nov 2008, 3:48 p.m., in response to message #85 by Norris Quote: My perspective is from the US, but from what I can tell, the rest of the world is not exactly awash in Casio scientific programmables. The Casio Worldwide Education Website does list a total of eight programmable scientifics. But it appears to me that there are two caveats: First, most of these models have rather marginal programming capabilities, such as small program memories (< 1 kb) or "programming" by formula storage. Second, while none of these models are offered in the US, they aren't necessarily all available in all overseas markets either. For example, the Casio UK website shows only one of these models, the FX-50FPLUS (which can store only 4 progams over 680 bytes of memory). The newest and best of the Casio models seems to be the FX-5800P, which seems comparable to a 33S or 35S (it even has built-in matrix support, which the HPs lack). At amazon.de, the 5800P is 52 euros, vs. 65.15 for the 35S (they don't list the 33S). The 5800P has a 4-line display, obviously larger than that of a 33S/35S. But not surprisingly, the overall length of the 5800P is even greater. The 5800P has another feature that the HPs lack: an output port, which is designed to connect via cable to other calculators. This feature would likely be frowned on by NCEES, which is very paranoid about calculators with any sort of communications capability. It seems unlikely that the 5800P would be allowed on NCEES exams (although other non-programmable Casios are). This could possibly explain why Casio does not bother to market the 5800P here. I just saw the latest NCEES list, short list! Allowed: Casio FX115, HP 33S and HP35S and TI30X and TI36X. Jeez, even my casio FX300 would be banned! It is not even programmable!

Re: What is the smallest full trig calculator in production? Message #97 Posted by Bill Triplett on 3 Nov 2008, 5:38 p.m., in response to message #96 by Don Jennings I suppose they would require students to erase all programs from the HP-35S, of course.

Re: What is the smallest full trig calculator in production? Message #98 Posted by Norris on 3 Nov 2008, 6:53 p.m., in response to message #97 by Bill Triplett Quote: I suppose they would require students to erase all programs from the HP-35S, of course. No, not at all. You have it completely backwards. It's perfectly legal to program your HP-35S in advance of an NCEES exam, and several commercial vendors sell HP calculator software for exactly this purpose. In fact, probably the only significant markets for commercial calculator software that still exist today are (1) surveying packages, and (2) NCEES exam software. It's true that NCEES is extremely paranoid about exam calculators -- but they are only concerned with what you might take OUT of the exam room, not what you bring IN. They don't want people typing actual test questions or answers into their calculators, then downloading the info to PCs and emailing it around. So they ban calculators with text-handling capabilities and I/O. Back when large graphing calculators were legal, NCEES actually caught a guy who installed a handheld scanner in the body of an HP-48 and used it in the exam room to copy questions. Edited: 3 Nov 2008, 7:07 p.m.

Re: What is the smallest full trig calculator in production? Message #99 Posted by Bill Triplett on 3 Nov 2008, 7:08 p.m., in response to message #98 by Norris The really real world can be so strange. Soon, people with glass eyes will have cameras inside. I would definitely take the HP-35S from the available choices.

Re: What is the smallest full trig calculator in production? Message #100 Posted by Norris on 3 Nov 2008, 7:18 p.m., in response to message #99 by Bill Triplett Many people, even among state licensing boards, regard the NCEES calculator policy as overly conservative. For example, the California Engineering Board uses NCEES exams, but supplements them with non-NCEES, state-specific exams in certain disciplines. The California Board is required to enforce the NCEES calculator policy on NCEES exams, but does not enforce it on the state-specific exams. So you can still use an HP48G or other graphing calculators on certain licensing exams in California. California only bans models with QWERTY keyboards. Edited: 3 Nov 2008, 7:19 p.m.

Re: What is the smallest full trig calculator in production? Message #101 Posted by Jeff O. on 3 Nov 2008, 9:12 p.m., in response to message #98 by Norris Quote: Back when large graphing calculators were legal, NCEES actually caught a guy who installed a handheld scanner in the body of an HP-48 and used it in the exam room to copy questions. That guy ruined it for everybody. Of course it would be totally impossible to install a scanner or imager of some kind in the body of a 35s or another of the allowed calculators. So the policy makes perfect sense.....

Re: What is the smallest full trig calculator in production? Message #102 Posted by Jeff O. on 4 Nov 2008, 12:39 p.m., in response to message #101 by Jeff O. Quote: That guy ruined it for everybody. But then again, perhaps he saved the hp calculator division, at least scientific calculators. Without the steady market for the 33s and now the 35s provided by the NCEES calculator restrictions, perhaps hp would have just said to heck with producing any new scientific models.

Re: What is the smallest full trig calculator in production? Message #103 Posted by Norris on 3 Nov 2008, 7:02 p.m., in response to message #96 by Don Jennings Quote: I just saw the latest NCEES list, short list! Allowed: Casio FX115, HP 33S and HP35S and TI30X and TI36X. Jeez, even my casio FX300 would be banned! It is not even programmable! NCEES only accepts calculators that are deemed to lack text handling capabilities and I/O. Of course, there are many other calculator models, including the Casio FX300, that meet this standard. However, NCEES intentionally keeps the list of approved models very short, in order to simplify enforcement by exam proctors, who are typically not calculator enthusiasts. Since NCEES-approved TI and Casio models cost as little as $15-20, this doesn't seem like a huge hardship. Incidentally, NCEES should be publishing a new "approved" list for 2009 in a couple weeks. Edited: 3 Nov 2008, 7:05 p.m.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall