The Museum of HP Calculators

HP Forum Archive 19

[ Return to Index | Top of Index ]

HP-32s Engineering Applications Manual
Message #1 Posted by Hansel on 13 Feb 2009, 2:03 p.m.

Hi,

Does anyone know where I can get either the book or a downloadable copy of the book entitled "Engineering Applications" which was written for the HP-32s? ISBN 00032-90057 (or58?)

Thanks, Hansel

      
Re: HP-32s Engineering Applications Manual
Message #2 Posted by Jeff Kearns on 13 Feb 2009, 3:04 p.m.,
in response to message #1 by Hansel

Hansel - I have a copy of "Engineering Applications Step-by-Step Solutions for Your HP-32S Calculator", edition 1, dated June 1998 that I bought from HP in 1994 when I purchased my HP-32sii. The reorder number 00032-90057 is not an ISBN AFAIK.

I do not see this manual on the DVD nor have I seen it for sale elsewhere. If all else fails, maybe I can scan my copy for you (and for the museum at the same time). There are 108 pages plus front and back cover. It would go a bit faster if I did it at the office photocopier but it looks like it would take me a bit of time nonetheless. Let me know how you make out. Jeff Kearns

            
Re: HP-32s Engineering Applications Manual- Already planned for DVD V.7
Message #3 Posted by Allen on 13 Feb 2009, 4:47 p.m.,
in response to message #2 by Jeff Kearns

FYI, before you get too far. There is already a color copy included for the DVD Version 7 (not yet released).

            
Re: HP-32s Engineering Applications Manual
Message #4 Posted by Hansel on 13 Feb 2009, 5:49 p.m.,
in response to message #2 by Jeff Kearns

Thanks for your input. I guess from the email following your email, it looks like they will put this book on the next DVD. Do you have any other items of interested related to the 32s? It doesn't seem that the 32s is as popular as others. I have a 32s, a 41CV, and a 48GX, but I like the 32s the best because it is very handy for quick calculations and its small size. Since I am not in school anymore (BS and MS in Engineering) I don't have the need for the power found in the 41CV or the 48GX. I am keeping all of the HPs for my kids when they get into college and get away from the brainwashing of the school system with the TIs. One of my gripes about the 48GX is that it doesn't float the comma, like a 32s, 41CV and other HPs, unless someone has a download to fix this issue.

                  
Re: HP-32s Engineering Applications Manual
Message #5 Posted by Don Shepherd on 13 Feb 2009, 7:58 p.m.,
in response to message #4 by Hansel

Quote:
get away from the brainwashing of the school system with the TIs

This reflects the perception of many members of this forum that our students would somehow be much better off if the schools were using HP RPN calculators rather than calculators from TI. As an educator, I would guess that maybe one-half of one percent "might" be better off. They would be the really bright kids who might embrace RPN as something different and they might gain some useful mathemtatical insights from using HP RPN calculators in school and at home. But for most kids, RPN would just be something else they would not understand at all in math class, and believe me there is plenty they don't understand today, and RPN would not fix that.

I agree that math instruction (actually all instruction) in the US is woefully inadequate, and I--like most teachers I know--try every day to make a positive difference in my students' lives. But RPN is not the answer. And TI calculators are actually pretty good.

                        
Re: HP-32s Engineering Applications Manual
Message #6 Posted by Hansel on 13 Feb 2009, 8:20 p.m.,
in response to message #5 by Don Shepherd

Maybe I miss directed my disloyalty to TIs. Let me tell you my story of fate. When I was a junior in high school, in 1981, I had received a TI-59. It was a wonderful calculator, it even had a magnetic card reader for programs. Then one day during school, someone absconded with it. I never did recover the TI. Then a coworker of my dad showed me his HP-41. And I have been hooked on it ever since. RPN is not for the faint of heart. I would only recommend it to high school students with a high apptitude for math. Is is a godsend when you have many numbers in an equation to solve such as ((2x45)+(34+8))/(sqrt(65*898)*(45+999)). Try doing this once and only once with a TI and see if you don't mess up the stinking parenthesis! I race my fellow TI owners at work to do a similar problem and they just stair in awe when I am done and they are still trying to remember which parenthesis goes with which! For now, my kids will use the TIs that the school "recommends" for them to use. It is dispecable that they use any calculator at such an early age. And don't even get me start with the state of how mathematics is taught!

                              
Re: HP-32s Engineering Applications Manual
Message #7 Posted by Don Shepherd on 13 Feb 2009, 9:24 p.m.,
in response to message #6 by Hansel

