Conversion Routine

[SlideRule]

In his three volume publication of Structural Programs for the HP67 programmable calculator, W. L. Ashley (PE) includes a program for FEET-INCHES-SIXTEENTHS arithmetic with a 77 line routine for conversion to (LBL B) and from (LBL A) FEET-DecimalFeet and FEET-INCHES-SixteenthsInches. I developed a similiar but much more compact routine for my Hp calculators when I was employed by an International Bridge Design firm in the early 80's.

The savings in program steps begins with a parallel comparison of the two separate conversion routines, as follows:
[attachment=3706]

which yield a 40 line replacement (if used directly as listed)

BUT

when merged, as follows;
[attachment=3707] error in line 30, see reply #2

yield a 31 line program (less than half the original size).

To use;

Code:


    FIX 4    set display to SEE sixteenths digits

where   FT = Feet
        IN = inches
        in = sixteenths
    with feet left of radix and inches & sixteenths right or radix.

        convert FT.ft to FT.INin  (LBL B)
    1.5208
    GSB B    1.0604    read as 1 foot six and four sixteenths, or one quarter, inches.

        convert FT.INin to FT.ft (LBL A)
    1.0604
    GSB A    1.5208    read as one and five thousand two hundred eight ten-thousanths feet.

The program is of limited utility BUT illustrates one of the many step-saving techniques so important in the early days of handheld programmables. ENJOY!

BEST!
SlideRule

ps: I would include the 77 line program for the Hp67 if the copyright is waived. The algorithm presented is fairly universal among the early RPNs' but has plenty of opportunity for modification / improvement. Press to Test!

[Dieter]

(07-02-2016 02:45 AM)SlideRule Wrote:  The savings in program steps begins with a parallel comparison of the two separate conversion routines, as follows:

The 31 step program uses flag 0 which is initially set at LBL A but not cleared at LBL B. However, at the end of the program flag 1 (!) is cleared. I think this is an error. In any case it's good practice to always initialize a flag and not rely on a certain state at program start, e.g. like this:

Code:

LBL A
SF 0
GTO 0
LBL B
CF 0
LBL 0
...

You say this is a HP67 program, but the keycodes look strange: f and g in the fourth row (that's the one with the ENTER key), flag commands with g prefix and keycodes like 20, 40 or 36. Which calculator does this refer to?

Dieter

[SlideRule]

(07-02-2016 06:07 AM)Dieter Wrote:  The 31 step program uses flag 0 which is initially set at LBL A but not cleared at LBL B. However, at the end of the program flag 1 (!) is cleared. I think this is an error.

Yes, I had a small conversion problem from a real calculator and an emulator. This slipped by me!

Quote:You say this is a HP67 program ... which calculator does this refer to?
Dieter

The program is compared to a 67 program. I understand the inference to keep the base calculator the same but the universality of RPN was also being illustrated so I chose an HP-15LE. I do believe the key sequences will work (not necessarily the key codes) on an HP67, but I leave that to the audience to discover and report in their usual and thorough manner. The listings are from an Excel spreadsheet I use to transfer RPN programs from photocopied sources to a more legible reading.

BEST!
SlideRule

ps: ok here's a 67 listing
[attachment=3708]

[Dieter]

(07-02-2016 12:43 PM)SlideRule Wrote:  ...so I chose an HP-15LE. I do believe the key sequences will work (not necessarily the key codes) on an HP67, but I leave that to the audience to discover and report in their usual and thorough manner.

So let's take a closer look. ;-)

In general the code is fine, but flag 0 still is not initialized. So if the flag happens to be set when the program is run for the first time it will produce wrong results when routine B is called.

(07-02-2016 12:43 PM)SlideRule Wrote:  The listings are from an Excel spreadsheet I use to transfer RPN programs from photocopied sources to a more legible reading.
...
ps: ok here's a 67 listing

What about simple text that can be viewed without special software or downloading any attachments? Or used in emulator files.
May I humbly suggest the following version that initializes flag 0 so that both routines will run reliably? This way the CF command at the end may even be omitted.

Code:

LBL A
SF 0
GTO 0
LBL B
CF 0
LBL 0
INT
STO I
EEX
2
ENTER
1
2
F0?
X<>Y
LASTX
FRAC
*
INT
LASTX
FRAC
.
1
6
F0?
1/x
*
+
RUP
/
RCL I
+
RTN

OK, on a real 67/97 you can record the program with flag 0 cleared so that it is initialized as the card is read. ;-) On the other hand initializing the flag is essential on the 15C as its state is preserved by continuous memory. That's why I suggest an explicit CF 0 at LBL B.

Dieter

[SlideRule]

(07-04-2016 08:22 PM)Dieter Wrote:  May I humbly suggest the following version that initializes flag 0 so that both routines will run reliably? This way the CF command at the end may even be omitted.
Dieter

Sehr gut, danks!

BEST!
SlideRule

[SlideRule]

Code:


… how might one proceed when NO flags are available, say on an HP-33 calculator?

    instruction                        input       KEYS    output

1. Key in Program

2. Set Display                                    f FIX 4

3. Decimal Feet to Feet.Inches/16’s    FF.ffff    GSB 01    FF.INin

