HP 35s successor?



#2

Hi,

Yesterday I got a HP35s calculator, and I have to say I'm pretty disappointed with the handling of complex numbers. (I'm an EE student and one of the main reasons I got the calculator was to crunch complex numbers). The fact that you need to write programs to do R->P, P->R, complex conjugate and solve complex linear equations is a real bummer. http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=122519

I was wondering if anyone knew when/if HP will be releasing a successor to the 35s that fixes these problems. If HP is planning on releasing one soon, I think I might want to sell my 35s now and wait for the new one to come out. Does anyone have any thoughts on this subject?

Thanks,

Kyle


#3

If you search the archives you'll find that many share your disappointment with the 35s support of complex numbers and operations.

My advice would be to get a 42S, but it will cost you. Alternatively use Free42 (http://free42.sourceforge.net/). Free42 is a clone of the 42S that runs on Windows, Linux, OS/X, and a number of PDAs, and soon (very soon I hope) iPhones.

Speaking of iPhones if you have one, get the 15C emulator for it. I prefer the 15C complex support over the 35s, but nothing really beats the 42S. Install Free42 and you'll see what I mean. E.g. simply enter -1 and press SQRT, 35s will return SQRT(NEG) error, and the 42S will correctly return 0 i1, or 0.0000 i1.0000 (FIX 4).

Good luck.

Edited: 13 May 2008, 9:44 p.m.


#4

Hi, Egan:

    Egan wrote:

    "I prefer the 15C complex support over the 35s, but nothing really beats the 42S."

      Not to repeat old arguments which have already been discussed here an number of times, but though I recognize the 42S complex-number implementation as very worthy and certainly one of the best, I still think that the HP-15C has the best support for elementary complex number manipulation in plain-vanilla RPN (i.e., arithmetic, plus standard functions and usual transcendental functions), while the HP-71B/Math ROM provides the easiest, fastest, most capable handling of complex number operations, bar none.

      Everytime I have to do something which requieres complex number handling, I invariably turn to my HP-15C if far from a PC, or Emu71 (which includes MathROM) if on a Windows PC. There are times when I'm out of town and have neither. In that case, Free42 running on my ultra-small PDA is the perfect solution, incredibly fast, accurate and convenient.

      As for general use, I never use an actual, physical HP42S for this, I much prefer Free42 on a PDA if given the option for many reasons, among them the fact that selecting functions from menus is far faster and easier with a pointer on a PDA's touchscreen than pressing real 42S keys.

      Using an HP35S for complex number crunching would never be a viable option to me.

Best regards from V.

#5

Valentin, I direct this question to you because of your extensive knowledge of non-HP calculators.

Has there ever been a non-HP calculator with excellent complex number capability?

The ones I've seen have been abysmal.

#6

I've used Free42 on the Nokia N800 PDA (which has an 800x480 resolution. It is pretty cool. But I can't understand why the author only uses 763 pixels of the available 800 pixel resolution. The original author (well, this is a port of Free42 actually) has a skin here along with a file that numerically describes the skin...

http://www.tajuma.com/download/extra-skins.tgz

If there is any kind, artistic, soul out there that would like to come up with an 800 pixel wide skin I think that would be very cool.

Incidentally, and somewhat off-topic I guess - someone has ported the TI89/92 and V200 to the Nokia as well. I've not used this - but some message boards I persused seemed to imply that it ran slower than the original calculator - not sure if it is useful or not... and I prefer HP...

http://maemo.org/downloads/OS2008/scientific/

Kevin


#7

Quote:
I've used Free42 on the Nokia N800 PDA (which has an 800x480 resolution. It is pretty cool. But I can't understand why the author only uses 763 pixels of the available 800 pixel resolution. The original author (well, this is a port of Free42 actually) has a skin here along with a file that numerically describes the skin...

http://www.tajuma.com/download/extra-skins.tgz


This looks like it was based on my original work (http://sense.net/zc/free42/). I suspect that whoever scaled up my 640 wide image to 763 must of had a different window manager that may have used up 37 pixels on the sides.

#8

It's not terrible - but on the Nokia N770/N800 it leaves a 37 pixel black bar on the right side of the screen.

For my eyes - the font on the N770/N800 on the Free42 calculator is just a bit too small. It would have been nice to either use this space to make the font a little bigger - or put a little more white space in between keys - I think that the newest version allows one to just use their fingers instead of having to use the stylus - which would be handy - no pun intended. ;-)

Edited: 14 May 2008, 3:59 p.m.


#9

The original was based on Nonpareil 15C. I used GIMP to stretch it out to 640 wide to get the general dimensions. But I still had to create every key and label from scratch and adjust a number of other things (stretching does not work too well). The entire project took about an hour. It was not a lot of work. I suggest you try it out. You will have to update the layout file however to match the new location of things.

#10

Hi Kyle,

I second Egan's two recommendations fully. After 20 years, the 42S is still the best you can get for advanced RPN. And the value of Thomas's Free42 divided by its cost goes straight to infinity. Both are running circles around the other offers when it comes to complex number and matrix support. The 15C is HP's smallest calc computing complex numbers and matrices, and a cute one, but its way of handling and displaying such objects is history and its programming paradigma is way outdated. This will not improve with a 15C simulator.

HTH, Walter

Edited: 14 May 2008, 4:07 a.m.


#11

Hi Everyone, thanks for the quick replies.

I just tried the 42S emulator and I was very impressed. What a pity the physical calculator is discontinued! How could HP do such a thing?

It looks like I'll be sticking with my 35s since I need something portable and don't have a PDA that can run the emulator, and I don't have the money for a used 42S (wow, some are going for over $400 on ebay).

I'll just enter in the complex number handling and matrix multitool programs, and although it is somewhat inconvenient I think it will be satisfactory for a majority of the problems I need to solve.

I'm still curious though if anyone has any idea if HP will plan to release a new calculator to fix the problems in the 35s. I've seen some talk in the forums about people suggesting improvements to HP for a 35sii or something. Has there been any news about that?

I realize this has probably been discussed many times before, but it tortures me to think of how close the 35s is to be an excellent machine! HP's oversights in this calculator seem like they would have been so easy to correct, and yet would have made it many, many times better. Argh! </rant>

Kyle


#12

Quote:
Hi Everyone, thanks for the quick replies.

I just tried the 42S emulator and I was very impressed. What a pity the physical calculator is discontinued! How could HP do such a thing?

It looks like I'll be sticking with my 35s since I need something portable and don't have a PDA that can run the emulator


Older second hand PDA's go very cheaply on Ebay.

Easily worth buying one just for a calc.

Dave.

#13

If you can live with the size, the HP50g matches (at least) the HP42S in complex number handling, and has tremendous additional capabilities. Programming is RPL rather than RPN, which takes a lot of adjustment.

As others have indicated, the 1988 HP42S is the finest RPN calculator that has ever existed by large margin, especially for complex numbers. But it carries a high price. The HP49g+/HP50g series are the first HP calcs to interest me since the HP42S, and I could be happy with one of those if I couldn't have an HP42S.

I always carry an HP42S and an HP50g in my briefcase. Sometimes I add an HP17BII.


#14

How are the 48g+'s in terms of complex number crunching? I might have access to one.

I've tried the 48g+ before (not the complex number capability though), and found the menu systems and plotting to be very slow. are the 49g and 50g faster/more responsive?


#15

The HP48g+ is equal to or better than the HP42s for complex number crunching. The two main downsides to any of the HP48/49/50 series is the size and weight in comparison to the HP42s, and their powerful RPL programming model has a steeper learning curve than the simpler RPN model of the HP42s (if you plan to program).

#16

I forgot to comment on speed. The HP49g+ and HP50g are, AFAIK, the fastest handheld calcs that HP has produced. They are about twice the speed of the HP48g/gx/g+ series, or about ten times the speed of the HP42s, in typical applications.

#17

Hi Kyle,

I have both a 48GX and a 50G. Indeed the 50G is much faster in all environments.

Slower speed notwithstanding, the 48GX is (IMO) excellent for working with complex numbers. With the R>C (real to complex) function, composing them is syntax free.
Also, degree/radian, as well as polar/rectangular selection is right on the keyboard (albeit shifted). Conversely, the 50G requires delving into either the mode selection screen, or a menu to set these two important parameters.

Best regards, Hal


PS... I'm not sure what the chronological relationship is between the 48GX and the 48G+, so my comments may be moot.

#18

Hi Kyle,

Quote:
I'm still curious though if anyone has any idea if HP will plan to release a new calculator to fix the problems in the 35s. I've seen some talk in the forums about people suggesting improvements to HP for a 35sii or something. Has there been any news about that?

Anyone that has any idea probably works for HP and is not free to share such knowledge. After all, if it became common knowledge that they were about to release a 35sii, that would pretty much kill sales of the 35s and result in a lot of un-sold and practically un-sellable inventory. (This phenomenon purportedly led to the demise of Osborne computers in the early 1980's, although this link states that other factors actually had more to do with killing Osborne.) In any case, it seems unlikely (to me, at least) that HP will make any official announcement. My hope is that they will soon quietly begin to ship a 35s with a revised rom which does two things:

1. fixes the most egregious "bugs" and/or operational quirks. I could live with the following:

- fix the checksum and length bug(s)

- change the thing with needing to enter the base suffix when working in binary or octal or hex.

- change the symbol used to separate the magnitude and angle in a complex number. I previously suggested that it should look like this:



- if there is some sort of bug with the vector input, fix that.

- with a complex number in the x register, pressing SHOW should present the full mantissa of the imaginary component (or angle) on the top line of the display and the real component (or magnitude) on the second line.

- in ALL mode, the mantissa should be properly rounded so that the exponent fits on the screen. i.e. the entire number is displayed without scrolling.

- fix the cosine bug

- fix the ability to lock-up the calculator when restarting a program after an equation used as a prompt that is not followed by a PSE instruction. (See here for a full explanation.)

2. Adds the following menu:

Since the calculator would be able to determine the type of argument, it would only take five functions instead of the seven I proposed in the thread you linked to above. The functions in the menu would work as follows:

->P :To Polar - With a complex number in the x register, this would deconstruct it into its magnitude and angle in the x and y registers, respectively. With real numbers in the x and y registers, it would treat them as real and imaginary components and convert them to magnitude and angle. (It would give an invalid argument message if there was a real in the x and a complex or vector in y.)

->R :To Rectangular - With a complex number in the x register, this would deconstruct it into its real and imaginary components in the x and y registers, respectively. With real numbers in the x and y registers, it would treat them as magnitude and angle components and convert them to real and imaginary components. (Also would give an invalid argument message if there was a real in the x and a complex or vector in y.)

R->C :Rectangular to Complex - would treat the real numbers in the x and y registers as real and imaginary components and form a complex number in the x register. (invalid argument if there was a real in the x and a complex or vector in y.) It might also change the display mode to rectangular.

P->C :Polar to Complex - would treat the real numbers in the x and y registers as magnitude and angle and form a complex number in the x register. (invalid argument if there was a real in the x and a complex or vector in y.) It might also change the display mode to polar.

C->C* :Complex Conjugate, works as expected.

I also put the ARG function in the complex menu.

Not so much to ask, I'm sure you'll agree ;-)

Best regards,

Jeff

Edited: 14 May 2008, 8:53 a.m.


#19

I wish...

-- Antonio

And I'd add the ability to do square root or LOG or 10x or ASIN (ACOS,ATAN) or HYP SIN (COS,TAN) or HYP ASIN (ACOS,ATAN) on a complex number...


Edited: 14 May 2008, 10:48 a.m.

#20

I would add the ability to treat 2D vectors as complex numbers and vice versa. A "type of" command would be handy for programmers to determine the type of the number or vector currently in X.


#21

I'll add a way to accomplish this without adding a new instruction.

Just set two flags depending on the argument type:

Flag       12   13
X
------------------
real - -
complex x -
2D vector - x
3D vector x x
------------------
This should be easy to implement and does not change the programming model. The flags should always be set according to the table without the need to add a special instruction to do so.

Edited: 15 May 2008, 8:52 a.m.

#22

OK, the wishlist seems to be open again ;) For those of you who want to see more elaborated concepts I'd like to draw your attention to two articles of Jake Schwartz in HPCC Datafile V27 (i.e. 2008) N1 + N2, and one of me in V27 N2 presenting 4 complete RPN calculator models carefully bred. The latter article will be continued in the next issue with the presentation of a full fledge menu system granting access to >425 functions in 4 keystrokes maximum.

Maybe some tattered and torn specimens of this modest little British magazine succeed in reaching the realm of West Coast HP, maybe they are even looked at and (ooh oh! How dare you!) read, and perhaps some of its thoughts and seeds drop on fertile soil there ... just dreaming ...

Edited: 14 May 2008, 7:01 p.m.


#23

I'd settle for a reliable keyboard

#24

My intention was to propose a minimum set of improvements that could be implemented somewhat transparently. I do like Antonio's suggestion that all functions accept complex arguments, plus I'd add that all functions should return complex results from a real argument if appropriate.


#25

Quote:
My intention was to propose a minimum set of improvements that could be implemented somewhat transparently. I do like Antonio's suggestion that all functions accept complex arguments, plus I'd add that all functions should return complex results from a real argument if appropriate.

I wonder how much room in the program memory they have left?
They might have to upgrade the hardware too to accommodate any major software additions.

Dave.


#26

Dave; At the San Diego HHC it came out during a side discussion that the 35's ROM is pretty much full. Those useless conversions fill up the left-over space.


#27

Hi, "db" --

Quote:
At the San Diego HHC it came out during a side discussion that the 35(s)'s ROM is pretty much full. Those useless conversions fill up the left-over space.

I was at the SD HHC, but did not partcipate in that "side discussion".

"Those useless conversions"? If you're referring to the ones proposed by Jeff O. for complex numbers, please bite your tongue...

:-)

The few metric-English unit conversions are trivial, and I doubt that you object to those, given that you've performed engineering work in both systems.


-- KS


#28

You probably weren't in that chat. I think i knew everyone there. We didn't have a ROM map but i came away wondering how much space could have been saved by leaving off the (yes) useless conversions. 3.28084, that's all i need to know. Others need to know other ones. All those conversions and more could have been printed on the back of the calc, and should have if it would have saved enough room for P-R & R-P. I believe that HP was the first to use that function and it's been on their units since the 9100 and the 45. Thankfully; i don't have to use my bad solution since other better programmers wrote the one i use. I hate that third keystroke though, and i use P-R daily to check things calculated by infallible computers and Teflon coated engineers.


#29

"db" --

Quote:
You probably weren't in that chat. I think i knew everyone there.

I'm sure that I heard your full name during the introductions at HHC, but there were too many new ones, and I might not have related it to "db". Certainly, I would have remembered the discussion if I'd been involved.

Quote:
All those conversions and more could have been printed on the back of the calc, and should have if it would have saved enough room for P-R & R-P.

HP hasn't printed operating info on the back plates since the Voyager series (due to production costs and other considerations). The informative back plates were largely motivated by the value of providing a quick reference to the single-digit codes for errors and other things (MATRIX, TEST) given by their 7-segment display. A key to the numbered summation registers was also handy. Beats having to look it up in the manual!

I agree that omission of P->R and R->P was a blunder, but I'd say that any limiting factor would have been keyboard space, not ROM space.

If one metric-English conversion were to be omitted, I'd vote for "in<->cm". Any engineer/scientist in the US ought to remember that 1 inch = 2.54 cm exactly, by definition. If he can't, the value can be derived from the "MILE<->KM" conversions, which are handier for most of us yankees.

For short lengths, the approximate foot<->meter conversion you stated is often more useful, as is the exact 1 inch = 25.4 mm (think wrenches).

-- KS

Edited: 17 May 2008, 2:14 p.m.

#30

Quote:
The few metric-English unit conversions are trivial, and I doubt that you object to those, given that you've performed engineering work in both systems.

8 of these could have been covered with the 4 corresponding conversion constants stored in arbitrary memory locations if required. Result: 8 free lots for *useful* functions. P>R and R>P will take just 2 of them.

Ceterum censeo: outside of the USA all these conversion functions are a mere waste of keyboard space.


#31

Quote:
...outside of the USA all these conversion functions are a mere waste of keyboard space.

even inside ;-)


#32

Hi, George --

You have to admit that the built-in metric-English conversions have value as long as both systems of measurement are used. I addressed the back-plate issue in the post above, and it's also a minor hassle for the user to have to key in those conversion factors.

If keyboard space for these conversions is of concern, here's a possible solution: The Pioneer-series HP-22S consolidated four pairs of those into a single two-level menu called "UNITS".

-- KS

Edited: 17 May 2008, 3:23 p.m.


