▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Now that we have an extended quadratic equation solver, what about a simple linear equation system solver for 2 variables?
I know this would be handled by a matrix package, but for 2 variables/equations it's just a few bytes and would fit quite well to SLVQ. ;)
Here's my code for this (SLVL, SLVS or SLVLS ?):
/*
Linear Equation System
a*x + b*y = c
d*x + e*y = f
Mode: SSIZE8
Input: a [ENTER] b .... e [ENTER] f
Output: X:x Y:y Z:det (or "Invalid data" if det=0)
Used: Stack
*/
001 LBL'LS'
002 RCL B
003 RCL[times] Z
004 RCL B
005 RCL[times] A
006 
007 x=0?
008 ERR 18
009 RCL C
010 RCL[times] Z
011 RCL B
012 RCL[times] B
013 
014 RCL/ Y
015 RCL B
016 RCL[times] A
017 RCL D
018 RCL[times] A
019 
020 RCL/ Z
021 0
022 ENTER[^]
023 [cmplx]R[v]
024 RTN
It preserves the coefficients of the 2nd equation (d,e,f), puts the coefficient determinant to Z and the solution x,y to X,Y.
Of course it works only in SSIZE8 mode!
With the use of Pauli's 'private' ;) internal registers it could even preserve ALL coefficients, if e.g. the determinant would be stored to register L (or simply ignored).
If you want you can include it in the XROM, if not then it's just one more little user program ... ;)
Franz
Edited: 14 Aug 2011, 8:54 a.m.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: Of course it works only in SSIZE8 mode!
and
Quote: If you want you can include it in the XROM
are exclusive.
So a library routine it will have to be.
 Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Yes, I was already afraid that SSIZE8 might be a problem for XROM.
But I can't store 6 values on a 4level stack  and using registers instead is no good idea IMO, because it's much more complicated to input.
Now for another idea I had today: ;)
Currently register "I" is only used in complex operations and stores the previous imaginary part (Yvalue).
What if the same would be done also for real (duadic) operations, i.e. before executing any of these operations the Yvalue is stored in I (together with X in L)?
So also for real operations the Iregister would work like a "LastY"  this would almost allow a kind of "UNDO" function: after any duadic operation (e.g. done by mistake) you could just do DROP, RCL I, RCL L, and you have the previous stack back again.
I think this would be very easy to implement (if I don't overlook something?), because such a "STO Y to I" could simply be done whenever X is stored in L.
Good idea or not? ;)
Franz
Posts: 3,229
Threads: 42
Joined: Jul 2006
Is there a reason you've got three cross products (of the form a b  c d) here but aren't using complex multiply to maintain accuracy?
 Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Is there a reason you've got three cross products (of the form a b  c d) here but aren't using complex multiply to maintain accuracy?
Yes, there are even a few reasons! ;)
1) I would have to put all 4 values (used in [cpx]*) at the right position on the stack, which would cost a lot of program steps
2) this correct positioning would also need much more than the 8 stack registers, because the values used for any [cpx]* are used in the following step(s), too (and without actually trying it I doubt that I could use both the real and imaginary part of the complex product, so one of them would always be useless)
3) last but not least I don't care SO much about EXTREMELY high precision (anywhere at 16 digits) like you  when do you (in everydayproblems) really have a linear equation system (2x2) with coefficients which would give wrong results if you don't use your favoured "superhighprecisiontricks"? ;)
Franz
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Franz, neat little program. One more idea which might even allow for Pauli's idea to compute the determinant with a complex multiply: Why not enter the complete system column wise or coefficients first, then right hand side? If the routine would preserve the coefficients in stack levels Z, T, A & B and a allow to enter another set of values for the right hand side to solve a similar system without reentering the matrix.
Pauli, even if in XROM the stack mechanics a nailed to 4 levels, all 8 registers are still available so that a program which expects data in registers A to D can still be written. It may consume more steps but we have some room left.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: Pauli, even if in XROM the stack mechanics a nailed to 4 levels, all 8 registers are still available so that a program which expects data in registers A to D can still be written. It may consume more steps but we have some room left.
XROM is for built in commands. Playing games like this with the stack & registers really isn't appropriate :( The command has to work regardless of the stack size and the user's settings.
In a library, things are very different however.
 Pauli
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
One more idea which might even allow for Pauli's idea to compute the determinant with a complex multiply: Why not enter the complete system column wise or coefficients first, then right hand side? If the routine would preserve the coefficients in stack levels Z, T, A & B and a allow to enter another set of values for the right hand side to solve a similar system without reentering the matrix.
Yes Marcus, the idea with preserving the coefficients is indeed a very good one, and also using the complex multiply would be preferable, but both ideas require to use additional registers Rnn  it's just not possible to do this with an 8level stack (at least not without dozens of "stackswappings").
So if you would say using additional registers is ok, then I would certainly give it a try ... ;)
But what surprises me a bit more at the moment: my idea above (having an additional "LastY" (i.e. storeing Y in "I") to the usual "LastX" in L) doesn't even seem to be worth any answer!?
 And this although such a "LastY" after a duadic operation would certainly be just as useful as "LastX" for further calculations.
 And this although it would just need an internal "Y > I" command whenever X is backup'ed in L.
