The Museum of HP Calculators

HP Forum Archive 21

[ Return to Index | Top of Index ]

Help with RPN programming
Message #1 Posted by hpnut on 1 Mar 2012, 7:39 p.m.

Hi all,

Can anyone help me write an RPN program to count to infinity based on the following BASIC program?

10 x=1 20 print x 30 x=x+1 40 goto 20

thanks!

hpnut in Malaysia

      
Re: Help with RPN programming
Message #2 Posted by Kerem Kapkin (Silicon Valley, CA) on 1 Mar 2012, 8:05 p.m.,
in response to message #1 by hpnut

On a HP-41

01 LBL 'INFTY

02 0

03 LBL 01

04 PRX

05 1

06 +

07 GTO 01

08 END

Edited: 1 Mar 2012, 8:06 p.m.

            
Re: Help with RPN programming
Message #3 Posted by C.Ret on 2 Mar 2012, 3:32 a.m.,
in response to message #2 by Kerem Kapkin (Silicon Valley, CA)

HI, Kerem

I am in the regret to inform you that you miss a very very very little detail. So that your code is not a correct translation of the BASIC code since it donít behave exactly the same.

If you RUN the BASIC code, you may observe the following outputs:

%---- BASIC Code ----       |      ---- Screen/Display OutPut ----
LIST                        |       RUN
10 X=1                      |       1.
20 PRINT X                  |       2.
30 X=X+1                    |       3.
40 GOTO 20                  |       4.
                            |       5.
                            |       ...

In comparison, this is what I get by probing out your code:

%---- HP41 Code ----       |        ---- Printer OutPut ----
01 LBL 'INFTY              |                  0.0000     ***
02 0                       |                  1.0000     ***
03 LBL 01                  |                  2.0000     ***
04 PRX                     |                  3.0000     ***
05 1                       |                  4.0000     ***
06 +                       |                  5.0000     ***
07 GTO 01                  |                  ...
08 END                     |

Has you may have note it, your code start to count from zero, whereas one is expected as starting value. I donít know the purpose of this counter, but other differences are that HP41 list decimals number with trailing 0 digit, where BASIC only show up integer with no fractional part draw.

O.K., I agree with you, hpnut have not specify a lot, nor has he give example. As far as we donít know much about the purpose of his code, all this are perhaps actually unmindful.

To quickly converge to infinity, may I suggest to use a more rapid solution such as :

10 X=0                     |  01 Clx
20 X=EXP(X)                |  02 LBL 00
30 PRINT X                 |  03 e^x
40 GOTO 20                 |  04 VIEW X
                           |  05 GTO 00
[pre]
Or, as an immediate answer
[pre]
10 PRINT 1/0                |     0 1/X

Edited: 2 Mar 2012, 3:33 a.m.

                  
Re: Help with RPN programming
Message #4 Posted by Garth Wilson on 2 Mar 2012, 6:06 a.m.,
in response to message #3 by C.Ret

Quote:
but other differences are that HP41 list decimals number with trailing 0 digit, where BASIC only show up integer with no fractional part draw.
I'm surprised how many 41 owners keep their 41's in FIX 4 display mode. You can do FIX 0 and it won't show even the decimal point, let alone any fractional part; but I almost always have mine in ENG 3 (or actually ENG 03 since I have the ZENROM which allows FIX 10).
                        
Re: Help with RPN programming
Message #5 Posted by C.Ret on 2 Mar 2012, 9:42 a.m.,
in response to message #4 by Garth Wilson

It's true.

In itself is so true that one might think that the FIX 4 has become a hallmark.

Like you I have the habit to use ENG mode, but often with only two significant digits. My field samples and data that occur from it are generally of poor quality.

And by delivering too precise results to my clients, I certainly put at risk my responsibility and I may be put under prosecution.

Besides that leaves me no chance at a possible future increase in my charges, if by chance I finally got good analytic equipments and produce better results !

                        
Re: Help with RPN programming
Message #6 Posted by Mark Storkamp on 2 Mar 2012, 12:44 p.m.,
in response to message #4 by Garth Wilson

In a machine shop, anything less than a tenth (0.0001) is pretty much meaningless, but thousandths (0.001) would not be enough accuracy, so FIX 4 is ideal for everyday use.

                              
Re: Help with RPN programming
Message #7 Posted by Garth Wilson on 2 Mar 2012, 2:14 p.m.,
in response to message #6 by Mark Storkamp

Ah yes, that does sound like the perfect thing there. But in electronics engineering, I'm always dealing with values from 1pF (.000000000001 Farad) to over 2GHz (2,000,000,000Hz) and I seldom need more than four digits altogether and I want the exponent to go in threes (pico, nano, micro, milli, [units,] kilo, mega, giga, etc.).

