HP Forums
[WP34s] Bug? - 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: [WP34s] Bug? (/thread-202182.html)



[WP34s] Bug? - fhub - 10-20-2011

I've almost finished my Polynomial RootSolver for the WP34s, but in my final tests I've jumped into a problem:

The command RTN+1 doesn't work in a program!

Now I've checked it with the following short testprogram:

LBL A
XEQ 00
SKIP 01
ERR 20
RTN
LBL 00
RTN+1
Running this program (with shortcut [A]) should always show the error message 20 because LBL 00 just returns to this ERR 20 line - or better said it should do it, but it doesn't work: no error message at all! :-(

So unless I'm misunderstanding something this RTN+1 command doesn't work as it should in a program.

Franz.

Edited: 20 Oct 2011, 7:45 a.m.


Re: [WP34s] Bug? - Marcus von Cube, Germany - 10-20-2011

I haven't tested this but if you are right it's a bug. Maybe later today Pauli or me will find the time to look at it.


Re: [WP34s] Bug? - Kerem Kapkin (Silicon Valley, CA) - 10-20-2011

I think program is working the way it should.
LBL A -> XEQ 00 -> LBL 00 -> RTN+1 -> SKIP01 (skipps ERR20) -> RTN (END)

If you remove the SKIP01 command

LBL A -> XEQ 00 -> LBL 00 -> RTN+1 -> ERR20 (Get "Solve FAILED")

Or if you add some other line right after SKIP01, and before ERR20, it works too.

From the 34s Manual: Skips n program steps forwards (1 <= n <= 99). So
e.g. SKIP 02 skips over the next two steps,going e.g. from step 123 to step 126.

EDIT: Never mind :) you are right, after reading the RTN+1 definition more carefully, it should actually go to the second line AFTER XEQ, skipping the one right after XEQ (SKIP01 in this case), therefore it should execute ERR20, but it lands on SKIP01.

-Kerem


Edited: 20 Oct 2011, 5:14 p.m.


Re: [WP34s] Bug? - Paul Dale - 10-20-2011

This problem seems to go away if the RTN+1 command is not at the end of program memory. So there is a workaround until we fix the issue properly.


- Pauli


Re: [WP34s] Bug? - Paul Dale - 10-21-2011

Fixed in the sources. Not built yet, but soon will be I expect.

- Pauli


Re: [WP34s] Bug? - fhub - 10-21-2011

Quote:
Fixed in the sources. Not built yet, but soon will be I expect.

Yep, it's working again, thanks!

This was indeed a very strange bug and it was pure coincidence that I had this RTN+1 at the end of my program - I guess otherwise it won't have been found for a very long time. ;-)

Franz


Re: [WP34s] Bug? - Walter B - 10-21-2011

That's the way bugs are found - else they would have been found earlier.


Re: [WP34s] Next Bug? - fhub - 10-22-2011

Ok, here's the next bug, this time in the quadratic solver SLVQ:

Solving the equation x^2-x=0 with SLVQ returns 0 (zero) for both solutions (instead of 1 an 0).

To test it: 1 ENTER 1 +/- ENTER 0 SLVQ ==> 0 in X and Y

I know that SLVQ is based on my own code I've posted some time ago here, but my code returns the correct results, so there must have gone something wrong in translating my code to the internal XROM code.

Franz




Re: [WP34s] Next Bug? - Marcus von Cube, Germany - 10-22-2011

This one is for Pauli, I'm afraid.


Re: [WP34s] Next Bug? - Paul Dale - 10-22-2011

I think I've got this fixed now. It was quite a mess :-(

- Pauli


Re: [WP34s] Next Bug? - fhub - 10-23-2011

Quote:
I think I've got this fixed now. It was quite a mess :-(

Without having tested it I guess your 'fix' is still not working for a*x^2=0 (i.e. when b=c=0).

Looking at your new code

   x>0?
[cmplx]CONJ
- /* -b-sqrt 2c 2c 2c */
STO/ Y /* -b-sqrt 2c/(-b-sqrt) 2c 2c */
I see that you've now removed the step "x[!=]0?" before the "STO/ Y",

so this division may fail if -b-sqrt=0.

And you won't have run into this 'mess' if you would just have used my code (which is working perfectly) ... ;-)

(calculating the discriminant with a "cpx *" is ok, but why change my other code?)

Franz

Edited: 23 Oct 2011, 6:22 a.m.


Re: [WP34s] Next Bug? - Paul Dale - 10-23-2011

Quote:
And you won't have run into this 'mess' if you would just have used my code (which is working perfectly) ... ;-)

(calculating the discriminant with a "cpx *" is ok, but why change my other code?)

Using complex * changed the stack layout and I needed to preserve more on the stack and last X to call this a built in command. That's why I rearranged things.

Feel free to update your code to use complex * for the discriminant and preserve the stack semantics of the built-in and I'll happily include this instead.

Otherwise, it will have to wait until I get around to revisiting the current code which has the problem you mentioned :-( Sigh.


- Pauli


Re: [WP34s] Next Bug? - fhub - 10-23-2011

Quote:
Feel free to update your code

No need for this because it works fine! ;-)

Your XROM code should look like this (only the 5 problematic lines):

x[>=]0?
[cmplx]CONJ
-
x[!=]0?
STO/ Y
So just change x>0? to x[>=]0? in line 1 and insert [x!=]0? again at line 4.

Franz


Re: [WP34s] Next Bug? - Dieter - 10-23-2011

Quote:
This one is for Pauli, I'm afraid.

And for Walter as well, I think. Currently the manual says:

"Solves the quadratic equation ax² + bx + c = 0 with the real parameters put on the stack [c, b, a, ...], and tests the result."

(Version 2.2.1687 as included in the last emulator package)

The manual seems to suggest that the user enters c first, then b, finally a, and maybe even more due to the "..." following these three. In fact, the correct order seems to be a [ENTER] b [ENTER] c. The manual should state this clearly in exactly this way, and the final "..." should get deleted.

I think a simple stack diagram would be useful here:

     input      real solution     complex solution
T ... ... ...
Z a discriminant discriminant
Y b => 2nd real root |imaginary part|
X c 1st real root real part
 
L ... c c
Dieter


Re: [WP34s] Next Bug? - fhub - 10-23-2011

I interpret [c, b, a, ...] as [X, Y, Z, ...=T] because otherwise this "..." at the end won't make any sense at all.

Edited: 23 Oct 2011, 9:10 a.m.


Re: [WP34s] Next Bug? - Dieter - 10-23-2011

There you are: the manual allows different interpretations, while it should simply state the required information unambigously.

"[c, b, a, ...]" denotes a vector with four or more components. Instead, the user should be told directly that a is expected in Z, b in Y and c in X. Preferably by a simple and graphic stack diagram, as suggested.

Dieter


Re: [WP34s] Next Bug? - Dominic Richens - 10-23-2011

Dieter, Franz,

Please consider adding a section to WP34s users' guide. All the button .png files are there so you can write something in the un-ambiguous style of the classic HP manual.

cheers!

Edited: 23 Oct 2011, 9:31 a.m.


Re: [WP34s] Next Bug? - fhub - 10-23-2011

Quote:
There you are: the manual allows different interpretations, while it should simply state the required information unambigously.

When I wrote "I interpret [c, b, a, ...]" then I meant of course that it can't be interpreted in a different way IF you're using your logic brain. ;-)
Quote:
"[c, b, a, ...]" denotes a vector with four or more components.

Come on, we're talking about a (usually 4-level) stack calculator but not about mathematics in common.

What sense should "a vector with 4 or more components" make in the WP34s context?

Franz


Re: [WP34s] Next Bug? - Walter B - 10-23-2011

Dieter, I added a sentence to the "Print Conventions" for you.


Re: [WP34s] Next Bug? - Paul Dale - 10-23-2011

Thanks. The changes are in but won't be built until someone kicks it off -- I can't at the moment.


- Pauli