4. Feet-Inches to Decimal Feet         FF.INin    GSB 17    FF.ffff

5. repeat steps 3 or 4 as needed

00
01  GSB 32
02  1
03  2
04  *
05  GSB 32
06  .
07  1
08  6
09  *
10  +
11  EEX
12  2
13  /
14  +
15  GTO 00
16  R/S
17  GSB 32
18  EEX
19  2
20  *
21  GSB 32
22  .
23  1
24  6
25  /
26  +
27  1
28  2
29  /
30  +
31  GTO 16
32  INT
33  LST x
34  FRC
35  GTO 00

... advice ... critique ... rebuttal?

ENJOY!!

BEST!
SlideRule

[Dieter]

(07-07-2016 01:13 AM)SlideRule Wrote:  ... advice ... critique ... rebuttal?

There are ways to do this without flags, but I fear these will require as least as much steps as the current solution. ;-)

Anyway – don't you think that the last step of the subroutine...

Code:

32  INT
33  LST x
34  FRC
35  GTO 00

...should be a RTN ?
Or does a GTO 00 do the same here?

Dieter

[Dieter]

(07-07-2016 05:20 PM)Dieter Wrote:  There are ways to do this without flags, but I fear these will require as least as much steps as the current solution. ;-)

Well, it can be done with the same 35 steps and one data register.

Here is a solution without flags. The idea is that decimal feet are positive and ft.inss are negative. So 1.5208 feet are entered and displayed as 1.5208, while for 1 ft, 6 in and 4/16 it's –1.0604. This way the user always knows how to read a result and, as an additional benefit, two separate starting points are not required.

Code:

01  STO 0
02  EEX
03  2
04  ENTER
05  .
06  1
07  6
08  ENTER
09  1
10  2
11  RCL 0
12  X>0?
13  GTO 21
14  R↓
15  ENTER
16  R↓
17  R↓
18  1/x
19  x<>y
20  RCL 0
21  FRAC
22  *
23  INT
24  x<>y
25  LastX
26  FRAC
27  *
28  +
29  x<>y
30  /
31  RCL 0
32  INT
33  +
34  CHS
35  GTO 00

Enter the program, set FIX 4 and GTO 00

 1,5208 [R/S] => –1,0604 = 1 ft 6 in and 4/16
–1,0604 [R/S] =>  1,5208 = 1,5208 ft

Dieter

Edit: Replaced Rdn in listing with R↓

[SlideRule]

(07-07-2016 06:33 PM)Dieter Wrote:  Well, it can be done with the same 35 steps and one data register. Here is a solution without flags.
Dieter

I LIKE, very creative!

BEST!
SlideRule

[SlideRule]

(07-07-2016 05:20 PM)Dieter Wrote:  Anyway – don't you think that the last step of the subroutine...

Code:

32  INT
33  LST x
34  FRC
35  GTO 00

...should be a RTN ?
Or does a GTO 00 do the same here?

Dieter

Dieter

I think I sent the pointer back to the top to facilitate the primary use of this more than 35-years-ago routine: convert FT-IN to decimal feet for SUMMATION, otherwise, I've long since forgotten the reason & neglected to document same in the source document.

Anyway, I greatly enjoy the analysis & perspective of these old utility routines from an era that struggled thru capability & capacity far less than todays' available calculator selection.

Thanks for the second look.

BEST!
SlideRule

[Dieter]

(07-08-2016 01:58 PM)SlideRule Wrote:  I think I sent the pointer back to the top to facilitate the primary use of this more than 35-years-ago routine:

Sure, ending a program with GTO 00 is a good idea as the next R/S will start the program from the beginning. But in this case we are talking about a subroutine call: There are several occurences of GSB 32 which calls line 32 and then is supposed to return to the calling program with a RTN. Ending this subroutine with GTO 00 just stops the program at this point. Which of course will yield strange results.

Have you tried this code on a real HP-33C/E? I did so on the Panamatic 33E emulator. Indeed GTO 00 does not work while everything is fine with a final RTN.

Dieter

[SlideRule]

(07-08-2016 06:32 PM)Dieter Wrote:  Have you tried this code on a real HP-33C/E? I did so on the Panamatic 33E emulator.
Dieter

Dieter

ALL my first print code comes from printed archives; documentation I retained from work projects. I have NO reason to assume this documentation is in error, that's why I retained the code - I used it, once upon a time ago. However, I DO NOT routinely use simulators / emulators designed for computers, so, I can't say.

Once, I did submit a MASTERMIND program for the HP-25. I KNOW it worked as recorded, yet would NOT run as advertised on an emulator. For this ONE program I modified the original to run on a specific emulator (similar issue with branching instruction).

I wait in anticipation for another to answer your query on this archive from the past.

BEST!
Sliderule

[SlideRule]

(07-08-2016 06:32 PM)Dieter Wrote:  Have you tried this code on a real HP-33C/E? I did so on the Panamatic 33E emulator. Indeed GTO 00 does not work while everything is fine with a final RTN.
Dieter

Dieter

Entschuldigen mir! I misread your reply concerning the RTN & GTO 00 keystrokes. YES, there is a missing RTN prior to the string of GTO 00's that pad out the program memory. Your observations are appreciated, danks!

BEST!
SlideRule