Edited: 2 Mar 2012, 2:15 p.m.

                        
Re: Help with RPN programming
Message #8 Posted by Howard Owen on 2 Mar 2012, 3:35 p.m.,
in response to message #4 by Garth Wilson

Quote:

You can do FIX 0 and it won't show even the decimal point, let alone any fractional part;


You need to surpress the radix with CF 29 for the decimal to disappear in FIX 0.

                  
Re: Help with RPN programming
Message #9 Posted by Kerem Kapkin (Silicon Valley, CA) on 2 Mar 2012, 3:12 p.m.,
in response to message #3 by C.Ret

Oppps! :) Thanks for the catch!

                  
Re: Help with RPN programming
Message #10 Posted by Crawl on 2 Mar 2012, 4:17 p.m.,
in response to message #3 by C.Ret

Quote:

O.K., I agree with you, hpnut have not specify a lot, nor has he give example. As far as we donít know much about the purpose of his code, all this are perhaps actually unmindful.


I don't know his purpose, either, but I think this sort of program should really be the first program you learn in any programming language, rather than "Hello world".

      
Re: Help with RPN programming
Message #11 Posted by Les Bell on 1 Mar 2012, 8:05 p.m.,
in response to message #1 by hpnut

LBL A
1
LBL 00
PSE
1
+
GTO 00

That should do it.

Best,

--- Les
[http://www.lesbell.com.au]

      
Re: Help with RPN programming
Message #12 Posted by Gerson W. Barbosa on 1 Mar 2012, 8:09 p.m.,
in response to message #1 by hpnut

HP-15C LE:
001- f LBL B 002- 1 003- f LBL 1 004- R/S 005- 1 006- + 007- GTO 1

HP-12C:
01- 1 02- g PSE 03- 1 04- + 05- g GTO 02

      
Re: Help with RPN programming
Message #13 Posted by reth on 1 Mar 2012, 8:16 p.m.,
in response to message #1 by hpnut

HP41:

LBL 'X
1
ENTER
ENTER
ENTER
LBL 00
VIEW X
+
GTO 00
END

      
Re: Help with RPN programming
Message #14 Posted by Paul Dale on 1 Mar 2012, 8:22 p.m.,
in response to message #1 by hpnut

For the 34S:

001: LBL'[infinity]'
002: 1
003: VIEW X
004: INC X
005: BACK 002

- Pauli

            
Re: Help with RPN programming
Message #15 Posted by hpnut on 1 Mar 2012, 9:55 p.m.,
in response to message #14 by Paul Dale

thanks! you guys are great :-)

Now i know how to drain the batteries in HP 15C LE....

                  
Re: Help with RPN programming
Message #16 Posted by Thomas Klemm on 2 Mar 2012, 12:04 a.m.,
in response to message #15 by hpnut

You might want to try the following:

CLEAR PRGM
001- RCL 0
002- PSE
003- ISG 0
CLEAR REG
R/S

Regards
Thomas

                        
Re: Help with RPN programming
Message #17 Posted by Paul Dale on 2 Mar 2012, 12:08 a.m.,
in response to message #16 by Thomas Klemm

Nice use of the recently discovered 15C bug :-)

- Pauli

                        
Re: Help with RPN programming
Message #18 Posted by Patrice on 2 Mar 2012, 1:30 a.m.,
in response to message #16 by Thomas Klemm

To drain batteries, remove the PSE

                              
Re: Help with RPN programming
Message #19 Posted by Thomas Klemm on 2 Mar 2012, 2:51 a.m.,
in response to message #18 by Patrice

But then we can get rid of the RCL 0 as well and end up with the ultimate battery drainer program:

001- ISG 0
      
Re: Help with RPN programming
Message #20 Posted by Marcus von Cube, Germany on 2 Mar 2012, 3:37 a.m.,
in response to message #1 by hpnut

None of the programs featured here will ever reach infinity, not even the largest number representable on the respective machine. An HP 41 will not count beyond 1e10.

            
Re: RPN programming little challenge help
Message #21 Posted by C.Ret on 2 Mar 2012, 12:12 p.m.,
in response to message #20 by Marcus von Cube, Germany

Good Catch Marcus! Felicitations!

None of the programs listed here will ever reach the largest number representable on the respective machine.

Thatís a good question.

How to get the largest representable number on the RPN classic's and vintage BASIC's system ? What will be the shortest efficient sequence ?

Note that on RPL the largest number is easily obtained with specific instruction MAXR or by setting appropriate sy stem flags allowing calculus overflow.

Edited: 2 Mar 2012, 12:12 p.m.

                  
Re: RPN programming little challenge help
Message #22 Posted by Paul Dale on 2 Mar 2012, 5:52 p.m.,
in response to message #21 by C.Ret

Quote:
None of the programs listed here will ever reach the largest number representable on the respective machine.

The 34S and 16C would theoretically in integer mode. Nobody has produces a program specifically for the latter though.

- Pauli

                        
Re: RPN programming little challenge help
Message #23 Posted by Tom Grydeland on 5 Mar 2012, 4:31 a.m.,
in response to message #22 by Paul Dale

setting WSIZE 8 makes the WP-34S 'infinity' program overflow in a few tens of seconds :-)

                              
Re: RPN programming little challenge help
Message #24 Posted by Paul Dale on 5 Mar 2012, 4:52 a.m.,
in response to message #23 by Tom Grydeland

Try WSIZE of 2 then :-)

Of course it wraps around and keeps counting.

- Pauli

            
RPN...
Message #25 Posted by Reth on 2 Mar 2012, 3:12 p.m.,
in response to message #20 by Marcus von Cube, Germany

Quote:
None of the programs featured here will ever reach infinity, not even the largest number representable on the respective machine. An HP 41 will not count beyond 1e10.
Nothing reaches infinity. It's only a figure of speech.
                  
Re: RPN...
Message #26 Posted by Kerem Kapkin (Silicon Valley, CA) on 2 Mar 2012, 3:18 p.m.,
in response to message #25 by Reth

May be, think about it from the calculator's point of view, as the battery gets weaker and weaker, calculator starts seeing the white light as it moves towards it, the number in the X register reaches infinity :) but no one is there to see it or measure it.....there are no more 1s and 0s in the X register anymore...

Edited: 2 Mar 2012, 3:21 p.m.

                        
Re: RPN...
Message #27 Posted by Reth on 2 Mar 2012, 6:25 p.m.,
in response to message #26 by Kerem Kapkin (Silicon Valley, CA)

Yea, except in poetry, I should say :)

                  
Re: RPN...
Message #28 Posted by Kiyoshi Akima on 2 Mar 2012, 4:48 p.m.,
in response to message #25 by Reth

I remember when a local institution was replacing their Cray 1 with a newer model. One person said that the new machine was so fast that it would finish an infinite loop in thirty minutes ;-)

                        
Re: RPN...
Message #29 Posted by Bill (Smithville, NJ) on 2 Mar 2012, 6:16 p.m.,
in response to message #28 by Kiyoshi Akima

Quote:
finish an infinite loop in thirty minutes

That's funny. Reminds me of my experience with a Cray 1. In 1980, we had an intensive calculation program that took 1 to 2 hours on the IBM mainframe we had. We contracted with a service firm to use a Cray 1. I flew out to Kansas City to a clients office and told him that the Cray was so fast "the results would return before I could release the submit key". Of course no results returned so I submitted it a few more times. Still no results, so I flew back to New York to find that each submission of the program timed-out at one hour of computing time - each at a cost of $8,000 per hour. Man I was sweating those charges.

I lucked out - they had updated the fortran compiler and it had a bug in it which caused every program to run forever - or at least until they timed out. So we got the charges reversed.

I learned a very valuble lesson - make sure the time out is set approprately for the estimated computing time.

Side note: this program took 1-2 hours on IBM main frame, 5-6 seconds on Cray in 1980, and less than 5 minutes on todays PCs.

Bill

                              
Re: RPN...
Message #30 Posted by Paul Dale on 2 Mar 2012, 8:44 p.m.,
in response to message #29 by Bill (Smithville, NJ)

Quote:
Side note: this program took 1-2 hours on IBM main frame, 5-6 seconds on Cray in 1980, and less than 5 minutes on todays PCs.

This doesn't sound right. Modern PCs are *much* faster than a 1980's Cray. Much much faster.

- Pauli

                                    
Re: RPN...
Message #31 Posted by Bill (Smithville, NJ) on 2 Mar 2012, 9:52 p.m.,
in response to message #30 by Paul Dale

Quote:
Modern PCs are *much* faster than a 1980's Cray

You're probaly right - but it would all depend on the code being executed.

I haven't run this out-dated code for sometime. The code wasn't very efficient - was overlayed like crazy and sort of pages itself to death. Originally was designed to run in 256K of memory on the IBM mainframe. It had all sorts of memory saving methods including overlaying two interger variables on top of a real vaiable. As long as both were not required at same time, it worked. The overlaying of modules made sure that the same common variable storage area could be re-used in various ways. I remember putting in dummy variables so that the common blocks would line up correctly. I seem to remember they had to start on an even address. Otherwise you could get the second half of one variable combined with the first half of another. I spent many sleepless nights tracing down problems with overlayed variables.

The last time I tested it on a PC was a few years ago and it took a little less than 5 minutes. I ran it on a PC just to see if it would run, not to actualy use. The verison was the overlayed version from the IBM. I should pull a copy out and see how much faster it is on my current PC. But really not worth it.

I do remember that we spent some time optimizing it for the Cray to take advantage of array vector arithmetic that it offered. Something my fortran compiler for the PC doesn't have. And we unrolled some of the overlaying of modules and variables. So that may be some of the speed difference.

Bill

                                          
Re: RPN...
Message #32 Posted by Paul Dale on 2 Mar 2012, 10:13 p.m.,
in response to message #31 by Bill (Smithville, NJ)

That kind of fine tuning really shouldn't matter much. The Cray 1 was circa 80 megaflop fully vectorised. Let's call it 100 to keep the numbers simple. This is amazing compared to the microcomputers of the time (circa 1 - 4 MHz, small integer only).

However, a modern PC is pulling 1 - 2 gigaflops without any parallel optimisations. It's arithmetic unit is generally fully pipelined which is basically as good as vectorised if the data is in registers or L1 cache. The relatively small memory footprint means everything will be in L1 or L2 cache on most modern processors which will avoid the huge stall to DRAM times. The dual use of memory could impact things, but it seems unlikely.

In other words, a modern PC should be at least five to ten times faster without trying and a lot more if you do.

Hardware advances are simply astounding and quite amazing :-)

Sadly, I never got to play with a Cray 1, I did get some time on a CDC Cyber 205 which was comparable.

- Pauli

                                                
Re: RPN...
Message #33 Posted by Bill (Smithville, NJ) on 3 Mar 2012, 9:22 a.m.,
in response to message #32 by Paul Dale

Quote:
In other words, a modern PC should be at least five to ten times faster without trying and a lot more if you do.

The CPU should be faster, but not necessarily the total process. As I mentioned, the PC version was the old IBM version which was overlayed with lots of read/writes to disk and runs in 256K of memory. The Cray version was non-overlayed with everything in memory. I don't have the source any more for the Cray version. I'm sure if I did away with the overlays and did everything in memory, the PC version would be faster. The speed of the disk drives and the overhead of overlaying becomes more of a factor than the cpu speed.

Bill

                                                
Re: RPN...
Message #34 Posted by Raymond Wiker on 3 Mar 2012, 10:26 a.m.,
in response to message #32 by Paul Dale

The Cray-1A has been reincarnated in FPGA: http://chrisfenton.com/homebrew-cray-1a/

I'm amazed at all the neat stuff that can be done (and has been done) using FPGAs.

                                                
Re: RPN...
Message #35 Posted by Bill (Smithville, NJ) on 3 Mar 2012, 12:41 p.m.,
in response to message #32 by Paul Dale

Quote:
Sadly, I never got to play with a Cray 1, I did get some time on a CDC Cyber 205 which was comparable

Never got to use a Cyber 205, but grew up on a CDC 6600 at Indiana University.

Submitting jobs to the Cray was interesting. We used a CDC 7600 to prepare the data and then submitted it to the Cray. There was a word size and character set difference between the two machines, so there was a program that translated the character set, submitted to the Cray and then trapped the return output so it could translate the character set back to a readable form on the CDC 7600. Kinda of Time Share, batch, and then back to time share.

Bill

                              
Re: RPN...
Message #36 Posted by Palmer O. Hanson, Jr. on 2 Mar 2012, 9:55 p.m.,
in response to message #29 by Bill (Smithville, NJ)

Quote:
I learned a very valuble lesson - make sure the time out is set approprately for the estimated computing time.
I had a similar experience back in the 1970's with one of my first programs on a Sigma-5. I had submitted the cards about 11 PM and my program ran until the next morning. The charge for the run time would have been many thousands of dollars. I was saved because I was a student. The system supposedly had a capability and responsibility to monitor the operation of student programs for problems like that. Whew!
                                    
Re: RPN...
Message #37 Posted by Bill (Smithville, NJ) on 3 Mar 2012, 9:31 a.m.,
in response to message #36 by Palmer O. Hanson, Jr.

Quote:
The charge for the run time...

Got me thinking about how they used to charge for computer use. There was a price for total time, price for amount of memory used, price for number of characters printed, price for number of cards read, etc, etc. It was really amazing on how detailed they could get in their pricing.

Depending on how they charged, I can remember modifing programs so they would use more total time, but less memory, or vice versa, depending on which was more expensive. If it was a production program that was run a lot, then any savings was usually worth it.

Bill


[ Return to Index | Top of Index ]

Go back to the main exhibit hall