Hansel, I agree that some bright high school kids might find RPN worthwhile, and I would encourage that. Gosh knows they would appreciate a challenge!

I worked in the information technology field for 28 years, then decided to become a math teacher, thinking I would make a positive difference in my students' lives. When I got into the public school middle school classroom, however, reality hit me. While there are some bright spots, public school education is boring for the kids, stressful for the teachers, and a disappointment for almost everyone associated with it. It is a wonder that kids learn anything at all. And don't even get ME started on principals; I'm sure there are good ones out there, but unfortunately I worked under one who cared more about advancing her own career than the kids (or, by the way, my career). I am reminded of the Simon and Garfunkel lyric: "when I think back to all the crap I learned in high school, it's a wonder I can think at all".

Unfortunately, there are no easy answers for making education better. I have just resigned myself to doing what I can do with my own little group of students (I currently volunteer teach in a very small private school with 11 students). The state curriculum guidelines in my state say that we have to teach middle school kids about box and whiskers plots, although I know from experience that they will never see these idiotic things in their life once they leave middle school. I wrote the education department in the state capital and some bureaucrat just said they think there is "some" value in them. Good grief.

                                    
OT: Paul Simon, Kodachrome, film photography, and "crap"
Message #8 Posted by Karl Schneider on 14 Feb 2009, 2:50 a.m.,
in response to message #7 by Don Shepherd

Hi, Don --

Quote:
Simon and Garfunkel lyric: "when I think back to all the crap I learned in high school, it's a wonder I can think at all".

Ah, but it was only a Simon lyric in the song "Kodachrome", which was part of his second solo album following the duo's breakup. At least one radio station bleeped out "crap" many years ago; today, anything goes... ;-)

Production of Kodachrome film by Eastman Kodak has all but ceased, largely a victim of digital photography. Apparently, only Kodachrome 64 (ISO 64 slide film) is still available.

Several years ago, I bought a handsome 1978 Olympus OM-2S 35-mm SLR camera from the same local used-electronics shop where I bought a few of my HP calc's -- mainly to own an example of fine vintage engineering. It even uses the same button cells as the Voyagers and Pioneers!

I soon took a few photos and had the prints developed. Film-developing services are getting scarcer, and I suspect that within a few short years, purchase, developing, and printing of film will be available only at specialized sites by mail or parcel service.

Digital photography is much more flexible, convenient, and less risky in so many ways, but I wonder how many people will fail to get their valuable and irreplaceable photos printed before losing the small SD card or thumb drive that carries them. Or copying them to a PC hard disk that later crashes. Or subsequently being unable to read an obsolete digital format or storage medium. Or...

And finally, back to Don's quote including "crap": This superb 2005 short comedy video from JibJab sprinkles the word liberally as a term for low-quality unessential goods. You-know-who is skewered for its role in the decay of the American economy. The critique is spot-on.

-- KS

Edited: 15 Feb 2009, 5:44 a.m. after one or more responses were posted

                                          
Re: OT: Paul Simon; Kodachrome; film photography
Message #9 Posted by George Bailey (Bedford Falls) on 14 Feb 2009, 4:28 a.m.,
in response to message #8 by Karl Schneider

As Paul Simon sings, I also got a Nikon camera. To tell the truth, I own several pro-sumer and high end analog as well as digital Nikons. And I use both systems. And both systems have their advantages and both systems can fail me: the digital files could become unreadable in the near future and the analog slides can burn or get lost. The latter of those two is one reason why I love digital: it's so much easier to copy and to store at different locations, hundreds of miles apart.

                                          
Re: OT: Paul Simon; Kodachrome; film photography
Message #10 Posted by Martin Pinckney on 14 Feb 2009, 5:24 p.m.,
in response to message #8 by Karl Schneider

Quote:

Production of Kodachrome film by Eastman Kodak has all but ceased, a victim of digital photography. Apparently, only Kodachrome 64 (ISO 64 slide film) is still available.


Alas...

I still have some in my freezer, but will the processing still be available when I shoot it?

I also have some 35mm Technical Pan in my freezer, but I can develop that myself.

Nikon itself has quit manufacturing nearly all film cameras...

                                          
Re: OT: Paul Simon, Kodachrome, film photography, and "crap"
Message #11 Posted by db (martinez, ca.) on 15 Feb 2009, 1:53 p.m.,
in response to message #8 by Karl Schneider

