Re: optimized prime factor finder for HP-32s Message #7 Posted by Don Shepherd on 7 July 2010, 6:23 p.m., in response to message #6 by Pablo P (Spain)
Quote: As this is so simple I am wondering why did not Dave do it? So I am asking if this modification is correct.
When I looked at the code around the original label x:
x=0
goto x
rtn
lbl x
I realized that that whole goto/lbl could be avoided if I changed the x=0 to x!=0. But then I saw the reference to xeq x over at the end of the z routine, and I knew this would have to change if I eliminated label x, obviously. So then I considered that the end of the label z routine is really the end of the program, which has the net effect (although achieved in a rather roundabout way) of displaying the final factor which is still in x, if you reach that point in the code. So, yes, I basically replaced xeq x with view f, and that seemed to have the effect I wanted and it made the end-of-file logic clearer, at least to me.
Now, why didn't Dave do it that way too? I suspect because he adapted his programs for the 32sii and 20s from an existing HP-67 program that did MORE than just find prime factors, and considering the other functions that that program had, there was probably a reason that the original programmer did xeq x and handled end-of-file that way. Dave also had an extra label that was unnecessary (Lbl A for the 20s and Lbl Y for the 32sii) in this code that was undoubtedly in the original code and Dave just left it there in case it was necessary here, which is is not since there are no other references to A or Y.
The other label I got rid of, Lbl V (which a followup poster in the original thread listed as a solution to the problem that the 32s has no x<=y), could be safely deleted by changing the order of variables M and F on the stack and using x>y. The followup poster probably considered this option but was unsure if changing the stack order would harm the rest of the program, and I looked at it and determined that it wouldn't. As you know, changing the order of things on the stack sometimes goofs everything up, but sometimes it has no effect, as in this case (I hope and think!).
I'm pretty sure these changes are correct. I've tested them with a bunch of numbers that are prime and not prime and it still seems to give me the correct factorization.
Don
Edited: 7 July 2010, 6:33 p.m.
|