Would it be possible to change the new error message #20 from "Solve failed" to the more general message "no solution"?
Then it could also be used in many other programs (with ERR 20) whenever there is no solution for a problem. :)
Franz
WP34s: a small request


« Next Oldest  Next Newest »

▼
08122011, 01:48 PM
Would it be possible to change the new error message #20 from "Solve failed" to the more general message "no solution"? Then it could also be used in many other programs (with ERR 20) whenever there is no solution for a problem. :) Franz ▼
08122011, 02:02 PM
Seems like a bad idea; that implies the solver knows for a fact that there is no solution, rather than that it merely failed to find a solution. "Routine failed" would be a more general message. ▼
08122011, 02:13 PM
Ok, then let's forget it  I'll do it with an alpha message (which cost lots of bytes however :( ▼
08122011, 07:14 PM
"Es war schon immer etwas teurer, einen besonderen Geschmack zu haben." Old tobacco ad. ▼
08122011, 07:19 PM
Quote:Mein Gott Walter, /* dieses Lied kennst Du sicher, oder? */ Du bist heute wohl wieder besonders zum Scherzen aufgelegt! ;)
08122011, 07:27 PM
We also have a recently included three characters in two steps command. Not the easiest to use from the keyboard but it is there. The assembler will support it nicely however.  Pauli ▼
08122011, 07:36 PM
Yes I know, but I just thought that such a "no solution" message would be useful for many programs.
BTW, another question: I did it then with alpha commands, but that needs quite a few bytes ... Franz ▼
08122011, 08:02 PM
You found the way: use alpha. It doesn't use quite a few bytes BTW: three instructions I think. Clear alpha, a 'C' and one of the alpha views. The big 'C' is just a capital 'C'.
▼
08122011, 08:24 PM
Quote:Yes, that's exactly as I did it. :)
It was just for a little extension of the implemented SLVQ, which also return complex solutions: /* Edited after Marcus' hint!
Edited: 13 Aug 2011, 4:50 a.m. after one or more responses were posted ▼
08132011, 04:37 AM
Franz, be aware that the following two lines are not the same:
[alpha]'C' The first line creates a multi byte string which is long enough to hold three characters in just two steps, the second one is just a single step. The effect on the alpha register is the same. In order to enter a three letter alpha from the keyboard (only available in program mode) press f ENTER f ENTER. You'll see the single quote after [alpha] as a visual feedback. ▼
08132011, 04:48 AM
Thanks Marcus  one more byte saved! :) If I optimize it even more (and get it down to 14 steps), then maybe Pauli will use it as code for SLVQ ... ;) Franz
▼
08132011, 04:54 AM
Figure out a compact way to implement this version and I'm not overly concerned about the number of steps :)
▼
08132011, 05:26 AM
Quote:Well, although not much more code to do it this way, I don't think this would be worth the troubles (or extra bytes). What then do with complex solutions (i.e. if b^24ac<0)? Make a complex division? Well, I guess this would destroy again the accuracy gained from these formulas.
And even with these special formulas you get completely wrong result for illconditioned equations  take for example: You'd need an internal accuracy of at least 16 digits to get correct solutions for this equation. ▼
08132011, 05:44 AM
Quote: I think you're wrong :) Numerical mathematics is a bizarre and arcane art quite unlike the rest of mathematics. This sort of attention to detail makes a difference.
Quote: I doubt the more complex formulas are losing accuracy here either :) The accuracy is coming from the b  sqrt(...) where the sqrt(...) term is approximately b. i.e. b  b produces a catastrophic cancellation. The b^2  4ac also risks cancellation but this is less critical. One does have to be careful about calculating this for b^2 approximately equal to 4ac however since it is easy to get the sign wrong :( e.g. a simplistic application of a fused multiple add here can cause problem. Fortunately the 34S has a complex multiply that can achieve the desired calculation without any rounding issues.
Quote: Clearly, this is exceeding the precision available. But there are plenty of cases in the middle where b^2 >> 4ac and the naïve formula results in b  almost(b) with a huge loss of precision and a resulting incorrect answer. This middle region is where these more complicated formulas come into their own. Try this reference for a better description.  Pauli
Edited: 13 Aug 2011, 6:22 a.m. after one or more responses were posted ▼
08132011, 05:55 AM
Quote:Correct, and that's exactly the reason why I don't like it very much. ;) And if I really need such an excessive accuracy  well, them I'm using a CAS with almost _arbitrary_ precision. :) ▼
08132011, 06:01 AM
The 34S needs to produce correct results and retaining accuracy is mandatory. Look at the trouble I had with the statistical functions. With Dieter's assistance, we've managed to get them accurate with correct rounding. As I mentioned in the discussion about the 35s, a calculator must produce correct results all the time. It is a tool and the tool must work properly.  Pauli _{edit to fix silly grammatical / typo error  I'm having a bad evening :(}
Edited: 13 Aug 2011, 6:24 a.m. after one or more responses were posted ▼
08132011, 06:07 AM
Quote:Ok, I'll work on these 2 (more accurate) formulas! ;) But getting also the complex case will certainly need a few bytes more ... ▼
08132011, 06:14 AM
A quadratic solver using the stable formulas which also handles complex roots is pretty much guaranteed to be included. I rate correct and stable answers as more important than everything else :) The reason the current solver is there is because it is very small, neat and concise. It is a lovely example of keystroke programming. That it suffers from instability is a minus that should be corrected in due course (sorry Gerson).  Pauli
Edited: 13 Aug 2011, 6:21 a.m. ▼
08132011, 07:16 AM
Quote:Well, at least for real solutions I already have the code  it's 21 steps compared with 14 in xrom.c. But the complex case needs more space (and time ... ;)) ▼
08132011, 11:13 AM
Quote:In the complex case the cancellation isn't a problem except for the term below the square root. The subtraction b  sqrt(..) is never carried out. :) ▼
08132011, 12:10 PM
Quote:Correct  and right I'm finished with it! :) With LBL and RTN it's 37 steps (compared to 16 in xrom.c), could be made 34 steps shorter by removing 2 tests (like e.g. a=0?) but this would give 'strange' error messages for some cases.
Two things are not optimal: So let me know if these circumstances are ok and I should post my solution, or if I can throw it away ... ;) Franz ▼
08132011, 01:26 PM
Quote:That's suboptimal indeed, since "I" is the second half of complex last x. How about taking "A" instead? Another opportunity may be confining this function to stack size 8 (I knew we would need this stack size for certain tasks d:) Quote:Applying your measure of tidyness (of an earlier thread), the stack levels not needed for the result shall contain what was on the stack before calling complex SLVQ.
Just my 20m€, ▼
08132011, 01:42 PM
Quote:And where's the problem??? "I" is not used at all in this calculation, and also "L" contains garbage at the end  what counts are the 2 solutions in X and Y, nothing else! Quote:How could I retain 3 coefficients (a,b,c) AND return 2 solutions (x1,x2) on a 4level stack, can you please explain this? So the best solution would be _replacing_ the 3 coeffs by the 2 solutions  but this would need again (not so few) bytes. Ok, I've now finally lost my interest in trying to fulfill your extremely high 'requirements'  if you want and need all these conditions then do it yourself. :( Franz ▼
08132011, 01:59 PM
Quote:versus Quote:Now what?? Quote:I don't get it. How do you place 2 complex solutions in two stack levels :? ▼
08132011, 02:08 PM
Sorry, don't you really get it or do you just want to annoy me? Quote:Since these 2 solutions are complex conjugates, it's enough to put Re(x0) in X and Im(x0) in Y. The 2nd solution is just Re(x0)Im(x0)*i
Edited: 13 Aug 2011, 2:09 p.m. ▼
08132011, 05:34 PM
Thanks for your explanation of the 2 solutions. I should have known that but I didn't :/
For the other point: Quote:You're shouting this  but you didn't tell this before. Keep cool, boy 8) "Needing" a register may be for any reason (in a calculator I guess most probably for calculations but  as stated several times already  my abilities in clairvoyance are limited). No, I didn't want to annoy you, though I admit it's very easy to tease you  and easy to foresee you will declare your resignation (once again) but won't do it ;) ▼
08132011, 06:42 PM
Quote:No, I didn't shout  it's just faster to capitalize words that I want to mark than putting them between 2 "bold"s. Quote:Ahhh, interesting, so you admit you want or try to tease me ... ;)
Edited: 13 Aug 2011, 6:43 p.m.
08132011, 08:30 PM
Quote: No no no no no!!!!!!! Lettered things are special and shouldn't be used in libraries. Fortunately, this is intended for XROM. With a suitable prologue and epilogue added to the code, there are another five registers available. These are numbers 00 through 04 and they are completely separate from the same numbered registers the user sees. There are also fifteen extra flags 0014 FWIW. XROM also operates with a stack size of four regardless of what the user sets  this might cause problems with stack drop. So, what I'd be doing is to preserve T & I in two of these extra registers, use a third for the temporary storage of the value. A fourth preserving X if you want Last X done like an internal operation. Then do the calculation and finally fix things up at the end. Yes this will take more steps. Often quite a few more. For the b^2  4ac calculation use a complex multiply. Assuming a, b & c are in X, Y & Z respectively (also should work for c, b & a in X, Y & Z).
4 a b c T Which, assuming I've got that correct, will calculate the difference without any loss of precision. Also, 4a is still in I.  Pauli
Edited: 13 Aug 2011, 8:32 p.m.
08132011, 05:40 PM
The register isn't a problem if your code makes it to XROM because we have some private registers there for exactly this purpose. I wouldn't mind that the stack gets used, other functions do the same. It's just not a standard function but a routine. With the help of the private registers we may even save stack level T and restore it. I have no idea what would be the "correct" result for L in this case. Please post your solution! Chances are high that it will replace what we have now. ▼
08132011, 06:20 PM
Well, with additional internal registers many thing would of course be much easier to code. And about "L" I won't care at all  after such a lot of operations there's just no useful value which should intentionally be placed in "L".
I've now checked all 8 test equations at the link of Gerson, and for 7 of them I get exactly the same solutions. Only in Case 5 my program returns 2 equal real solutions (the same as the real part on this site), when in fact there is a imaginary part, but it is about 3e10. For this special equation (Case 5) both expressions b^2 and 4ac are VERY big and differ only at the 17th or 18th digit, so that's of course far beyond the 34s precision.
So here's my code: /* ▼
08132011, 11:09 PM
Steps 19, 20 and 21 are a complex conjugate, so replacing them with CONJ saves two more steps. Then the conditional can be reversed and the skip removed for a third step saved. That is replace:
017 x<0? with
017 x>0? and fix the skips up.
▼
08142011, 05:54 AM
Quote:A nice trick indeed! (maybe you should make a doc file "tips & tricks for 34s programming" ;)) But this CONJ also changes RegI (where I have stored the coefficient b), so I hope you haven't overlooked this.
Quote:Hey, that's quite unfair if you have more registers than we have! ;) Why can't we use them in our programs too? That would simplify programming a lot ... :) Franz ▼
08142011, 06:56 AM
Quote: You can have them if you're willing to forgo solve, integrate, sum, product and the derivatives. Oh and now the quadratic solver. I'm sure most people would like to keep these functions and not have the extra registers. It is also not a case of having an extra five registers. All the above are limited to using no more than these five registers in total. They don't even get the luxury of having the stack preserved across callbacks to user code.
08142011, 07:01 AM
Quote: I'd like to eventually. I've got other things for the moment.
Quote:
I stopped using register I and restore it afterwards :)  Pauli ▼
08142011, 07:57 AM
Quote:Ok, then it's no problem.
BTW, since you mention accuracy:
And one more thing (rather for Walter than for you):
Edited: 14 Aug 2011, 8:04 a.m. ▼
08142011, 08:12 AM
Quote: It should address the overflow issues, or at least push them off a bit. I'd be concerned about the second term when b is approximately 2 sqrt(ac). It might not be an issue, but it would have to be investigated.
Quote: The current code handles example 5. The complex multiply addresses the b^2  4ac precision loss concerns. The internal code evaluates the multiplies exactly and does the subtraction without any rounding or truncation until the result is returned. i.e. it should be as good as is possible without resorting to extended precision.
▼
08142011, 08:20 AM
Quote:Well, but anywhere you would have to stop  what should you do when those 2 terms are almost equal? You can't completely avoid subtractions in any cases ... Quote:Aaah, that's fine  so this problem seems to be solved at least with this extended precision. Of course we can't never handle ALL situations correctly when the numbers are getting to big. Franz
08142011, 01:07 AM
Much goodness in subversion. No build yet.
08132011, 12:25 PM
Quote: That's really good news! Palmer O. Hanson has written an excellent quadratic solver that handles some really tough examples: A "Cadillac " Quadratic Solver for the hp 33s and HP35s Gerson.
08132011, 06:03 AM
Quote:Bad luck  calculators are numerical mathematics all over ;)
08142011, 06:07 PM
Quote: Here's my first attempt at it. Like Franz's, it handles Palmer's examples (except number 5). Too many steps though, "cut a few and it'll be perfect" :) Gerson.
// Source file(s): wp34s0.dat _{Edit to correct the listing as per Franz's observation below. }
Edited: 14 Aug 2011, 6:31 p.m. after one or more responses were posted ▼
08142011, 06:23 PM
Quote:I guess these 3 "STO[times]" should be Y,Z and T instead. With X,Y and Z in fact none of these values is changed. ▼
08142011, 06:30 PM
You're right, thanks! It's correct on my wp34s, but not on the emulator. Will fix the listing. Gerson.
08142011, 07:18 PM
The code I've put into xrom is:
81ee: 5b59 LBL 89 Entry: QUADRATIC SOLVER
Label 41 is basically a RTN. Label 42 is a RTN+1.
