The Museum of HP Calculators

HP Forum Archive 14

[ Return to Index | Top of Index ]

Re: P.S., 15 bytes for a ANY number on 33s
Message #1 Posted by Brent on 29 Feb 2004, 12:21 a.m.

Apparently, if you enter numbers via an equation it only takes 4 bytes for numbers 0 thru 9 and 5 bytes for negative numbers 1 thru 9, and the bytes increase slowly as you add digits.

      
Indeed, you are correct.
Message #2 Posted by Paul Brogger on 1 Mar 2004, 4:55 p.m.,
in response to message #1 by Brent

Brilliant bit of observation!

Pushing EQN while in PRGM mode causes the entry of an equation on the program line, rather than a command or number. A single digit may be entered as an "equation". The memory cost is 3 bytes for the program entry and one byte for each numeric character in the equation. So "1" takes four bytes, and "10" takes five bytes, etc.

This renders utterly meaningless my earlier quest of command sequence substitutes for numeric constants in programs.

It was fun while it lasted!

            
Re: Indeed, you are correct.
Message #3 Posted by bill platt on 1 Mar 2004, 5:04 p.m.,
in response to message #2 by Paul Brogger

But how about the mere existence of the equation? That is only 3 bytes then?

                  
3 bytes of overhead + eqn length
Message #4 Posted by Paul Brogger on 1 Mar 2004, 9:14 p.m.,
in response to message #3 by bill platt

It appears that all program lines take at least three bytes, including the "placeholder" (or whatever) for an equation. The actual length of the equation, plus the three-byte program line entry is the memory cost of an equation in a program.

For example, if in PRGM mode, EQN enters equation mode, with the cursor on a new, blank program line. If I enter, say, 5 ENTER then the numeral 5 is entered as the equation. If I then look at MEM for the program, it will show the program using 4 bytes more than before.

If, however, in PRGM mode I simply type "5" and then look at MEM, it will show the program using fifteen bytes more than before.

If I do one after the other and scroll through them in PRGM mode, the only apparent difference between the program lines with the 4-byte EQN "5" and the 15-byte numeric "5" is the little "EQN" annunciator that flashes on when an EQN line is in the lower display area.

Execution time seems to be impacted by use of equations rather than numeric constants. (There's GOT to be a trade-off, right?) Each equation must have to be evaluated and stored as a numeric value on the stack. My test of 500 iterations through a "0" numeric and then through 500 "0" equations showed the latter took about 1/3 longer (15 seconds for the simple number vs. 20 for the equation).

(All of which tends not to matter much with 32K memory ... )

      
two more observations
Message #5 Posted by Brent on 1 Mar 2004, 5:46 p.m.,
in response to message #1 by Brent

I noticed that the 33s does not use up memory when you
store variables. The 32sii uses eight bytes per non zero variable.
Sorry if this has already been mentioned.

I also noticed that in programming the 33s, the ISG and DSE
operators are slower than the ones in the 32sii. Can
anybody explain why? Is it a hardware difference?

Other than that, the calculator seems to be about
twice as fast as the 32sii.

Edited: 1 Mar 2004, 5:47 p.m.

            
trig functions on 33s slower as well
Message #6 Posted by Brent on 2 Mar 2004, 1:21 p.m.,
in response to message #5 by Brent

If I run the trig code from the museum's
Benchmark section, I get a score of 135 on my
33s and a score of 151 on my 32sii.

http://www.hpmuseum.org/speed.htm

... after one minute of looping

Edited: 2 Mar 2004, 1:50 p.m.

            
Math functions
Message #7 Posted by Brent on 2 Mar 2004, 1:38 p.m.,
in response to message #5 by Brent

For the math functions from the museums
routine I score an 862 on the 33s vs. 618
on my 32sii.

for one minute of looping.

http://www.hpmuseum.org/speed.htm

Edited: 2 Mar 2004, 8:02 p.m.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall