HP Forum Archive 20

[ Return to Index | Top of Index ]

Public apology to Valentin Albillo Message #1 Posted by fhub on 13 Nov 2011, 2:52 p.m. 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.

Re: Public apology to Valentin Albillo Message #2 Posted by Marcus von Cube, Germany on 13 Nov 2011, 3:18 p.m., in response to message #1 by fhub 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."

Re: Public apology to Valentin Albillo Message #3 Posted by Alexander Oestert on 13 Nov 2011, 3:36 p.m., in response to message #1 by fhub :-)

Re: Public apology to Valentin Albillo Message #4 Posted by Paul Dale on 13 Nov 2011, 4:55 p.m., in response to message #1 by fhub 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

Re: Public apology to Valentin Albillo Message #5 Posted by Marcus von Cube, Germany on 13 Nov 2011, 5:01 p.m., in response to message #4 by Paul Dale Most probably superseded by cABS and R->P. But the function may be replaced by: cABS (or R->P) x<>y DROP.

Re: Public apology to Valentin Albillo Message #6 Posted by Paul Dale on 13 Nov 2011, 5:16 p.m., in response to message #5 by Marcus von Cube, Germany "cABS +" is one step shorter :-) Alas, DROPY went away a long time ago. - Pauli

Re: HYPOT and complex ABS Message #7 Posted by Dieter on 13 Nov 2011, 5:46 p.m., in response to message #4 by Paul Dale 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.

Re: HYPOT and complex ABS Message #8 Posted by Bart (UK) on 14 Nov 2011, 5:05 a.m., in response to message #7 by Dieter 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).

Re: Public apology to Valentin Albillo Message #9 Posted by Walter B on 13 Nov 2011, 5:47 p.m., in response to message #1 by fhub 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 :-)

Re: Public apology to Valentin Albillo Message #10 Posted by Dieter on 13 Nov 2011, 5:48 p.m., in response to message #9 by Walter B Please see my other post in reply to Pauli's. Dieter

Re: Public apology to Valentin Albillo Message #11 Posted by Walter B on 13 Nov 2011, 5:57 p.m., in response to message #10 by Dieter 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.

Re: Public apology to Valentin Albillo Message #12 Posted by Ángel Martin on 14 Nov 2011, 2:06 a.m., in response to message #11 by Walter B Excellent logic - I used the same convention in the 41Z with functions like ZABS, ZARG, etc. returning zero as imaginary part.

Re: Public apology to Valentin Albillo Message #13 Posted by Walter B on 14 Nov 2011, 1:06 p.m., in response to message #12 by Ángel Martin Muchas grazias :-)

WP 34S complex mode Message #14 Posted by Marcus von Cube, Germany on 14 Nov 2011, 2:09 a.m., in response to message #11 by Walter B 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!

Re: WP 34S complex mode Message #15 Posted by Paul Dale on 14 Nov 2011, 2:36 a.m., in response to message #14 by Marcus von Cube, Germany 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

Re: WP 34S complex mode Message #16 Posted by Walter B on 14 Nov 2011, 1:08 p.m., in response to message #15 by Paul Dale 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?

Re: Public apology to Valentin Albillo Message #17 Posted by Valentin Albillo on 14 Nov 2011, 9:53 a.m., in response to message #1 by fhub 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.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall