▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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 xth 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
▼
Posts: 1,619
Threads: 147
Joined: May 2006
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 xth 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.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
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 invalidon 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.
▼
Posts: 406
Threads: 47
Joined: Jul 2005
Awwh, come on Bill. I like a calc, like the 15C or a 42s that can handle all numbers in stride.
tm
Posts: 305
Threads: 17
Joined: Jun 2007
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?
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 xth 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:
 Complexnumber functionality is provided for every transcedental mathematical operation for which it is defined.
 The user is given the choice whether a complexvalued result or an error message is to be provided if no realvalued result is defined.
 Complex numbers are handled as single entities for computation using standard mathematical functions, not special commands.
The first principle is selfexplanatory, but few calculators fulfill it, even the ones that boast of "complex numbers".
On the HP15C, the second principle was implemented by the status of Flag 8. On the HP42S, it was implemented by the choice "RRES" (real result) or "CRES" (complex result).
The complexnumber functionality of the HP32S, HP32SII, HP33s, and now apparently the HP35s, was essentially a porting of the HP41 Math Pac's RPN routines. This set of routines was not mathematically complete, and could not fulfill the third principle due to design limitations. x^{2}, sqrt(x), and xth root of y for complexvalued x and y were not provided because they were not absolutely necessary: y^{x} can be used for those calculations.
It's apparent that y^{x} is defined in the complex domain on the HP35s only when y is clearly identifiable as complexvalued. 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 complexvalued argument.
It seems that the main improvement was easier entry and oneline display of complex numbers. A more ambitious improvement that restored the capabilities of the HP15C and HP42S would have been the following:
Userfriendly complexnumber calculations
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 HP35s 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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote:
x^{2}, sqrt(x), and xth root of y for complexvalued x and y were not provided because they were not absolutely necessary: y^{x} 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 nonobvious but still complete set of functions doesn't gel with me.
 Pauli
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
"x^{2}, sqrt(x), and xth root of y for complexvalued x and y were not provided because they were not absolutely necessary: y^{x} 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 HP41 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 complexvalued 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 realinteger and complexvalued powers and roots for complexvalued arguments as "Z^N", "Z^1/N", "Z^W", and "Z^1/W".
Certainly, complexvalued functions for square root and square, as a minimum, ought to have been implemented in microcode for the HP32S, HP32SII, HP33s, and HP35s, even if the original HP41 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 quarterdollar. It was rejected by the public, minted only in 1979, 1980, and 1999 as a leadin 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, smoothsided, 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, "seigniorageproducing collecting activity").
http://www.usmint.gov/mint_programs/$1coin/index.cfm
http://money.cnn.com/2005/04/27/pf/new_dollar/
http://money.cnn.com/2003/05/13/pf/banking/currency_miscues/index.htm
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, longlasting coins for small lowtech transactions, as most Western countries do. Instead, we use lowvalue 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 HP35s doesn't have a mathematicallycomplete set of complexvalued functions, that can be traced back originally to the compromises made in the HP41 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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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 HP41 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
Posts: 1,092
Threads: 57
Joined: May 2007
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.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
That's what's called added value ;)
Posts: 489
Threads: 11
Joined: Jan 2005
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.
Posts: 17
Threads: 3
Joined: Jul 2007
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.
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
What word about the labeling paradigm?
▼
Posts: 17
Threads: 3
Joined: Jul 2007
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.