Karl; I too bought an OM2 in 78. What a great piece of equipment, light reliable and intuitive. The chosen camera for astronomers. With it's Vivitar rubber normal lens, mine's been down the Grand Canyon, to nearly 7000 meters in the Andes, and lots of points in between. I used to burn Kodachrome 25, and yes; it's gone. "They" say that today's 64 is equal to what 25 used to be in terms of grain. OK. The only bad thing is that last time i went to get some they wouldn't sell just two rolls. I had to buy a whole stick but it was worth it. Like they said on WKRP: "They're solid plastic, so don't settle for imitations". -db

                              
Re: HP-32s Engineering Applications Manual
Message #12 Posted by Martin Pinckney on 14 Feb 2009, 5:15 p.m.,
in response to message #6 by Hansel

Quote:
Is is a godsend when you have many numbers in an equation to solve such as ((2x45)+(34+8))/(sqrt(65*898)*(45+999)). Try doing this once and only once with a TI and see if you don't mess up the stinking parenthesis!
Well, that may have been true during the early years, but now with textbook display (available on HP RPL machines as well), there are no problems with "messing up" parentheses. Even with some non-RPL models (e.g. 17b, 27s), you at least see all open parentheses.
                                    
Re: HP-32s Engineering Applications Manual
Message #13 Posted by Hansel on 14 Feb 2009, 9:27 p.m.,
in response to message #12 by Martin Pinckney

I remember my college roommates, who at the time were EE students, with their Casios with the full screen to show all of the parts of the equations including the paranthese. They were still punching in the numbers and paranthese while I had my answer and went on to solve the next problem.

                              
Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #14 Posted by Thomas Klemm on 16 Feb 2009, 12:51 p.m.,
in response to message #6 by Hansel

The limitation of RPN is of course the restriction to 4 registers in the stack. This made me think about the simplest algebraic expression that can't be calculated with a typical HP-calculator:

((1 + 2)*(3 + 4) + (5 + 6)*(7 + 8))*((9 + 10)*(11 + 12) + (13 + 14)*(15 + 16)) = 236964

There might be different ways to do that in RPN but it will be something like:

1 2 + 3 4 + * 5 6 + 7 8 + * + 9 10 + 11 12 + * 13 14 + 15 16 + * + *

Whichever solution you might choose you will always run into a stack-overflow and what's worse you probably won't even notice. In the example above you will end up with: 556738.

Neither TI-57 nor TI-59 have problems with the expression above. Agreed, they have other limitations concerning the maximal number of open parenthesis.

Of course there are ways to circumvent the limitation using LASTx or other registers. But that's rather cumbersome.

Actually I never ran into this limitation myself but on the other hand this expression isn't that complicated neither. Compared to your example I'd even say it's not that far away.

Tools have their limitations. Best is to know them.

PS: Can anybody think of an even simpler expression that can't be calculated using RPN?

                                    
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #15 Posted by Michael de Estrada on 16 Feb 2009, 1:36 p.m.,
in response to message #14 by Thomas Klemm

You bring up a very important point regarding most HP RPN calculators, which have a fixed 4-level stack. However, several HP models do not have this limitation, notably the HP-28C, HP-28S, HP-48S and HP-48SX, which have a stack limited only by free memory. I don't own any of the more recent HP calculators, such as the HP-50g, so I don't know if they also have unlimited stacks. I use these calculators when performing long chained calculations with many levels of pending operations.

Edited: 16 Feb 2009, 3:08 p.m. after one or more responses were posted

                                          
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #16 Posted by bill platt on 16 Feb 2009, 2:36 p.m.,
in response to message #15 by Michael de Estrada

The 50G is based on the same 48G paradigm. Essentially any user program written for the 48 will run on the 50 but it needs to be recompiled from the high-level user RPL language.

                                    
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #17 Posted by bill platt on 16 Feb 2009, 2:42 p.m.,
in response to message #14 by Thomas Klemm

Yes, you can run out, if you aren't paying attention. RPN is not a "fire and forget" system. It was devised in the early 1970s and when it became clear that memory was cheap enough, and demand for more capability present, the 28 series was invented. That some of us choose to use the simple tool from the early 70s and know how to use it--paying attention to stack depth--really isn't that big a surprise. Many more people continue to use "4-bangers" with a ludicrous form of chain logic--which is also the product of memory-limitations and ease of machine programming from the 70s....

Of course you already know all of that :-)

Edited: 16 Feb 2009, 3:37 p.m.

                                          
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #18 Posted by Gene Wright on 16 Feb 2009, 3:44 p.m.,
in response to message #17 by bill platt

