[WP34s] Bug?



#15

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.


#16

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.

#17

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.

#18

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

#19

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

- Pauli


#20

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


#21

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

#22

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


#23

This one is for Pauli, I'm afraid.


#24

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

- Pauli


#25

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.


#26

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


#27

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


#28

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


- Pauli

#29

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

#30

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.


#31

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


#32

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.

#33

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

#34

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


Possibly Related Threads...
Thread Author Replies Views Last Post
  wp34s binomial bug Andrew Nikitin 4 579 09-22-2013, 05:20 PM
Last Post: Paul Dale
  Expon bug in wp34s Andrew Nikitin 7 845 07-14-2013, 03:23 AM
Last Post: Marcus von Cube, Germany
  another wp34s bug Andrew Nikitin 8 907 06-26-2013, 01:01 AM
Last Post: Paul Dale
  weird statistics bug in wp34s Andrew Nikitin 5 797 06-20-2013, 01:54 PM
Last Post: Namir
  [WP34S] A funny bug in Pi (prod) Eduardo Duenez 3 593 01-28-2013, 03:41 AM
Last Post: Walter B
  [WP34s] Bug or feature? Dieter 25 2,003 01-03-2013, 06:20 PM
Last Post: Paul Dale
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 425 10-04-2012, 04:59 PM
Last Post: Paul Dale
  Bug in WP34S? Namir 5 653 08-05-2012, 06:32 PM
Last Post: Namir
  [WP34S] Curious Bug in Inverse Normal Function Les Wright 61 3,293 05-01-2012, 02:44 AM
Last Post: Paul Dale
  WP34s: Complex AGM (Bug...) Eduardo Duenez 33 2,482 04-23-2012, 05:59 PM
Last Post: Paul Dale

Forum Jump: