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. *

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

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

Yes, I was already afraid that SSIZE8 might be a problem for XROM.

But I can't store 6 values on a 4-level 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 (Y-value).

What if the same would be done also for real (duadic) operations, i.e. before executing any of these operations the Y-value is stored in I (together with X in L)?

So also for real operations the I-register 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

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 every-day-problems) really have a linear equation system (2x2) with coefficients which would give wrong results if you don't use your favoured "super-high-precision-tricks"? ;-)

Franz

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.

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

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 8-level stack (at least not without dozens of "stack-swappings").

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

For me your suggestion about LastY sounds reasonable. Let's wait what the others think about it.

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

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.

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

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. *

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

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.

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

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

Quote:

What about a SWAP4 command?

LOL, that's funny: exactly

**my** idea from a few days ago ...

All 3 features (Save/Restore/Swap-stack between the lower- and upper-stack were my suggestions a few days ago (and I've even provided user-code 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*

Some suggestions just take their time... ;-)

Number 13 and counting ;-)

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

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.