To make things clear here some octave (matlab as well) calculation with complex:
octave:1> a = Inf + sqrt(-Inf) a = Inf + Infi octave:2> a * a ans = NaN + Infi octave:3> a = Inf + sqrt(-1) a = Inf + 1i octave:4> a * a ans = Inf + Infi octave:5> a = 1 + sqrt(-Inf) a = 1 + Infi octave:6> a * a ans = -Inf + Infi octave:7> a = 1 - sqrt(-Inf) a = 1 - Infi octave:8> a * a ans = -Inf - Infi Maybe Im wrong but I thought that was the result I could expect from commons math too. In electrical engineering there is a difference if you have + or - 90 degree phase shift, the tan will be +infinity or -infinity... If you math guys tell me that there is really no difference with complex numbers - I can live with it (Even if I dont understand why ;-)). Am Montag, den 05.09.2011, 12:45 +0200 schrieb Arne Ploese: > Sorry answering that late, but I was busy... > > So simply I try to write a lib that doing some DSP stuff. I took some > *.m files from the octave signaling package ant converted them to java > (digital filters aka. Butterworth ...) there is a litte bit calculation > needed. > > So my problem is: if the commans.math.Complec behaves differently from > the octave implementation, I dont know what I get. Currently it looks to > me that I will have to implement a separate Complex class - I cant see a > clean way to enhance Complex without side effects. > > For All-Pole filters I need some matrix arithmetic, which is currently > only in the jama packages (solve a non symmetric matrix). > For others I need FFT. So currently I have to use at least two > implementations of Complex (octave and commons jama and FFT). > > Thats my problem, plain and simple... > > Arne > > Am Samstag, den 03.09.2011, 08:10 -0700 schrieb Phil Steitz: > > On 9/3/11 2:30 AM, Gilles (JIRA) wrote: > > > [ > > > https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096621#comment-13096621 > > > ] > > > > > > Gilles commented on MATH-657: > > > ----------------------------- > > > > > > I've just posted a mail on "dev". > > > > Should be discussed on the dev list. We should not be trying to > > have discussions on API changes on JIRA tickets. That is not what > > JIRA is for. It is an unwritten (well, probably is actually written > > down somewhere by now) rule @apache that if a decision "did not > > happen on the dev list, then it did not happen." We should be > > talking about API design issues on this list, not opening JIRAs each > > time we think an API should be changed and trying to have the > > discussion on the JIRA ticket. > > > > > > IMO, the main argument is consistency. Also with how reals (i.e. > > > {{double}}) work; IIUC, MATH-164 triggered a change for that same reason. > > > > > > Arne Plöse is a user and [reported|MATH-620] that the previous behaviour > > > was not fine for him. > > > > What exactly was the practical problem? Arne, care to elaborate? > > > > > > I don't think that this one change can have a discernible performance > > > impact. > > > It might not be necessary to map all {{Complex}} instances that have an > > > infinite component to a single object. I pointed it as a convenient > > > justification for fixing a bug > > > > Not so clear it is a "bug" - the only way to characterize it as such > > is to model the space as compactified. > > > > I notice now that multiply sort of behaves this way, and as I said > > on the ticket, we have already defined "INF" so an argument could be > > made that we are partly there already. I would like to understand > > the practical arguments pro and con - and by "practical" I mean > > examples of how the proposed change and any others impact actual > > uses of the class in applications. I have reviewed my own > > applications and for those, there is no immediate impact (other than > > performance hit in division and complex construction), but I worry a > > little about losing the ability to represent directed infinities if > > we decide to really aim for "consistency" here. I guess we could > > retain directed infinities by adding a directed INF with an argument > > attribute, but that would again add overhead to several operations. > > > > At this point, I would like to see r1164756 reverted until we have > > agreed on this change. > > > > Phil > > > (and for not fixing the other two points reported by Arne in MATH-620). > > > > > > > > >> Division by zero > > >> ---------------- > > >> > > >> Key: MATH-657 > > >> URL: https://issues.apache.org/jira/browse/MATH-657 > > >> Project: Commons Math > > >> Issue Type: Bug > > >> Reporter: Gilles > > >> Assignee: Gilles > > >> Priority: Minor > > >> Fix For: 3.0 > > >> > > >> > > >> In class {{Complex}}, division by zero always returns NaN. I think that > > >> it should return NaN only when the numerator is also {{ZERO}}, otherwise > > >> the result should be {{INF}}. See > > >> [here|http://en.wikipedia.org/wiki/Riemann_sphere#Arithmetic_operations]. > > > -- > > > This message is automatically generated by JIRA. > > > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
