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 AllPole 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/MATH657?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=13096621#comment13096621
]
> > >
> > > Gilles commented on MATH657:
> > > 
> > >
> > > 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, MATH164 triggered a change for that same reason.
> > >
> > > Arne PlĂ¶se is a user and [reportedMATH620] 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 MATH620).
> > >
> > >
> > >> Division by zero
> > >> 
> > >>
> > >> Key: MATH657
> > >> URL: https://issues.apache.org/jira/browse/MATH657
> > >> 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 [herehttp://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, email: devunsubscribe@commons.apache.org
> > For additional commands, email: devhelp@commons.apache.org
> >
>
>
>
> 
> To unsubscribe, email: devunsubscribe@commons.apache.org
> For additional commands, email: devhelp@commons.apache.org
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
