Public apology to Valentin Albillo

[fhub]

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 ABS-value in X and 0 in Y!

Since you have to compare 2 ABS-values 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 abs-value with 0 (instead of the 1st abs-value), 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.

[Marcus von Cube, Germany]

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

[Alexander Oestert]

:-)

[Paul Dale]

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

[Marcus von Cube, Germany]

Most probably superseded by cABS and R->P. But the function may be replaced by: cABS (or R->P) x<>y DROP.

[Paul Dale]

"cABS +" is one step shorter :-)

Alas, DROPY went away a long time ago.

- Pauli

[Dieter]

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.

[Bart (UK)]

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

[Walter B]

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 ABS-value in X and 0 in Y!

---

All complex functions of the WP 34S deal with pairs of registers in input and output. So does ^CABS. Simply consistent :-)

[Dieter]

Please see my other post in reply to Pauli's.

Dieter

[Walter B]

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.

[Ángel Martin]

Excellent logic - I used the same convention in the 41Z with functions like ZABS, ZARG, etc. returning zero as imaginary part.

[Walter B]

Muchas grazias :-)

[Marcus von Cube, Germany]

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!

[Paul Dale]

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

[Walter B]

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?

[Valentin Albillo]

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.