Franz
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
For me your suggestion about LastY sounds reasonable. Let's wait what the others think about it.
Posts: 3,229
Threads: 42
Joined: Jul 2006
Since you are pushing the point, I hope you can deal with a bit of negativity :)
We considered a last Y a long time back. It doesn't work and introduces inconsistencies. Ignoring the lack of RAM for extra registers for a moment...
Complex dyadic operations would require a complex equivalent of last Y. Triadic operations would require a last Z. Fortunately, there are no complex triadic operations yet or we'd require more.
We simply can't stay consistent treading this path.
Now think about the number of times you've used register I as a temporary (& I've seen your code doing just this and I've done the same many times). Users can and will do this. Adding a last Y using "I" will impact this use of the register.
So, yes we considered this and rejected it.
Now, we could use our final bit in the mode word to specify an optional stack backup before every operation or not. That would achieve pretty much the same thing. Is this worthwhile? I really don't know.
 Pauli
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Quote:
Now, we could use our final bit in the mode word to specify an optional stack backup before every operation or not. That would achieve pretty much the same thing. Is this worthwhile? I really don't know.
This reminds me of the "Last Stack" feature of the RPL machines. I think it's overkill. We should consider to put STOS and RCLS on the keyboard instead (where ITOA and ATOI reside now) and to allow register A as the destination if in SSIZE4 mode.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: This reminds me of the "Last Stack" feature of the RPL machines. I think it's overkill. We should consider to put STOS and RCLS on the keyboard instead (where ITOA and ATOI reside now) and to allow register A as the destination if in SSIZE4 mode.
Allowing A is problematic and would require some work in the argument processing code.
I also think it is overkill.
 Pauli
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Quote:
Allowing A is problematic and would require some work in the argument processing code.
Yes, I know. But I still thinks it's worth the effort. So with a 4 level stack, A to D can assume the role of a quick backup.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
What about a SWAP4 command?
Swaps X, Y, Z & T with A, B, C, & D.
Not quite as good as a STO/RCL of the stack but useful I think.
 Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
What about a SWAP4 command?
LOL, that's funny: exactly my idea from a few days ago ...
All 3 features (Save/Restore/Swapstack between the lower and upperstack were my suggestions a few days ago (and I've even provided usercode for all 3 commands), and what answer did I get? "not needed, you can use STOS and RCLS instead"
And now when Marcus (and even Pauli himself) 'suggest' exactly the same features, they are now suddenly "useful"?
Sorry, but I couldn't resist ... ;)
Edited: 15 Aug 2011, 7:44 a.m. after one or more responses were posted
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Some suggestions just take their time... ;)
Posts: 3,229
Threads: 42
Joined: Jul 2006
I've figured out the "best" way to do the swap4 command:
LBL'SW4'
[cpx]SWAP C
[cpx]SWAP Z
[cpx]SWAP C
[cpx]SWAP A
RTN
Seven instructions = 14 bytes. To introduce an internal command table entry takes 12 bytes and to add a function that does nothing pushes things closer to 40 bytes. To add the relevant swaps pushes this higher. So this is the most compact implementation I can think of.
The question is to do this as a user subroutine  no extra flash bytes but 7 user steps  or put it in xrom as is  14 bytes  or to put it in xrom with an internal command to call it  30+ bytes  or to write a dedicated command  60+ bytes.
I'm leaning towards letting the user do this one.
 Pauli
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Now add another label, LBL 32, and XEQ x<>y does the swap from the keyboard as long as the PC is positioned in the correct region.
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Since you are pushing the point, I hope you can deal with a bit of negativity :)
Well, a bit of negativity won't be a problem for me, but as far as I can remember each and every idea or suggestion from me to improve the 34s has been rejected by you so far  either "not useful" or "not possible"!
So since it seems that all my ideas are in fact that bad, I guess it's better for me (and you) if I completely resign from the 34s project.
Franz
Edited: 15 Aug 2011, 6:11 a.m.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Grow up.
We've taken several of your suggestions on board and I expect we'll accept more in the future. Just not this one.
You're the one who pushed for a comment about this one.
 Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Grow up.
I would rather say you should grow up!
Your usual stubborn argument "because it won't work for all functions, we don't implement it at all" is pure nonsense, and I really can't hear it anymore!
Because you won't have a LastZ for a few single 'exotic' triadic functions (or for complex functions), you don't implement such an extremely useful LastY feature at all?
Just because a few percent of functions (certainly used very seldom) can't profit from such a feature, all other (maybe 95%) functions shouldn't profit from a LastY, too? Sorry, but that's just ridiculous.
(I guess you would also reject a 2nd prize in a lottery just because you didn't win the 1st prize?)
Quote:
We've taken several of your suggestions on board
May I laugh?
Yes, I'm good enough for you to improve and optimize some code (crossproduct, TVM, SOLVQ), but when it comes to ideas or suggestions your opinion is that I should better shut up.
Thanks, but I'm not your slave  it's really enough now!
Goodbye  an my best wishes to the WP34s team,
Franz
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Number 13 and counting ;)