#33

They could have put the conversion factors in a menu like the physical constants menu.

Stefan


#34

Quote:
They could have put the conversion factors in a menu like the physical constants menu.

The HP-30S has something like that. It's versatile, but kind of a chore to use (like everything else on the HP-30S). It allows conversions between members of nine categories of similar units for a total of 62 bidirectional conversions, but does not support conversion of compound units (as does the HP-28C/S).

-- KS

Edited: 18 May 2008, 4:15 p.m. after one or more responses were posted


#35

Quote:


The HP-30S has something like that. It's versatile, but kind of a chore to use (like everything else on the HP-30S). It allows conversions between members of nine categories of similar units, but does not support compound units (as does the HP-28C/S conversions).

-- KS


Aside from the RPL units, which have extensive and relatively easy-to-use conversion capabilities, I really like(d) the Unit Conversions program in the Machine Design Pac for the 41C. It's billed as a "program that provides a virtually unlimited number of unit conversions useful to Mechanical Engineers". The program, executed either by FCON or BCON, is "controlled by unit abbreviations and combinations of unit abbreviations placed in the ALPHA register".

I almost got my hands on a pristine 42S a few years back that was 'lost and never claimed'. I supposedly had first dibs on it, in the event no one ever claimed it (after a reasonable period of time). Unfortunately, the secretary who hung on to it, gave it to her teenage son who had zero appreciation for it... I use Free42 on my PalmTreo and quite like it. I also used the 15C daily from 1985 until 1996, so I appreciate its capabilities too. I nevertheless think that a properly loaded 41cv/cx with Advantage Pac and others is still the best overall calculator that HP has developed, certainly in that form factor (i.e. pocket sized). OK, so it is rather slooow and the Advantage Pac support for complex numbers is à la 32sii, but I doubt that we will see anything as good from HP in the near term.

Regards,

Jeff Kearns

#36

Hi, Jeff --

We've had some discussions about this dating back to 2004:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=63415#63415

and we also exchanged some information at the 2007 HHC in San Diego.

We are substantially in agreement about these things, but I see things a bit differently regarding your proposed complex-function menu in item 2:


->P :To Polar

->R :To Rectangular

These should be two-keystroke functions on the keyboard for convenience, and for usability with real-valued inputs (as on the HP-15C and HP-42S).

R->C :Rectangular to Complex

P->C :Polar to Complex

A single "Re->Cx" function to complement "Cx->Re" would suffice if the rectangular/polar mode setting were utilized to determine the format of the two real-valued arguments. That's what the HP-42S does (but not the HP-48 and its successors, which assume rectangular format).

Best regards,

-- KS


#37

Quote:
We've had some discussions about this dating back to 2004:

Yes we have, and it appears that we are destined to continue :-)

Quote:
and we also exchanged some information at the 2007 HHC in San Diego

I still have the proposal you gave me, a fine piece of work.

Quote:
We are substantially in agreement about these things...

I have no problems with your proposals. I would definitely prefer to replace the English<>SI conversions on the keyboard with a set of polar/rectangular/complex functions, something like this maybe:





My suggestion to put the functions in a menu is just to make it easy on hp...simply replace the ARG (function) label with a CMPLX (menu) label on the keyboard.

Best regards,

Jeff


#38

Proposal for 4 conversions, covering the real-complex-rect-polar topic in 2 and 3 dimensions:

>CPX converts the 2 real objects found in x and y into 1 complex object in x (or throws an error if x or y contain strings or complex objects). The result will depend on the coordinates mode settings at conversion time:

  • In polar mode, if x and y contain real numbers, >CPX takes the contents of x as the magnitude and those of y as the angle and merges this pair to one complex number displayed as in 42S (e.g. 1.2 /_ 3.4, where /_ stands for the angle symbol). If x and y contain matrices, >CPX builds one complex matrix out of the elements converted individually.
  • Else (in rectangular mode), the real part(s) are taken from x and imaginary from y and merged to one complex object displayed similar to 42S (e.g. 9.8 – 7.6i).

>REAL converts the complex object found in x into two real objects in x and y (or throws an error if x contains any non-complex object). The result will depend on the coordinates mode settings at conversion time:

  • In polar mode, >REAL splits the object found in x into a part containing the magnitude(s) and another one containing the angle(s), storing the angle(s) in y and the magnitude(s) in x.
  • Else, >REAL splits the object in x into its real and imaginary part and stores the imaginary part in y and the real in x.

>POL converts the lowest stack level(s):

  1. If x contains a complex object, >POL takes its real and imaginary parts and converts re + im i into r /_ theta. An object displayed in polar mode already will remain unchanged.
  2. Else, if 3d, it converts x, y, z into spherical coordinates r, theta, phi.
  3. Else, it converts x, y into cylindrical coordinates r, theta.
Remarks for >POL: (a) The angles will be displayed in the angular mode selected (DEG, RAD or GRAD). (b) The general coordinate system will stay as set (RECT or POLAR). (c) In cases 2 and 3, the input is taken from the respective stack levels, and the conversion results r, theta, phi are put in the stack levels x, y, z , respectively. If any of the input stack levels does not contain a real number at conversion time, an error will be thrown.

>REC converts the lowest stack level(s):

  1. If x contains a complex object, >REC takes its radii and angles and converts r /_ theta into re + im i . An object displayed in rectangular mode already will remain unchanged.
  2. Else, if 3d, it assumes spherical coordinates on the stack and converts r, theta, phi into x, y, z .
  3. Else, it assumes cylindrical coordinates on the stack and converts r, theta into x, y.
