Help with RPN programming

[hpnut]

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

[Les Bell]

LBL A

1

LBL 00

PSE

1

+

GTO 00

That should do it.

Best,

--- Les

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

[Kerem Kapkin (Silicon Valley, CA)]

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.

[C.Ret]

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.

[Garth Wilson]

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).

[C.Ret]

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 !

[Mark Storkamp]

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.

[Garth Wilson]

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.

[Howard Owen]

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.

[Kerem Kapkin (Silicon Valley, CA)]

Oppps! :) Thanks for the catch!

[Crawl]

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".

[Gerson W. Barbosa]

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

[Reth]

HP41:

LBL 'X

1

ENTER

ENTER

ENTER

LBL 00

VIEW X

+

GTO 00

END

[Paul Dale]

For the 34S:

001: LBL'[infinity]'

002: 1

003: VIEW X

004: INC X

005: BACK 002

- Pauli

[hpnut]

thanks! you guys are great :-)

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

[Thomas Klemm]

You might want to try the following:

CLEAR PRGM

001- RCL 0

002- PSE

003- ISG 0

CLEAR REG

R/S

Regards

Thomas

[Paul Dale]

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

- Pauli

[Patrice]

To drain batteries, remove the PSE

[Thomas Klemm]

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

001- ISG 0

[Marcus von Cube, Germany]

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.

[C.Ret]

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.

[Paul Dale]

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

[Tom Grydeland]

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

[Paul Dale]

Try WSIZE of 2 then :-)

Of course it wraps around and keeps counting.

- Pauli

[Reth]

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.

[Kerem Kapkin (Silicon Valley, CA)]

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.

[Reth]

Yea, except in poetry, I should say :)

[Kiyoshi Akima]

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 ;-)

[Bill (Smithville, NJ)]

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

[Paul Dale]

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

[Bill (Smithville, NJ)]

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

[Paul Dale]

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

[Bill (Smithville, NJ)]

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

[Raymond Wiker]

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.

[Bill (Smithville, NJ)]

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

[Palmer O. Hanson, Jr.]

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!

[Bill (Smithville, NJ)]

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