The Museum of HP Calculators

HP Forum Archive 17

 35s thoughts and a bugMessage #1 Posted by Paul Dale on 27 July 2007, 9:13 p.m. Some quick initial thoughts before I go back to playing: Very light. I'm not sure if this is a plus or a minus just yet. I guess it will boil down to personal preference. The case seems decent enough, more like a gameboy case than a calculator one but I can live with that. Fast. I don't have a 33s so I cannot compare it with that but it feels a lot faster than my 32sii. What a poor selection of complex operations. I know they are the same as on the 32sii and 33s but those models lacked proper complex numbers. Why no x-th root of y, square root or square? Orange (left) shift C for off feels very unnatural. Luckily Blue (right) shift C does the same function. The keyboard layout will take a bit of getting used to but I'm fast warming to it. And I think I found a bug. Enter a 999 line single label program. The calculator rightfully doesn't allow you to enter any more steps. However, it also doesn't allow you to enter a new LBL step either. Oops. If you enter 998 steps, then the new label and then go back and fill in the 999th step, all is well. You also cannot create two programs whose combined length is > 999 steps and delete the LBL for the second, so some thought had been put into long program sizes. - Pauli

 Re: 35s thoughts and a bugMessage #2 Posted by Egan Ford on 27 July 2007, 9:58 p.m.,in response to message #1 by Paul Dale Quote:What a poor selection of complex operations. I know they are the same as on the 32sii and 33s but those models lacked proper complex numbers. Why no x-th root of y, square root or square? Add 0i0 to y, then y^x will work. I do not understand how 15C/42S thinking and functionality got dropped. My tests: sqrt(-1) returns: SQRT(NEG) -1 .5 y^x returns: INVALID y^x sqrt(-1i0) returns: INVALID DATA -1i0 .5 y^x returns: 0i1, finally. It should not be this hard.

 Re: 35s thoughts and a bugMessage #3 Posted by bill platt on 28 July 2007, 6:14 p.m.,in response to message #2 by Egan Ford I really don't see why you consider this to be such a bad thing. y^x is the most general form for *any* exponential, and that includes roots. The machine is designed so that the sqrt function is for reals only. Furthermore, for complex numbers, the machine merely "asks" that you provide valid arguments. Therefore, a "-1" is invalid--on this machine it is a real number. Simply provide the complex equivalent and use y^x and you can do all. I don't see anything so terrible about keeping the real and complex argument results separate. It would be a royal pain in the neck if it parsed a -1 asa complex number automatically.

 Re: 35s thoughts and a bugMessage #4 Posted by Trent Moseley on 28 July 2007, 10:51 p.m.,in response to message #3 by bill platt Awwh, come on Bill. I like a calc, like the 15C or a 42s that can handle all numbers in stride. tm

 Re: 35s thoughts and a bugMessage #5 Posted by Rodger Rosenbaum on 29 July 2007, 5:06 a.m.,in response to message #3 by bill platt Bill, you say "...on this machine it (-1, that is) is a real number." You also say "...the sqrt function is for reals only." So if -1 is a real number and the sqrt function is for reals only, then there shouldn't be any problem with sqrt(-1), should there?

 Re: 35s complex-number functionalityMessage #6 Posted by Karl Schneider on 28 July 2007, 8:00 p.m.,in response to message #2 by Egan Ford Paul Dale posted, Quote: What a poor selection of complex operations. I know they are the same as on the 32sii and 33s but those models lacked proper complex numbers. Why no x-th root of y, square root or square? Egan Ford posted, Quote: Add 0i0 to y, then y^x will work. I do not understand how 15C/42S thinking and functionality got dropped. My tests: ```sqrt(-1) returns: SQRT(NEG) -1 .5 y^x returns: INVALID y^x sqrt(-1i0) returns: INVALID DATA -1i0 .5 y^x returns: 0i1, finally. It should not be this hard. ``` Addressing both of these insightful posts together: Indeed, "15C/42S thinking and functionality" regarding complex numbers was the right target, but no other RPN calculator incorporated its three principles: Complex-number functionality is provided for every transcedental mathematical operation for which it is defined. The user is given the choice whether a complex-valued result or an error message is to be provided if no real-valued result is defined. Complex numbers are handled as single entities for computation using standard mathematical functions, not special commands. The first principle is self-explanatory, but few calculators fulfill it, even the ones that boast of "complex numbers". On the HP-15C, the second principle was implemented by the status of Flag 8. On the HP-42S, it was implemented by the choice "RRES" (real result) or "CRES" (complex result). The complex-number functionality of the HP-32S, HP-32SII, HP-33s, and now apparently the HP-35s, was essentially a porting of the HP-41 Math Pac's RPN routines. This set of routines was not mathematically complete, and could not fulfill the third principle due to design limitations. x2, sqrt(x), and x-th root of y for complex-valued x and y were not provided because they were not absolutely necessary: yx can be used for those calculations. It's apparent that yx is defined in the complex domain on the HP-35s only when y is clearly identifiable as complex-valued. This is because ```y^x = e^(ln(y^x)) = e^(x*ln(y)) ``` and the second principle is not fulfilled. I'm sure that the same holds for all other transcedental functions that require natural logarithm of a complex-valued argument. It seems that the main improvement was easier entry and one-line display of complex numbers. A more ambitious improvement that restored the capabilities of the HP-15C and HP-42S would have been the following: If you read the post, you'll see why I consider the omission of Rec->Pol, Pol->Rec, Cx->Re (disassembly of complex number), and Re->Cx (assembly of complex number) on the HP-35s to be blunders. It cannot be said that we MoHPC'ers do not offer constructive product suggestions! -- KS Edited: 29 July 2007, 2:12 a.m.

 Re: 35s complex-number functionalityMessage #7 Posted by Paul Dale on 29 July 2007, 5:23 p.m.,in response to message #6 by Karl Schneider Quote: x2, sqrt(x), and x-th root of y for complex-valued x and y were not provided because they were not absolutely necessary: yx can be used for those calculations. I really don't think this argument holds water. Following it merrily along, we also don't need any of the trig functions or even subtraction defined for complex arguments, they are available easily enough using other complex functionality. Extend this argument to the real functions and we don't need both the hyperbolics and trig functions they relate naturally via complex numbers. LOG and LN? Why bother? e^x, use the constant e and y^x. I could go on and on. The whole point of a calculator is to make life easier, providing a non-obvious but still complete set of functions doesn't gel with me. - Pauli

 Re: 35s complex-number functionality (& US \$1 coin)Message #8 Posted by Karl Schneider on 29 July 2007, 6:56 p.m.,in response to message #7 by Paul Dale "x2, sqrt(x), and x-th root of y for complex-valued x and y were not provided because they were not absolutely necessary: yx can be used for those calculations." Hi, Paul -- You stated: Quote: I really don't think this argument holds water. Following it merrily along, we also don't need any of the trig functions or even subtraction defined for complex arguments, they are available easily enough using other complex functionality. Hey, don't blame the messenger! :-) The HP-41 Math Pac was a "quick and dirty" 4 kB ROM released in 1980 or 1981, to provide some lacking functionality such as complex numbers and hyperbolics, as well as other useful applications such as triangle solutions and Fourier analyses. All functions were implemented as RPN keystroke programs. Sure, dedicated complex-valued functions for square root and square would have been useful on the Math Pac, but space limitations might have precluded that. (The Math Pac did provide real-integer and complex-valued powers and roots for complex-valued arguments as "Z^N", "Z^1/N", "Z^W", and "Z^1/W". Certainly, complex-valued functions for square root and square, as a minimum, ought to have been implemented in microcode for the HP-32S, HP-32SII, HP-33s, and HP-35s, even if the original HP-41 Math Pac didn't have them as RPN routines. But, for whatever reason, they weren't. A historical parallel: The misbegotten US \$1 coins since 1971 Unfortunately, mistakes have a way of becoming immortal by perpetuation. Consider the US \$1 coin. The old ones from the early 20th century were quite large, when a dollar was worth a lot and metals were less pricey by comparison. The 1971 Eisenhower dollar was the same size, but few people wanted to use it, and few vending machines accepted them. As a reaction to that, the next \$1 coin -- the 1979 Susan B. Anthony dollar -- was barely larger than, or distinguishable from, a quarter-dollar. It was rejected by the public, minted only in 1979, 1980, and 1999 as a lead-in to -- the 2000 Sacagawea dollar coin. This new coin was made the same size as the Anthony dollar for compatibility with the machines that accepted it. However, the Sacajawea was goldtone, smooth-sided, and rimmed in order to distinguish it from quarters. It still failed to achieve public acceptance, as Americans preferred their beloved \$1 paper "greenback". Now, there's a new upcoming set of \$1 coins that commemorate presidents. They look more like medallions, and yes, they will be the same size as Anthony and Sacagawea dollars. If that is true, I predict general failure once again to achieve widespread usage (as opposed to um, "seigniorage-producing collecting activity"). So, the bottom line of all that: If only the \$1 coins from 1971 or 1979 had been made a reasonable and practical size -- not too big, but not just barely larger than a quarter -- and if the \$1 paper bill had been politely but firmly phased out, we'd be using practical, long-lasting coins for small low-tech transactions, as most Western countries do. Instead, we use low-value coins and problematic paper currency -- all because of unsound thinking, perpetuation of mistakes, and an unwillingness to make unpopular decisions or expend the effort for progress. So today, if the HP-35s doesn't have a mathematically-complete set of complex-valued functions, that can be traced back originally to the compromises made in the HP-41 Math Pac 27 years ago -- and the unwillingness to research the product history, and to make the effort to rectify shortcomings. -- KS Edited: 30 July 2007, 9:56 p.m. after one or more responses were posted

 Re: 35s complex-number functionality (& US \$1 coin)Message #9 Posted by Paul Dale on 29 July 2007, 8:15 p.m.,in response to message #8 by Karl Schneider Quote: Hey, don't blame the messenger! :-) I wasn't :-) Sorry if it came out that way. My objection is that we've a good and proper complex type but the set of operations on it are woeful. As has been pointed out, having the calculator work out sqrt(-1) takes several attempts to get right. Certainly the HP-41 Math Pac can be excused for its lack of coverage. Likewise, I can forgive the 32sii and 33s. They all implement complex numbers poorly. If I've a real complex type, I want to be able to use it easily. As a not really related aside: I've a scientific calculator bought from a discount shop for about A\$5 which includes a "complex" button. I've never been able to figure out what it actually does. - Pauli

 Re: 35s thoughts and a bugMessage #10 Posted by DaveJ on 28 July 2007, 2:41 a.m.,in response to message #1 by Paul Dale Quote: Some quick initial thoughts before I go back to playing: Very light. I'm not sure if this is a plus or a minus just yet. I guess it will boil down to personal preference. If there is space inside the case then it should be easy to glue a thin strip of lead sheet inside, to give it some extra heft. Thin lead flashing sheet is available from hardware stores. Dave.

 Re: 35s thoughts and a bugMessage #11 Posted by Walter B on 28 July 2007, 2:45 p.m.,in response to message #10 by DaveJ That's what's called added value ;-)

 Re: 35s thoughts and a bugMessage #12 Posted by Wayne Brown on 28 July 2007, 9:43 p.m.,in response to message #10 by DaveJ That would give it a more pleasant weight, but would add nothing to the structural strength or durability. Making the whole calculator of thicker, denser materials would be a much better solution.

 Re: 35s thoughts and a bugMessage #13 Posted by Charles Bennett on 29 July 2007, 12:42 p.m.,in response to message #1 by Paul Dale OK... mine showed up on the 20th and I've had a chance to go over it. Just to be clear where I'm coming from: 34C, 15C, 32SII. I like it. It's pretty. It could be heavier and thicker. I'm very happy to have BIG ENTER back since I won't buy a calculator without one. I'm twice as happy to have the south face of the keys back - I've always liked that. I disliked the menus on the 32SII and I dislike them even more here. I'd gladly put 'f' and 'g' legends above the keys and take 'h' shifted functions on the south face. Like everybody else said, the BASE capabilities are a disaster. The complex stuff is done quite nicely. Some features for packing/unpacking complex and vector types on the stack would have been nice. Until I found XEQ foo ENTER, I was pretty cranky about XEQ foo 001 to get at programs. The programming/label paradigm has its ups and downs. Having line numbers being significant GTO and GSB destinations makes it really hard to develop programs in a text editor and then bang them in - this was much easier for the 32SII. On the other hand I use far fewer actual labels and interal labels take up no space. It feels a lot more like programming for HP33E. More on this in a minute... First thing I did was port one of my favorite programs from the 32SII: ```# factor.hp35s # xeq a: factor REGX # xeq b: factor REGY, using known smallest factor in REGX # # X: number to factor # Y: candidate factor # Z: upper bound # # use: # REGX <- number to factor # xeq A enter # # REGX <- number to factor # enter # REGX <- known cofactor # xeq B enter # # once it stops: # if REGX == 1: REGY holds your prime # else: REGX is smallest prime factor, REGY quotient # # hit xeq B enter to find next smallest prime factor # (A) # REGX: number to factor # A001 lbl A A002 3 # start search at 3 # (B) # REGX: known to be at least as large as any known factors of ... # REGY: number to factor # B001 lbl B B002 fix 0 # for rounding B003 sto Y # start search here (REGX) B004 Rv B005 sto X # to be factored (REGY) B006 2 # we always check 2, even if xeq B B007 x >= y # REGX is 1 or 2 B008 gto B023 # (Prime) signify! B009 xeq B026 # (Test) will stop if 2 is a factor B010 rcl X # compute search upper bound B011 sqrt B012 rnd # compensate possible rounding error B013 sto Z # stash it # (Loop) # main test loop # B014 rcl X # target B015 rcl Y # candidate B016 xeq B026 # (Test) will stop if Y is a factor of X B017 rcl Z # fetch upper bound B018 2 B019 rcl + Y B020 sto Y # increment candidate B021 x <= y? B022 gto B014 # (Loop) not done, try next one # (Prime) # REGY <- original number # REGX <- 1 to signal as prime, cheaper than eqn PRIME? # B023 rcl X B024 1 B025 rtn # all done # (Test) # the factor test routine # REGX: candidate factor # REGY: the number we're trying to factor # halt if (REGY mod REGX) == 0 # B026 rmdr # B027 x != 0? B028 rtn # scram, not a factor B029 rcl X B030 last x B031 / # REGX <- quotient B032 last x # push factor B033 stop ``` Runs pretty fast. I'm happy. Now for Gene, a word about the labeling paradigm: ```B034 xeq B028 ``` That's all for now. For the guys at HP: Nice job. Many thanks.

 Re: 35s thoughts and a bugMessage #14 Posted by Gene Wright on 29 July 2007, 2:59 p.m.,in response to message #13 by Charles Bennett What word about the labeling paradigm?

 Re: 35s thoughts and a bugMessage #15 Posted by Charles Bennett on 29 July 2007, 6:36 p.m.,in response to message #14 by Gene Wright We're back to the days of GSB NNN - every line a subr destination. Once again we can write subrs with default args that we can jump into the middle of without burning a label... Including an XEQ to a line that contains a RTN: provided you have subr levels to burn it's a slow NOP with no side effects.

Go back to the main exhibit hall