▼
Posts: 1,153
Threads: 94
Joined: Mar 2006
After the previous "improved" display on the HP-33s, I had my doubts.
But (as already reported by others) the latest version I've seen (at Wal-Mart) is very much like what should have been released initially. Each character matrix has been reduced in size, leaving more room between them for the larger decimal point. The contrast appears better too. I'll have to take a closer look to see if the spaces between the pixels have been narrowed.
I do notice that the latest model has embossed on (actually, molded into) its back a garbage can icon with a diagnoal line through it. I'm sure this is meant to suggest that we properly dispose of the batteries and/or circuit board. However, I can't help taking this as an admission that the earlier models should be thrown out! ;-)
▼
Posts: 801
Threads: 36
Joined: Nov 2005
Does HP allow trade-ins for the 33S like they did with the 49G+? I forget.
▼
Posts: 348
Threads: 74
Joined: Jun 2013
The only way to know would be to call support and find out.
They may take the line that there is no defect in the earlier 33S units. This is merely an incremental improvement.
But hey, if you are in the US, it is a toll free call.
Posts: 64
Threads: 10
Joined: Aug 2007
I bought a 33s with the older decimal point and bad keyboard, and called up and complained. This calculator didn't always register keystrokes. I told them that I design life-safety elements for a living (which is the truth), and that because the keys didn't always register, and because the decimal point was extremely difficult to distinguish, I couldn't rely on this calculator. The guy on the phone had me reset the thing, which did nothing, and then he said that he would send me a new one, which he did. He also said that he would specify as a special instruction that the replacement unit should have the improved decimal. I received this replacement unit in the mail very quickly, and it did have the improved display. I now use this calculator daily at work, with confidence.
If I was the owner of one of the previous versions of the 33s, I would call them to voice my displeasure over the decimal point issue, and ask if I could be sent a replacement unit with the improved display. You may be surprised, and they may do it. If they hadn't sent me a new one, I would never spend another cent on an HP. However, because they did send me an improved one, I bought another one at Wal Mart to have as a backup.
Posts: 1,153
Threads: 94
Joined: Mar 2006
. . . supposedly a new unit is on the way.
The voice recognition system kept hearing "HP 33S Scientific Calculator" as "Laser Printer", but later it dropped back and started listting product classes. "Handheld" got me to "Calculator" and (FYI) when asked "Home, Home office, or Business", I replied "Business".
From my converstaion with the very helpful attendant, I gather that it helps greatly to have a receipt showing purchase within the last 12-15 months. (Another, even older 33s has a serial # indicating that its replacement is a bit too much to ask, so I'll only be upgrading one of my two original-style units.)
I understand that, should they want my old unit, they'll send a mailing label. If no label, I can do what I want with the old one. ("Throw it out" comes to mind, but I know a high school student who might want it . . . )
So, "Hooray!" for HP calculator support. (And good luck to you all!)
▼
Posts: 111
Threads: 22
Joined: Jul 2007
That's funny, I too had some funny recognitions to 'calculator'..Response: "Did you say Jukebox?" :)
But I did eventually get through, and the HP rep was quite helpful.
ECL
▼
Posts: 801
Threads: 36
Joined: Nov 2005
Did you guys note how sometimes the voice would sound "frustrated"??!
LOL!
Posts: 1,153
Threads: 94
Joined: Mar 2006
FYI . . .
The replacement showed on Saturday. Calculator only (with batteries installed), wrapped in bubble wrap. Ser # CNA 442nnnnn, with the improved display.
It came with a curious circular beige sticker on the back, printed in black with "MARKETING SAMPLE", and some illegible handwriting.
Though it has the newest display, it seems to have the old (uncorrected) ROM.
.1 ten minutes
->HR as decmial portion of hour (result: 0.1667)
1 one hour
- subtract (result: -0.8333)
->HMS convert (result: -0.4920)
(My newest unit -- Ser # CNA 532nnnnn -- gives -0.5000 .)
So, beware: there are some "transitional" units with newer displays, but old ROMs.
Curiously, it's got the worst keyboard of my several units -- seems to "miss" on the arithmetic operation keys occasionally. (I hadn't noticed a single problem with 33s keys until this one arrived.) I'll try the "wiggle fix" that seemed to clear up my 49G+ keys so well.
Hey! I'm not complaining! Thanks to H-P for the replacement. I'm just sharing to add to the knowlege base.
My son is using the older unit, in ALG mode, and with no idea yet how to program the thing. He considers it a glitzy upgrade from his previous 20S. And who am I to argue? The two-line display and 26+ variables are indeed steps up.
Edited: 14 Nov 2005, 12:58 p.m.
▼
Posts: 801
Threads: 36
Joined: Nov 2005
I called today and the gentleman who responded got my information and set the replacement process underway. I suspect I might just remain a (satisfied) customer...
... funny thing, though, shades of 1984 or the V chip: I asked if he could tell from their records (I did register my calculator, if I recall correctly) where I bought it and in doing so, I mentioned that I have been buying their calculators since I was old enough to afford and buy my own calcs. To this he replied, "Oh, we have an EXTENSIVE record on you!" :P ::( ; I guess it must be extensive... for some of us
;) .
It would also be a gas if this fellow happens also to read our forum!
(I also hope on their records, I didn't come across as too whiny!!)
Posts: 875
Threads: 37
Joined: Jul 2005
Paul,
Sounds like you have a collector's item. For everybody else, I'd advise buying only units with serial numbers beginning with CNA5xx, or maybe even only CNA532 or later. I finally went to a local Walmart yesterday to see if they had any in stock. I found a hanger with several units hanging on it. I pulled the first one off, pushed the ON button through the blister pack and entered a string of twos. Sure enough, the display seemed much better than my original unit. The serial number on the back was CNA532xxxxx. Curious, I checked the next unit. Its serial number was something like CNA442xxxxx. I pushed its ON button and entered all twos, and saw the old tiny radix. All of the other units were in the same serial number range and had the old display. Needless to say, I put the bad units back and purchased the one good one. So if you want a 33S with the new display, don't buy one that begins CNA4, and your best bet is to actually check before you buy if you can.
Regarding the missing key presses and the need to try the "wiggle-fix", let's hope that is a problem only with your particular prototype (or whatever it is.) (Except for the collector's item aspect, I'd say you would have a right to complain and request yet another replacement.) For what it is worth, the keyboard on my new unit passes the self test, functions flawlessly in use, and feels noticeably better than my first 33S. The feel is a little softer and less "clicky". It is virtually indistinguishable from several pioneers to which I compared it.
▼
Posts: 64
Threads: 10
Joined: Aug 2007
I noticed the same thing at my local Walmart. They a few of the newer machines with the improved display at the front, and towards the back were the older ones with the flawed display. I wonder how much additional bad blood directed against the 33s and HP as a result of people buying the older 33s with the horrible display.
My initial reaction to the 33s was extremely negative. I had spent about $60 for something with an unusable display, and if I hadn't heard in this forum that machines with the improved display were on the way HP would never have seen another dime of my money. After getting a replacement 33s with the improved display and buying another one from Walmart, I have given the 33s another chance, and have to admit that I actually like it. I think it could be in HP's best interest to recall any of the older 33s that are still on the shelves with the flawed display.
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi Paul,
Which ALGebraic stack logic does it have?
Is it the parallel stack, or the swap x.,y stack?
▼
Posts: 1,153
Threads: 94
Joined: Mar 2006
If you mean the "swap" key function described here,
it (# CNA442nnnnn) gives DIVIDE BY 0,
just like my newest unit (# CNA532nnnnn),
while my oldest unit (# CN404nnnnn) gives 0.5 .
So it would appear there are at least three ROM versions?
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Yep.
So far, I have delineated:
REV Description
beta Gene's Calc sample.
- Walmart initial release. (just before the EIT exam a few years ago).
A 1st full-time release
B Bugs fixed for the polar rect and the h.ms
Regarding ALG
beta and "-" have the same functionality, viz 24 / 12 SWAP <enter> gives 0.5
"A" and "B" give 24 / 12 SWAP <enter> give div 0. Note that you really need to see my old thread that desribes what is really happening here.
In short, the newer ones maintain two parallel independent algebraic stacks--you can actually run tow independent algebraic chain calculations simultanious ly. SWAP simply moves from one to the other, and so you can also link them.
The earlier ROMS gave the more familiar x<>Y swap which reverses the order--similar to the 20s.
The LCD display appears to be changed indepenedt of the ROM. In otherwords there is not synchronization between the two imporvements.
BETA and "-" may be the same ROM. But the keyboards were different with some of the functions (ask Gene about it! :-)
Edited: 15 Nov 2005, 12:56 p.m.
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Nope, all my 33S calculators have the same keyboard layout. :-(
▼
Posts: 1
Threads: 0
Joined: Jan 1970
I stand corrected!
Funny though--I distincly remember something about that---was there an early "image" released before actual hardware, that you might have pointed out?
Answer me up-thread--we can kill this one?
I am correcting my post above, and so i will put "1234" here for erasing--then you can erase yours if you like (or has this feature been disabled?)
Posts: 1,153
Threads: 94
Joined: Mar 2006
Thanks. I'll chase down your older thread on the stack thingie.
Without knowing what's behind the curtain, I was surprised that the older units "behaved better" than the newer with regard to this (SWAP in ALG mode).
But I've assumed it's simply not an issue to an RPN user.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
"better"?
Don't you think it is kind of cool to have two parallel stacks?
(Of course the loss of the inversion capability is sort of vexing...)
Somewhat related, at least as far as ALG goes: the only unpleasant surprise for me, when I finally got a 27s, was that there is no swap command. the 17bii has it--but only because it *has* to because of the RPN mode.
Regards,
Bill
Posts: 282
Threads: 46
Joined: Jul 2005
Just out of interest, there is an example of the H.MS but in this thread but could someone supply an illustration of the way in which the polar to rect bug manifests itself...?
Thanks.
Mike T.
▼
Posts: 74
Threads: 14
Joined: Jul 2007
Rectangular to Polar Conversion
When performing a rectangular to polar conversion of a number where the X or Y coordinate is equal to zero, the result might be inaccurate.
Workaround :
When performing rectangular to polar conversions, if any of the 2 input is 0, take the absolute value of the number before performing the rectangular to polar conversion to yield
the correct result.
Example :
10(enter)0(CHS)(ABS)(r-p) will yield the correct result (10, 90)
while
10(enter)0(CHS)(r-p) will not (10,270)
There was at one time a workaround posted on the HP website for all the 33S bugs, but I could not find it. The update was dated September 2004, while the newest manual (3rd Ed)is dated November 2004, the updates should have made it into the manual but I didn't check. Email me if you need a copy.
mike at safetyplans.net
Edited: 18 Nov 2005, 9:19 a.m.
Posts: 1,153
Threads: 94
Joined: Mar 2006
Here's something I've found:
CNA 442nnnnn CNA 532nnnnn
... keystroke display display
... 10 x: 10 y: 0.00 x: 10 y: 0.00
... ENTER x: 10.00 y: 10.00 x: 10.00 y: 10.00
... 0 x: 0 y: 10.00 x: 0 y: 10.00
... ->theta,r x: 10.00 y: 90.00 x: 10.00 y: 90.00
... ->y,x x: 0.00 y: 10.00 x: 0 y: 10.00
... ->theta,r x: 10.00 y: 270.00 x: 10.00 y: 90.00
... ->y,x x: 0.00 y: -10.00 x: 0 y: 10.00
... ->theta,r x: 10.00 y: -90.00 x: 10.00 y: 90.00
... ->y,x x: 0.00 y: -10.00 x: 0 y: 10.00
... ->theta,r x: 10.00 y: -270.00 x: 10.00 y: 90.00
... ->y,x x: 0.00 y: 10.00 x: 0 y: 10.00
I assume that illustrates the bug?
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
My CNA 51500163 seems to be a bastard:
1.) The display is perfectly OK; I can't compare to an older machine but I have no trouble reading the decimal point (a comma in my case.)
2.) The P-R bug is present, exactly as shown above.
3.) X<->Y in ALG mode doesn't exchange the last two numbers entered (as to reverse the result of - or /) but seems to use a shadow register that can be used for any purpose. (Very much like the t-Register on older AOS TI machines such as the TI-59)
Marcus
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Marcus,
Do this:
clear registers, clear stack in RPN
ALG
1 + 6 <enter>
<x<>Y>
If you see "6" then you have the original "pre-release" or rev "-".
If you see "0" then you have the second version of the ROM ("A"). (The third version would have bugs fixed).
Now, continuing from above, assuming you can see "0", then do this:
9
x
<x<>y>
{at this point you should be seeing "7" from the 1st calc}
+
<enter>
Notice that you have carried on two independent calculations, with their own x,y stacks, and you have tied them together by prefixing an operation (in this example <+>) followed by "swap" (<x<>y>).
The odd thing about this algebraic feature is that it is un-documented...and there was no change in the manual between the 1st and second issues (Rom "-" and rom "a" have edition 1 and edition 2 respectively).
Further, the PDF documents that were written and are available at HP have one spot where they explicitly use the "swap" functionality of rom "-". (A contributor here wrote them--and had that ROM).
So if you have the P-R and the H.ms bug, and the algebraic behavior, and the C.nr overflow bug, and the annunciator but after reset.(asre there more--see archives of Mike's post)...then you have ROM #3 (what I call "B") (as far as we can determine) or in other words, I am inferring from the anecdotes, that there have been three roms:
"-" bugs, ALG swap between last stack entry and current command line
(ealry walmart release--essentially a "pre-release")
"A" bugs, parallel ALG stack (1st full retail release)
"B" no bugs, parallel ALG stack
It looks like the new display (and there may be more than one iteration!) happened to some of "A" as well as to "B" ROM machines
Let's see if we find more!
(visions of "red-dots" dancing in my head...)
One other thing--does anyone have a rom "A" that does *not* have a CNA (as opposed to CN) serial? In otherwords, I think that rom "A" was instituted at factory "A" and perhaps not at the other? We'll see.
Regards,
Bill
Edited: 18 Nov 2005, 4:03 p.m.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Here are my observations:
Keys Display
---------------------------
1 + 6 <enter> 7.00
<x<>y> 0.00
9 9_
x 9.00
<x<>y> 7.00
+ 63.00
<enter> no change
----------------------------
The only thing I can see is that there is a shadow register holding the result of the first addition (7.) after x<>y. This result is then retrieved by the second x<>y and used in the calculation. I can't see any "secondary AOS stack" or whatsoever.
Marcus
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hey Marcus,
You need to "play around" with the ALG more. THe example I gave you is only one very simple starting point. Try this:
1 + 6 <enter> 7.00
<x<>y> 0.00
9 9_
x 9.00
4 4_
<enter> 36.00
<x<>y> 7.00
<x<>y> 36.00
<x<>y> 7.00
+ 7.00
4 4_
<enter> 11.0
+ 11.0
<x<>y> 36.00
<enter> 47.00
+ 47.00
<x<>y> ......tell me where you take it from here!
As you can see, you can carry on parallel work indefinitely and link the work...
Regards,
Bill
Posts: 1,830
Threads: 113
Joined: Aug 2005
Yeah, as in "don't throw this one out!" LOL.
Posts: 105
Threads: 20
Joined: Aug 2011
I saw an HP33S in Walmart on Saturday that had a S/N that started with 530xxxx. The display was ALOT better. I could easily see the decimal with two "2's" next to each other from about 2 feet away. The digits looked thinner.
If I didn't already have 2, I might have bought it.
▼
Posts: 130
Threads: 36
Joined: Jan 1970
Is there a definative way to tell if I have an improved 33s? I bought mine at Walmart about July of this year. I always thought I could see the decimal point clearly, but now I'm not so sure.
Thanks, Hal
▼
Posts: 801
Threads: 36
Joined: Nov 2005
It may be helpful if some of you guys who have the ability to can post images of the pre- and post- displays.
▼
Posts: 1,153
Threads: 94
Joined: Mar 2006
I recently lost my digital camera, or I'd post some today.
I've been film-photographing some stuff for eBay sales, so I'll get comparative views of the 33s displays as well, if no one else does it sooner.
Posts: 1,830
Threads: 113
Joined: Aug 2005
I also bought a new 33S from Wal-Mart. (Fry's didn't have the new ones.) I've been staring at the display for quite a while, porting YATZ to the calculator. I know this has been brought up before, but I'm now nose-to-nose with just how limiting 26 variables and 26 labels can be. The other capabilities of this machine are quite nice, but that lack of labels, particularly, leaves most of the ample 32K unused for me. If I were using this calculator professionally, I would be extremely frustrated with this shortcoming. Since there's no way to store and retrieve programs either internally or exernally, it means that all of the ways you might want to program the calculator have to fit into the 26 label limit at the same time!
So that leaves a big gap in HP's product line where the HP-41 and HP-42 used to live. Not that there weren't significant differences between those two, but both of those machines were considered the top of the line in their days. Today they would occupy a place midway between the 33S and the 49GX in my opinion. The RPL models are at least one, and possibly two orders of magnitude more complicated to program than the keystroke models. Their power also surpasses the older platforms, but not in the same ratio, again in my opinion. I therefore feel the lack of a nice keystroke programmable machine with higher arbitrary limits in things like the number of labels.
One approach to bringing back this sort of thing would be to add a keystroke mode to the current high-end. I'm not talking about simulators of older machines, such as the fine software by Hrastprogrammer and others, but rather an updated keystroke mode that made a fair percentage of the built in power of the high-end machine available. That could be done in software by the community, I suppose, at the cost of RAM and CPU overhead in running programs. It would be far better to have it implemented natively by the calculator vendor, not only from the (presumably) better integration, but from the standardization that would bring to the new mode if it were deployed on all the machines in a given model.
▼
Posts: 1,153
Threads: 94
Joined: Mar 2006
No doubt about it, there's a limitation. Bummer.
FWIW, the 6 Stat variables are available indirectly, via i = 28 through 33.
And why they chose to make the i register available indirectly at i = 27 is beyond me! Zero would have been much better, leaving the limited available variable space uninterrupted.
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
The should have kicked out the i, introducing an IND statement to indirectly access a few KBs of memory (including A-Z) from any variable A-Z. That would allow multidimensional arrays. My TI/Casio can do this and AFAIK the 41 can do this too, correct?
Thomas
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
The 41C can do indirect addressing through any register. It's the only way to access registers above 99. Label indirection is similar, I think.
The limited programming model may have made sense in marketing terms with the 32S and 32SII. Those machines were low-to-midrange, and so either the programming model was deliberately crippled, or else the economics of RAM made it silly to allow more than that. But fast forward 15 years or so and the programming capability looks really lame compared with anything in else in the 33S'x class. This is just a consequence of outsourcing the calculator product development, and then not expecting much innovation from the O.E.M.
You know, just the capability to swap programs in and out of the name space would go a long way toward overcoming the limitation. I can probably avoid using all the labels in any given program, but not in half a dozen or so. If I could have one program, defined as a set of labels grouped by a metalabel, or dare I say it, a name, as the 'current" program, then I could be as liberal as I liked in my label usage. It would still suck to not be able to share common routines, but not half as hard as this ridiculously low ceiling does.
▼
Posts: 1,107
Threads: 159
Joined: Jan 1970
I'm not so sure about lame outsourcing.
It really probably did cost HP less to drop in the 32K chip than finding one that held only 500 bytes or so.
Perhaps if they had chosen to increase the cost a couple of $$ then they could have dropped in the 500 byte chip and all these comments about "I can't use the ram" wouldn't have come up. :-)
After all, this is essentially a 32SII that was upgraded because of component obsolesence. Nothing more probably intended.
If there are a few new things, ok, but I doubt there was much intent to re-engineer a totally different machine here.
When one understands that the old processors were going away very quickly, HP had to make choices: Make machines as similar as we can to the existing ones with new processors or drop out altogether.
They stayed in and appear to be successful, some isolated problems notwithstanding.
Perhaps, given time, they may come out with totally different machines, but keep in mind...HP calculators are MUCH smaller than they used to be in terms of personnel, so I'm glad with whatever I get.
▼
Posts: 1,153
Threads: 94
Joined: Mar 2006
I agree. On the 32/32s, memory was the overriding limitation, on what otherwise was a VERY simple, straightforward programming model.
Now, the memory limitation has effectively been eliminated. The current limitation is in program labels and variables.
If you want to get 'round those limits, you've got to go "retro" with a 32K 42s, or up to one of the graphical models.
But for a readily available, almost-cheap, shirt-pocket RPN programmable, we have a choice analogous to the old Model T's color selection: any H-P calculator, as long as it's the 33s.
Posts: 1,830
Threads: 113
Joined: Aug 2005
Quote:
It really probably did cost HP less to drop in the 32K chip than finding one that held only 500 bytes or so.
No doubt.
Quote:
Perhaps if they had chosen to increase the cost a couple of $$ then they could have dropped in the 500 byte chip and all these comments about "I can't use the ram" wouldn't have come up. :-)
No doubt. 8)
Quote:
After all, this is essentially a 32SII that was upgraded because of component obsolesence. Nothing more probably intended.
If there are a few new things, ok, but I doubt there was much intent to re-engineer a totally different machine here.
Obviously true. *whine*
That's what I meant by saying they weren't expecting innovation from their O.E.M.
Quote:
When one understands that the old processors were going away very quickly, HP had to make choices: Make machines as similar as we can to the existing ones with new processors or drop out altogether.
They stayed in and appear to be successful, some isolated problems notwithstanding.
True, as far as it goes.
Quote:
Perhaps, given time, they may come out with totally different machines, but keep in mind...HP calculators are MUCH smaller than they used to be in terms of personnel, so I'm glad with whatever I get.
Well, I'm not so complacent. For example, the 49G+, with all its warts, is an improvement on the 49G and the 48G. It's got modern I/O , a modern processor and modern storage. If I were starting out with calculators, and I picked up a recent version of that machine, I'd be pretty happy, assuming I wasn't overwhelmed with the complexity or the world's demands that I get a TI.
But if I were starting with the 33S, I'd definately be disappointed. The programming restrictions are too onerous. They make the machine practically unusable for a set of programmed tasks. The key thing there is that all programs share a single name space. So it's very difficult (I'd never say "impossible" around this place) to get a nice variety of useful programs into the darned thing. That makes the 32k sort of a cruel joke, as you alluded to.
I understand that HP lost the calculator wars to TI, and that that meant they faced a choice to either exit the market or drastically curtail their investment in it. I'm glad they chose the latter too. But I'm just not willing to give them a (rhetorical) pass on an obviously bad choice to bring their low end machine forward without addressing the, um, addressing. They did better than that for the high end machine, after all. I'm sure the MBAs crunched the numbers on that choice, but it still sucks in my book.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Quote:
The programming restrictions are too onerous. They make the machine practically unusable for a set of programmed tasks. The key thing there is that all programs share a single name space. So it's very difficult (I'd never say "impossible" around this place) to get a nice variety of useful programs into the darned thing. That makes the 32k sort of a cruel joke, as you alluded to.
Hi Howard,
I disagree. In fact, the 33s has everything that the 32sii had, and then some. It has more than the 11c. It has more capability than the 67 in terms of variable names and labels. The only pocket calculators that exceed it are the 15c and the 42s--both of which were higher in the chain. (Is the 41 a pocket calculator? Not quite as much).
There were many many extremely useful programs written for the 67, the 11c, the 32s, the 32sii.
Sure, you can't do everything that the 41 or the 42 or the 15c did, but you can do a lot.
In fact, for some things, the 33s can do more than the 15c--if it is memory or lines of code that is a stumbling block, the 33s has efffectively 7k relative to the 15c.
(The memory structure of the 33s is less efficent and so it really isn't 32k).
When you consider that the 33s has equations as well as RPN, and the ability to use equations as prompts, and real command names rather than keycodes, then you have a much easier interface for programming.
Regards,
Bill
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Since I posted this rant, I've become aware that the 33S is better regarded as a programmable than I gave it credit for. You are right about all its advantages relative to the Voyagers and the 67/97. And it does have a much nicer set of capabilities in its built in functions, which of course makes the programming that much more powerful.
I guess I'm really comparing it to the 49G+. The fact that the comparison is unfair is exactly the point! 8)
Posts: 111
Threads: 22
Joined: Jul 2007
I agree on the limitating nature of a finite number of variables. But, as a student, and knowing that 'heavy' work is frequently done with PC software, it is actually very enjoyable to address the challenges of this machine.
For example, I enjoy being able to solve polynomials and do matrix multiplication, approximate % error, and other "little" stuff that does take some time to do via longhand. And to have the answer as they are just locating the application in their GameBoys' is even more fun.
However, if HP is listening, a 42s style machine (built-in matrices, alpha-num variables, and a sophisticated menu system) would be warmly received :)
ECL
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Interesting. Thanks for that perspective.
As a hobbyist, I enjoy a programming challenge too. But it was my frustration at trying to port a non-trivial game to the 33S that occasioned my fit of pique above. But what really burned my toast was the realization that nobody would ever use the game, once I succeeded in porting it, because it would basically turn the 33S into a one trick pony. And for fifty bucks, you can get a much nicer gaming experience than that nowadays.
▼
Posts: 111
Threads: 22
Joined: Jul 2007
Howard,
If it can be written off as a pursuit in which you were confronted by a new problem, I say do it!
One of the 33s's pros to me is that I could outgrow it at some point. This may not frame my thoughts properly. Perhaps a better statement is that if I could load a C compiler and all the capabilities of such a language onto my 33s, I would likely try to write "The Complete Student-Engineer's Suite for the HP-33s" which would really derail me from my studies.
I appreciate the 33s for being somewhat limited, but to still be able to 'shirt-pocket' some very useful capabilities. All that said, I still dream of a 'lost' case of 42s' arriving at the local Fry's. Or even better, a new 33s/42s = 43s?? 34s? :) Thanks for the insights,
ECL
Posts: 111
Threads: 22
Joined: Jul 2007
Sorry to saturate the thread here, but I have noticed some elementary ways to get labels to go farther in my case. I have two programs that deal with matrices. One lets me input two rows for manipulation, and the other multiplies two matrices up to 3x3 (this one is brute force, and will be updated).
However, before operating on these rows and matrices, I have to build the matrix. Also, once done, I have to output the new values. I realized that I can have one short program do both. And then both matrix programs can call on the same 'builder/printer' routine. (sorry if this is exceedingly basic)
Routine to input and output matrix elements:
LBL A
FS? 1
INPUT (i)
FS? 2
VIEW (i)
ISG i
GTO A
RTN
So, if I am building the matrix, the main label will set flag 1 before calling on 'A', and if I am done, and want to output the results, I disable 1, and set flag 2 before calling 'A'. Hey, I think I see how I can fit this into the main label...That's another benefit to these discussions, I see how I could have been more efficient through sharing something :)
ECL
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Yeah, at least half the benefit of explaining what you are doing to other people is the fact you have to explain it to yourself first. 8)
Seriously off-topic: I think that's because when you speak, or even when you frame your thoughts to be spoken aloud, you engage parts of your cortex that aren't in gear when you are thinking to yourself. My intuition says talking aloud to yourself wouldn't have the same benefit. If that's so, then the clarifying power of telling others what you are up to is not due to the motor pathways for speech and hearing being warmed up. It would be interesting to test that experimentally, but I'd have to be working from home before I started talking to myself. 8)
Back on HP calculators. There's an article in the archive that discusses some techniques for optimizing for label usage, specifically for the 33S. It sounds like some of the items you mentioned are discussed there. But odds are you've had a thought or two that might make good additions.
▼
Posts: 111
Threads: 22
Joined: Jul 2007
Howard,
Thanks, I copy/pasted Paul's article for some fun post-study reading tonight.
ECL
Posts: 64
Threads: 10
Joined: Aug 2007
I agree with you that the ability to name a program would go a long way to increasing the programming capability. I wonder how hard it would be for Kinpo to do this, assuming HP had the desire to look into it. Most of the programs I write are relatively simple, I have minimal subroutines or branches. I have several different programs that use the same same variable but in different equations, and to keep it straight I make a user prompt in equation mode explaining what the required input is. It chews up memory, but the 33s has lots of it.
When I think of the shortcomings of the 33s, I try to remember to be thankful that at least there is still a basic RPN calculator in the market. I "grew up" on the 11c and 32sii, and felt that the higher end models had too many features that I would never use, and were probably too complicated for the day to day calcs that I usually am doing at work. Now that HP has addressed the design flaw of the 33s display, maybe they can address some of the programing limitations of the 33s. A basic RPN calculator like the 33s, but with some enhanced programming features would be totally ideal for me.
To go off on a tangent, does anyone know how successful HP ahs been with sales of the 33s?
Posts: 1,041
Threads: 15
Joined: Jan 2005
Well, to each his own, but personally, I find the RPL models much easier to program than my 12C or 16C.
What's so "complicated" about programming in UserRPL? It's mostly the Reverse Polish Notation that everyone here is so familiar with, along with a few very useful program structures, and named local and global variables. What could be simpler to use?
You can simply start the command line with the \<< UserRPL program delimiter, simply press the keys in the same order that you'd use to solve the problem in "immediate" mode, and then press ENTER to put the program on the stack. Doesn't that sound much like "keystroke programming"? Now type in your program name and press STO, and you now have a named program that you can use whenever you want, including calling it by name from another program.
Yes, you can write complicated RPL programs. For example, utilizing local variables, elaborate nested program structures, and recursive programming, but you don't have to utilize all of the power of RPL to write some very useful programs.
Even SysRPL isn't much more complicated than UserRPL, though much less forgiving of mistakes. Assembler language isn't difficult, though perhaps rather tedious to program in. For these two, keep an archive of user memory on a card, or in the case of the 49 series, in flash memory, while you're programming and testing, and it's easy enough to restore when things go south.
To be sure, there are more commands than almost anyone will ever learn to use, but complaining about that seems much like complaining about your bride being "too beautiful". If you don't know what a command is useful for, then simply don't use it.
I suppose that it largely depends on which model first hooked you on HP calculators.
Regards,
James
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
My concern with UserRPL is that I forget the keywords and syntax when away from it for some time;). But there is another issue: The missing 'break' statement strikes you especially when writing more complex programs for which keystroke programming wouldn't be suitable anymore. There are some (awkward) ways around it but would it have been much of a problem to implement it?
Thomas
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
Quote:
My concern with UserRPL is that I forget the keywords and syntax when away from it for some time;).
The keywords are the same used in the menus. Granted, the menu system in the 49 series leaves a lot to be desired, but even there the menus for program structures are straight-forward, and you can use the CAT key to see all of the commands. What is there about the syntax that's easy to forget?
Quote:
But there is another issue: The missing 'break' statement strikes you especially when writing more complex programs for which keystroke programming wouldn't be suitable anymore. There are some (awkward) ways around it but would it have been much of a problem to implement it?
Maybe you mean something like the HALT command? You can use the DBUG operation to start single-stepping through a program. Or you can start single-stepping at the first HALT command, or CONT to the next HALT command.
Regards,
James
▼
Posts: 362
Threads: 30
Joined: Jul 2005
I believe he is talking about a kind of EXIT or RTN statement that allows early exit from a subroutine. Though I rarely find the need for them when I do well structure programming. I only really need this kind of functionality when I am looking for the shortest and fastest way to do something. However, now with the speed and memory of the 49g+ it is only required for "challenges"
Arnaud
Posts: 1,089
Threads: 32
Joined: Dec 2005
I was talking about 'break' as in the C language. I'm often in need to leave a loop somewhere in the middle of the enclosed statements. This might not be the most elegant technique, but it is 'resource friendly' and a standard on several programming languages.
About the forgotten keywords, yes I can look them up but that takes some time. So basically RPL gets my job done but I'm usually faster with keystroke programming. And no, I'm not against RPL, I was just pointing out what I dislike about it. I have used it and will use it in the future, for sure.
Thomas
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
Quote:
I was talking about 'break' as in the C language.
Ok, I'm not familiar with C, which explains why I didn't recognize
your "break", and got sidetracked to "break point" instead.
Quote:
I'm often in need to leave a loop somewhere in the middle of the
enclosed statements. This might not be the most elegant technique,
but it is 'resource friendly' and a standard on several
programming languages.
Which kind of loop?
Somehow, it seems to me that using a WHILE...REPEAT...END or
DO...UNTIL...END loop would satisfy your requirements quite
nicely.
Of course, you could also nest "conditional" program structures
within the loop clauses.
Even with a FOR index...NEXT loop, it's easy enough to force an
early stop to looping simply by storing an appropriate value in
the 'index' local variable.
Offhand, the only way that occurs to me to force a START...NEXT
loop to end early is to force an error (such as 0 DOERR), which of
course ends the entire program, unless you have the loop within an
error trap.
In the case of a FOR index...STEP or START...STEP loop, one could
force an early end by substituting a different value for STEP,
sort of forcing a "giant STEP".
Okay, some of those aren't simple methods. I suppose that the
simple answer would be that it depends on what you're trying to
accomplish.
Regards,[n]James
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
Quote:
Even with a FOR index...NEXT loop, it's easy enough to force an
early stop to looping simply by storing an appropriate value in
the 'index' local variable.
Yes, but that would mean that you have to go through the rest of the current loop until the condition is queried the next time. A 'break' would leave it immediatley.
Quote:
Offhand, the only way that occurs to me to force a START...NEXT
loop to end early is to force an error (such as 0 DOERR), which of
course ends the entire program, unless you have the loop within an
error trap.
I tried that. Can't remember exactly but I think that was possible only once, while I was in need for several 'break's. Probably my fault but at that time I didn't found out how to accomplish that and haven't touched my 48G since then. I'll look at it again.
Thomas
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
Quote:
Quote:
Even with a FOR index...NEXT loop, it's easy enough to force an
early stop to looping simply by storing an appropriate value in
the 'index' local variable.
Yes, but that would mean that you have to go through the rest of
the current loop until the condition is queried the next time. A
'break' would leave it immediatley.
Well, you want the "break" only if a certain condition is (or
isn't) met, right? So you're going to be testing for that
condition. How about something like this:
1 10 @ Loop from 1 through 10.
FOR n @ Loop index is local variable 'n'.
@ Code to be executed before break test.
IF
@ Test, continue if true, break out if false.
THEN
@ Rest of code to be run in loop.
ELSE
@ Optionally record that a break was used.
10 'n' STO @ Actually, any value greater than 9
@ should work in this case.
END
NEXT @ Increments and tests loop index.
@ Optionally test whether a break was used.
You could use a CASE structure to allow for multiple break tests
within a loop, for example:
1 10 @ Loop from 1 through 10.
FOR n @ Loop index is local variable 'n'.
CASE
@ Code to to run before first break test.
@ Test for first break condition.
THEN
@ Optionally save information on reason for breaking.
10
END
@ More code to be run.
@ Test for second break condition.
THEN
@ Optionally save information on reason for breaking.
10
END
@ Etc.
@ More code to be run.
@ Test for last break condition.
THEN
@ Optionally save information on reason for breaking.
10
END
n @ Use existing loop index value if no
@ break occurred.
END
'n' STO @ Store value in loop index.
@ Additional code to be run within loop.
NEXT @ Increments and tests loop index.
@ Optionally check reason for breaking.
Of course, you could also force a FOR...NEXT loop to run
indefinitely, just by storing a value at least 1 lower than the
stop value into the index every time.
Quote:
Quote:
Offhand, the only way that occurs to me to force a START...NEXT
loop to end early is to force an error (such as 0 DOERR), which of
course ends the entire program, unless you have the loop within an
error trap.
I tried that. Can't remember exactly but I think that was possible
only once, while I was in need for several 'break's. Probably my
fault but at that time I didn't found out how to accomplish that
and haven't touched my 48G since then. I'll look at it again.
The START loops are problematic to break out of early. The START
loops are basically simplified FOR loops, for use where the user
doesn't need access to the index. They don't test for whether to
loop again, like WHILE and DO loops. Like NEXT loops, they do use
a local variable for the index, but START's index local variable
is nullnamed, and thus inaccessible from "pure UserRPL". I suppose
that one could access it with SYSEVAL, but why bother when FOR
loops are available?
Maybe something like the following, but note that pressing CANCEL
just once may just cause breaking out of the loop, with a second
press required to abandon the program:
\<< @ Begin program.
RCLF \-> f @ Save current flags.
\<< @ Begin local environment defining procedure.
-55 CF @ Force Save last args for consistent error handling.
@ Code to be run before loop.
IFERR @ Start error trap.
1 10 @ Loop from 1 through 10.
START @ Loop index is not accessible by user.
CASE
@ Code to be executed before test for first break.
@ Test for first break condition, break if true.
THEN
@ Optionally save information on reason for breaking.
0 DOERR
END
@ More code to be executed.
@ Test for second break condition.
THEN
@ Optionally save information on reason for breaking.
0 DOERR
END
@ etc.
@ More code to be executed.
@ Test for last break condition.
THEN
@ Optionally save information on reason for breaking.
0 DOERR
END
@ More code to be executed if no breaks occurred.
END
NEXT @ Increments and tests hidden loop index.
THEN @ Start error clause.
IF
0 ERRN \=/ @ Was the error unexpected?
THEN
@ Optionally any additional error testing and cleanup.
f STOF @ Restore original flags.
ERRN DOERR @ Execute the error, abandoning program.
ELSE
@ Optionally any additional code based on reason for breaking.
END
END @ End error clause.
@ Code to be executed after loop.
f STOF @ Restore original flags.
\>> @ Abandon local environment.
\>> @ End program.
But it's easier to just use a FOR loop and use the index local
variable to break out, otherwise ignoring it if you have no other
use for it. I suppose the main value of this START...NEXT example
is to show that "there's more than one way to skin a cat", and
some ways are better than others.
Of course, if you want the loop to execute until some condition is
met, with a single test for breaking, then very simply use
something like:
WHILE
@ Code to be executed before break.
@ Test for break condition, false to break, true to continue.
REPEAT
@ Code to run if not breaking.
END
Although only the FOR loops have a user-accessible built-in loop
index, it's easy enough to add your own loop index to any loop
using your own local variable and INCR (or DECR), or for that
matter, doing any operation to modify the index value and storing
the new value back into the local variable.
For example:
\<<
0 \-> n @ Initialize loop index.
\<<
DO
@ Code to be looped through.
'n' INCR DROP @ Increment loop index value.
UNTIL
@ Test whether to loop again, optionally using the value of n.
END
@ The loop index value is still in n, even after the loop has
@ ended.
\>>
@ Now the loop index has been abandoned.
\>>
Or, for the following, the index is 2 to the power of the loop count.
\<<
1 \-> n @ Initialize loop index.
\<<
DO
@ Code to be looped through.
n 2 * 'n' STO @ Modify loop index value.
UNTIL
@ Test whether to loop again, optionally using the value of n.
END
@ The loop index value is still in n, even after the loop has
@ ended.
\>>
@ now the loop index has been abandoned.
\>>
Note that in a DO...UNTIL...END structure, the UNTIL can actually
be anywhere between the DO and the END, as long as it doesn't
occur within a nested program structure. The END uses the T/F
(zero/non-zero) stack flag, and the DO tells it where to "loop
back" to. The UNTIL usually divides the loop into a "loop clause"
and a "test clause", but that's only for reasons of program
legibility.
But the above doesn't hold for a WHILE...REPEAT...END structure.
In this case, REPEAT uses the T/F flag, END tells it where the
"loop clause" ends, and WHILE tells it where to "loop back" to for
the next "test clause".
A DO loop is always executed at least once, but with a WHILE loop,
the "loop clause" may not be executed at all.
Finally, note that what you're trying to do may well be easier in
SysRPL.
Regards,
James
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
Yes, it is certainly possible to get the job done without 'break' and it might look even better. But compare your first solution
Quote:
1 10 @ Loop from 1 through 10.
FOR n @ Loop index is local variable 'n'.
@ Code to be executed before break test.
IF
@ Test, continue if true, break out if false.
THEN
@ Rest of code to be run in loop.
ELSE
@ Optionally record that a break was used.
10 'n' STO @ Actually, any value greater than 9
@ should work in this case.
END
NEXT @ Increments and tests loop index.
with this one:
1 10
FOR n
@ Code to be executed before break test.
IF
@ Condition for a break is met
THEN
@ Optionally record that a break was used.
BREAK
END
@ Remaining code
NEXT @ Increments and tests loop index.
It's slightly shorter (I inserted 'Remaining code' to make clear why 'break' is of advantage here) so you can probably see why I really would appreciate the inclusion of a BREAK keyword.
Thomas
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
Quote:
It's slightly shorter (I inserted 'Remaining code' to make clear
why 'break' is of advantage here) so you can probably see why I
really would appreciate the inclusion of a BREAK keyword.
Oh, I can easily see where your BREAK would be useful, at least in
some cases, but it's just not available. I don't see any pressing
need for it though. I don't suppose that it would be all that
difficult to develop, and the 49g+ does have upgradeable firmware.
Maybe ask on the comp.sys.hp48 newsgroup; I know that at least one
HP employee occasionally posts there. Other than that, someone who
programs a lot in SysRPL might be willing to develop it as a
add-in.
In the case that there's only one place that you might want to
BREAK, and you want an indefinite loop, the WHILE loop seems to me
to be suitable.
Regards,
James
Edited: 13 Nov 2005, 8:44 a.m.
Posts: 135
Threads: 11
Joined: Jan 1970
RPL beats RPN hands down with programming. For me, writing a User RPL program on an HP48/49 to do darn near anything is almost second nature now.
Indeed, I'm a bit amazed at how people can become excited over an ordinary scientific calculator, as they are in this thread. It's a free country, to each his own...
Edited: 9 Nov 2005, 7:43 a.m.
Posts: 1,830
Threads: 113
Joined: Aug 2005
Well, this is a can of worms, of course. It reminds me of the editor wars between emacs and vi, in fact. People take positions in that conflict and assume that anyone with a different stance is an idiot. Communication between the camps is replete with disclaimers like "to each hos own" and "YMMV" but those are usually preambles to blistering rhetorical attacks on the other side. Not that anyone has reached that level in this particular thread, but it's a danger.
When I look at the relative merits of emacs and vi I see that each editor is useful in different contexts. I spent the earliest 10 years of my career as a systems administrator, so I had to learn both in order to support my users. Though I started out an emacs partisan, I now use both editors in different situations, as I have for the latter 10 years of my career.
I have yet to write a non-trivial program in RPL, so I'm not as qualified to address the differences between it and RPN as I perhaps am the differences in Unix editors. But I'm in the process of tooling up for the exercise of porting YATZ to the HP48G*, and I've been spending lots of time on my 48 machines, learning what I will need for that application, principally the graphics subsystem.
I'm feeling more comfortable on the calculator, but I must say that it has taken me a lot longer to start getting up to speed on the 48/49/49G+. than it has for any other machine in my collection. In fact, it has taken an effort comparable to learning a new operating environment like Python, say, if you are used to Perl, or Java if you know C. This isn't just an RPL issue, but also stems from the very large command set. Yes, that is a nice thing to have, but it also, by definition, increases the complexity of the machine. I think partisans of RPL, all of whom presumably have gotten over the steep learning curve of the calculators that implement it, tend to downplay the complexity. This is natural, but it misses an important feature of these machines.
That complexity, in my opinion, contributed to the triumph of TI in the education market. The average teacher didn't have time or interest to learn the rudiments of RPL, when compared to the familar, BASIC-like TI programming model. I know it sucks. That's not the point. It's simpler. HP must have gotten feedback that RPL was a problem in the marketplace, because they added some TI BASIC like syntax. Of course, nobody uses them in the RPL world because they suck. But that's the opinion of self-selected RPL lovers!
I also don't want to start another HP vs TI flame war. I like HP. TI is devil-spawn. The better calculators lost the calculator wars, a situation not unlike the triumph of Windows over technically superior rivals. I also don't mean to suggest that complexity was the only determinate in that war. I do think that it was an important one, however.
But I'm a hobbyist, so I'm willing to take the time (sandwiched in between fits of work designing grid systems) to learn RPL. I must say, it kind of grows on you. The manuals are essential, basic and advanced, since the help systems are a joke. This is somewhat improved on the 49G+. but a basic problem remains: limited screen real estate. Complicated functions require lengthy explanations, and there just isn't room on even a 49G+'s expanded display. There's also an issue of covering your work while you read the instructions. Having the text side-by-side with the work in progress is the only way to go.
In the meantime, I can crank out 41C code at a high rate. I picked up the 33C in about half an hour. This was not only a function of my familiarity with keystroke programming, but of the fact that there are fewer functions to choose on the 33S. They almost all fit on the keyboard, in fact, with two shift keys and the addition of a few logically laid out menus. Simplicity counts when it comes to learning a new system.
Of course, another consequence of the simplicity of the 33S is less functionality. You can truly do a boatload of interesting stuff on the 48G. I have Hrastprogrammer's 71X simulator loaded in my 48GX, and it rocks. I have his earlier 41E on my 48G+ and it's cool too. There is no question that I will be able to implement YATZ on the 48. That program is non-trivial in BASIC or keystroke models, but I expect it will be a quick knock-off on the 48, once I learn enough about the darn thing. (I know there's a Yahtzee clone already available for the 48. Delivering something unique is not the point of my exercise.) I'm probably going to revisit YATZ on the 33S sometime, but it is shelved for now.
So I have an enthusiast's interest in the RPL models. But I still find the keystroke models easier to understand and to program. I believe that's not entirely due to my familiarity with the 41C. I took up 41C after a nearly 20 year hiatus this Spring, after all. I do think that RPL is, by golly, more complicated and difficult to learn. But my hobby is learning about complicated old (or new) systems, so this appeals to me. I also think that the model of keystroke programming hasn't been upddated in those same 20 years. That's a shame. The last 20 years have brought multiple revolutions in software engineering that a keystroke model coould benefit from.
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
The war between different systems (or their users) will never stop. I once tried to point out just a few shortcomings of Windows to one over-enthusiastic user and was immediatley labeld a luddite and later accused for not being able to manage my system. I'm at an age where I can laugh at this and leave a discussion without further insiting on my point but a few years earlier the result would have been one of these endless flame wars. The good thing about HP calc users is that they apparently almost always have a working brain between their ears, capable of early stopping a pointless discussion a la 'mine is longer than yours'. A rare species indeed.
Thomas
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
The old Usenet adage was to try to "shed more light than heat." I agree that's often a lost cause, and also that it may not be around here.
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi Howard,
Very good post and good points.
The key "issue" if there is one appears to be the "learning curve". Essentially, learning RPL is like learning PASCAL or C or some high level language. RPN keystroke is low-level machine code.
The machine code is mostly keystroke stuff, with the addition of some "indirection" and some boolean statements and flags. If you already know these tools, its easy.
What I cannot answer is whether the machine code approach is easier if you haven't been there already. Since I was an RPN programmer at age 14, I cannot answer that.
Of course it also seems to me that the dividends on learning a language such as RPL are greater than learning a machine code such as RPL keystroke.
I think what we get to is, that structured high-level programming can "do more" but takes more initial learning.
What is readily apparent to me is that the keystoke approach is frightful to de-bug if it is large and complex with many subroutines and conditionals between subroutines. Once it gets to be really big in either size or complexity, it is a bear and a nightmare, which is why HP made all those great "pacs" starting with the 55! That way an end-user could get a program on board and running without having to become a machine language expert. I don't think the HP RPN programming would have been the success it was without that.
With the RPL approach, you still have the opportunity to provide "pacs" but you also open up the possibility of meaningful structured programming by an end-user who has "structured high level programming" skills.
Just a thought.
I am personally not proficient with RPL and have not climbed the curve--mostly because I'd rather do other things, and I feel like if I am going to do structured hi-level stuff, I might as well use a language that I already know, i.e. PASCAL.
So that is that.
Edited: 9 Nov 2005, 12:27 p.m.
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Hi, Bill,
Thanks for your thoughtful reply.
Quote:
The key "issue" if there is one appears to be the "learning curve". Essentially, learning RPL is like learning PASCAL or C or some high level language. RPN keystroke is low-level machine code.
I'd generally agree, if we are talking about assembly rather than machine language. But I think the keystroke stuff is just a bit higher level than assembly. Perhaps assembly coding with a very rich library of canned routines would be closer.
Quote:
What I cannot answer is whether the machine code approach is easier if you haven't been there already. Since I was an RPN programmer at age 14, I cannot answer that.
I can't answer that either, since I learned HP-41C programming before assembler. 6502 and PDP-11 were my first assembly languages. Both were understandable to me immediately, whereas my peers seemed to have trouble. I attribute that to knowing the HP-41, so your general point is well taken.
Quote:
What is readily apparent to me is that the keystoke approach is frightful to de-bug if it is large and complex with many subroutines and conditionals between subroutines. Once it gets to be really big in either size or complexity, it is a bear and a nightmare, which is why HP made all those great "pacs" starting with the 55! That way an end-user could get a program on board and running without having to become a machine language expert. I don't think the HP RPN programming would have been the success it was without that.
Good points, and ones that keystroke proponents often overlook in their turn.
Quote:
With the RPL approach, you still have the opportunity to provide "pacs" but you also open up the possibility of meaningful structured programming by an end-user who has "structured high level programming" skills.
I think it's more than that. I've got a background as a polyglot programmer. My experience in computer languages that I actually did work in, in the order encountered, is HP41, Apple BASIC, 6502 Assembly, VAX BASIC, Pascal and FORTRAN, PDP-11 Assembly on the VAX (in emulation mode), Micro$oft BASIC, HP BASIC 2.0, HP Pascal 2.1, REXX on Amiga, Amiga BASIC (original and MBASIC) C on Amiga, BSD and VMS, DCL, FORTRAN, Pascal and C on VMS, BSD and Ultrix grep/awk/sed/sh, Ultrix Perl 3 and Perl 4, csh on SunOS and Ultrix, SunOS C, gcc on Ultrix and SunOS, Perl 5 on a plethora of platforms, Java on Solaris and Windows, Python on Linux, Javascript all over, PHP, ASP on Windows, C++ on Linux, XSL, SOAP, JSP and other things now being called part of "web services." That's what I remember off the top of my head, I've left many systems out that I came to know but didn't actually use. I'm probably missing one or two.
I'm not presenting that list to ring my own bell, (well, maybe a little,) but to show that I have the background to be able to acquire new computer systems and languages. I also think I'm in a good position to judge complexity in computer systems. I think RPL itself is somewhat complicated, but probably no more than necessary to acheive generality. But combine it with what would be called its standard library set in a big system context, and you have a whoppingly complicated system. That's OK too. You also get functionality for that complexity. I know some would question the utility of that much power in a calculator, but I'm not one of them. I like having it there, even if I'm not using it, yet.
Quote:
So that is that.
Thanks again for the response!
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Thanks for correcting me on that.
I am not a programmer and so while I see now exactly what was inaccurate in my statements, I did not see at the time.
Indeed, when I see actual "machine code" it is gobbledeydgueck. But Assembly language appears to be a human-interpretable item----yes nore like RPN.
I like your description--"assembly with a rich very subroutine library"
And yes, there is something daunting about 48gx & RPL and part of the reason I replied is that I still can't quite put my finger on it...it should be easier than it is, or something----it's all so logical, so then why can't I adapt faster? Is it really merely that there is so much there, or is there a difficulty doing the simple stuff without already understanding the complicated stuff, too? In other words I am looking at the structure of the RPL language from an epistemological standpoint---that it is not modular enough if you see what I mean.
Interestingly the manuals show you three ways to do things--including a stack-based semi RPN keystroke approach--and then say that you really aught to try using the structured approach...but I never really "get there" and get frustrated with syntax and it all comes crumbling down and so I go pick up my fiddle or guitar instead...
OT my cousin used to live in Burlingame. And Sunnyvale, not far from you, has got to be the HAM radio capital of the world (sorry, Dayton, O.!)
Edited: 9 Nov 2005, 2:44 p.m.
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Quote:
I am not a programmer and so while I see now exactly what was inaccurate in my statements, I did not see at the time.
It's a common mistake. Strictly speaking, machine language is the binary numbers the machine processes when it runs a program. Assembly, as you note, is the human readable souce code that is closest to machine language of any source system. There is usually a one-for-one correspondence between the mnemonic label, "STO," say, and the binary opcode that it generates in machine language. So the distinction is subtle, but important.
Quote:
And yes, there is something daunting about 48gx & RPL and part of the reason I replied is that I still can't quite put my finger on it...it should be easier than it is, or something----it's all so logical, so then why can't I adapt faster? Is it really merely that there is so much there, or is there a difficulty doing the simple stuff without already understanding the complicated stuff, too? In other words I am looking at the structure of the RPL language from an epistemological standpoint---that it is not modular enough if you see what I mean.
Interestingly the manuals show you three ways to do things--including a stack-based semi RPN keystroke approach--and then say that you really aught to try using the structured approach...but I never really "get there" and get frustrated with syntax and it all comes crumbling down and so I go pick up my fiddle or guitar instead...
I think it's both things. First, there really is too much detail that needs to be mastered before you can do something useful. Second, there are too many ways to do the same thing. Since there is so much detail, texts that try to teach you RPL tend to start in different places, and be pretty imposing. It's not unlike how mathematics texts differ among themselves. The second feature, the diversity of programming models and constructs, adds to the confusion by letting different authors write code that acts similarly or identically, but looks completely different. (C.F, the lame TI "BASIC" like statements.)
I have mastered another rich language in which There Is More Than One Way To Do It. The capitalization should clue those in the know that I am talking about Perl. Perl is an enormous language with a huge diversity of ways to accomplish things. The difference is that you can bootstrap into the language with very little effort. Tis is in line with another Perl dictum: to make hard things easy and impossible things possible. What do you suppose the following code does?
#!/usr/bin/perl
use strict;
my $pattern="^h.*";
while (<>){
if /$pattern/ then print;
}
This searches the input for lines beginning with "h" and prints them. I think it's crystal clear from the code what it does, but I'm really not in a position to tell. What do you think?
The other advantage Perl has going for it is that its creator is a linguist. Larry Wall has attempted to design a computer langage that is conversational in style. But because people have widly varying conversational styles, even when they speak the same language, making Perl "conversational" means different things to different people. So Larry just put all the idioms in there that made sense to him. It really can lead to some horrible looking code that is hard to debug. On the other hand, it is possible to be quite elegant with all that lexical flexibility. The point of that is, it's possible to find a path through the totality of Perl syntax that approximates the way you look at the world. That has got to make learning easier, hasn't it? It did for me.
Quote:
OT my cousin used to live in Burlingame. And Sunnyvale, not far from you, has got to be the HAM radio capital of the world (sorry, Dayton, O.!)
I actually live in San Mateo, just across the line from Burlingame. My mailing address is in Burlingame, however.
Posts: 1,792
Threads: 62
Joined: Jan 2005
Kudos to Howard Owen and Bill Platt (in proper titlecase) for their discussion of learning RPL. I would echo practically everything they stated, based on my similar experiences.
I coveted the 41C and experimented with it at stores in 1980-81 as a 17-year-old, but just couldn't afford it. I bought a 15C in late 1983 after taking a liking to the 34C. I got into collecting in 2002 with a 41CV and a 34C, followed initially by the 42S as well as RPL models, including the 28C, 48G, and 49G.
Like Eric, I readily picked up the 41C right where I'd left off 21 years prior. It's only a bit more complicated than the 15C I'd used through three science and engineering programs, in conjunction with experience in Fortran, C, and similar data-oriented high-level languages.
However, I see little about RPL that is intuitive or practical for myself or for most users. RPL has been discussed quite thoroughly in the last two years by different contributors in at least a few threads, including several that I started:
RPL is like a Leisure Suit
RPL Programming challenge: Area between two curves
RPN vs. RPL discussions
(The last one includes quite a bit of articulate input from Valentin Albillo.)
-- KS
Edited: 10 Nov 2005, 12:44 a.m.
▼
Posts: 896
Threads: 183
Joined: Jul 2005
This has personally been on my mind for a couple of months now: The old RPL vs. RPN problem. I have been trying to decide between my 48GX and my 41CX. Which should be my primary calc?
I used to program the 41 back in the 80's. Then a long period of no calc-programming. Then a couple of years back I picked up the 41 again. However, for more than 6 months I have now been eagerly programming the 48 in UserRPL.
I am now moving back to the 41 and it looks like the 41CX will be my primary calc.
The reason is this: The 41 is for me a better programming environment. It makes it faster to solve simple problems. It's got a superior debug environment.
RPL seems to be cross between RPN and Forth with some grains of Lisp. Had it only been pure Forth, I would probably have settled on the 48. I love Forth. RPL is somewhat cumbersome. RPN is very straight foreward.
▼
Posts: 8
Threads: 2
Joined: Jan 1970
My invaluable 41CX (Math1 & Advantage) helped get my BS and MA degrees a decade past. While writing a function for finding sinh and cosh the machine locked up; it's still sick.
I had thought that its potential replacement was the 49GX2 for all the trig and matrix operations needed. Are the keyboard algebraic operations different too? It seems they are. Right? Learning a new keyboard layout was enough of a change. Graphing? My laptop has Mathcad. Time to find a spare 41CX here or on E-Bay.
Posts: 56
Threads: 2
Joined: Jan 2005
I have to support both parts here.
Me too am an "old school RPN programmer" and I begun the RPL approach 2004 with a first 48SX (now up to 48GX).
After many approaches to the RPL programming paradigma I still have to say that I am an RPL novice! Not so with RPN, the 41serie in mind.
Well, I have to admit that my higly active PPC years are back in the last century. Maybe I lost some drive to start over again and learn the new RPL approach with all stripes and bells... Maybe other elder mates here have the same problem? ;-)
The 1st step up the RPL stair was understanding that RPL is not well suited for easy going LBL...DSE loops. I begun to look at it like another professional programming language where program entry is only the final step after a well done analysis of the problem and maybe also some structured diagrams for the programming task. And all of this is done on a computer environment with good ASCII programming tools (like ultraedit et al.).
And every few lines there is an explanation block (@...) for later upgrades to the software.
But I still don't have a 49G+ because...
...I'm still waiting for a "RPN pac" for this machine. Not for programming, bevare, but for easy keystroke ad hoc calculating.
With this point of few I finally found my peace regarding the RPN vs. RPL thing. The 32SII or 15C are my favorite RPN everyday calcs. And the 48series are for the serious big RPL programming. And the 41series? Today I like to port a 48/49 RPL solution to a 41 in RPN; but - I suppose you know it already:
RPL is programming, sophisticated, complicated and reliable
but RPN is real fun!
Valentino
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Valentino Ducati and Ed Look have compared programming in RPN to RPL and Fortran. I generally concur with their assessments, and have similar experience.
RPN-based programming does not utilize a true "language". An RPN-based (or even an AOS-based, as on the HP-20S) keystroke program is essentially a recorded sequence of instructions -- the exact same ones that one would execute interactively, with some extensions to provide structure and control.
These extensions are quite analagous to those in Fortran -- the original high-level number-crunching language, predominant when computers were actually used for computing:
- Numerical ("internal") labels are like statement labels.
- Alphanumeric ("external") labels are like ENTRY and SUBROUTINE.
- GTO and GSB/XEQ are like GOTO and CALL.
- Flags are like logical variables.
- All conditional tests ending with "?" (FS?; x=0?) are like IF.
- DSE/ISG/DSZ/ISZ help automate looping (DO-loop)
- RTN and END are like their Fortran namesakes RETURN and END.
NOTE: There is a distinction between internal and external labels -- as well as the END instruction that partions a block of programming -- only on the HP-41C* and HP-42S. On all other programmable RPN and AOS calc's by HP, all labels are external.
Any keystroke program is akin to assembly code in that there is only one instruction per line. However, there are no procedural requirements (e.g., declaration of variables), structural rules, or syntactical jargon to obey.
This is certainly not the case with RPL ("Reverse Polish LISP"), which seems to be an un-nautral melding of Object-Oriented Programming (OOP) with the spirit of RPN calculating methods. Language constructs are present (e.g., IF/THEN/ELSE, FOR/NEXT), but they are not intuitively arranged, as they are in Fortran, C, or BASIC.
I fail to see how anyone could possibly consider an RPN keystroke program "complicated", unless it implements a lengthy and highly branched-and-looped process, possibly using many variables. In such cases, a user program on a calculator is probably not the best platform for the application, anyway.
------------------------------------------------------------
Here's a fairly concise chronology of my training in programming tools:
1980-81: Discovered HP-41C; experimented with programming at store counter. Did not experience any confusion.
1982: Passed collegiate course in Fortran '77. Did not experience any confusion. Started work several years later, maintaining Fortran programs on mainframes.
1983: Bought HP-15C and wrote working programs as necessary -- including one to find the value represented by a 36-bit octal floating-point word.
1992: Introduced to Matlab; found it similar to Fortran, but more expedient.
1993: Introduced to MS Visual Basic and wrote successful programs.
1995: Passed collegiate course in C language. Wrote my own recursive program.
1996: Introduced to LISP and CLIPS object-oriented languages. Experienced much confusion.
2002: Bought HP-41CV and successfully entered and modified programs that performed properly.
2003: Bought HP-48G. Saw and entered RPL programs and went, "What the h--- ?" Successfully entered and ran trivial one-line programs, but that's all.
-----------------------------------------------------------------
Maybe the real determining factor isn't what one happened to learn first. Maybe it's more how one thinks, and organizes computational tasks. I've had little difficulty with data-oriented languages like Fortran, C, BASIC, and Matlab. However, I find little that is intuitive about the way certain object-oriented languages work, or RPL.
-- KS
Edited: 12 Nov 2005, 4:47 a.m.
▼
Posts: 801
Threads: 36
Joined: Nov 2005
You are right on target about the 20S as it too, can be keystroke programmed. And it would be as easy as programming a Spice programmable (all RPN) or a RPN Pioneer programmable.
But I just want to quibble with you in that it really is a language, and while not as fundamental as assembler, it sort of speaks directly to the chip by encoding the keys as commands visible in the LED or LCD display while in its programming space. Obviously, though, it is not a true high level language like FORTH or LISP or FORTRAN (or even BASIC).
And, what you pressed into the program memory is a true program, no matter what!
Posts: 1,041
Threads: 15
Joined: Jan 2005
Quote:
I fail to see how anyone could possibly consider an RPN keystroke
program "complicated", unless it implements a lengthy and highly
branched-and-looped process, possibly using many variables. In
such cases, a user program on a calculator is probably not the
best platform for the application, anyway.
Okay, maybe "complicated" isn't the correct word. How about the
phrase "hard to program"? They're pretty darn nice when used as
non-programmable models, but as for programming them....
My first experience with trying to program my 16C went something
like this. It doesn't have any I/O, so I don't have the option of
writing the program on the PC and simply transferring it to the
calculator. Oh well, it's not going to be a very complicated
program anyway. I try to program something, and what do I see in
the display? A line number, and in most cases, a keycode, but the
number or letter where applicable. Oh yeah, these things can
display only numbers and a few (sort of) letters. It would've been
hard to write on the PC anyway. Oh well, it's sort of like using
the keycodes in the 48, except that the shift keys are separate
codes instead of planes; I can deal with this, even though it is a
nuisance to have to keep track of the row and column to see what
I've keyed in. Hmm, no program structures, but it does have GTO,
GSB, and RTN, and a few tests, much like assembler or BASIC, so I
can implement all of the conditional branching and indefinite
loops as easy as pie. Now where was I (imagine, a programmable
that displays only one line at a time, but come to think of it, it
was designed well before my Sharp was). Maybe I should've written
the program out on paper, with line numbers, no less; now that
brings back some memories. Hey good, I can even use the "Index
register" to implement definite loops, but DSZ and ISZ skip only
only at zero, so it's not as nice as a FOR loop. Now let's see, a
bunch of these "RPN" commands actually use prefix notation instead
of postfix notation; what were they thinking? I'm supposed to
memorize which ones work right and which one are bassackwards?
Okay, I've finally gotten it entered; now I'll try it out. Doesn't
work; better have a look at what I keyed in wrong. Blasted
keycodes again, so I'll translate them and write them out on
paper. Edit a few mistakes and try again; still doesn't work. Look
over the code; that should work. Double-check that that's really
what I keyed in. Hey, how can it fail? Single-step through it;
hmm, something very strange is going on, but it's hard to put my
finger on just what the problem could be. Run through it a few
more times. Looks as if the object that I know I put on the stack
just plain changed to something else; what the hell? Single-step
through it again; sure enough, the object has been changed; how
could that happen? Maybe a hardware problem? Oh! These damned
things can handle only 4 stack levels, and when my object gets to
level 5, it just goes in the bit bucket, without even erroring out
or giving me any warning at all. Stranger yet, when I take an
object off of the stack, so level 5 (if the damned thing had a
level 5) should drop down to level 4, the object that was in level
4 stays there, as well as dropping down to level 3. Hmm, the
manual says it's a feature; somehow, I've a hunch that that
feature started out as a bug that someone found a use for. Okay, I
suppose that it could be useful, now that I know about the !@#$%
calculator doing such a &%$^ counterintuitive thing.
The 12C is even worse for programming. Edit a program that I've
keyed in? Easy enough if I want to change a line. But inserting a
line? Sure, as long as I want to key in every damned thing from
that line down all over again. Oh, I can add a line just by
overwriting a perfectly good line with a GTO to branch past the
end of the program, add my lines there, and GTO back to what
should be the next line. Now that makes for some nice,
straight-forward code. Why not a GSB and RTN instead of a two
GTOs? Oh, you have to be kidding me, it just doesn't have them.
Sure, I can get along without them as long as I still have GTO,
but they were handy. What about deleting a line? The fine manual
doesn't seem to mention this, but I suppose that overwriting it
with a GTO the next line is about the best I can expect from this
one. And where's DSZ and ISZ? I guess that if I want a definite
loop, I have to set up my own loop index and test.
Hey, I could probably write a BASIC program for my Sharp with not
too much more difficulty than writing a program for one of these
things.
And many RPN users seem to have some sort of problems with RPL
models? Hard to understand; I'd have thought that anyone who could
learn to like the RPN models would find the RPL models amazingly
easy, but apparently not.
Okay, I can program them, but this "True RPN" stuff that so many
rave about sure doesn't seem to make things easy for me. And it
looks as if only a few programs could fit into memory at any one
time anyway, and there's no way to transfer anything into the
calculator except for keying it in. I'm going to write a program
for one of these only to have to purge it to make room for another
program, and then key it back in the next time that I want it? Not
likely!
These two are great as non-programmable calculators for the
special purposes that they were designed for, once I more or less
got used to some of their quirks, and maybe even to hold a very
few very carefully written programs more or less permanently.
But switch from the RPL models to any "True RPN" model for my
regular programmable scientific? I just can't see that ever
happening.
Of course, now I've been told that these two models are poor
examples for programming in "True RPN", but my experience with
them have put me off the whole idea of using anything but RPL
(well, assembler for time critical things such as I/O) for
programming calculators. When something works so well, why switch?
Now, if they came out with a low-cost shirt-pocket sized RPN
model, even if not "scientific", I'd sure like to have that, even
if programming it was too much of a hassle to bother with.
Regards,
James
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Wow, this is great! You've really given me a clear sense of what it's like to approach RPN programming from the standpoint of RPL. It's hard to argue with your perceptions. But I do think that many of them boil down to not liking the limitations of the older machines (category "A"), and the rest are direct mirrors of the difficulty of going the other way (category "B".) Both are perfectly understandable.
Quote:
My first experience with trying to program my 16C went something
like this. It doesn't have any I/O, so I don't have the option of
writing the program on the PC and simply transferring it to the
calculator. Oh well, it's not going to be a very complicated
program anyway. I try to program something, and what do I see in
the display? A line number, and in most cases, a keycode, but the
number or letter where applicable. Oh yeah, these things can
display only numbers and a few (sort of) letters. It would've been
hard to write on the PC anyway. Oh well, it's sort of like using
the keycodes in the 48, except that the shift keys are separate
codes instead of planes; I can deal with this, even though it is a
nuisance to have to keep track of the row and column to see what
I've keyed in. ..
Category A. The Voyager models were middle tier machines in their day. They incorporated a programming model very similar to the previous generation's high end machines, the HP 67/97. They both showed numeric key codes in program mode. But the HP-97 had a built in printer that would print an alohanumeric version of the program. That made the 97 better for software development. None of the voyager series had this capability, of course. The high end of the time was occupied by the 41C, 71B and later the 42S. The 71B was programmable in BASIC, of course. The other two had alphanumeric capability that made listing programs much nicer. And of course the 41C and 71B both had very nice I/O capability, with standard (for the day) paths to and from a PC.
Quote:
.. Hmm, no program structures, but it does have GTO,
GSB, and RTN, and a few tests, much like assembler or BASIC, so I
can implement all of the conditional branching and indefinite
loops as easy as pie. Now where was I (imagine, a programmable
that displays only one line at a time, but come to think of it, it
was designed well before my Sharp was). Maybe I should've written
the program out on paper, with line numbers, no less; now that
brings back some memories. Hey good, I can even use the "Index
register" to implement definite loops, but DSZ and ISZ skip only
only at zero, so it's not as nice as a FOR loop. Now let's see, a
bunch of these "RPN" commands actually use prefix notation instead
of postfix notation; what were they thinking? I'm supposed to
memorize which ones work right and which one are bassackwards? ..
One from column "A" and two from column "B".
"Much like assembler or BASIC" indeed! I'd say BASIC is easier, actually. But this is the model many of us were first introduced to, so it seems natural to us. For example, when we look at RPL, we see everything being postfix as a jarring change, not the other way around. If you learn a thing one way, however illogical it is intrinsically, you are bound to see it as the "normal" or "sensible" alternative. (Just consider English for instance. I'll bet many of our non-native English speakers could give many, many examples of how illogical it is as a language.)
Quote:
.. Okay, I've finally gotten it entered; now I'll try it out. Doesn't
work; better have a look at what I keyed in wrong. Blasted
keycodes again, so I'll translate them and write them out on
paper. Edit a few mistakes and try again; still doesn't work. Look
over the code; that should work. Double-check that that's really
what I keyed in. Hey, how can it fail? Single-step through it;
hmm, something very strange is going on, but it's hard to put my
finger on just what the problem could be. Run through it a few
more times. Looks as if the object that I know I put on the stack
just plain changed to something else; what the hell? Single-step
through it again; sure enough, the object has been changed; how
could that happen? Maybe a hardware problem? Oh! These damned
things can handle only 4 stack levels, and when my object gets to
level 5, it just goes in the bit bucket, without even erroring out
or giving me any warning at all. Stranger yet, when I take an
object off of the stack, so level 5 (if the damned thing had a
level 5) should drop down to level 4, the object that was in level
4 stays there, as well as dropping down to level 3. Hmm, the
manual says it's a feature; somehow, I've a hunch that that
feature started out as a bug that someone found a use for. Okay, I
suppose that it could be useful, now that I know about the !@#$%
calculator doing such a &%$^ counterintuitive thing.
One from column "A" and two from column "B". I can't speak to why the T register acts the way it does on the RPN models. I can say that it seems natural and normal to me. I occasionally make use of it in the way it's explained in just about every manual for an RPN model I've ever read: a way to store a constant without using a register. That's actually pretty rarely needed, it's true. So I concede the feature is archaic (column A) and "normal" for RPN users (column B). The other column B item is the fact that the unlimited stack of the 28C onward confuses many of us old RPN jockeys. I've articulated what I think is wrong with it elsewhere in this thread. We have been used to using registers (variables by any other name) instead of holding too many intermediate results on the stack. This is especially true if you started on the 41C like I did. That machine has plenty of registers on the CV and CX models.
Quote:
The 12C is even worse for programming. Edit a program that I've
keyed in? Easy enough if I want to change a line. But inserting a
line? Sure, as long as I want to key in every damned thing from
that line down all over again. Oh, I can add a line just by
overwriting a perfectly good line with a GTO to branch past the
end of the program, add my lines there, and GTO back to what
should be the next line. Now that makes for some nice,
straight-forward code. Why not a GSB and RTN instead of a two
GTOs? Oh, you have to be kidding me, it just doesn't have them.
Sure, I can get along without them as long as I still have GTO,
but they were handy. What about deleting a line? The fine manual
doesn't seem to mention this, but I suppose that overwriting it
with a GTO the next line is about the best I can expect from this
one. And where's DSZ and ISZ? I guess that if I want a definite
loop, I have to set up my own loop index and test.
You won't get any argument from me about the brain-dead nature of the 12C's programming model. I suspect you'd be hard pressed to find a defender of that model in the RPN ranks hearabouts. (Who knows, though? We'll see.)
Quote:
Hey, I could probably write a BASIC program for my Sharp with not
too much more difficulty than writing a program for one of these
things.
BASIC was my second programming language. It seems pretty natural to me too. I have gone on to more modern languages, as I've noted elsewhere. But BASIC probably doesn't seem as outrageously wordy and antiquated to me as it does to you. (But see
the rant in this README file for my generally unfavorable impression of BASIC.)
I do think BASIC is easier than RPN - or RPL!
Quote:
And many RPN users seem to have some sort of problems with RPL
models? Hard to understand; I'd have thought that anyone who could
learn to like the RPN models would find the RPL models amazingly
easy, but apparently not.
I didn't. They are distinctly different, as you can tell trying to go the other way. I think you'd hear the opposite opinion expressed by RPN devotees, that RPN should be easy for RPL coders. It clearly isn't in your case. I don't think either of us is an exception.
I am making an effort, and having some success, at coming up to speed on the 48G. It is a fun machine, after a period of getting to know it better.
Quote:
Okay, I can program them, but this "True RPN" stuff that so many
rave about sure doesn't seem to make things easy for me. And it
looks as if only a few programs could fit into memory at any one
time anyway, and there's no way to transfer anything into the
calculator except for keying it in. I'm going to write a program
for one of these only to have to purge it to make room for another
program, and then key it back in the next time that I want it? Not
likely!
Column B, but mostly column A.
There has been no development of new RPN machines since the RPL family took over HP's top of the line. The few programs that fit in a 16C, or even a 41C, reflects the cost of RAM back then. The limited number of labels in the voyager series fits with this limitation. The 33S is the current shipping RPN programmable from HP. It has a programming scheme similar to the voyagers with the addition of alphanumerics. So your listing, as you step through it with two lines visible at a time, is more readable. But because HP gave Kinpo the old 32SII code to port to a more modern chip, there are still only 30 or so possible registers and only 26 labels! This makes the 32K of RAM almost useless. If RPN models had been further developed, they would have come up with more elegant ways to use additional memory. But RPL was the king, so it saw the development, not RPN.
So the existing RPN programmables are not as capable as the 48/49 machines. But this is because development essentially stopped in the late 1980s. I've noted elsewhere that there have been numerous successive revolutions in computer architecture and software engineering since then, none of which have been incorporated into an RPN-style machine. It is a pity.
Quote:
These two are great as non-programmable calculators for the
special purposes that they were designed for, once I more or less
got used to some of their quirks, and maybe even to hold a very
few very carefully written programs more or less permanently.
But switch from the RPL models to any "True RPN" model for my
regular programmable scientific? I just can't see that ever
happening.
Of course, now I've been told that these two models are poor
examples for programming in "True RPN", but my experience with
them have put me off the whole idea of using anything but RPL
(well, assembler for time critical things such as I/O) for
programming calculators. When something works so well, why switch?
No reason at all. I only play with the RPL machines because I'm gadget happy. Come to think, that goes for the RPN machines too! 8)
Quote:
Now, if they came out with a low-cost shirt-pocket sized RPN
model, even if not "scientific", I'd sure like to have that, even
if programming it was too much of a hassle to bother with.
Regards,
James
Likewise,
Howard
Edited: 13 Nov 2005, 4:14 p.m.
Posts: 887
Threads: 9
Joined: Jul 2007
For the prices these things went for when they were new, it was expected that users would be pretty serious about it. I started with the TI-58c and then the 59, and the key-code recognition very soon became automatic, such that I wrote my programs as columns of key codes on paper, with a few comments to the right. The printer did indeed spell out the function the key was labeled with, but I certainly didn't need that for speed.
Now I often do use the PC with 132 columns (monospaced DOS) and 43 or 60 lines on the screen to write out a program before entering it into the HP-41. That way I can keep a clearer mental picture of the program, have more than one instruction per line, have plenty of room for comments, indent, add diagrams and special usage instructions, etc.. RPL give some of this, but how much can you do with a 2" screen? (I'm not saying anything against RPL, but just cautioning against being too critical of characteristics that were not always a problem, had easy ways to get around, etc..)
Posts: 801
Threads: 36
Joined: Nov 2005
James,
I wished I had a Voyager series machine, but at the time, my 34C was still going very strong and I could not justify at the time spending for even a beautiful unit as the 15C or 16C.
But truly, it ISN'T counterintuitive to program RPN keystrokes on a 34C, 32SII, or 33S. I assume you have a 33S? If not, then this is moot, but the looping controls in these models, while not as powerful as in, say, FORTRAN, they were more than adequate for programs to "automate" things you would repetitively do on a calculator until you got so bored and sick of it that you'd scream.
But, I will admit to the frustration many a time when it came to edit or correct something in the keystroke RPN program. You really just have to scroll through it!
Edited: 13 Nov 2005, 9:46 p.m.
Posts: 1,792
Threads: 62
Joined: Jan 2005
James --
I think Howard Owen's response was excellent; there's no need to quote or rehash his post or yours.
Just a few points I'd like to make:
- Keycodes:
As Howard pointed out, some of your points seem to confuse RPN with the limitations of mid-level models and early models. The keycodes shown in programs on Voyagers stem from their 7-segment display, not RPN! All the LED-display programmable models had the same limitation (except the HP-97 printer, as Howard mentioned).
The algebraic-entry HP-20S, and HP-21S also show keycodes due to their 7-segment display.
By contrast, the HP-41 with its 14-segment display, and
the dot-matrix HP-32S, HP-32SII, the HP-42, and the KinHPo 33S are RPN models that display symbols instead of keycodes.
- Programming paradigms:
The Voyagers are and were not the best RPN models for programming, not only due to the 7-segment displays, but also lack of RAM, slow speed, and lack of functions to partition user programs and to manage catalogues of programs. They were really intended for "expedient and disposable programs" only.
The HP-12C programming paradigm is indeed an abomination that originated with the HP-55 and was unfortunately carried forward to the HP-65, HP-25, and HP-10C, and maybe others.
The HP-41 and HP-42S were much better suited for "keeper" programs; the HP-32S, HP-32SII are also useful for programming (albeit hampered by lack of RAM).
Please have a look at my AC Power Transfer programs for the 32S/32SII/33S. These programs are quite well-suited to those models, but would be more straightforward if these calcs had more-sophisticated complex-number functions.
- "t" register on the 4-level stack:
Since the stack depth is fixed, some value must occupy the top-level register after an operation "pops" a value out. Zero would certainly be logical, but retaining the value in the "t" register can conveniently provide the user an endless supply of that value for calculations -- e.g., a constant term, or an input variable used many times in an equation.
The 4-level stack was a compromise of required utility with the hardware limitations of the early days. If an all-new RPN calculator were to be designed today, I would suggest a user-settable fixed stack of up to 9 levels (and possibly 19).
One slight quibble with Howard's statement about development of RPN calc's effectively ending in the late 1980's: I'd say that it was actually 1991-92. That's when the HP-32SII replaced the HP-32S with expanded capabilities:
- Equation editor from the HP-22S
- Fractional-math functionality that is really quite useful and impressive (after the bugs in the initial run were fixed)
- Functions and conditional tests omitted from the HP-32S
1991 might also be when the HP-17BII replaced the algebraic-entry HP-17B, adding RPN mode along with with a nicer bezel and trim.
-- KS
Edited: 14 Nov 2005, 12:33 a.m.
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Quote:
The 4-level stack was a compromise of required utility with the hardware limitations of the early days. If an all-new RPN calculator were to be designed today, I would suggest a user-settable fixed stack of up to 9 levels (and possibly 19).
[/ol]
That's what I would have expected if development of RPN models had taken a more evolutionary approach. A settable fixed stack, perhaps with the inclusion of an unlimited stack as a choice, could have been one natural feature incorporated into RPN calcs to help make use of abundant memory.
Quote:
One slight quibble with Howard's statement about development of RPN calc's effectively ending in the late 1980's: I'd say that it was actually 1991-92. That's when the HP-32SII replaced the HP-32S with expanded capabilities:
- Equation editor from the HP-22S
- Fractional-math functionality that is really quite useful and impressive (after the bugs in the initial run were fixed)
- Functions and conditional tests omitted from the HP-32S
1991 might also be when the HP-17BII replaced the algebraic-entry HP-17B, adding RPN mode along with with a nicer bezel and trim.
Thanks for that correction, Karl. That means we've had just about 15 years of neglect of RPN calculator OS software. Like I said, it is a pity.
Quote:
-- KS
Regards,
Howard
Posts: 1,041
Threads: 15
Joined: Jan 2005
All good responses everyone.
I do recognize that trying to use more than four stack registers
on an RPN model is purely a user error, but one that's easy to
commit, at least for someone whose experience is in RPL. In RPL,
using "too many" levels may result in an "Insufficient Memory"
error or even an "Out of Memory" error, which puts you into a
routine of choosing options for freeing up memory so you can use
the calculator again, but objects can never be pushed off of the
top of the stack.
As for duplicating the T register when the stack drops, the RPL
stack can indeed be empty, so what the RPL user expects when he
tries to take something from the stack that was never pushed there
is a "Too Few Arguments" error, not to use something that was
replicated down from a higher level.
I suppose that the small command set reflects the limited number
of keys and shifted keys feasible in a calculator, as well as the
other hardware limitations.
I've tried to figure out why the RPN models so often put the
operator first, followed by the argument, for example, with LBL,
GTO, GSB, and STO. The hypothesis that I've come up with is that
it's due to the 4-register stack. If the argument came first, it
would have to be stored somewhere, presumably on the stack. With
the operator coming first, the keystroke can be stored elsewhere
until the argument is entered to "complete the command", so the
argument never has to be put on stack, thus never using up a
precious stack register. Does this make sense?
Yes, many of limitations of the voyager series may be largely due
to to the hardware limitations at the time they were designed.
Expensive memory, 7-segment single line displays and so on.
Yes, RPN model development seems to have stopped in the early '90s
with the 33s resuming development, but how much does even the 33s
improve things over the basics of the Voyagers released in the
early '80s? Yes, the 33s has a dot-matrix 2-line display but,
that's a relatively minor improvement. It's still limited to a
4-level stack, and still has a limited number of labels. But I
gather that the development of the 33s amounts mostly to adapting
the 32SII to new hardware? So it's much like asking how much
things had been improved by the time the 32SII was released in
1991.
But I see that the 33s actually does have menus after all. Okay
now, I suppose that the program doesn't actually record the
keystrokes to get to the particular menu, but only the command
actually chosen from the menu? In that case, I'd say that it isn't
strictly "keystroke programming" after all, but rather "command
sequence programming". Somehow, this seems very much like
programming the RPL models; the difference being that in the RPN
models you have to use a special "program mode" to write a
program, and in the RPL models you simply start the command line
with the \<< UserRPL program delimiter, type in the rest of the
program, press ENTER to put it on the stack, and STO it in a
named global variable if you want to save it for later use.
So just what the heck is it that RPN users find so all-fired
"complicated" about RPL?
Just for the record, I don't find BASIC to be at all "outrageously
wordy and antiquated". Actually, I've always liked BASIC, but
preferring the versions that use labels instead of line numbers
for GOTOs and GOSUBs. But using line numbers instead of labels
isn't that difficult, provided you've left enough unused line
numbers that you don't need to renumber your lines. It did get a a
bit of a bad reputation because of the "spaghetti code" that one
could make with GOTOs all over the program, but I regard that as a
matter of poor programming practice, not anything inherently wrong
with the language. You could write spaghetti code in RPN or
assembler, for example, but that would be the fault of the
programmer, not the language. It is rather "old" now, but we all
know the "newer" isn't necessarily "better".
Regards,
James
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Quote:
I've tried to figure out why the RPN models so often put the operator first, followed by the argument, for example, with LBL, GTO, GSB, and STO. The hypothesis that I've come up with is that it's due to the 4-register stack. If the argument came first, it would have to be stored somewhere, presumably on the stack. With the operator coming first, the keystroke can be stored elsewhere until the argument is entered to "complete the command", so the argument never has to be put on stack, thus never using up a precious stack register. Does this make sense?
Yes it makes sense.
RPL people like to see this STO LBL GSB GTO stuff as inconsistent. In fact, is is perfectly consistent. You see, STO LBL GSB GTO are not mathematical operators; they are *control commands* and by their very nature have nothing to do with Juskawicz or Infix or Reverse Polish or whatever you want to call it.
So you are correct, it keeps these thing off the stack. But that is not merely to save stack. Think about error checking, argument checking etc. When you press a control function, that is how the machine knows that a control function is to happen "starting from now".
There is a major change in error-checking going from voyager to pioneer.
On an 11c etc, load the stack with say:
t 1
z 2
y 3
x 4
and then push GSB.
the screen will flash, waiting for a label. If you push <X> instead, you will see "12". Or, if you push <backspace> you will see "0".
In other words, classicaly, the *control commands* can be over-ridden by mathematical commands. It's a hierarchy thing.
On Pioneers it is different. IF you push <exq> you will see "exq_" and you cannot push anything but a valid label. If you push <X> you will get a <!> annunciator and you have to push *either* <backpsc> or <C> to get back to the stack view.
I think it is perfectly logical and in fact far more logical than the RPL idea that everything is a stack "argument" which leads to the distracting problem of everything out of order and stupid inane error messages like "too few arguments" etc.
Edited: 16 Nov 2005, 8:51 a.m.
Posts: 1,792
Threads: 62
Joined: Jan 2005
James --
Regarding your first query about why RPN models use postfix for commands such as STO, RCL, LBL, GSB/XEQ, GTO, FIX/SCI/ENG, etc:
Bill Platt explained it: These are non-mathematical operations that have nothing to do with RPN. In fact, I had discussed this in my "RPN is like a Leisure Suit" thread that you claimed to have read. An excerpt, discussing prefix notation, in which arguments must be specified before a command is executed:
Quote:
This approach -- the essence of RPN -- makes perfect sense for mathematical functions.
However, it is often counterintuitive for device-control functions, such as STO/RCL and FIX/SCI/ENG. On the RPN calculators, these functions (as well as LBL/GTO/GSB/XEQ) require an appended identifier, generally numerical, to complete the command. On the RPL units, the input identifier must be specified beforehand, in the interest of uniformity.
Which is easier and more intuitive:
"FIX 5" or "5 (ENTER) FIX"?
"25.4 STO 4" or "25.4 (ENTER) 'R4' STO"?
As for your boldfaced question,
Quote:
So just what the heck is it that RPN users find so all-fired "complicated" about RPL?
I'll quote another excerpt from my "Leisure Suit" post:
Quote:
As for RPL programming, compare a sophisticated RPL statement with an equivalent line in C, Basic, Fortran, or any other high-level language:
"IF (A .LT. B) A = A + 360.0" (Fortran '77)
"<< IF A B < THEN A 360 + 'A' STO END >>" (approximate RPL syntax)
(Much to my surprise, that short RPL program I wrote but didn't test before posting actually did work properly!)
This example underscores my main statement, in that RPL is an ineffective compromise between a high-level language and a keystroke-programming system.
When a series of prefix instructions is listed one at a time (like an RPN program), it essentially looks like an assembly routine. "Jumps" (GTO) are necessary a part of that.
However, when a series of prefix instructions is listed on a single line, it just looks scrambled -- nothing like a line of a high-level-language. Adding IF-THEN-ELSE and other constructs to prefix instructions just doesn't work, in my estimation.
-- KS
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
Karl,
Quote:
Regarding your first query about why RPN models use postfix for
commands such as STO, RCL, LBL, GSB/XEQ, GTO, FIX/SCI/ENG, etc:
Bill Platt explained it: These are non-mathematical operations
that have nothing to do with RPN.
I did notice his post.
Yes, of course those are non-mathematical operations. I agree that
intrinsically they have nothing to do with RPN; indeed, they're
used in many languages. In my opinion, what they have to do with
RPN in these discussions is that they are used in a stack-based
RPN language.
Quote:
In fact, I had discussed this in my "RPN is like a Leisure Suit"
thread that you claimed to have read. An excerpt, discussing
prefix notation, in which arguments must be specified before a
command is executed:
In fact, I had read that thread a few times, I read it again a few
more times, and now I've read it yet again a few more times. I
still disagree with you.
Quote:
Quote:
This approach -- the essence of RPN -- makes perfect sense for
mathematical functions.
I agree, although it seems that most of the world disagrees with
us on this point.
Quote:
Quote:
However, it is often counterintuitive for device-control
functions, such as STO/RCL and FIX/SCI/ENG.
Perhaps seeing them used as postfix commands often seems
counterintuitive to you because you've never seen them used that
way except in RPL?
Having them prefix seems counterintuitive to me, because although
RPN seems so similar to RPL, they're always postfix in RPL.
Quote:
Quote:
On the RPN calculators, these functions (as well as
LBL/GTO/GSB/XEQ) require an appended identifier, generally
numerical, to complete the command.
As I figured out for myself, using them that way in a "True RPN"
calculator has a major advantage in that it doesn't use up a
precious stack level. Now that I've realized what a severe penalty
having them postfix on these models would be, I'm quite satisfied
that having them prefix is indeed the much better choice.
With the RPL models, there are many more non-mathematical
operations, and they take a variety of object types as arguments,
often more than one, and sometimes the number of arguments is
determined by a number supplied as the first argument. Using up a
stack level for each argument is, in some cases, a minor
disadvantage of making them postfix operations. Some
non-mathematical operations also return results of various object
types and numbers of objects, sometimes with a count returned as
the last result. What's more, the + operation can be either
mathematical or non-mathematical, depending on which types of
arguments it finds; should it be postfix or prefix? Perhaps we'd
have to have two separate commands instead of loading so much into
just that one little command.
Quote:
Quote:
On the RPL units, the input identifier must be specified
beforehand, in the interest of uniformity.
The important reason for specifying the arguments before the
non-mathematical operations is functionality, just as it is for
mathematical operations.
In RPL, operations may be invoked from the keyboard, along with
their arguments. Operations may also be within programs, along
with predetermined arguments. If these were the only ways to
invoke non-mathematical opeerations, it would make little
difference whether they were prefix or postfix.
The arguments could also be objects that were on the stack before
the operation or the program containing it was invoked, or input
while a program was waiting for input, as with a PROMPT, INPUT, or
INFORM. They could be objects stored in a variable and retrieved
as needed. They could be objects created by the program that
contains the operations. In these cases, as long as the operations
are postfix, all the user or programmer has to do is ensure that
any arguments are available in the proper locations on the stack
before the operations are executed. This is the same as with
mathematical operations, and the same methods of ensuring the
stack locations are available.
But suppose that an operation is prefix, just because some
arbitrary rule says that certain operations shouldn't be postfix.
I don't have any way to move any object from the stack into the
runstream. What could be done is to allow prefix operations
operations to take name arguments. That way, what I could do is
arrange for the program to store the arguments of the prefix
operation in a variable, and then place the unquoted variable
names immediately after the operations in the program. Dealing
with several named variables is a lot of bother, so I'd like to
allow prefix operations that require more than one object to take
lists instead; but wait, lists are non-mathematical, so operating
on them means using a prefix operation, so using lists is out.
Well, now I'm back to using multiple variables and names.
It could be done, but it seems to me that all of this handling of
named objects is going to take up extra memory both in the program
itself and at run-time, and more execution time. In the case that
the arguments were already in the right location for using them
with postfix operations, the user would still have to go through
the trouble of storing them and placing the names after the
operations,
Why not just make every operation postfix so it can find its
arguments in the most natural place in a stack-based program,
right on the stack? It's been done that way in RPL ever since the
28C was released, and hasn't caused any problem yet.
Quote:
Quote:
Which is easier and more intuitive:
"FIX 5" or "5 (ENTER) FIX"?
"25.4 STO 4" or "25.4 (ENTER) 'R4' STO"?
To me, very much
"5 (ENTER) FIX" and "25.4 (ENTER) 'R4' STO",
although I'd key them in as
"5 FIX and "25.4 'R4' STO";
no sense using an extra keystroke when there's no need for it.
Quote:
As for your boldfaced question,
Quote:
So just what the heck is it that RPN users find so all-fired
"complicated" about RPL?
I'll quote another excerpt from my "Leisure Suit" post:
Quote:
As for RPL programming, compare a sophisticated RPL statement with
an equivalent line in C, Basic, Fortran, or any other high-level
language:
"IF (A .LT. B) A = A + 360.0" (Fortran '77)
"<< IF A B < THEN A 360 + 'A' STO END >>" (approximate RPL syntax)
Both are clear enough, but I'd give a slight edge to
"<< IF A B < THEN A 360 + 'A' STO END >>"
I did have to think about whether the Fortran '77 example made
sense.
It's even clearer to me when formatted as:
\<<
IF
A B <
THEN
A 360 +
'A' STO
END
\>>
But if you don't like program structures, how's this:
\<<
\<<
A B <
\>>
\<<
A 360 +
'A' STO
\>>
IFT
\>>
Quote:
(Much to my surprise, that short RPL program I wrote but didn't
test before posting actually did work properly!)
This example underscores my main statement, in that RPL is an
ineffective compromise between a high-level language and a
keystroke-programming system.
When a series of prefix instructions is listed one at a time (like
an RPN program), it essentially looks like an assembly routine.
"Jumps" (GTO) are necessary a part of that.
However, when a series of prefix instructions is listed on a
single line, it just looks scrambled -- nothing like a line of a
high-level-language. Adding IF-THEN-ELSE and other constructs to
prefix instructions just doesn't work, in my estimation.
You've really lost me in that paragraph. What I take away from all
of this is:
-
You don't like to see postfix non-mathematical operations because
it seems counterintuitive to you.
-
I've given myself a good review of just why postfix operations are
so important to making a stack-based language easy to use.
-
You find RPL program structures hard to read.
-
In general, you don't like RPL.
Actually, that last point I figured out a long time ago.
Regards,
James
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
So RPL has postfix syntax for every operation for consistency, and for argument passing efficiency's sake. That's why RPL has 'A B > IF', right?
Oh.. wait.. 8)
▼
Posts: 896
Threads: 183
Joined: Jul 2005
Forth, on the other hand is rather consistent :)
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Right, IF is a postfix operator in FORTH.
Pardon me, I meant to say 'IS' 'FORTH' 'OP' 'POSTFIX' 'IF'
8)
Posts: 1,792
Threads: 62
Joined: Jan 2005
James --
Your first indented multi-line RPL program is indeed clearer that the one-liner, in my view. Of course, the Fortran '77 program can also be written using multiple lines (and would have to be, if there were an ELSE clause):
IF (A .LT. B) THEN
A = A + 360.0
ENDIF
(360 is written as 360.0 to avoid mixed-mode arithmetic, although that is not absolutely necessary. Fortran will handle mixed-mode calculations properly.)
Quote:
You've really lost me in that paragraph. What I take away from all of this is:
- You don't like to see postfix non-mathematical operations because it seems counterintuitive to you.
- I've given myself a good review of just why postfix operations are so important to making a stack-based language easy to use.
(Of course, I meant "postfix", not "prefix" in the paragraph you referred to. I'm sure that you understood that. My bad...)
I see some merit, but don't fully concur, on the first two points:
I believe that postfix non-mathematical operations (and RPL itself) is conterintuitive to many people, not just myself.
I do concede that a very complicated and "overloaded" function (i.e., multiple functions for one command) may be best to implement as fully postfix.
Quote:
- You find RPL program structures hard to read.
- In general, you don't like RPL.
Actually, that last point I figured out a long time ago.
Regards, James
Exactly, and "Right on!" about the last two points.
Now, James, would you care to try my RPL challenge from last year, and provide a solution different from those posted by Arnaud Amiel and Raymond Del Tondo? I'd like to see an RPL program that makes sense to non-RPL'ers as to what exactly is taking place. The structure of the HP-71B solution posted by Valentin was evident, I think, even to those who are not familiar with that machine but have learned any high-level data-oriented language.
Regards,
-- KS
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Hi, Karl,
I just happen to be coding my eyes out in RPL right now, and trying to make it easier for me to read. I looked at Arnaud's first two programs in the referenced thread, and I think I can make a version that scans better. I don't know how it will perform relative to the stack based versions however.
Here is some of the setup Arnaud specified:
Quote:
I store SIN(X) in F I store SQ(X-1.5)-1 in G
..
<< RAD F G - DUP 'X' 0 ROOT OVER 'X' 3 ROOT ROT 'X' S >>
S being the integral function.
The program is the second one he wrote. It's stack-oriented gibberish to me. I think this is better:
<<
RAD @ Set Radians mode
F G - @ Create the expression SIN(X) - (X-1.5)^2 - 1
\-> d \<< @ Store it in 'd'
d 'X' 0 ROOT @ Solve d(X)=0 with intial guess of X=0.
d 'X' 3 ROOT @ Solve with guess of X=3
d 'X' S @ Integrate with respect to X, in the calculated interval
>>
>>
Regards,
Howard
Edited: 18 Nov 2005, 2:37 a.m.
▼
Posts: 362
Threads: 30
Joined: Jul 2005
It took me some time to understand it myself but here we are:
<< RAD F G - DUP 'X' 0 ROOT OVER 'X' 3 ROOT ROT 'X' S >>
or
<<
RAD @Set Radian Mode
F G - @Level 1 is F-G
DUP 'X' 0 @Stack is 4:'F-G' 3:'F-G' 2:'X' 1:0
ROOT @Stack is 2:'F-G' 1:Root1
OVER @Stack is 3:'F-G' 2:Root1 1:'F-G'
'X' 3 ROOT @Stack is 3:'F-G' 2:Root1 1:Root2
ROT @Stack is 3:Root1 2:Root2 1:'F-G'
'X' S @The result
>>
I can now find some ways to improve the program but the stack manipulation would be even more complicated.
Anyway, when programming anything slightly involved in RPL, I need to keep stack diagrams as on the comments above. Note the this example uses a maximum of 4 stack levels and would not be very different on an advaced RPN machine: OVER=RCL Y and ROT=RCL Z
Also note that this is really keystroke programming.
But anyway Howard solution is more directly accessible.
Arnaud
Edited: 18 Nov 2005, 10:44 a.m.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Arnaud:
Arnaud wrote:
"It took me some time to understand it myself [...]"
That's the point, indeed. Even the author of the code himself finds it difficult to understand a few lines of RPL code he wrote after a small amount of time has elapsed.
"... but here we are: << RAD F G - DUP 'X' 0 ROOT OVER 'X' 3 ROOT ROT 'X' S >>"
without the comments you provide below, this line of code seems absolutely messed up, kind of an entry for the "Obfuscated C" contest (not that it would win, mind you !)
"I can now find some ways to improve the program but the stack manipulation would be even more complicated."
So less apt to be understandable, even in the least, to someone not familiar with RPL, as Karl's challenge posits.
"when programming anything slightly involved in RPL, I need to keep stack diagrams as on the comments above"
Once again, that's the point. Anything *slightly* involved in RPL means that you have to keep stack diagrams in order not to get lost and more or less find your way through the mess.
On the other hand, I can assure you that, in my extensive, 30-year experience with RPN, I've never found any need at all to keep or write down "stack diagrams". With just 4 levels, always present, and a few simple commands to deal with them, you can keep where everything is in your head ( "... this is in LASTX now, and this other result is in T, I need to Rup it, then LASTX and +, ...") and I've *never* felt "lost" or insecure about where some results are on the stack. And if I did, a simple look at the program steps and some mental tracing would be sufficient to keep my bearings.
That's *not* something you can do with RPL, and certainly *not* if you make extensive use of the stack and avoid named variables. And, if you do resort to using them, dispensing with unfathomable stack manipulations, then BASIC is far, far, far more understandable and easy to use, even to RPN/RPL people, as my BASIC version of the above algorithm clearly demonstrates.
RPL may have its good points, if any, but clarity and understandability are not among them.
Best regards from V.
▼
Posts: 362
Threads: 30
Joined: Jul 2005
Although I am a strong supporter of RPL, I fully agree with you. Although RPN is not any better.
Quote:
Once again, that's the point. Anything *slightly* involved in RPL means that you have to keep stack diagrams in order not to get lost and more or less find your way through the mess.
I have nearly the same problem when I am working with RPN, just instead of keeping stack level in my mind, I need to keep a table of registers. At least, those usually don't move.
When I have a bit more money, I will try to get myself a 71 and play with basic. However, what I like programming in RPL or RPN is exactly the fact that it is not straightforward. You have 2 challenges first find the algorithm, second code efficiently. With basic, step 2 is not very challengeing. I have spent days improveing a few lines of RPL.
Arnaud who sounds like a masochist :-(
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Quote:
I have nearly the same problem when I am working with RPN, just instead of keeping stack level in my mind, I need to keep a table of registers. At least, those usually don't move.
Other platforms call them "variables," 8) They leverage this odd human tendency to associate concrete or abstract things with names. (Like our stack diagrams or register tables help us to do.)
Posts: 1,830
Threads: 113
Joined: Aug 2005
I agree that RPL, as generally employed by the experts, is hard to read. It is also hard to remember what you were doing in a particular fit of impenetrable stack manipulation two weeks after you wrote it. However, I'd like to point out that Arnaud's approach uses at most four levels of the unlimited RPL stack. If you use his translation of OVER as RCL Y and ROT as RCL Z, then you have exactly the same set of manipulations you would have on an RPN stack! Assuming you had an RPN calc that could do symbolic math, a comparison might be as follows:
RPL RPN
=========================
F F
G G
- -
DUP ENTER^
'X' 'X'
0 0
ROOT XEQ 'ROOT'
OVER RCL Y
'X' 'X'
3 3
ROOT XEQ 'ROOT'
ROT RCL Z
'X' 'X'
S XEQ S
I naturally lean toward HP-41 syntax in my pseudo-RPN. 8)
My point is that keeping track of stack levels on an RPN calc can be troublesome, too. RPL is inherently worse for three reasons, IMHO. First, going over four stack levels is evil if you want to have any clarity in your code at all. Second, the RPL models have a richer set of program control structures, and frequently more than one of a particular kind. This allows RPL code to be more convoluted, more readily than RPN. Finally, the RPL calcs are more advanced than their RPN progenitors. This means that stuff you store on the stack can have an arbitrary amount of internal structure, further obscuring what a particular operation does. For instance subtraction in the example code composes a symbolic expression of the difference of two functions of X, not a simple arithmetic difference.
A fourth reason RPL is harder to read is not due to anything inherent in the language. It's the culture of RPL programmers who code it without regard for readibility. You can name your variables in RPL, at the expense of some efficiency, and reduce your dependence on the stack. You can code with comments and nice indentation in a PC file. Unfortunately, both niceties are lost when the text is transferred to the calculator. This would lead me on to a further rant about the usability of the HP-48 as a software development platform, except that I'd rather not root around in that can of worms right now. 8)
Regards,
Howard
Edited: 18 Nov 2005, 12:53 p.m.
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
Quote:
My point is that keeping track of stack levels on an RPN
calc can be troublesome, too.
Yes, with an RPN model, there are only four stack registers to
keep track of, but things can be "pushed off" of the top of the
stack, and the content of the t register is propagated downward as
things are removed from the bottom (the stack can never be empty).
This may seem very intuitive to RPN programmers, but for someone
who first learned RPL, these are "gotchas". Of course, in RPN
there are also the Last X and storage registers that may be
utilized, in which case the user has to keep track of those too,
and a GSB may be used to call a subroutine, or a GTO to jump
anywhere, so those have to be kept track of.
Quote:
First, going over four stack levels is evil if you want to have
any clarity in your code at all.
Why exactly four stack levels for the maximum? Should we also
impose an arbitrary maximum for the number of storage registers or
variables to be used? Or how deeply program structures or
parentheses can be nested?
It's a matter of how easy it is for the individual programmer to
"see" the stack in his head. The high levels can often be regarded
as objects that are set aside for a while, until the user gets
back to them. Sometimes a large group of objects with a count are
treated as a "meta-object", as when a list or array is "exploded"
onto the stack, or as preparation in making a list or array.
Quote:
Second, the RPL models have a richer set of program control
structures, and frequently more than one of a particular kind.
This allows RPL code to be more convoluted, more readily than RPN.
I don't think that "convoluted" is quite the right word. A program
structure can never begin in one program structure clause and
continue or end outside of that clause. "Overlapping" structures
aren't permitted; any structure has to be entirely within the same
clause of any "outer" structure. You can indeed "nest" program
structures as deeply as you like (available memory allowing), but
you can never "jump" out of a program structure clause early. You
can also call programs by name, and a program may even call
another instance of itself, and execution of the calling program
resumes when the called program is finished. A clause may be
skipped over entirely, but execution always has to return to any
"outer" clause being executed to finish it up. Well, exceptions
being when the structure is within a IFERR clause and an error
occurs, in which case, the return stack is discarded back to the
IFERR structure's marker, and execution resumes with the IFERR's
THEN clause, and when execution is abandoned entirely due to an
error. The compilers enforce the rules, returning an "Invalid
Syntax" error if you don't stick to the rules.
An RPL subroutine is a quoted procedure already placed on the
stack earlier in the program, or a local or global variable,
instead of being jumped to with a GOSUB, as in many other
languages.
Internally, RPL keeps track of where execution is to resume with a
separate return stack. Indeed, the built-in commands (actually
special SysRPL programs) use both stacks heavily. Like the data
stack, the return stack has variable depth, limited only by
available memory. In SysRPL, the programmer has some commands to
work with the return stack, but in UserRPL, the user utilizes the
return stack with program structures and calls to variables, and
may not even be aware of its existence.
Execution can be suspended with the HALT command (or PROMPT or in
the debugger, for examples), in which case the "suspended" program
is kept in memory, ready to be resumed with the current data stack
by CONT or a single-step operation, or abandoned with KILL.
With RPN's GTO, one could develop "spaghetti code". I suppose that
RPL's program structures are intended to prevent developers from
writing such truly "convoluted" code. Some sort of GOTO or BREAK
would indeed be handy in RPL, but offhand, it seems to me that it
would have to be restricted to "jumps" within the same structure
clause, and perhaps to only "forward" jumps, and a GOTO would
require a label or line number, neither of which RPL has. I'm not
against GOTO, but it can be used to make very complicated code.
Quote:
Finally, the RPL calcs are more advanced than their RPN
progenitors. This means that stuff you store on the stack can have
an arbitrary amount of internal structure, further obscuring what
a particular operation does. For instance subtraction in the
example code composes a symbolic expression of the difference of
two functions of X, not a simple arithmetic difference.
Well, whether subtraction returns a number or an algebraic object
depends on what the arguments were, and the state of system flags
for the modes.
But indeed, there are various object types, and a single object
may be a list or program (or other composite) which may itself
contain any other objects. An algebraic object is very similar to
a program object, but is more restricted; it's contents must be
logically equivalent to a valid (for the calculator) algebraic
expression. Arrays aren't composite, as they don't hold objects
complete in themselves, but they might be thought of as containing
(among other information) "object bodies".
Quote:
A fourth reason RPL is harder to read is not due to anything
inherent in the language. It's the culture of RPL programmers who
code it without regard for readibility.
There's some truth to this. What may be obvious to the programmer
may be very obscure to others, particularly to beginners. A public
discussion among "experts" may well be impenetrable to those who
don't have the knowledge required to understand it. When answering
a question, it may be difficult to guess how much the person
asking already knows, and tailor the response appropriately.
Some will just post a compiled program or library on hpcalc.org
for example, without bothering to include source code or explain
how it works internally. Presumably, these are meant to be
"useful" rather then "educational". Of course, others may
decompile it back to source code if they know how, and nothing can
document the code as accurately as the code itself, although it
may indeed be very difficult to understand without comments or at
least the original source code.
In "challenges", the object is usually to develop the smallest or
fastest program to accomplish a desired objective, so obscure
"tricks" are often used without any regard for readability or
explanation of just why it works.
Quote:
You can code with comments and nice indentation in a PC file.
And in the command line editor, for that matter.
Quote:
Unfortunately, both niceties are lost when the text is transferred
to the calculator.
As you probably know, these niceties are discarded because source
code is compiled to an object (or objects). Compiling discards all
source code delimiters, comments, separators, and indeed even the
source code "words" are replaced in most cases. Every object
begins with a prologue (actually, a prologue address), a location
pointer to the system code (the actual prologue) that tells the
system what type of object it is, how to handle it, and how to
find its end. That said, as implemented so far, the end of any
composite object is delimited with an object pointer to the
system's primitive code object SEMI.
RPL source code is largely "free form", except that a Line Feed
code (but not other separators) ends any comment (which can also
be ended with another "@" character). A comment also functions as
a separator. Separators (or series of separators) are otherwise
logically equivalent. One could use a separate line for every
"word" or comment, with indenting optional, or could make the
entire source code a single line, as long as it doesn't contain a
character string with an embedded Line Feed code. Even a Line Feed
within a string in a source code file may be written as the
character translation sequence \010, as long as translation mode 2
or 3 is used.
Programmers use a variety of styles for their source code. There's
no one "right" way to do it; it's rather a matter of what the
programmer considers readable. The calculators' command line
editor decompilers choose to start an indented new line for every
structure word or embedded program, but then continue the line up
to the display width and start subsequent lines at the left margin
until the next structure word, presumably to fit more information
into the calculator's limited display area while still giving some
idea of the structure. Sometimes source code is posted online
exactly as the calculator decompiles it, or the poster writes it
on the PC and doesn't bother formatting it for easy readability.
On a calculator, I mostly follow the decompiler's example, except
that I usually put any structure word or program delimiter on its
own line, except for putting the index name on the same line as
FOR. In a source code file on the PC, I tend to use "multi-line"
source code and indent the contents of a clause for the entire
clause, but sometimes put a short program structure or subprogram
on a single line. I tend to put things that seem to logically go
together, such as arguments and the operator, on the same line, if
I don't want separate comments for them. Just how I format and
comment source code depends on who I intend to have read it. For
my own use, I may well consider the source code to be
self-documenting with no or very little need for comments. For
posting online, I may well go to the trouble of extensive
commenting. For projects that seem as if they're going to be
complicated, I sometimes write comments as an outline before
writing any source code.
If you really want to preserve your nice indentation and comments,
you can write the source code within a character string. That way
the calculator compiles it to a character string object,
preserving the source code as written (or in the case of a "text"
transfer, optionally "as translated").
You can't very well have an unescaped " within a quoted-delimited
string, but a counted string form may be used for this. NUL marks
the end of the command line, so the calculators (mostly) prevent
an actual NUL from being used within the command line. For the 49
series, within a quote-delimited string, \00 can be used instead
of NUL, \" is used for ", and \\ is used for \. The 49 series
still compiles counted strings exactly as the 48 series does, but
never decompiles to the counted string form, instead using the new
"escaped" forms for decompiling NUL, ", and \. Note that 49G ROM
versions prior to 1.19-6 incorrectly compile the \00 to 00 instead
of NUL. Within a quote-delimited string, all characters except (on
the 49 series) the \00, \", and \\ sequences and \ are treated as
literal. Within a counted string, all characters are treated as
literal. Note that Conn4x has its own rules for these characters,
and can be "confused" by a \ character outside of a
quote-delimited string, mistaking it for the beginning of a
character translation sequence.
To "execute" the source code string, put it on the stack and
execute STR\-> or OBJ\->, which compiles it to an object. If it's
a "quoted" object, for example with program delimiters, you'll
need to use EVAL to pop it off the stack and actually execute its
contents. For convenient viewing on a calculator, you'd probably
want to adjust the style to fit the display, without any
horizontal scrolling to see a whole line.
So why is source code compiled? I suppose for one thing, the
compiled object nearly always uses less memory than the source
code. Then too, at run-time, the calculator doesn't have to parse
stored code from a form that's easy for a human to read to a form
that's easier for the system to execute. For source code in the
command line, compiling is a step in the execution sequence. To be
sure, the calculator does have to decompile objects for display,
\->STR. printing, and text transfers.
The developers also probably expected the users to be writing
mostly short programs, and perhaps calling other short programs by
name. Having a set of "utility" programs for other programs to
call may indeed make sense, but that introduces a dependency tree;
purging a program or changing what it uses for arguments or what
it returns affects anything else that calls it, directly or
indirectly. For an online example, any program that the example
depends on has to be included (or at least its inputs and outputs
described) for the source code to make sense to others.
RPL is indeed somewhat "different" from classic RPN. It uses a
variable depth stack instead of a 4-register stack, execution
control is restricted to "program structures" instead of jumping
just anywhere with GTO, and they have various other differences.
What I can't see is that RPL is necessarily "complicated" to use.
Regards,
James
Posts: 3,283
Threads: 104
Joined: Jul 2005
Arnaud,
you just proved that you got lost:
Quote:
Note the this example uses a maximum of 4 stack levels
Here is the Problem:
Quote:
OVER @Stack is 3:'F-G' 2:Root1 1:'F-G'
'X' 3 ROOT @Stack is 3:'F-G' 2:Root1 1:Root2
Just before the command ROOT is executed, the stack holds the following items:
5:'F-G'
4:Root1
3:'F-G'
2:'X'
1:3
It's not a problem of your code because the RPL stack has enough levels, but your reasoning that 4 levels were sufficient is certainly wrong.
Marcus
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Quote:
Just before the command ROOT is executed, the stack holds the following items:
5:'F-G'
4:Root1
3:'F-G'
2:'X'
1:3
Oops! That renders my RPN translation invalid too.
I suppose Arnaud can be forgiven for missing a 4-item stack limit. His platform doesn't enforce such a limit. I on the other hand have no such excuse.
On the other hand, missing the stack overflow doesn't invalidate my main point, which is that RPN and RPL really are similar at a certain level. Many common RPL stack manipulations have direct RPN equivilants.
Edited: 18 Nov 2005, 5:12 p.m.
Posts: 362
Threads: 30
Joined: Jul 2005
Quote:
you just proved that you got lost:
Oops!!!
As I said above, I NEVER argued that RPN was straightforward and that quickly keeping stack diagram become necessary. But I also keep stack diagrams in RPN (maybe a bad habit I got from RPL)
Arnaud
Posts: 1,041
Threads: 15
Joined: Jan 2005
Karl,
Quote:
Your first indented multi-line RPL program is indeed clearer that
the one-liner, in my view. Of course, the Fortran '77 program can
also be written using multiple lines (and would have to be, if
there were an ELSE clause):
IF (A .LT. B) THEN
A = A + 360.0
ENDIF
And that's clearer to me than the Fortran '77 one-liner.
Quote:
Now, James, would you care to try my RPL challenge from last year,
and provide a solution different from those posted by Arnaud Amiel
and Raymond Del Tondo? I'd like to see an RPL program that makes
sense to non-RPL'ers as to what exactly is taking place. The
structure of the HP-71B solution posted by Valentin was evident, I
think, even to those who are not familiar with that machine but
have learned any high-level data-oriented language.
I thought the examples posted before demonstrated that RPL was
easiest to understand, but why not?
First off, the way you described the challenge isn't entirely
clear to me. Should the two expression be defined separately, and
should they be "user-defined functions"? I chose to combine them
into one expression. Also, should there be three separate
programs, one that finds the lower limit, one that finds the upper
limit, and finally one that calls the other two and finds the
area, or should it all be combined into a single program? I chose
the single program,
An assumption: It's already known that there's exactly one
intersection point between X=0 and X=1, there's exactly one
intersection point between X=2 and X=3, and there are no
intersection points between these two. This can be verified easily
enough by plotting.
My examples are slightly "unfriendly" in that they purge global
variables named 'X' and 'IERR' without restoring the originals. I
don't like to do that, but in this case, restoring them would be
more likely to mislead the user than to be useful.
They are "friendly" in that they follow good practice and resto |
