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
