![]() |
Is this another bug for the 35s? - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: Is this another bug for the 35s? (/thread-213071.html) |
Is this another bug for the 35s? - Matt Agajanian - 03-02-2012 Hi all. On the Learning Module entitled, Line Addressing, an example is given: S001 LBL S S002 INPUT A S003 INPUT B S004 INPUT C S005 INPUT D S006 RCL D S007 RCL C S008 RCL B S009 RCL A S010 X^2 S011 XEQ Q001 S012 XEQ Q001 S013 XEQ Q001 S014 SQRT S015 RTN Q001 LBL Q Q002 X <> Y Q003 X^2 Q004 + Q005 RTN And then it's said that the 35 automatically adjusts the line numbers of GTO and XEQ instructions when lines are added or deleted. So, if we delete the line Q001, in this pamphlet, it is said that the 35s automatically adjusts line numbers in GTO and XEQ statements so they reflect the modification. Then, if we delete line Q001, the program becomes: S001 LBL S S002 INPUT A S003 INPUT B S004 INPUT C S005 INPUT D S006 RCL D S007 RCL C S008 RCL B S009 RCL A S010 X^2 S011 XEQ S016 S012 XEQ S016 S013 XEQ S016 S014 SQRT S015 RTN S016 X <> Y S017 X^2 S018 + S019 RTN But, when I tried this on my 35s, although the line numbers changed to reflect the new Snnn numbering, the branching statements still stated XEQ Q001? Is this a bug or have I missed a step or is that Learning Module incorrect?
Edited: 2 Mar 2012, 2:06 a.m.
Re: Is this another bug for the 35s? - Bart (UK) - 03-02-2012 Interesting, if the XEQ's referred to Q002, then it does automatically change it to the correct new line. The step pointed to by a GTO or XEQ instruction is deleted:So it IS following the stated paradigm, but in the case where the GTO or XEQ point to the start of a Label, this philosophy fails, as they are now left pointing to a non-exitent program. I will leave it to Pauli to decide if it goes into the bug list. Re: Is this another bug for the 35s? - Paul Dale - 03-02-2012 Happy to add it if someone comes up with a smaller example and verifies it. This one is a little on the large size. It sure seems like a bug to me.
Re: Is this another bug for the 35s? - Bart (UK) - 03-02-2012 How about this: K001 LBL KIn this case deleting L001 correctly gives the following: K001 LBL K But now try: K001 LBL KNow deleting L001 gives the following: K001 LBL Ki.e. K003 is left pointing to a non-existent label. Re: Is this another bug for the 35s? - Bart (UK) - 03-02-2012 Hi Pauli, a more compact form:
The "Line Addressing" learning module states: The step pointed to by a GTO or XEQ instruction is deleted:But in the case where the GTO or XEQ point to the start of a Label, this philosophy fails, as they are left pointing to a non-exitent program. Example A: K001 LBL K In this case K001 LBL KIt works across labels too Example B: K001 LBL K In this case K001 LBL KBut not if the line that is being pointed to and deleted is the first line (LBL) of a new label: Example C: K001 LBL K Now deleting K001 LBL K
i.e. K003 is left pointing to a non-existent label.
Edited: 2 Mar 2012, 2:41 p.m. after one or more responses were posted
Re: Is this another bug for the 35s? - Jeff O. - 03-02-2012 Quote:Your first example is a case where a step between the XEQ and the step pointed to by the XEQ is deleted. If we delete the actual target of the jump, your example would be as follows: K001 LBL K In this case K001 LBL K
It is still inconsistent with the learning module information, as you say: K001 LBL K Deleting K001 LBL K
when we would need the following to adhere to the rule: K001 LBL K Deleting L001 K001 LBL K
But this may actually be on purpose - the way it actually works preserves your intention to jump to a different label. That way if you accidentally deleted your label while editing, you would not have to go back and find all places where you meant to jump there and fix them. (It has been a while since I did much programming on the 35s, so forgive me if the above suffers from some logical flaw.) Either way, deleting the target of a jump must be handled with care, wouldn't you say? Edited: 2 Mar 2012, 1:16 p.m.
Re: Is this another bug for the 35s? - Bart (UK) - 03-02-2012 Hi Jeff, Re: Is this another bug for the 35s? - Matt Agajanian - 03-02-2012 So, it seems Bart and I are on to something. I Just tried my original example by replacing the original 'XEQ Q001' commands with 'XEQ Q002' and all is as it should be. The line numbers corrected themselves after I deleted the 'LBL Q' instruction.
Thus, in order for the editing to work, XEQ commands should call instructions 002 instead of 001. It does follow that deleting a LBL statement leaves all GTO n001 and XEQ n001 statements unchanged (thus referring to a non-existent location). Although, logically you would address n001 to call a label's start point, perhaps the habit should be to avoid calling a subroutine at the 001 point but rather another step number.
Re: Is this another bug for the 35s? - Paul Dale - 03-02-2012 The bug list is updated with just the failure case.
|