Yes, you can run out even if you ARE paying attention.

In circumstances like this, you'd have to store off an intermediate result to a register.

That said, it does not necessarily follow that a semi-infinite stack is the solution.

I remember articles from the PPC Journal proposing a 5-level stack. Would have been interesting.

                                    
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #19 Posted by Karl Schneider on 16 Feb 2009, 5:23 p.m.,
in response to message #14 by Thomas Klemm

Quote:
The limitation of RPN is of course the restriction to 4 registers in the stack.

Hi, Thomas --

Well, no, the 4-level fixed stack is not a chracteristic or RPN per se, but rather an effective compromise of what is useful, necessary, and practical. Three levels is inadequate (which, alas, did not stop National Semiconductor in the 1970's), but most people have difficulty keeping track of more than four values in the stack.

I've advocated a settable value for fixed RPN stack depth, with mimimum = default = 4; and maximum = 9 or 19, set respectively by a command on the HP-35s such as "STKD 9" or "STKD .9". (An HP-43s might require "STKD 09" to support indirection.)

Quote:
((1 + 2)*(3 + 4) + (5 + 6)*(7 + 8))*((9 + 10)*(11 + 12) + (13 + 14)*(15 + 16)) = 236964
Neither TI-57 nor TI-59 have problems with the expression above.

Sure, as long as all the required parentheses are properly placed in the expression, and meticulously entered during calculation.

Quote:
Of course there are ways to circumvent the limitation using LASTx or other registers. But that's rather cumbersome.
1 2 + 3 4 + * 5 6 + 7 8 + * + 9 10 + 11 12 + * 13 14 + 15 16 + * + *

If the blank spaces between numbers indicate use of the "SPACE/SPC" command, that's RPL, which handles this problem just fine.

Quote:
There might be different ways to do that in RPN but it will be something like

an expression that is not too cumbersome:

1 ENTER 2 + 3 ENTER 4 + * 5 ENTER 6 + 7 ENTER 8 + * + 
STO 0 
9 ENTER 10 + 11 ENTER 12 + * 13 ENTER 14 + 15 ENTER 16 + * +
RCL* 0 (or RCL 0 *)

Quote:
PS: Can anybody think of an even simpler expression that can't be calculated using RPN?

If the "gotcha" does not entail limited stack depth, I'm not sure what it would be. Entering inputs when usable and reversing with x< >y, instead of left-to-right, helps to avoid the problem.

-- KS

Edited: 16 Feb 2009, 5:26 p.m.

                                          
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #20 Posted by Walter B on 16 Feb 2009, 6:03 p.m.,
in response to message #19 by Karl Schneider

Quote:
I've advocated a settable value for fixed RPN stack depth, with mimimum = default = 4; and maximum = 9 or 19, set respectively by a command on the HP-35s such as "STKD 9" or "STKD .9". (An HP-43s might require "STKD 09" to support indirection.)
So did I in my draft of a 43S in 2007: fixed settable stack depth, 4 through 12 levels. Today I'd reduce it to the choice of 4, 6, and 8 levels. This shall be sufficient for all reasonable equations in real life ;) while 4 levels are a bit tight some times.
                                                
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #21 Posted by bill platt on 16 Feb 2009, 6:15 p.m.,
in response to message #20 by Walter B

I like the idea of RPL with RPN subset. Actually, 4 level, 8 level, and RPL would be everything. The value of a replicating "t" register would be available with 4 and 8 level stack; the infinite RPL will handle anything.

The interesting thing is that there are perfectly good ways to use RPL to take care of *everything* regular RPN guys like, but we find ourselves always reaching for our o9ld favorites. At least that's what I do.

It seems to me that a compact RPL machine, with a built-in RPN mode emulator would do everything. The likelihood of such a model is very remote as it would directly steal from the large graphing machines. Perhaps what really needs to be done is to start making the RPL graphing machines smaller. The cumbersome size is the only real downside. That's the only reason I really see to have a 32sii around any more...that and my familiarity and nostalgia...

I've used the 41cx emulator on the 48GXquite a lot. What I think wold be even better going forward would be a "native" sort of RPN emulator or shell for the 50G. Call it "quick-calc" or something...

                                          
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #22 Posted by Michael de Estrada on 16 Feb 2009, 6:27 p.m.,
in response to message #19 by Karl Schneider

Actually, not all National Semiconductor (aka Novus) calculators had a 3-level stack, such as the model 4510 Mathematician and 4615 programmable. The model 4640 featured a 4-level stack with x<>y exchange and stack roll down and was a virtual clone of the HP-45 in terms of features. It even attempted to mimic the appearance of the Hp's with a black pebble grain case with silver trim. Unfortunately, the simililarity ended there, as the keys were tiny with no feel and the internal NiCad batteries were not replaceable.

                                          
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #23 Posted by Martin Pinckney on 16 Feb 2009, 8:53 p.m.,
in response to message #19 by Karl Schneider

Quote:
Quote:

((1 + 2)*(3 + 4) + (5 + 6)*(7 + 8))*((9 + 10)*(11 + 12) + (13 + 14)*(15 + 16)) = 236964

Neither TI-57 nor TI-59 have problems with the expression above.

Sure, as long as all the required parentheses are properly placed in the expression, and meticulously entered during calculation.


In other words, to get the correct answer, you have to enter the problem correctly.

Is RPN any different in this regard?

I just entered this expression into my 22s and got the answer above on one try. Why shouldn't I?

                                          
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #24 Posted by db (martinez, ca.) on 16 Feb 2009, 9:21 p.m.,
in response to message #19 by Karl Schneider

Gene, Karl, Michael;
There was one 5 level stack RPN scientific, marketed by Heathkit. It was very well designed and used the best parts available in America that were not already getting bolted onto an HP. The only improvement i can see would have been to paint or mold the functions onto the keytops, but that would have surly broken the bank for this specialized and limited production run.
This has links to Katie Wasserman's and Joerg Woerner's pages on it. - db

                                          
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #25 Posted by Thomas Klemm on 16 Feb 2009, 9:39 p.m.,
in response to message #19 by Karl Schneider

Hi Karl

Quote:
If the blank spaces between numbers indicate use of the "SPACE/SPC" command, that's RPL, which handles this problem just fine.

You might also think of an HP-41 program without line numbers. Actually I used the unix command bc:

echo "((1 + 2)*(3 + 4) + (5 + 6)*(7 + 8))*((9 + 10)*(11 + 12) + (13 + 14)*(15 + 16))" | bc -c
 1 2+ 3 4+* 5 6+ 7 8+*+ 9 10+ 11 12+* 13 14+ 15 16+*+*ps.

But you're right you could as well use ->RPN from the HP-48 examples to get the same result.

Quote:
an expression that is not too cumbersome:

1 ENTER 2 + 3 ENTER 4 + * 5 ENTER 6 + 7 ENTER 8 + * + 
STO 0 
9 ENTER 10 + 11 ENTER 12 + * 13 ENTER 14 + 15 ENTER 16 + * +
RCL* 0 (or RCL 0 *)

So how do we know at that point that we need to keep an intermediate result for later? That's all but trivial because you have to parse the whole tree in your mind. Just assume that one of the terms is shorter, say instead of (5 + 6) we have just 5. In this case you don't need an additional register but you could rearrange the calculation so that this term is the last one. But then you have to start calculating the right expression first.

What I meant with cumbersome is the following:
Let's assume I'm not so clever as to keep the intermediate result in register 0 until the last addition when all of a sudden I realize: Now I can't enter 16 or I'll loose register T. So what will I most probably do?

R^
STO 0
RDN

And later I can use register 0 as you suggested. But what's happening when the expression gets bigger and bigger using 32, 64, 128, ... numbers? Either you use different registers for each intermediate result at the risk of running out of registers or you try to use them cleverly as a stack. But then you have two stacks to synchronize. And that's definitely the moment where I'd quit and use a different tool without this limitation.

Personally I prefer a 4-level stack calculator to any other. I wouldn't need 5, 8 or more levels. I'd be completely lost with them since I can't remember more than three things at a time. I'd be scrolling up and down the stack all the time to find my intermediate results again.

Kind regards
Thomas

                                                
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #26 Posted by Walter B on 17 Feb 2009, 1:46 a.m.,
in response to message #25 by Thomas Klemm

Hallo Thomas,

Quote:
I wouldn't need 5, 8 or more levels. I'd be completely lost with them since I can't remember more than three things at a time. I'd be scrolling up and down the stack all the time to find my intermediate results again.
FYI, you don't need to remember all level contents. Nobody operating an RPL model is able to remember the infinite stack ;) You just push the intermediate results on it and know they will pop out when you need them.

The advantage of a finite stack - top level repetition - will remain for e.g. 8 levels, too. To ease calculations with constants, a FILL command shall copy x to all stack levels at once.

Viele Gre,

Walter

                                    
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #27 Posted by Palmer O. Hanson, Jr. on 18 Feb 2009, 11:39 p.m.,
in response to message #14 by Thomas Klemm

Quote:
The limitation of RPN is of course the restriction to 4 registers in the stack. This made me think about the simplest algebraic expression that can't be calculated with a typical HP-calculator:

((1 + 2)*(3 + 4) + (5 + 6)*(7 + 8))*((9 + 10)*(11 + 12) + (13 + 14)*(15 + 16)) = 236964

There might be different ways to do that in RPN but it will be something like:

1 2 + 3 4 + * 5 6 + 7 8 + * + 9 10 + 11 12 + * 13 14 + 15 16 + * + *

Whichever solution you might choose you will always run into a stack-overflow and what's worse you probably won't even notice. In the example above you will end up with: 556738.

PS: Can anybody think of an even simpler expression that can't be calculated using RPN?


A similar problem was proposed in this Forum back in 2006 where the only difference was that a divide was used in the middle instead of a multiply. You can read about it in my 3 November 2006 thread titled "It Can Be Done" I have reproduced the essentials of my solution below:
Quote:
Cuppo wrote:

"I think the followig problem highlights pretty clearly some disadvantages of 4-level RPN:

[(3+1)(4+3)+(2+6)(4+6)] / [(2+3)(2+1) + (3+5)(4+2)] = ?

This problem is not possible using a 4-level stack without using STORE."

Not so! Try this which doesn't even require the use of LAST X:

Calculate the denominator first: 2 ENTER 3 + 2 ENTER 1 + X 3 ENTER 5 + 4 ENTER 2 + X + The denominator (63) is in the x register. Now calculate parts of the numerator divided by the denominator and add them together: 3 ENTER 1 + 4 ENTER 3 + X 2 ENTER 6 + Roll Down x<>y / Roll Down / x<>y Roll Down 4 ENTER 6 + X +

and see 1.71428 ... = 108/63 in the display.


So I suggest that you try something similar on your slightly different problem. If you really can't get there after trying then let me know and I will give it a go. I admit that it took me a couple of hours and several false starts before I got the solution. So, a user really shouldn't try to do this instead of using a memory location for intermediate results. But it was an interesting programming challenge.

This whole issue of whether AOS or RPN is better has been an ongoing issue with the AOS people contending that RPN is limited and difficult and the RPN people contending that they just can't handle parentheses. On page 39 of his book A Guide to HP Handheld Calculators and Computers - Fifth Edition Wlodek wrote

Quote:
Many users - and not only those brought up on Friden calculators - prefer RPN. Others find it a total mystery - or at least profess to do so. I do not really believe it - ...
I am hoping to convince Wlodek to include a corollary in the next edition which would read something like this
Quote:
Many RPN afficianados profess that they simply can't cope with the parentheses inherent in AOS. I do not really believe that either.
Palmer

                                          
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #28 Posted by Michael de Estrada on 19 Feb 2009, 12:18 p.m.,
in response to message #27 by Palmer O. Hanson, Jr.

I am a total RPN afficionado, however, calculators for me as an engineer are practical tools, not toys. I want them to provide the simplest methodolology for providing fast and reliable results. As such, when confronted with a problen such as discussed above, the simplest methodology for me is to perform the operations from left to right, rather than moving around the expression and playing with stack operations or changing division into multiplication. It is here than I run into problems with the fixed 4-level stack, and revert to my HP-48SX, which has an unlimited stack.

                                          
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #29 Posted by Thomas Klemm on 19 Feb 2009, 6:03 p.m.,
in response to message #27 by Palmer O. Hanson, Jr.

Hi Palmer
Very clever the trick to use distributive law. But then you can always use a function like SQRT or LN which is not distributive:

SQRT(LN(1 + 2)*SQRT(3 + 4) + LN(5 + 6)*SQRT(7 + 8))*SQRT(LN(9 + 10)*SQRT(11 + 12) + LN(13 + 14)*SQRT(15 + 16))

Actually I'm happy the expression has to be more complicated. I'm still wondering what the limitations of a 4-level stack are.

It seems there are other people disliking parentheses as well:

Quote:
Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in.
-- Larry Wall

Kind regards
Thomas

Edited: 19 Feb 2009, 6:06 p.m.

                                                
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #30 Posted by Palmer O. Hanson, Jr. on 19 Feb 2009, 10:25 p.m.,
in response to message #29 by Thomas Klemm

Thomas:

Quote:
I'm still wondering what the limitations of a 4-level stack are.
I'm not sure that I really care. I struggled writing RPN programs until I took the time to understand the stack. If I suspect that I may run into a problem then I take the time to carry forward a stack diagram.
Quote:
It seems there are other people disliking parentheses as well:
I suspect that most of the engineers who say that they just can't keep track of parentheses really could if they tried.

The problem that you proposed is one of those that has been around for some time and was generated by someone who wasn't really conversant with what can be done with RPN. The RPN folks have devised their own test problems which they say can't be solved with AOS -- the Mach Number problem is a classic case. But any self-respecting AOS guy can handle it with ease, and there is the Wozniak comment to consider.

I am a little bemused by all the back and forth talk about difficulty in programming because whether in RPN or AOS it is all so easy relative to the "good old days" (actuallly, not so good) with airborne computers where, for example, it took about ten word times to complete a multiply and the programmer needed to be doing other calculations in the interim, but be ready to read the result of the multiply when it was done. In those days programming was as much an art as a science.

Palmer

                                                      
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #31 Posted by bill platt on 20 Feb 2009, 9:03 a.m.,
in response to message #30 by Palmer O. Hanson, Jr.

All of it is "trivial" in the world of physics...just different logical systems with advantages and disadvantages.

In ad-hoc manual solutions, you need to keep track of the stack in your head. This is a skill that an RPN user should develop. It prevents t-register drop-off. Yes, it is a potential weakness and as we have seen,the infinite stack eliminates the problem for manual problems.

In programming, the problem can get more complicated, depending on how the program works. If there is dynamic memory and stack use, you can end up with unanticipated t-register drop. But in AOS you can also have unanticipated things happen.

The real advantage of various improvements to AOS or EOS etc is that the user doesn't need to change his thinking as much. But the RPN defender will point out that most of us speak of taking the sin, taking the log (rather than log[x] or sin[x] we really think x sin), and of the pencil and paper write a number, write another, act on it...so I am afraid the argument will be perpetual. Gives us all something to do :-)

                                                            
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #32 Posted by Hansel on 20 Feb 2009, 12:01 p.m.,
in response to message #31 by bill platt

Stack? What stack? You guys actually worry about what is in the stack? I have used an HP calculator for 8 years of college (BS and MS) and never once worried about what was in the stack. That is the simplicity of the RPN system!

                                                                  
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #33 Posted by bill platt on 20 Feb 2009, 12:12 p.m.,
in response to message #32 by Hansel

You must never have to do anything particularly long or any calculations that have deep parenthesis then...it is really a matter of what sort of calculations you end up doing.

If oyu use your 48 most of the time, then of course you don't worry.

These days I usually go to the computer for long things anyway...

Edited: 20 Feb 2009, 12:13 p.m.

                                                
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #34 Posted by Palmer O. Hanson, Jr. on 20 Feb 2009, 11:20 p.m.,
in response to message #29 by Thomas Klemm

Thomas:

You wrote:

Quote:
... But then you can always use a function like SQRT or LN which is not distributive:
SQRT(LN(1 + 2)*SQRT(3 + 4) + LN(5 + 6)*SQRT(7 + 8))*SQRT(LN(9 + 10)*SQRT(11 + 12) + LN(13 + 14)*SQRT(15 + 16))

It turns out that this problem is a very simple extension of the previous problem if the user only remembers that SQRT(A)*SQRT(B) = SQRT(A*B). Then the user doesn't do the SQRT before LN(1+2) or the SQRT before LN(9+10) as in the expression but rather does a single SQRT at the end.

The answer for the expression is 19.8983982... . I checked that by doing the problem as written in BASIC. I did run into a problem when trying to use the BASIC in the CC-40 or TI-74 because of the length of the expression. So I had to store some intermediate results to get the answer. The BASIC in my Radio Shack Model 100 handled the expression without difficulty.

I suspect that the problem would become significantly more difficult to solve if the first SQRT was changed to a LN. I wouldn't say that is couldn't be solved without storing an intermediate result since I hadn't needed to use LAST X in the solutions for the previous problems. What do you think?

Palmer

                                                      
Re: Limitations of RPN (was: HP-32s Engineering Applications Manual)
Message #35 Posted by Thomas Klemm on 24 Feb 2009, 11:02 p.m.,
in response to message #34 by Palmer O. Hanson, Jr.

Quote:
I suspect that the problem would become significantly more difficult to solve if the first SQRT was changed to a LN.

That's exactly what I had in mind. Close, but no cigar.

Quote:
What do you think?

Obviously not enough before posting.

I'll try one last time:

sqrt(sqrt(sqrt(1 + 2) + sqrt(3 + 4)) + sqrt(sqrt(5 + 6) + sqrt(7 + 8))) + sqrt(sqrt(sqrt(9 + 10) + sqrt(11 + 12)) + sqrt(sqrt(13 + 14)  + sqrt(15 + 16)))

The same expression in postfix-notation (v ~ sqrt):

 1 2+v 3 4+v+v 5 6+v 7 8+v+v+v 9 10+v 11 12+v+v 13 14+v 15 16+v+v+v+

And here's the result:

4.696150115171

I doubt that LASTx might be useful here. But most probably you teach me something different ...

Thomas

                                    
The RPN solution is much easier than in my earlier response
Message #36 Posted by Palmer O. Hanson, Jr. on 21 Feb 2009, 3:43 p.m.,
in response to message #14 by Thomas Klemm

Thomas:

You wrote:

Quote:
The limitation of RPN is of course the restriction to 4 registers in the stack. This made me think about the simplest algebraic expression that can't be calculated with a typical HP-calculator:

((1 + 2)*(3 + 4) + (5 + 6)*(7 + 8))*((9 + 10)*(11 + 12) + (13 + 14)*(15 + 16)) = 236964

There might be different ways to do that in RPN but it will be something like:

1 2 + 3 4 + * 5 6 + 7 8 + * + 9 10 + 11 12 + * 13 14 + 15 16 + * + *

Whichever solution you might choose you will always run into a stack-overflow and what's worse you probably won't even notice. In the example above you will end up with: 556738.


I responded with a solution that does not run into stack overflow which was based on an earlier solution that I had developed for a similar problem back in 2006. That solution involves the use of three Roll Down commands and two x<>y commands. While it will yield a correct answer it is admittedly a cumbersome way to do the problem. It turns out that there is a much more straightforward way to do the problem which only requires the use of plus and multiply commands. All you need to do is multiply the left hand half of the expression by the right hand half of the expression which yields a modified form of the expression which looks like this
(1+2)*(3+4)*(9+10)*(11+12)+ ...      ... +(5+6)*(7+8)*(13+14)*(15*16)
and solve in the standard RPN manner. With just a small amount of attention you do not actually have to write out the modified expression but just enter the elements directly from you original expression.

Palmer

                  
Re: HP-32s Engineering Applications Manual
Message #37 Posted by Didier Lachieze on 16 Feb 2009, 7:32 a.m.,
in response to message #4 by Hansel

Hansel, you have mail.

Regarding your second question, I'm aware of another book related to the HP-32s:

Tips and Programs for the HP-32s: A Handbook for Science and Engineering by Wlodek Mier-Jedrzejowicz

however I don't have it and I don't think it's on the museum DVD set. If someone could scan it for the next DVD version it would be great.

Edited: 16 Feb 2009, 9:07 a.m. after one or more responses were posted

                        
Re: HP-32s Engineering Applications Manual
Message #38 Posted by Allen on 16 Feb 2009, 8:02 a.m.,
in response to message #37 by Didier Lachieze

As an American, I found the "Black Hole" Section of Wlodek's 32S book very useful approximating the length of impact of the Economic Stimulus Efforts. See p.35

                        
Re: HP-32s Engineering Applications Manual
Message #39 Posted by Hansel on 17 Feb 2009, 9:35 a.m.,
in response to message #37 by Didier Lachieze

Yes, I just bought the book on ebay last week. I will find a good scanner and scan the book soon. Thanks again for your book.

                              
Re: HP-32s Engineering Applications Manual
Message #40 Posted by BruceH on 17 Feb 2009, 7:39 p.m.,
in response to message #39 by Hansel

Quote:
Yes, I just bought the book on ebay last week. I will find a good scanner and scan the book soon. Thanks again for your book.
Before you do that, and we have to invoke the DMCA and have you carted off to Gitmo[1], why don't you ask Wlodek's permission first? He often posts to MoHPC.

And to the earlier poster who wanted a scan - why don't you first ask Wlodek if he has any left for sale?

[1] This is probably not true - the penalties for breaching the DCMA are far more severe than trying to overthrow the US. ;-)

                                    
Re: HP-32s Engineering Applications Manual
Message #41 Posted by Hansel on 18 Feb 2009, 9:47 p.m.,
in response to message #40 by BruceH

No problem. Actually I am surprised that you don't already have this manual on the DVD collection.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall