commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Ploese <>
Subject Re: [math] Complex division WASRe [jira] [Commented] (MATH-657) Division by zero
Date Mon, 05 Sep 2011 10:45:12 GMT
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

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


Am Samstag, den 03.09.2011, 08:10 -0700 schrieb Phil Steitz: 
> On 9/3/11 2:30 AM, Gilles (JIRA) wrote:
> >     [
> >
> > 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:
> >>             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|].
> > --
> > This message is automatically generated by JIRA.
> > For more information on JIRA, see:
> >
> >        
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message