Remarks for >REC: (a) The general coordinate system will stay as set (RECT or POLAR). (b)In cases 2 and 3, the input r, theta, phi is taken from the stack levels x, y, z, respectively, and the conversion results are put in the corresponding stack levels. If any of the input stack levels does not contain a real number at conversion time, an error will be thrown.

Hope this is sufficiently complete. It will need 4 labels on the keyboard, which are readily available when the IMP<>SI conversions are dropped or packed in a menu, as others proposed already as well. It can be done most compact:
.
These keys are taken from the 15S as shown in Datafile V27N2.

Best regards, Walter





Edited: 19 May 2008, 3:50 p.m.

#39

Jeff, the blue functions on key 4&5 should be swapped. Blue shift is normally the inverse function of yellow shift.

#40

There are several issues that bother me about this calculator, many of which have been mentioned. It doesn't handle a basic method for entering numbers with a mantissa of 1 just using the "EEX" key. For example, using "EEX 7 ENTER" will not yield 1E7. Another annoying issue is why it can't handle right hand side distribution, using implicit multiplication in algebraic mode. That is, it cannot properly handle "(2 + 3)4" although it can handle "4(2 + 3)".

I haven't been paying that much attention to the HP-35S threads, so some of these may already have been mentioned. I have the same question we all have: "Why can't HP just get it right any more?" Just a rhetorical remark.


#41

Quote:
I have the same question we all have: "Why can't HP just get it right any more?"

Probably HP can get it right. The problem is that HP didn't create the HP 35s. Or at least, they had a lot of help getting it wrong.

Stefan


#42

Maybe a few more reasons:
1) My 11c in 1981 cost $120. Thats about $350 today, and it's not graphing. Obviously no-one expects to spend over $100 for a new scientific calculator today (although several of us here would, but not enough to justify it).
2) The developers of the early "great" calculators were all slide-rule trained people; they cared more. We're a throw-away society now, and long-lasting quality is no longer an inherent trait.


#43

Quote:
We're a throw-away society now, and long-lasting quality is no longer an inherent trait.

I think you may have found the crux of the matter. When the early HPs came out, people tended to work for their entire lives for a single company. Thus, even without stock options or profit sharing, they had a vested interest in producing good products, since they would have to stand behind them, and their livelihood depended on the company remaining profitable.

Nowadays, people tend to change jobs every few years. Although it may not be a conscious decision, this may result in less care taken in the design of products, because the designer probably won't be around when the bugs start to surface.

Going a bit further, I think that modern technology may have actually _caused_ this problem. In the days when people used slide rules and drafting tables instead of the tools used today, it took an entire career to do a handful of interesting things. These days, one can do that same handful of interesting things in less time. After a while, the things aren't interesting any more, and one moves on to something else.

Totally off topic now, but ...

Stefan

#44

Quote:
2) The developers of the early "great" calculators were all slide-rule trained people; they cared more. We're a throw-away society now, and long-lasting quality is no longer an inherent trait.

They cared more because they were designing products for themselves.

Nowadays a marketing team collects requirements from customers, resellers, and partners, then after trying to understand the requirements, they try to find the LCD that will yield the greatest profit. Then a specification is created and sent out to the lowest bidder. This isn't a bad thing.

Yes, someone is going to be left out. Poor complex number support was probably an oversight (was designed by a marketing type not a user). No matrix operations was probably intentional (50g does it better).

Apple is a good example of what to do. Yes, they too cannot make 100% of the people 100% happy 100% of the time. But, from the very top to the bottom every employee is a user and they are developing products that they want to use and the byproduct of that thinking are products that we all want to use.


#45

Hi, Egan --

Quote:
Nowadays a marketing team collects requirements from customers, resellers, and partners, then after trying to understand the requirements, they try to find the LCD that will yield the greatest profit. Then a specification is created and sent out to the lowest bidder. This isn't a bad thing.

I'm sure that your description slightly exaggerates the dysfunctionality of modern product development in the realm of low-end consumer electronics. However, it sounds to me like a "race to the bottom".

Quote:
Poor complex number support was probably an oversight (was designed by a marketing type not a user)

If true, that's a blunder. Those who know best should be designing the specifications. If that knowledge isn't available in-house, a consultant should be hired for that purpose.

-- KS

#46

Quote:
Poor complex number support was probably an oversight...

I don't believe it was an oversight, but rather a continuation of HP's scientific calculator philosophy that goes back at least 25 years.

The first HP calc that had decent and consistent complex number support was the HP-15C. I almost retired my expensive new HP-41CX after I saw how much better the HP-15C was for complex numbers. Unfortunately all other Voyagers like the HP-11C had very poor complex number support.

The HP48/49/50 series calculators have excellent complex number support, but in the small pocket models only the HP42S of 20 years ago advanced the capabilities of the HP-15C. The complex number support of contemporary and later models like the HP32S, HP32SII, HP33, HP35S, etc. is very unsatisfactory.

Unless the various HP marketing teams of the past 25 years have all made the same "oversight," one must conclude that HP purposefully doesn't consider decent complex number support to be of interest to the purchasers of its calculators except for purchasers of the HP50g. What a shame!


#47

Hi, Mike:

Mike posted:

    "Unfortunately all other Voyagers like the
    HP-11C had very poor complex number support."

      Very poor ? They had no complex number support whatsoever, period.

      Also, this has been discussed oftentimes before but it bears repeating once more: the HP42S doesn't better the HP-15C as far as complex number support is concerned. It does a number of things the HP-15C doesn't but such an essential, basic capability as entering 4 complex numbers into the stack one after the other, in the natural RPN way, the HP-15C does but the HP42S can't.

Best regards from V.


#48

Hi, Valentin --

Quote:
Also, this has been discussed oftentimes before but it bears repeating once more: the HP42S doesn't better the HP-15C as far as complex number support is concerned.

All in all, I don't concur with the statement, but ... never mind that.

Quote:
...such an essential, basic capability as entering 4 complex numbers into the stack one after the other, in the natural RPN way, the HP-15C does but the HP42S can't.

The lack of an alternative means of entering complex-valued numbers is indeed a "bugaboo" on the HP-42S.


Valentin is referencing the problem on the HP-42S in which a new complex number cannot be directly entered onto the stack in the conventional manner (not recalled from a storage register) without pushing the contents of the z-register off the stack.

This "conventional manner" of entering a complex number a+jb on the HP-15C and HP-42S is basically identical:

(a) ENTER (b) "R->C"    

where "R->C" is the RPL term for the function that constructs a complex number for stack register x from two real-valued numbers in stack registers x and y. On the HP-15C, it's "f I"; on the HP-42S, it's "COMPLEX".

If the existing contents of stack registers x, y, and z are to be preserved, the new complex number a+jb can be entered using only one stack level on the HP-15C by

(b) 
Re<->Im
CLx
(a)

So, how might one push a new complex number onto the HP-42S stack?

My only idea is to store one of the stack elements, clear it or allow it to be pushed off, then restore it after the new complex number is assembled:

STO "X" (or a numbered register, if usable)
CLx (or Rdn)
(a)
ENTER
(b)
COMPLEX
RCL "X" (or numbered register)
x<->y

RCL ST Z
STO "Z" (or a numbered register, if usable)
CLx (or Rdn)
(a)
ENTER
(b)
COMPLEX
RCL "Z" (or numbered register)
Rdn

Whichever is, um, "easier". A complication is that numbered registers cannot store complex numbers unless dimensioned as such. To do so:

RCL "REGS"     
ENTER
COMPLEX
STO "REGS"

-- KS


Edited: 18 May 2008, 3:38 a.m.


#49

I have never been inconvenienced by the problem of rolling off Z register complex contents on the HP42S because I don't fully load the stack with complex numbers before performing operations that cause stack content drop. I consider this to be just a small part of the informed strategy that must always be employed with RPN use...for the HP42S I just have to pretend that it is really a 3-level stack under this special circumstance. For another case, when all four stack registers are to be loaded with complex numbers within a program, say, in order to pass a set of inputs to a subroutine, usually the four complex numbers will be "pre-assembled" before stack load and once again this problem doesn't arise. But the point is valid that this is a minor faux pas that is surprising in the otherwise excellent HP42S complex number processing.

I used the HP-15C almost daily from 1986 to 1997, and then the HP-42S since. I immediately found the HP42S far easier to use, far faster, far more accurate, and much better for operating from the hand since it doesn't have the artsy but awkward "landscape" aspect ratio of the HP-15C. But the HP-15C is more visually attractive, and had the HP42S never appeared with its impressive advances, the HP-15C would easily retain the "best-there-ever-was" pocket calc status, IMHO.

When I claimed that the other Voyagers had *very poor* complex number support rather than *no* complex support, I did so with the view that even the earliest calcs, especially programmables, can be manipulated to perform complex calculations.


#50

Mike --

That's all quite reasonable; just several comments:

Quote:
...usually the four complex numbers will be "pre-assembled" before stack load...

Ah, but the crux of this problem is that an complex number entered on the HP-42S must be assembled on the stack from reals in the x- and y- stack registers.

Those "pre-assembled" complex numbers must either be 1) pre-calculated; or, 2) assembled, stored to variables or registers, and then recalled.

Quote:
...and much better for operating from the hand since it doesn't have the artsy but awkward "landscape" aspect ratio of the HP-15C

The only thing I found "artsy" about the HP-15C was the brushed aluminum bezel and raised logo. I didn't like it at first, in comparison to the HP-34C.

The landscape layout is very ergonomic if the calc is sitting on a desktop or tabletop. The shift keys are near a right-hander's thumb. If only several fingers are used for keystroking, the hand will be moved in a natural side-to-side motion with the upper arm virtually stationary -- as with those horizontal "slider" HVAC controls on automobiles that were the de facto standard from the 1960's through the 1980's.

The Voyagers were not really designed for handheld use, and are indeed awkward for that. Not impossible, just
awkward.

-- KS


Edited: 18 May 2008, 2:50 p.m.


#51

Hi, Karl:

Karl posted:

    "The Voyagers were not really designed for handheld use, and are indeed awkward for that. Not impossible, just awkward."

      That's only your opinion, which I respect but don't share.

      Tha landscape Voyagers are "awkward" to use as handhelds if and only if you try to do it as you would with a vertical-layout model, such as the HP42S, i.e., you grip the calculator with your left hand so that it resides in the palm, so to say, then press the keys with the index finger. If you try to do that, the Voyager doesn't rest naturally in the palm and it's awkward to grip.

      But that's not how I use my Voyagers when handheld. The proper way, for me, is to take it symmetrically with both hands, where the hands are placed horizontally with their index fingers pointing to (or touching) one another, and the calculator symmetrically placed over all fingers of both hands save the thumbs, which are then used to press the keys. The machine itself is firmly grasped by the internal side of the base of each thumb.

      This arrangement is not only natural, secure, and comfortable, but you can actually press keys with both thumbs in quick succession, so that one thumb press the digit keys, say, and the other instantly
      press the ENTER key or any of the Shift keys. This makes for essentially two-fingered entry of operands and operations, almost without delays, and thus the gain in speed is considerable.

      Vertical-layout models aren't amenable to that kind of handling.

Best regards from V.

#52

Hi, Valentin --

Yes, of course, everything you stated is correct. With my small hands, I also prefer the "two-hand, thumb-keystroking" method, even sometimes with Pioneers. Its only problem -- a minor one -- is trying to hold a pen or other small device in one hand while using the calculator, for recording results.

I'm aware that you've used an HP-11C in field situations, but Voyagers are not the ideal for that, due to their lack of plug-in storage and expandability (e.g., HP-41 and HP-48). The old LED models (e.g., HP-34C) even have the advantage of cold-weather usability.

-- KS

#53

Hi, Mike:

Mike posted:

    "When I claimed that the other Voyagers had *very poor* complex number support rather than *no* complex support, I did so with the view that even the earliest calcs, especially programmables, can be manipulated to perform complex calculations."

      Then you might as well state that they have "very poor quaternion support" or that they (save the HP-15C) have "very poor matrix support".

      Of course these calculators, and most other from most other brands, can be "manipulated to perform complex calcultions", that goes without saying. But calling that "poor support" or any flavor of support for that matter is utterly misleading.

Best regards from V.

#54

Hi V.

You wrote:

Quote:
    Then you might as well state that they have "very poor quaternion support" or that they (save the HP-15C) have "very poor matrix support".

That statement would only be true had the purpose of the post included detailing a canonical list of everything for which Voyagers provided poor support. Since the subject of thread was complex number support, the subject of reply was limited within that scope.

To have stated that most Voyagers provide no complex number support would have invited contesting verbal arrows fired by those who have ever managed to manipulate a complex number on a Voyager.

Best. MM


#55

Hi, Mike:

Mike posted:

    "To have stated that most Voyagers provide no complex number support would have invited contesting verbal arrows fired by those who have ever managed to manipulate a complex number on a Voyager."

      You're twisting language here and frankly, I'm getting the distinct impression that you know you're wrong but it seems you can't deal with it gracefully.

      In this context, most people understand that "providing support for XX" means said model does include operations and instructions which are specifically designed to deal with XX.

      In the case of matrices, say, the model might include operations for dimensioning a matrix, or matrix inversion, or whatever. In the case of complex numbers, perhaps a complex stack, or some CPLXSUM, CPLXMUL, etc. arithmetic operations, whatever.

      If the model does *not* include *any* specific instructions to deal with XX, but rather you can do it by yourself simply using the normal, non-specific instruction set (such as doing complex number operations or matrix operations with an HP-10C, say) then said model has no support for XX, period. Saying it has "poor support" instead seems like a travesty of political correctness.

      So "no support" it is. Anything else is just twisting language, altering meanings, and just plain stubbornness on your part.

Best regards from V.
#56

Quote:
So, how might one push a new complex number onto the HP-42S stack?

While not exactly convenient, here's a way to do so without using a storage register and works on a calculator in memory reset* condition without the need to dimension the REGS matrix to allow complex number storage:

keystrokes            comments
1 key in number 1
CHS make it negative
square-Root take its square root to get 0 + i 1
1/x single key way to store (0 + i 1) in the Last X register
<- backarrow to clear display and disable stack lift
key in imaginary component
STO x . ST L the store-times register arithmetic function using the Last X register
<- backarrow to clear display and disable stack lift
key in real component
RCL + . ST L the recall-plus register arithmetic function using the Last X register
proceed with calculations...

* - should have stated "works on a calculator in memory clear condition" per Karl's post below.


Edited: 21 May 2008, 12:27 p.m. after one or more responses were posted


#57

Jeff, this is a proof of concept, isn't it? No one will ever work in this way. It's even hard to program as the input is somewhere in the middle of the sequence.

RPN is a way to simplify things and should be treated as such.


#58

Yes, just proof of concept. Not really practical for everyday usage.

While it is easy for me to say, it seems that a simple solution would have been for hp to build a "phantom" fifth level into the stack. Instead of being pushed into oblivion, values would be pushed from the T level into this phantom register. The stack would function normally except following the use of the shift-STO sequence to assemble a complex number out of two reals. In that case and that case only, the stack would drop and the phantom level would have been copied back into T. This would also have allowed a "Last T" function, to enable you to recover when you did accidentally push something off of the stack.

#59

Hi, Jeff --

Very clever! If that had been a mini-programming challenge, you might very well have won. LAST X is a stack register, so my original statement still stands -- two stack registers are needed in order to enter a new complex number on the HP-42S. However, you did find a way to avoid the annoyances of named variables and complex-valued storage registers.

One minor nit-pick, though: You stated, "works on a calculator in memory reset condition", presumably to ensure real-valued storage registers. Machine reset maintains the status of Flag 74 (flag set will give real-valued results only, RRES). Your calculation requires Flag 74 clear (complex-valued results, CRES), which is guaranteed by machine clear.

Pages 170 and 282 of the HP-42S Owner's Manual tell more.

-- KS

Edited: 21 May 2008, 12:38 a.m.


#60

Karl,
Thanks for the praise, I very much appreciate it coming from a 42S aficionado such as yourself. I worked out this "technique" some time ago, probably the last time the subject came up here. I actually considered posting it as some sort of challenge, but never got around to it.

I was aware that it requires the complex results flag to be cleared. When I stated "works on a calculator in memory reset condition", I really meant memory clear, but I failed to check the manual for the proper terminology. Serves me right for not checking before posting.

Regarding the complex results flag, that brings to mind a mildly amusing story. Soon after I got my first 42s back in late 1988 or early 1989, we got a new cooperative education student in our work group. He was in an EE program, so I showed him how handily my 42s handled complex numbers. He was very impressed and immediately went out and bought one. Well, somehow flag 74 was already set when he got it, or he accidentally set it, and he showed me with great disappointment that it would not, for example, take the square root of -1 like mine would. At the time I did not have a lot of experience with my 42S and was unaware of flag 74, so I couldn't help him. Instead of looking in the index of the manual, for example, he assumed it was defective and took it back to exchange it for a new one. Apparently that one was in a "memory clear" state and worked properly.

