35s thoughts and a bug « Next Oldest | Next Newest »

 ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 07-27-2007, 09:13 PM 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 ▼ Egan Ford Posting Freak Posts: 1,619 Threads: 147 Joined: May 2006 07-27-2007, 09:58 PM 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. ▼ bill platt Posting Freak Posts: 2,448 Threads: 90 Joined: Jul 2005 07-28-2007, 06:14 PM 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. ▼ Trent Moseley Senior Member Posts: 406 Threads: 47 Joined: Jul 2005 07-28-2007, 10:51 PM Awwh, come on Bill. I like a calc, like the 15C or a 42s that can handle all numbers in stride. tm Rodger Rosenbaum Senior Member Posts: 305 Threads: 17 Joined: Jun 2007 07-29-2007, 05:06 AM 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? Karl Schneider Posting Freak Posts: 1,792 Threads: 62 Joined: Jan 2005 07-28-2007, 08:00 PM 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. ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 07-29-2007, 05:23 PM 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 ▼ Karl Schneider Posting Freak Posts: 1,792 Threads: 62 Joined: Jan 2005 07-29-2007, 06:56 PM "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 ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 07-29-2007, 08:15 PM 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 DaveJ Posting Freak Posts: 1,092 Threads: 57 Joined: May 2007 07-28-2007, 02:41 AM 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. ▼ Walter B Posting Freak Posts: 4,587 Threads: 105 Joined: Jul 2005 07-28-2007, 02:45 PM That's what's called added value ;-) Wayne Brown Senior Member Posts: 489 Threads: 11 Joined: Jan 2005 07-28-2007, 09:43 PM 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. Charles Bennett Junior Member Posts: 17 Threads: 3 Joined: Jul 2007 07-29-2007, 12:42 PM 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. ▼ Gene Wright Posting Freak Posts: 1,545 Threads: 168 Joined: Jul 2005 07-29-2007, 02:59 PM What word about the labeling paradigm? ▼ Charles Bennett Junior Member Posts: 17 Threads: 3 Joined: Jul 2007 07-29-2007, 06:36 PM 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.

 Possibly Related Threads... Thread Author Replies Views Last Post "A Penny for your thoughts" on the HP50g Tom Grydeland 3 1,261 08-01-2013, 03:57 AM Last Post: Les Koller Is the HP-35S bug free? Matt Agajanian 22 4,671 07-01-2013, 04:03 PM Last Post: Andrés C. Rodríguez (Argentina) A Non-Graphing Calculator with CAS? Thoughts...? mr-scorpio 1 778 02-17-2013, 01:02 AM Last Post: Les Koller [WP34S] Beginner's positive thoughts - 1 week in. Chris Tvergard 7 1,774 05-14-2012, 03:35 PM Last Post: Walter B Re: [WP34S] Beginner's positive thoughts - 1 week in. Chris Tvergard 2 1,086 05-13-2012, 06:50 PM Last Post: Chris Tvergard thoughts about HP-35S P<-->R Matt Agajanian 3 978 04-07-2012, 08:47 PM Last Post: Matt Agajanian Bad News for 33S: a bug shared with 35s bill platt 20 3,985 03-25-2012, 03:57 AM Last Post: Paul Dale Is this another bug for the 35s? Matt Agajanian 8 1,701 03-02-2012, 02:54 PM Last Post: Matt Agajanian HP 41CL; requirements and thoughts about donor shells Geoff Quickfall 11 2,506 12-06-2011, 11:04 PM Last Post: Randy 15c LE thoughts kc 20 3,375 10-20-2011, 01:14 PM Last Post: Ethan Conner

Forum Jump: