HP Forums
Help with RPN programming - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: Help with RPN programming (/thread-213045.html)



Help with RPN programming - hpnut - 03-01-2012

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 - Les Bell - 03-01-2012

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 - Kerem Kapkin (Silicon Valley, CA) - 03-01-2012

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 - Gerson W. Barbosa - 03-01-2012

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 - Reth - 03-01-2012

HP41:

LBL 'X

1

ENTER

ENTER

ENTER

LBL 00

VIEW X

+

GTO 00

END



Re: Help with RPN programming - Paul Dale - 03-01-2012

For the 34S:

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


- Pauli


Re: Help with RPN programming - hpnut - 03-01-2012

thanks! you guys are great :-)

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


Re: Help with RPN programming - Thomas Klemm - 03-02-2012

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 - Paul Dale - 03-02-2012

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


- Pauli


Re: Help with RPN programming - Patrice - 03-02-2012

To drain batteries, remove the PSE


Re: Help with RPN programming - Thomas Klemm - 03-02-2012

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 - C.Ret - 03-02-2012

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 - Marcus von Cube, Germany - 03-02-2012

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: Help with RPN programming - Garth Wilson - 03-02-2012

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 - C.Ret - 03-02-2012

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: RPN programming little challenge help - C.Ret - 03-02-2012

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: Help with RPN programming - Mark Storkamp - 03-02-2012

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 - Garth Wilson - 03-02-2012

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 - Kerem Kapkin (Silicon Valley, CA) - 03-02-2012

Oppps! :) Thanks for the catch!


RPN... - Reth - 03-02-2012

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... - Kerem Kapkin (Silicon Valley, CA) - 03-02-2012

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: Help with RPN programming - Howard Owen - 03-02-2012

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 - Crawl - 03-02-2012

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: RPN... - Kiyoshi Akima - 03-02-2012

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 programming little challenge help - Paul Dale - 03-02-2012

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... - Bill (Smithville, NJ) - 03-02-2012

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... - Reth - 03-02-2012

Yea, except in poetry, I should say :)


Re: RPN... - Paul Dale - 03-02-2012

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... - Bill (Smithville, NJ) - 03-02-2012

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... - Palmer O. Hanson, Jr. - 03-02-2012

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... - Paul Dale - 03-02-2012

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... - Bill (Smithville, NJ) - 03-03-2012

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... - Bill (Smithville, NJ) - 03-03-2012

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


Re: RPN... - Raymond Wiker - 03-03-2012

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... - Bill (Smithville, NJ) - 03-03-2012

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 programming little challenge help - Tom Grydeland - 03-05-2012

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


Re: RPN programming little challenge help - Paul Dale - 03-05-2012

Try WSIZE of 2 then :-)

Of course it wraps around and keeps counting.


- Pauli