▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Hi Valentin!
First to our differences about the Laguerre method:
I now have to agree that you were right, the Laguerre algorithm is indeed a very powerful method and definitely better than the Bairstow algorithm!
What changed my mind? Well, today I've slightly modified my WP34s Laguerre program, and suddenly I got an error message which I couldn't explain. Analyzing this problem I found that there was a misunderstanding between me and the WP34s about the absolute value of a complex number: I assumed that [cpx]ABS would of course return just a single real value, but the WP34s implementation returns a complex value with the ABSvalue in X and 0 in Y!
Since you have to compare 2 ABSvalues of complex numbers in the Laguerre method (to find the larger denominator), I simply used a x>=y? after having calculated both absolute values, and so in fact I compared the 2nd absvalue with 0 (instead of the 1st absvalue), and this caused the program to always use the wrong denominator and so the iteration was so bad.
After having now corrected this program step (x>=z? instead of x>=y? to comply with this unexpected behaviour of the WP34s [cpx]ABS function), my Laguerre program now is working excellent and  as you said  indeed better than the Bairstow program (in average it needs only 1/3 of the iterations).
So in short words: you were right with Laguerre and I was wrong (due to my misunderstanding of this [cpx]ABS function in WP34s)!
Now about the 'style' of our communication:
Usually I'm a very friendly person and never use 'bad' words, but I was really angry about your answers to my postings with those numerous "Nope, ... is your lack of relevant theoretical knowledge",
"Nope, ... it's your lack of understanding", etc. etc. ...
You really treated me as if I would have "no clue about anything" (in other words, like being an idiot), and this may explain my reaction that I also answered in a quite unfriendly way.
So  although it was not only my fault  I nevertheless apology for my unfriendly and harsh words!
I hope you accept my apology,
Franz.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
I'm of course not Valentin, but as a person who has followed this dispute with some personal involvement (WP 34S is our baby, isn't it?) I very much appreciate your statement. I hope, Valentin will see it similarly.
Marcus
"I's not the errors we make, it's how we deal with them."
Posts: 429
Threads: 31
Joined: Jul 2011
Posts: 3,229
Threads: 42
Joined: Jul 2006
I was sure I'd implemented a HYPOT command that calculated sqrt(x^2 + y^2). Must have been removed somewhere along the line :(
 Pauli
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Most probably superseded by cABS and R>P. But the function may be replaced by: cABS (or R>P) x<>y DROP.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
"cABS +" is one step shorter :)
Alas, DROPY went away a long time ago.
 Pauli
Posts: 653
Threads: 26
Joined: Aug 2010
Well, I remember some person suggesting a HYPOT command and another person saying this was not required since CPX ABS would do the same. ;)
In fact, the complex ABS command evaluates sqrt(x^2 + y^2) exactly  it's done with 39 digits while only 32 are required. There is just one thing that looks a bit strange for me: consider a function that uses a complex argument while it always returns a real result. Do you think the result should still be returned as a complex number with a zero imaginary part? In other words: is it a good idea if the complex ABS function finishes with the C indicator set and a result in X and Y where Y = 0 ? I think it should simply return the (real) result in X and drop Y.
Dieter
Edited: 13 Nov 2011, 5:49 p.m.
▼
Posts: 850
Threads: 10
Joined: Mar 2009
Quote:
I think it should simply return the (real) result in X and drop Y.
I disagree, I'd rather stay in complex mode because if I was to use the result as an argument for another function, it would likely be complex too (and thus save me putting 0 in Y).
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
I assumed that [cpx]ABS would of course return just a single real value, but the WP34s implementation returns a complex value with the ABSvalue in X and 0 in Y!
All complex functions of the WP 34S deal with pairs of registers in input and output. So does ^{C}ABS. Simply consistent :)
▼
Posts: 653
Threads: 26
Joined: Aug 2010
Please see my other post in reply to Pauli's.
Dieter
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Well, the basic assumption is anybody calculating complex functions wants to continue this way  so we better return a complex result. If, OTOH, some complex functions would return just a single number in a single stack level, a continuation in complex realm would become quite difficult.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
Excellent logic  I used the same convention in the 41Z with functions like ZABS, ZARG, etc. returning zero as imaginary part.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Posts: 3,283
Threads: 104
Joined: Jul 2005
Which leads me to the conclusion that CPX should be renamed i. We have dynamic register allocation so it's time for a complex stack and a complex mode going with it. We will save a lot of flash space in the keyboard, display and catalog handlers which we can spend better on a proper complex mode. No need to recode the subroutine behind label E to use cLN instead of LN. Let's do it the same way as the 15C!
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: We will save a lot of flash space in the...
 keyboard: yes.
 display: where?
 catalog handlers: no?
Doing a 15C style complex stack will be very invasive. Better will be real types (including complex) for the 43S.
 Pauli
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
Doing a 15C style complex stack will be very invasive. Better will be real types (including complex) for the 43S.
I fullheartedly concur :) Surprise?
Posts: 1,755
Threads: 112
Joined: Jan 2005
Quote:
So  although it was not only my fault  I nevertheless apology for my unfriendly and harsh words!
I hope you accept my apology,
Of course, why not, thanks and let bygones be bygones.
Best regards from V.
