▼
Posts: 8
Threads: 2
Joined: Jan 1970
Circumference, Area or Diameter Program for the hp42s
Was wondering if anyone can come up with a more elegant or shorter program to work out any of the unknowns when one is given. This works fine, I enter the value and use the RS key to view the unknowns.
I’m not that experienced in writing programs and I’m sure someone can probably make it a little shorter or, has a better way to write it to save on memory.
Thanks
Tom
00 160 {byte Prgm}
01 LBL "CAD
02 SF 21
03 CLMENU
04 "DIA"
05 KEY1 XEQ 01
06 "AREA"
07 KEY2 XEQ 02
08 "CIRC"
09 KEY3 XEQ 03
10 MENU
11 STOP
12 LBL 01
13 STO "DIA"
14 x2
15 PI
16 X
17 4
18 /
19 STO "AREA"
20 RCL "DIA"
21 PI
22 X
23 STO "CIRC"
24 VIEW "AREA"
25 VIEW "CIRC"
26 RTN
27 LBL 02
28 STO "AREA"
29 4
30 X
31 PI
32 /
33 SQRT
34 STO "DIA"
35 PI
36 X
37 STO "CIRC"
38 VIEW "DIA"
39 VIEW "CIRC"
40 RTN
41 LBL 03
42 STO "CIRC"
43 PI
44 /
45 STO "DIA"
46 x2
47 PI
48 X
49 4
50 /
51 STO "AREA"
52 VIEW "DIA"
53 VIEW "AREA"
54 RTN
55 END
1234 to delete
▼
Posts: 237
Threads: 20
Joined: Mar 2006
Tom,
I looked over your program and saw you are using PI and 4 in several location. I modified your program to put PI and 4 in storage registers 01 and 02. Then when the program called for the either number I did a RCL*01 when I wanted to multiply by PI or RCL/02 when I wanted to divide by 4 and so on. I found this works well when you are using the same numbers in a calculation and only the input numbers change. The one command does 2 functions, it recalls the number that you have stored and does the arithmetic operation all in 1 step. In the case of your program it increased the byte count by 9, but reduced your steps by 5.
Posts: 614
Threads: 66
Joined: Jul 2006
Hi Tom,
Great to see some HP42S programs. I'm afraid I didn't shorten or save on memory, but did try to add a few twists to your program.
00 165Byte Prgm
01 LBL “CAD”
02 LBL 00
03 CLMENU
04 “DIA”
05 KEY 1 XEQ 01
06 “RAD”
07 KEY 2 XED 02
08 “AREA”
09 KEY 3 XEQ 03
10 “CIRC”
11 KEY 4 XEQ 04
12 “PRT”
13 FS? 99
14  “#” NOTE: THE # IS THE ‘SQUARE’ SYMBOL
15 KEY 6 GTO 06
16 MENU
17 STOP
18 GTO 00
19 LBL 01
20 ENTER
21 ENTER
22 ENTER
23 PI
24 X
25 X<>Y
26 RCLX ST Y
27 4
28 /
29 LBL 07
30 “DIA=”
31 ARCL ST Z
32 FS? 99
33 AVIEW
34 “CIRC=”
35 ARCL ST Y
36  “LFAREA=” NOTE: LF IS LINE FEED CHARACTER
37 ARCL ST X
38 FS? 99
39  “LF”
40 AVIEW
41 RTN
42 LBL 02
43 2
44 X
45 GTO 01
46 LBL 03
47 ENTER
48 4
49 X
50 PI
51 /
52 SQRT
53 STO ST Z
54 PI
55 X
56 X<>Y
57 GTO 07
58 LBL 04
59 ENTER
60 ENTER
61 PI
62 /
63 X<>Y
64 ENTER
65 RCLX ST Z
66 4
67 /
68 GTO 07
69 LBL 06
70 FC? 99
71 GTO 08
72 CF 99
73 PROFF
74 GTO 00
75 LBL 08
76 SF 99
77 PRON
78 GTO 00
79 .END.
While the total number of lines is longer (79 versus 55) the actual amount of memory is only a little larger (165 bytes vs 160).
Flag 99 is used to determine if the printer is on or off. Pressing Key 6 will toggle the printer on/off.
If printer is on, then DIA, CIRC and Area is printed. The display will show two lines  Circ and Area. Probally should change display sequence to show the two missing items based on which one is entered. For example, enter Dia, then have display show Circ and area. If Area is entered, then have display show Dia and Circ.
I didn't save any of the input/output. So you would need to add STO as required.
Hope this helps. And keep posting HP42S programs!!
Bill
12345
▼
Posts: 8
Threads: 2
Joined: Jan 1970
Thanks to Richard and Bill for your input, I will input your program and have a play and see how it works.
If anyone else out there has any custom written 42s programs, post them so we (me)all can see and learn how to program a little better.
Tom
1234
▼
Posts: 7
Threads: 0
Joined: Jan 1970
Hi Tom (and all),
Well, since you ask, here's one of mine. Sadly (I suppose) this is no longer in everyday use.
My 42s programs are all to do with archaeological surveying, a specialized kind of surveying where truetoscale drawings are made in the field. Before we "really" computerized, the 42s facilitated many innovations in my work, mostly to do with setting up the station. Nevertheless, a far more simple program (mathematically) was one that I was most pleased with. I called it "ITFOS" which stands of "If Traverse Falls Off Sheet".
Most of my work was done by placing pairs of surveyor's arrows at either end of "user friendly" measuring lines that would be used to draw the details of our site. Having surveyed the arrows, two (x,y) coordinate pairs would define each line on our global grid. These would be plotted manually on drafting film placed over graph paper. If both points were not on the same planning field sheet, it was impossible to know in which direction it went from just one point on one sheet. "ITFOS" solved the problem in a very satisfying way.
Alpha messages bump up the byte count and variables attempt to be totally descriptive so they are longer than would strictly be necessary. An extra feature was added later called "?DIST". This calculates the horizontal distance between the two points (using another program called "PYTH") which served both as a "check" on the ground when the measuring line was set up and on the plotted points on the drawing. If the actual measured distance between the points was not the same as the "calculated" distance, then some error had been made. I found I always used the program even when both ends of a line actually fell on the same sheet. It was easy to find where the line crossed (handy, round) gridline numbers and little ticks would be made at these points. If the plotted end points and the little ticks didn't all fall exactly on a straight line, then, again, error was detected. (Surveying has "zerotolerance" for error!)
Three of the "variables" also ask questions. If I wanted to find where the measuring line crossed the x=455 line (455 m East), then I would enter 455 in the "@x=?" menu variable. One "trick" was that I knew I must then also place a zero in the "@y=?" variable which would deactivate it. Similarly the "?DIST" requires a zero if I didn't want a distance to be calculated or a one (or any other number) if I did. If I really did want to find where a line crossed the x or y equals zero lines (which was never) I would have entered an infinitessimal value in one, zero in the other.
Again, this problem is mathematically elemental but it demonstrates how "user friendly" the 42s can be. (All of my programs were used fairly successfully by archaeology students who were frequently not particularly comfortable with numbers!) Note that the variable names use parentheses, spaces, @ and = which help make them "user friendly" but these characters are illegal on the 48 series. Also, that it works best with values less than 1000 and the display set to FIX 02.
I'm sure a few of you 42s "partizans" will enjoy this...and it might even have some more general usefulness than in my odd field.
Richard (in Athens...enjoying the Olympics!)
00 (232Byte Prgm)
01 LBL "ITFOS"
02 MVAR "x (A)"
03 MVAR "y (A)"
04 MVAR "x (B)"
05 MVAR "y (B)"
06 MVAR "@x=?"
07 MVAR "@y=?"
08 MVAR "?Dist"
09 VARMENU "ITFOS"
10 "Enter Line/Int."
11 (append) "Info."
12 PROMPT
13 EXITALL
14 RCL "?Dist"
15 x>0?
16 XEQ "PYTH"
17 "Trav. intersect"
18 RCL "x (A)"
19 STO 00
20 RCL "x (B)"
21 RCL "y (A)"
22 STO 01
23 RCL "y (B)"
24 (convert)POL
25 (roll down)
26 TAN
27 STO 02
28 RCL "@x=?"
29 STO 03
30 X (does not =) 0?
31 GTO A
32 RCL "@y=?"
33 STO 03
34 RCL 01
35 
36 RCL 02
37 x
38 RCL 00
39 (divide)
40 (append)"s (y)= "
41 GTO B
42 LBL A
43 RCL 00
44 
45 RCL 02
46 (divide)
47 RCL 01
48 +
49 (append) "s (x)= "
50 LBL B
51 RCL 03
52 ARCL ST X
53 (append)" line @ "
54 X (swap) Y
55 ARCL ST X
56 PROMPT
57 GTO "ITFOS"
58 END
00 (82Byte Prgm)
01 LBL "PYTH" (for Pythagorean theorem)
02 RCL "x (A)"
03 RCL "x (B)"
04 (square)
05 RCL "y (A)"
06 RCL "y (B)"
07 (square)
08 +
09 SQRT
10 "H.Dist.between"
11 (append) " A & B ="
12 PROMPT
13 0
14 STO "?Dist"
15 GTO "ITFOS"
16 END
▼
Posts: 7
Threads: 0
Joined: Jan 1970
The program is linebyline on the reply form right now...and I think it was before. This time I'll preview it.
Nope, it's the same. (2nd try) Now I've put another "enter" between each line.
Richard
00 (232Byte Prgm)
01 LBL "ITFOS"
02 MVAR "x (A)"
03 MVAR "y (A)"
04 MVAR "x (B)"
05 MVAR "y (B)"
06 MVAR "@x=?"
07 MVAR "@y=?"
08 MVAR "?Dist"
09 VARMENU "ITFOS"
10 "Enter Line/Int."
11 (append) "Info."
12 PROMPT
13 EXITALL
14 RCL "?Dist"
15 x>0?
16 XEQ "PYTH"
17 "Trav. intersect"
18 RCL "x (A)"
19 STO 00
20 RCL "x (B)"
21 RCL "y (A)"
22 STO 01
23 RCL "y (B)"
24 (convert)POL
25 (roll down)
26 TAN
27 STO 02
28 RCL "@x=?"
29 STO 03
30 X (does not =) 0?
31 GTO A
32 RCL "@y=?"
33 STO 03
34 RCL 01
35 
36 RCL 02
37 x
38 RCL 00
39 (divide)
40 (append)"s (y)= "
41 GTO B
42 LBL A
43 RCL 00
44 
45 RCL 02
46 (divide)
47 RCL 01
48 +
49 (append) "s (x)= "
50 LBL B
51 RCL 03
52 ARCL ST X
53 (append)" line @ "
54 X (swap) Y
55 ARCL ST X
56 PROMPT
57 GTO "ITFOS"
58 END
00 (82Byte Prgm)
01 LBL "PYTH" (for Pythagorean theorem)
02 RCL "x (A)"
03 RCL "x (B)"
04 (square)
05 RCL "y (A)"
06 RCL "y (B)"
07 (square)
08 +
09 SQRT
10 "H.Dist.between"
11 (append) " A & B ="
12 PROMPT
13 0
14 STO "?Dist"
15 GTO "ITFOS"
16 END
Edited: 20 Aug 2004, 7:40 a.m. after one or more responses were posted
▼
Posts: 614
Threads: 66
Joined: Jul 2006
Richard,
To keep formating exactly as you've written, put [ pre ] at start and [/pre] at end. Works great for program listing. There's other formating codes that can also be used. See following article:
http://www.hpmuseum.org/artfmt.htm
Just be carefull with [ pre ] and [/pre]  if you enter really long lines without carriage returns, then the reader will have to scroll the message to the right to read them.
Thanks again for posting your program.
Bill
Posts: 614
Threads: 66
Joined: Jul 2006
Hi Richard,
Thanks for posting your program. Hope you don't mind  I took the opportunity to reformat it and replaced some of the lines with the usual symbols (  for append, etc).
I have already learned something from your program  I never knew that names of storage registers could have spaces in them. I just always assumed that wouldn't work. Just tested it and no problem with spaces in names.
When I get time I'll enter your program and play around with it. I'm always on the hunt for HP42s specific programs.
I've been working on a psychrometric calculator program for single and mixed air streams. Have about half of it writen but have gotten distracted from it with work load. If I ever finish it, I'll post it.
"(in Athens...enjoying the Olympics!)"
Oh man  rub it in :) You must be having a great time.
Bill
Your program reformated:
00 (232Byte Prgm)
01 LBL "ITFOS"
02 MVAR "x (A)"
03 MVAR "y (A)"
04 MVAR "x (B)"
05 MVAR "y (B)"
06 MVAR "@x=?"
07 MVAR "@y=?"
08 MVAR "?Dist"
09 VARMENU "ITFOS"
10 "Enter Line/Int."
11  "Info."
12 PROMPT
13 EXITALL
14 RCL "?Dist"
15 x>0?
16 XEQ "PYTH"
17 "Trav. intersect"
18 RCL "x (A)"
19 STO 00
20 RCL "x (B)"
21 RCL "y (A)"
22 STO 01
23 RCL "y (B)"
24 >POL
25 RDN
26 TAN
27 STO 02
28 RCL "@x=?"
29 STO 03
30 X #= 0?
31 GTO A
32 RCL "@y=?"
33 STO 03
34 RCL 01
35 –
36 RCL 02
37 x
38 RCL 00
39 /
40  "s (y)= "
41 GTO B
42 LBL A
43 RCL 00
44 –
45 RCL 02
46 /
47 RCL 01
48 +
49  "s (x)= "
50 LBL B
51 RCL 03
52 ARCL ST X
53  " line @ "
54 X<>Y
55 ARCL ST X
56 PROMPT
57 GTO "ITFOS"
58 END
00 (82Byte Prgm)
01 LBL "PYTH" (for Pythagorean theorem)
02 RCL "x (A)"
03 RCL "x (B)"
04 X^2
05 RCL "y (A)"
06 RCL "y (B)"
07 X^2
08 +
09 SQRT
10 "H.Dist.between"
11  " A & B ="
12 PROMPT
13 0
14 STO "?Dist"
15 GTO "ITFOS"
16 END
▼
Posts: 7
Threads: 0
Joined: Jan 1970
Many thanks, Bill, for the formatting tip. Because I didn't think I would ever be an "advanced article formatting" kinda guy, I had never checked it out. It all shows what a great site this is!
Going through my 42s hard copy program file, I found another program that could be of interest to anybody and I think is fun. It finds simple (or common or "vulgar") fractional equivalents of decimal fractions. Again, it showcases the menu system and the nature of the solution is perfect for the twoline display. My approach to the problem could doubtless be more sophisticated so it can be a bit slow. Still, I find watching it work is rather satisfying...as long as it comes up with a result before too long!
The decimal fraction is placed in variable DecF and whatever variation from the "exact" equivalent that might be allowed is placed in Var. (I normally divide the DecF value by 5000, a useful "surveyor's" sort of accuracy...but you can have a higher or lower precision.) Then, starting "guessed" numerator and denominator values (normally both 1) are entered in the NUM and DEN variables.
The math is elemental. DecF x DEN = NUM ± Var and if DECF < NUM/DEN, then DEN is incremented by one. If DECF > NUM/DEN, then NUM is incremented by one. The result is expressed as a fraction using the two registers with the "inaccuracy" showing as a decimal part of the numerator. The whole numbers are stored in NUM and DEN.
It is interesting to find what small integers can sometimes express manyplaced decimal fractions though it doesn't always work. I just keyed (at random) 0.1245879 with VAR = 0.1245879/5000, and it took the calculator about 95 seconds to come up with 36/289. Anyway, I find it interesting. It has a "real" application for me in trying to find proportional relationships in historic architecture.
42s Rules!
Richard (who played a big part in helping OZ nearly win the Olympic Baseball!)
00 { 145Byte Prgm }
01 LBL "SFRAC"
02 MVAR "NUM"
03 MVAR "DEN"
04 MVAR "DecF"
05 MVAR "Var"
06 VARMENU "SFRAC"
07 "Enter Starting "
08 (append) "data"
09 PROMPT
10 EXITALL
11 CF 01
12 RCL "DecF"
13 STO 00
14 RCL "DEN"
15 STO 01
16 RCL "NUM"
17 STO 02
18 RCL "Var"
19 STO 03
20 LBL A
21 RCL 02
22 RCL 01
23 ÷
24 RCL 00
24 X<Y?
26 SF 01
27 
28 X<0?
29 +/
30 RCL 03
31 
32 X(<or=)0?
33 GTO C
34 FS?C 01
35 GTO B
36 1
37 STO+ 02
38 GTO A
39 LBL B
40 1
41 STO+ 01
42 GTO A
43 LBL C
44 RCL 02
45 STO "NUM"
46 RCL 00
47 RCL 01
48 x
49 RCL 01
50 STO "DEN"
51 END
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Richard:
Have a look at this. I think you'll find it pretty
interesting, easy to implement, and will enjoy trying it up with your 42S.
Best regards from V.
▼
Posts: 7
Threads: 0
Joined: Jan 1970
Hi Valentin,
That's an interesting site. With my little program, I once "discovered" what I learned later was the Fibonacci Sequence. I observed that as I tightened up my "Var" while looking for "golden section" fractions, the numerator of one fraction reappeared as the denominator of the next, and each successive numerator was the sum of the previous two. Great Moments in Mathematics and me! 1/1, 2/1, 3/2, 5/3, 8/5, 13/8, 21/13, 34/21....it was brilliant!
Thanks and best regards,
Richard
Edited: 28 Aug 2004, 8:24 a.m.
Posts: 170
Threads: 24
Joined: Jan 1970
For an application of continued fractions on the HP42S, see
my implementation of QPI.
Best regards,
Erik Ehrling (Sweden)
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi;
this is a little suggestion and I'd like to 'say' a few words about it.
I thought about writing an article mostly related to automatic register stack (RPN calculators) and memory usage (regular numbered registers and variables) while programming and directly using the calculator, but I thought this sort of subject is no longer an issue. Maybe I'm wrong.
When designing calculators in the 70's, designers should deal with expensive RAM circuits, lots of HW resources and control/arithmetic SW development. RPN was, at that time, THE designers solution at the same time it created a new way to develop applications. I still take RPN, and also RPL, as great achievements and powerful tools, but I also like them, so I am not a 'neutral' reference. Today a lot of things have changed: RAM cost is no longer an issue and it is easier ($) to develop the best multipurpose processor and stuff it in with dedicated SW. Powerful, fast and efficient 'gadgets' are available with a lowcost production. Efficient programming with low memory resources is something like 'state of the art' programming, and I 'feel' as if there is no more space for this sort of development, only when locally required. Some industrial, multipurpose controllers still offer the HW environment, but the use of highlevel languages instead of binary, mnemonicbased development simply enhance productivity, allows nonsystem programmers to develop systemrelated applications and... lead to bigger codes. Well, RAM enough for any taste!
Back to calculators: extensive stack manipulation while programming may result in efficient, small and fast programs, but as many contributors discussed in this very forum, RPN/RPL may not be the first choice in many circumstances, but writing programs with these "languages" allow us all to face some teasing tasks like shortening a program.
No further ado: my suggestion is listed below. (consider LineFeed as ALPHA [^{L}_{F}] single character, please)
00 { 127Byte Prgm }
01•LBL "CAD"
02 SF 21
03 CF 00
04 CF 01
05 CLMENU
06 "DIA"
07 KEY 1 GTO 01
08 "AREA"
09 KEY 2 GTO 02
10 "CIRC"
11 KEY 3 GTO 03
12 MENU
13 STOP
14•LBL 01
15 ENTER
16 STO 00
17 PI
18 ×
19 STO 01
20 ×
21 4
22 ÷
23 STO 02
24 CLA
25 GTO 04
26•LBL 02
27 STO 01
28 4
29 ×
30 PI
31 ÷
32 SQRT
33 STO 00
34 PI
35 ×
36 STO 02
37 SF 00
38 GTO 00
39•LBL 03
40 ENTER
41 STO 02
42 PI
43 ÷
44 STO 00
45 ×
46 4
47 ÷
48 STO 01
49 SF 01
50•LBL 00
51 "DIA="
52 ARCL 00
53 "LineFeed"
54•LBL 04
55 FC? 00
56 "AREA="
57 FC?C 00
58 ARCL 01
59 FC? 01
60 "LineFeedCIRC="
61 FC?C 01
62 ARCL 02
63 AVIEW
64 END
The 'regular' HP42S has 8KBytes RAM, and many 'custom' models have either 32KBytes or 64KBytes, but it is hard to find a way to fill them all with program lines... Also, any Memory Lost would lead to painful 'reload'... Anyway, in any case, memory is not endless, so 'shrinking' programs is not only fun, but RAM saving. Well, as it can be seen, all ''variables' where removed and numbered registers are used. If there is a need to keep variables, all lines from LBL 00 must be rewritten. Yes, I know that numbered registers lack a better reference for their contents, while variables may have their names 'declaring' their contents. I still believe programmers must keep track of their programs as a whole, but when code is too long it becomes more and more complicated to do so. In this case, variables help a lot keeping track... for as long as we have available RAM.
Hope it helps illustrating other alternatives. Please, add comments and suggestions as well.
Cheers.
Luiz (Brazil)
Edited: 18 Aug 2004, 8:49 a.m.
▼
Posts: 614
Threads: 66
Joined: Jul 2006
Hi Luiz,
I've been waiting for your post on this. I always enjoy your comments.
I agree that with today's fast equipment and the large ram envirnment, there's really no reason for programmers to worry about efficiencies or program size. But I feel that this leads many a programmer to write very sloppy code ridded with either errors or unusual side effects. They just grab any available algorithm and throw it together.
One great side effect in writing code for small machines with limited resources  I was forced into reviewing various agorithms to determine witch was best for the application and machine. Since there wasn't much ram, I couldn't afford to have inefficiencies in the code.
Like you, I much prefer using numbered register in programs in lieu of alpha type registers. If the HP42S had a layered directory for variables, I'd probally use Alpha Variables more often.
As usual, your post has caused me to relook at my programs (:  which is a very good thing.
In the program I'd posed earlier, Key 06 toggled the prinnter onoff. I'd used the following routine:
69 LBL 06
70 FC? 99
71 GTO 08
72 CF 99
73 PROFF
74 GTO 00
75 LBL 08
76 SF 99
77 PRON
78 GTO 00
79 .END.
I kept thinking there had to be a better way, without the extra GTO and Label. I came up with the following:
69 LBL 06
70 PROFF
71 FC? 99
72 PRON
73 CF 99
74 FS? 21
75 SF 99
76 GTO 00
77 .END.
A little cleaner, but there still should be a better way of doing this. I could probally change line 71 to FC?C 99 and then delete line 73 (CF 99). Just tested it and clearing flag while testing does work. So I'm a step smaller.
Thanks again Luiz for motivating me to take a relook.
Bill
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi, Bill;
thank you for your always welcome and wise comments. I appreciate that! ;)
Quote: I agree that with today's fast equipment and the large ram envirnment, there's really no reason for programmers to worry about efficiencies or program size. But I feel that this leads many a programmer to write very sloppy code ridded with either errors or unusual side effects. They just grab any available algorithm and throw it together.
I see this way as well.
Something to be noticed, back to your HP42S listings: although your program uses some extra steps and only 5 extra bytes RAM, you use no registers at all, only stack registers. So, no extra bytes holding data, meaning the 165 bytes are the amount of memory needed to run it. Even if mine is 127 bytes long, it uses three numbered registers, i.e., 28 extra bytes (not counting the default amount of memory used to hold the REGS matrix itself). And if I decide to use the stack only, my output routines (LBL 00 and LBL 04) must be heavily changed.
Quote: If the HP42S had a layered directory for variables, I'd probably use Alpha Variables more often.
That would indeed save RAM in programs when accessing variables. You see, what most calls my attention when using and/or programming an HP42S is the overall harmony. I like using different HP models for some specific jobs, like the HP15C for fast calculations and some complexnumber crunching (I cannot help thinking it is a damn good looking piece of technology...), any RPL for extensive, indeep research (I wrote a few routines in an HP49G for neural net learning when achieving my EE master degree; my teacher could not believe on what he was seeing), the HP41 with IL for basic RPN development, but the HP42S lacks only the I/O input and builtin units conversion. I like very much writing programs for the HP42S because almost everything you need is there as an easytouse, builtin resource: complex mode, matrix operations, SOLVE and INTEG, 'variables' (custom) MENU, ALPHA and graphics display... and some 'hacking' possibilities (mine is 32KBytes RAM). What else do you need?
You see, I always "print" my HP42S listings and output data to an HP48 running inprt for later documentation. You should try running a troubled program with TRACE mode ON this way... simply revealing! Although batteries will not rest longer than in normal use, debugging is actually easier. You'll see everything that happened in your program printed from your favorite word processor or directly in an HP48 larger screen. Affordable, at least, and no thermal paper consuming.
I know many guys are trying to bring the HP15C back to production, and I support them in every way I can, but if I'm asked to choose between the HP15C and the HP42S, I'd rather trying to bring back an HP42S. Almost each addon resource some guys want to be available in the newer 'brought back' HP15C is already available in the HP42S.
A great calculator, indeed. Except for the lack in I/O capabilities, it is the best of many worlds in one single package.
Cheers and thanks again, Bill. Please, forgive me! I cannot help writing too many words when talking about some good stuff...
Luiz (Brazil)
Edited: 19 Aug 2004, 1:47 a.m.
▼
Posts: 614
Threads: 66
Joined: Jul 2006
Hello Luiz,
Quote:
______________
You see, what most calls my attention when using and/or programming an HP42S is the overall harmony ................ I like very much writing programs for the HP42S because almost everything you need is there as an easytouse, builtin resource: complex mode, matrix operations, SOLVE and INTEG, 'variables' (custom) MENU, ALPHA and graphics display... and some 'hacking' possibilities (mine is 32KBytes RAM). What else do you need?
____________________
Very well put  I couldn't have expressed it any better. 'Harmony' is a great way to say it.
I agree with you that the 42S would be a better calculator to 'bring back' than the 15C. Although I have several 15C's (and five 42S), I alternate between the 11C and the 42S. The 11C gives me all the basic calculating I need for most 'on the fly' tasks and fits my shirt pocket. The 42s is used for more complicated tasks and for programming. The few times I require complex, matrices, solver and integration, I would rather use the 42S with it's easier inputting and displaying than a 15C for these tasks  plus it's faster.
Unfortunatelly, I'm too much of a realist to ever believe that any manufacturer will bring back a 20 year old product. And I'm not sure I would really want them to  the few times I've seen it done, it's usually a disaster.
I'd much rather see the development of good emulators that can run on Windows, Palm, and PocketPC. At least then, I know I'll hae a true emulation of the product I love and not a halfbaked rework by a manufacturer who really doesn't care about it anymore. That's why I fully support Erik's HP42S campaign.
I like your idea of printing to a HP48 for debug purposes. Unfortunatelly, I recently sold all the 48's I had. I never could adjust to the RPL way of doing things. I had bought one when they were first introduced, couldn't tolerate the original low contrast display and sold it. When the new higher contrast dispay came out, I picked up another one. Much better  but still couldn't adjust to RPL for programming. It was too much like writing programs for the PC. Part of the joy of creating programs in RPN is the elegance of the programming.
Before getting rid of the 48's, I did use them to dump the HP42S ROMS, so I'm all ready for the Emulator once it arrives.
Back to RPN programs and creating short programs. I find that reviewing the programs in the earlier HP application guides is a great way to learn creative RPN programming. The HP25 application book is a great one. It's really amazing how many different, fairly complicated programs, can be done in only 49 steps. The earliy HP application books also give good descriptions of the formulas and algorithms.
Just noticed the time  better get back to work!!
Bill
▼
Posts: 785
Threads: 13
Joined: Jan 2005
Hi, Bill!
You prefer either 11C or 42S...
Do you have any HP calculator "missing"?
I may want to exchange, say, a HP32SII
(with a good decimal point and none of the 33s bugs)
for one (any) of your 15C
[VPN]
▼
Posts: 614
Threads: 66
Joined: Jul 2006
Hi VPN,
Sorry  I think I'll hang onto the 15C's. I worked too long to aquire them. I had never even seen one till last year and then got lucky with several trades and was finally able to aquire them.
I had a 32SII for a while, but finally sold it earlier this year. I loved the display, but found it too limiting when comapared to the 42S.
Bill