#61

Hi, Karl:

Karl posted:

    "The lack of an alternative means of entering complex-valued numbers is indeed a "bugaboo" on the HP-42S"

      It's more than a "bugaboo", it's a very serious handicap when dealing with complex numbers.

      One of the main strengths of classical 4-level RPN is that you get used to it to the point that it becomes second nature. You tend to have a clear mental picture of where everything's on the stack and can quickly enter operands and perform operations and stack manipulations without thinking, almost instinctively. That's precisely why people tend to love RPN as opposed to AOS, where you aren't free to manipulate the pending operands in any way and having a clear picture of the present state is difficult, what with all those open parentheses and pending operations and such.

      This being so, if you're going to effectively work with complex numbers as easily as with real ones in manual operation in RPN mode, you absolutely need to be able to work in the exact same way: same philosophy, same operations, same handling, so that you can put your already extensive experience and intuition with real-number RPN computations to work in the same automatic, instinctive way you're used to.

      Thus, it's essential that you work the same whether you're working with real values or complex values, transparently, without pausing to think about it, without doing things in a different way,
      without slowing down, breaking your concentration, or leading to errors if you forget the caveat.

      That's what the HP-15C allows, and its "Owner's Handbook" makes it very clear that working with complex values is transparent, pointing out the fact that the same operations are used with complex and real values in a number of revealing examples.

      Unfortunately, that's not the case for the HP42S. The need to use two stack registers to assemble a single complex value ruins the paradigm. You now have to be pretty careful not to lose values off the top of the stack when you least expect it. Which is more, used to real valued RPN operations, you're prone to forget that the new complex value you entered (i.e. assembled) in X has resulted in some intermediate value being lost.

      And further, even if you're extra careful to "program" yourself for this serious caveat (extra work for your concentration) it still means you have an essentially 3-level stack to work with, not a 4-level stack, which is a very serious handicap and will surely force you to use registers to overcome the shortened stack's limitations or simply for peace of mind lest you lose some intermediate operands, thus ruining your fine-tuned 'reflexes' acquired with real-valued RPN manual computations over the years.

      So I rest my case: you going to do manual computations in RPN involving lots of complex value arithmetics and functions, nothing beats the HP-15C. It was a pinnacle of HP design and it was and still is the world's best pure calculator, bar none.

Best regards from V.


#62

Hi again, Valentin --

That's certainly an eloquent short essay, but I again submit that the HP-15C is susceptible to the very same problem.

An excerpt from my post above:

Quote:
This "conventional manner" of entering a complex number a+jb on the HP-15C and HP-42S is basically identical:

(a) ENTER (b) "R->C"    

where "R->C" is the RPL term for the function that constructs a complex number for stack register x from two real-valued numbers in stack registers x and y. On the HP-15C, it's "f I"; on the HP-42S, it's "COMPLEX".

If the existing contents of stack registers x, y, and z are to be preserved, the new complex number a+jb can be entered using only one stack level on the HP-15C by

(b) 
Re<->Im
CLx
(a)


The main difference between the two models is that the HP-15C offers a built-in alternative method for entering that fourth (and complex-valued) number, while the HP-42S doesn't.

The 4-element stack is adequate for most purposes -- usable and practical, as 3 elements would be too constraining, and 5 or more is too many for most users to mentally track. However, it was implemented before the complex-number functionality of these two models; several extra stack levels would have been welcome on the HP-42S.

Quote:

... absolutely need to be able to work in the exact same way: same philosophy, same operations, same handling, ...

Indeed, the HP-15C accomplishes this, with only one exception that is completely justified for reasons of utility:

  • CLx and CHS operate on only the real-valued element, in order to permit Re, Im, Conj, and replacement of individual components. Sure, a built-in library with single-digit codes (a la MATRIX and TEST) would have been desirable, but what would a menu named "COMPLX" have displaced on the keyboard, how crowded would the backplate info have been, and was there enough room in the ROM?

    In most other cases, the imaginary-valued component is simply ignored where a complex argument is undefined or unsupported. This makes HP-15C programs less likely to error-terminate than those on the HP-42S, which discerns data type and will refuse a "complex" argument having an imaginary component of zero as valid input to a real-domain function. Unfortunately, no "Re" function is provided, so the stack must be pushed to convert such a number; and, well -- careful, with that 4-element fixed stack!

    That's partly why the complex library functions missing from the HP-42S and HP-35s were and are so important.

    -- KS


    Edited: 21 May 2008, 3:24 a.m.


  • Possibly Related Threads...
    Thread Author Replies Views Last Post
      HP's chief strategy officer to retire next month, won't have a successor designnut 2 140 10-23-2011, 08:46 AM
    Last Post: Thomas Radtke
      Questions to the HP calculator group/community about HP 40gs/50g successor bluesun08 44 1,403 08-24-2011, 05:22 AM
    Last Post: bluesun08
      Worthy successor of the HP 41C secretly revealed! Joerg Woerner 16 534 04-02-2011, 04:03 AM
    Last Post: Marcus von Cube, Germany
      HP 32S Successor ka6uup 10 377 07-30-2010, 09:20 PM
    Last Post: db (martinez, ca.)
      Need a new calculator / will there be a successor of HP50g soon? Michael 7 274 09-30-2008, 01:10 PM
    Last Post: Chotkeh Software Corporation
      HP 50g successor Ivan Latorre 10 400 06-05-2008, 01:25 PM
    Last Post: papakanush

    Forum Jump: