You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2011/09/03 17:10:59 UTC
[math] Complex division WASRe [jira] [Commented] (MATH-657) Division
by zero
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division WASRe [jira] [Commented] (MATH-657) Division
by zero
Posted by Phil Steitz <ph...@gmail.com>.
On 9/5/11 7:21 AM, Gilles Sadowski wrote:
> On Mon, Sep 05, 2011 at 02:15:30PM +0200, Arne Ploese wrote:
>> 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.
> It seems that the above outputs result from a direct application of the
> computational formula (whereas.
> As I suggested on JIRA, a complete set of comparisons, as a unit test, would
> be most helpful to check where the discrepancies occur.
>
>> 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 ;-)).
> What would be really interesting is to know when the final result of the
> DSP algorithm differ between Octave and the Java translation using CM.
Right, that's what I am having trouble finding good examples for.
My own apps don't seem to be affected by the different choices - but
they tend to treat "divergence to an infinity" or "divergence to
NaN" similarly, so are not good test cases. I suspect that in most
practical use cases, the differences in behavior will most likely be
on exception paths, but I would be very interested in hearing about
examples where people actually depend on either a) attempts to
faithfully model the Riemann Sphere (so infinities get collapsed) or
b) computation with signed infinities and even elements including
NaNs and infinities (as C99x appears to allow).
I can't find a clear statement in the Octave docs on exactly how
complex arithmetic (or other) functions are defined. A decent
hypothesis is that it uses GCC under the covers, so it should be
more or less trying to do C99x (though depending on the version,
there are some spec compliance bugs reported). Could be I am
looking in the wrong place [1] for the docs. Does anyone know where
this is documented?
Phil
[1] http://www.gnu.org/software/octave/doc/interpreter/
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (OT)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> Well that is interesting. One of my first involvements with CM was
> suggesting just this. The suggestion was roundly shouted down. The Mikkel
> suggested it. It was declined.
>
> I am glad that you finally succeeded.
But you were there too! I was not discussing this with myself :-). Nor did I
start the discussion, because I did not have any use for sampling; I just
happened to agree that it was natural to get samples from a distribution.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (OT)
Posted by Ted Dunning <te...@gmail.com>.
Well that is interesting. One of my first involvements with CM was
suggesting just this. The suggestion was roundly shouted down. The Mikkel
suggested it. It was declined.
I am glad that you finally succeeded.
On Sun, Sep 11, 2011 at 3:54 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> >
> > Another example comes from the random distributions. The current design
> > separates generating values from evaluating CDF's even though users think
> of
> > those as operations on the same object.
>
> I remember that one round of this discussion happened when I started to
> contribute to CM. And I had been in favour of providing an interface to
> generated data inside the distribution objects. This led to a "sample"
> method being available in all those objects. Is it still not satisfactory?
>
Re: [Math] Two "Complex" classes? (OT)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sun, Sep 11, 2011 at 02:50:56PM -0700, Ted Dunning wrote:
> On Sun, Sep 11, 2011 at 2:37 PM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
> > Discussions on this list are sufficiently tense that we probably don't need
> > to have a flame war on OO. :-}
> >
>
> And I would hate to start that given that I think the discussions go too
> long in any case.
>
>
> > As for not being focused on the end user, I don't think that it is true.
> >
>
> Well, the recent discussion of exceptions for Cholesky decomposition was a
> great example. The suggestion was to throw an exception that basically said
> "one number that you have no idea of is less than another idea that is an
> obscure combination of stuff you input". The argument was that this was
> "more precise". The user centered exception is "you input was not positive
> definite".
My bad; I tried to be (too) nice to the end-user as per the numerous times
repeated argument that they should not have to turn to the source code in
order to figure out why their input was wrong (by input, I mean the
"threshold"). If the threshold is not the end-user's business, then why
allow to set it? If allowing to set it, why not report that changing it
might change the behaviour?
Is there is a way to deduce _the_ correct value of the threshold given the
input matrix?
>
> Another example comes from the random distributions. The current design
> separates generating values from evaluating CDF's even though users think of
> those as operations on the same object.
I remember that one round of this discussion happened when I started to
contribute to CM. And I had been in favour of providing an interface to
generated data inside the distribution objects. This led to a "sample"
method being available in all those objects. Is it still not satisfactory?
> Moreover, there is an intricate
> lattice of (unique) implementations and interfaces that the user has to
> figure out when all they want is a distribution. This isn't user centered
> design. And it doesn't facilitate improvement or back compatibility.
We all agree that when a single implementation of an interface exists, it
should replace it.
I bet that your patch to fix this will be readily applied. ;-)
>
> Sometimes, it's so focused towards user applications that any other
> > consideration is overriden.
> >
>
> I can't remember such a case.
You don't have to remember one; the discussion happening right now about
preset tables for "FastMath" is a perfect example of rushing to please a
user.
>
> > One of the dangers of only focusing on end-users is adding features
> > without
> > rhyme or reason; that will ultimately leads to unnecessarily complex and
> > consequently unmaintainable code, resulting in the death of the project,
> > with the consequence that the beloved user will be left with nothing.
> >
>
> That isn't user centered. User centered means implementing what the user
> actually needs and will use. Need and use of a function means that it has
> at least some reason. Rhyme comes from the design elements which cannot be
> forgotten.
IMO, this is backwards: I don't think that a general-purpose library can be
based purely on practical requirements; there needs to be an overall design,
which the end-user might not care about, but which will guarantee long-term
viability.
If the design is sound, then forgotten elements can be added easily; if they
can't, that means that it's time to refactor, as I said in the previous
message.
> Adding frills and filips is the opposite of user centered design.
What I meant is: trying to twist the design to accomodate what does not fit.
[For example, compare the root solvers in CM 2.2 and in trunk.]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Ted Dunning <te...@gmail.com>.
No. I have to admit that I haven't looked at these classes for a long time.
I am glad to hear that sampling is in the distributions.
On Sun, Sep 11, 2011 at 3:09 PM, Phil Steitz <ph...@gmail.com> wrote:
> Another example comes from the random distributions. The current design
> separates generating values from evaluating CDF's even though users think
> of
> those as operations on the same object. Moreover, there is an intricate
> lattice of (unique) implementations and interfaces that the user has to
> figure out when all they want is a distribution. This isn't user centered
> design. And it doesn't facilitate improvement or back compatibility.
>
> Have you looked at the code in trunk for the distributions? Does it
> still need to be made easier to use? We added sampling directly to
> the distribution classes. If it still looks too hard to use,
> patches are welcome as we prepare for 3.0.
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Phil Steitz <ph...@gmail.com>.
Another example comes from the random distributions. The current design
separates generating values from evaluating CDF's even though users think of
those as operations on the same object. Moreover, there is an intricate
lattice of (unique) implementations and interfaces that the user has to
figure out when all they want is a distribution. This isn't user centered
design. And it doesn't facilitate improvement or back compatibility.
Have you looked at the code in trunk for the distributions? Does it
still need to be made easier to use? We added sampling directly to
the distribution classes. If it still looks too hard to use,
patches are welcome as we prepare for 3.0.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Ted Dunning <te...@gmail.com>.
On Sun, Sep 11, 2011 at 2:37 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> Discussions on this list are sufficiently tense that we probably don't need
> to have a flame war on OO. :-}
>
And I would hate to start that given that I think the discussions go too
long in any case.
> As for not being focused on the end user, I don't think that it is true.
>
Well, the recent discussion of exceptions for Cholesky decomposition was a
great example. The suggestion was to throw an exception that basically said
"one number that you have no idea of is less than another idea that is an
obscure combination of stuff you input". The argument was that this was
"more precise". The user centered exception is "you input was not positive
definite".
Another example comes from the random distributions. The current design
separates generating values from evaluating CDF's even though users think of
those as operations on the same object. Moreover, there is an intricate
lattice of (unique) implementations and interfaces that the user has to
figure out when all they want is a distribution. This isn't user centered
design. And it doesn't facilitate improvement or back compatibility.
Sometimes, it's so focused towards user applications that any other
> consideration is overriden.
>
I can't remember such a case.
> One of the dangers of only focusing on end-users is adding features
> without
> rhyme or reason; that will ultimately leads to unnecessarily complex and
> consequently unmaintainable code, resulting in the death of the project,
> with the consequence that the beloved user will be left with nothing.
>
That isn't user centered. User centered means implementing what the user
actually needs and will use. Need and use of a function means that it has
at least some reason. Rhyme comes from the design elements which cannot be
forgotten.
Adding frills and filips is the opposite of user centered design.
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi Ted.
> Nah... I just meant get some usable code done before the inevitable
> discussion winds down. Discussions about designs in commons math tend to
> follow the pattern of a) proposing an OK design, b) proposing a fine
> improvement, and then c) iterating forever on hair-splitting details. The
> final result is rarely as good as even (a), much less (b).
I can more or less agree on the symptoms described above.
> The final design
> also tends to be very strongly focussed on obscure object-orientated design
> orthodoxy and not at all focussed on the end user of the library.
However, I would not derive the same diagnosis.
[Well, in my view, much of the hair-splitting comes from not enough of OO
design, in the sense that when it is recognized that the design is lacking,
it might be necessary to heavily refactor, which almost by definition
clashes with backward compatibility requirements.]
Discussions on this list are sufficiently tense that we probably don't need
to have a flame war on OO. :-}
As for not being focused on the end user, I don't think that it is true.
Sometimes, it's so focused towards user applications that any other
consideration is overriden.
One of the dangers of only focusing on end-users is adding features without
rhyme or reason; that will ultimately leads to unnecessarily complex and
consequently unmaintainable code, resulting in the death of the project,
with the consequence that the beloved user will be left with nothing.
> [...]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Ted Dunning <te...@gmail.com>.
Nah... I just meant get some usable code done before the inevitable
discussion winds down. Discussions about designs in commons math tend to
follow the pattern of a) proposing an OK design, b) proposing a fine
improvement, and then c) iterating forever on hair-splitting details. The
final result is rarely as good as even (a), much less (b). The final design
also tends to be very strongly focussed on obscure object-orientated design
orthodoxy and not at all focussed on the end user of the library.
So much suggestion is that we are now at (b) and somebody needs to code
something up quick and not wait for (c) to finish.
On Sun, Sep 11, 2011 at 6:51 AM, Phil Steitz <ph...@gmail.com> wrote:
> On 9/10/11 3:19 PM, Ted Dunning wrote:
> > Sounds great.
> >
> > Especially if the implementation of the sub-class is deferred until the
> > first is completed.
>
> What exactly do you mean by "the first is completed" - reverting
> what is in trunk now to eliminate the checks / recodes that it does?
>
> Phil
> >
> > On Sat, Sep 10, 2011 at 2:51 PM, Gilles Sadowski <
> > gilles@harfang.homelinux.org> wrote:
> >
> >> Hello.
> >>
> >> Coming back to this with a simple idea that may hopefully satisfy
> everyone.
> >>
> >> What do you think of having one class that performs all operations by
> >> directly applying the computational formulae, without worrying about NaN
> >> or infinities. This would be represent the complex field, would be
> simple
> >> and most efficient for general use (not involving limiting cases), would
> be
> >> documented as "producing undefined results in limiting cases" or
> "producing
> >> the results expected from direct application of the formulae". The
> latter
> >> would probably automatically keep track of all combinations of NaNs and
> >> infinities (as seems to be the case in Octave).
> >>
> >> In a subclass of the above one, we would attempt to get a completely
> >> consistent representation of the extended complex numbers (one point at
> >> infinity). It would thus contain all the special handling of the
> limiting
> >> cases of the current "Complex" class (plus all the missing ones and
> related
> >> bug fixes).
> >>
> >>
> >> Regards,
> >> Gilles
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Phil Steitz <ph...@gmail.com>.
On 9/10/11 3:19 PM, Ted Dunning wrote:
> Sounds great.
>
> Especially if the implementation of the sub-class is deferred until the
> first is completed.
What exactly do you mean by "the first is completed" - reverting
what is in trunk now to eliminate the checks / recodes that it does?
Phil
>
> On Sat, Sep 10, 2011 at 2:51 PM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
>> Hello.
>>
>> Coming back to this with a simple idea that may hopefully satisfy everyone.
>>
>> What do you think of having one class that performs all operations by
>> directly applying the computational formulae, without worrying about NaN
>> or infinities. This would be represent the complex field, would be simple
>> and most efficient for general use (not involving limiting cases), would be
>> documented as "producing undefined results in limiting cases" or "producing
>> the results expected from direct application of the formulae". The latter
>> would probably automatically keep track of all combinations of NaNs and
>> infinities (as seems to be the case in Octave).
>>
>> In a subclass of the above one, we would attempt to get a completely
>> consistent representation of the extended complex numbers (one point at
>> infinity). It would thus contain all the special handling of the limiting
>> cases of the current "Complex" class (plus all the missing ones and related
>> bug fixes).
>>
>>
>> Regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Ted Dunning <te...@gmail.com>.
Sounds great.
Especially if the implementation of the sub-class is deferred until the
first is completed.
On Sat, Sep 10, 2011 at 2:51 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> Hello.
>
> Coming back to this with a simple idea that may hopefully satisfy everyone.
>
> What do you think of having one class that performs all operations by
> directly applying the computational formulae, without worrying about NaN
> or infinities. This would be represent the complex field, would be simple
> and most efficient for general use (not involving limiting cases), would be
> documented as "producing undefined results in limiting cases" or "producing
> the results expected from direct application of the formulae". The latter
> would probably automatically keep track of all combinations of NaNs and
> infinities (as seems to be the case in Octave).
>
> In a subclass of the above one, we would attempt to get a completely
> consistent representation of the extended complex numbers (one point at
> infinity). It would thus contain all the special handling of the limiting
> cases of the current "Complex" class (plus all the missing ones and related
> bug fixes).
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Two "Complex" classes?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> >>>
> >>> Coming back to this with a simple idea that may hopefully satisfy everyone.
> >>>
> >>> What do you think of having one class that performs all operations by
> >>> directly applying the computational formulae, without worrying about NaN
> >>> or infinities. This would be represent the complex field, would be simple
> >>> and most efficient for general use (not involving limiting cases), would be
> >>> documented as "producing undefined results in limiting cases" or "producing
> >>> the results expected from direct application of the formulae". The latter
> >>> would probably automatically keep track of all combinations of NaNs and
> >>> infinities (as seems to be the case in Octave).
> >>>
> >>> In a subclass of the above one, we would attempt to get a completely
> >>> consistent representation of the extended complex numbers (one point at
> >>> infinity). It would thus contain all the special handling of the limiting
> >>> cases of the current "Complex" class (plus all the missing ones and related
> >>> bug fixes).
> >> I agree that to make everyone happy we are going to have to do
> >> something like this, but I would suggest that either we need a third
> >> implementation or the second one should try to implement C99x [1],
> >> preserving signed infinities. I have never seen a fully consistent
> >> implementation of the Riemannian space and if what we want is
> >> consistency with C-based packages, we are better off biting the
> >> bullet and implementing C99x. That could be done by either someone
> >> using their employer or other resource to get hold of the spec or
> >> reverse engineering a C-based OSS implementation like GCC or R. So
> >> I am +1 to
> >>
> >> 0) strip out the recoding / checks in trunk, reverting to previous
> >> "apply formulas and return the results" approach, documenting as the
> >> trig functions now do. (If we do this, we should remember to reopen
> >> any tickets that led to the checks in trunk and either close them as
> >> WONT_FIX or refer to the proposed second implementation as the
> >> proposed fix)
> >> 1) implement C99x in a subclass
> >>
> >> If we choose to implement something other than C99x in the subclass,
> >> we need to agree on the spec for it. Given the vagueness in at
> >> least the draft version of the spec, even in 1), it may turn out to
> >> be best to choose a reference implementation to emulate. In either
> >> case, full documentation of behavior in the javadoc will be necessary.
> >>
> >> As I have said before, I am also fine - and would prefer- doing
> >> nothing, i.e. staying with the documented contracts that are in the
> >> trunk now, realizing that they are not consistent with either the
> >> full Riemannian view or C99x. I see both of these as having
> >> pitfalls and the value of these changes as not worth users of the
> >> main class having to make changes to their exception management code
> >> to accommodate the change. I can see I am in the minority here, so
> >> I am OK with the split implementation idea above.
> > To avoid (or delay) any burden on satisfied users of the "Complex" class, we
> > could leave it as-is for now and create a new "BasicComplex" that will
> > contain the "apply formulas and return the results" approach.
> >
> > Then, if time and motivation allows, gradually implement an
> > "ExtendedComplex" class and/or a "C99Complex" class.
> >
> > Only when that work is done (after the hair-splitting and all), can it be
> > decided to deprecate "Complex" (telling users that they will be better off
> > using one of the new classes).
>
> Sounds good to me. When all is said and done, we might think about
> extracting the (by then stable) interface and just allowing the
> multiple impls to all exist. Or have the Complex class expose
> factory methods to create instances with the "basic" or "extended"
> behavior. In any case, we don't have to decide that yet.
JIRA issue opened:
https://issues.apache.org/jira/browse/MATH-667
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes?
Posted by Phil Steitz <ph...@gmail.com>.
On 9/11/11 2:50 PM, Gilles Sadowski wrote:
> On Sun, Sep 11, 2011 at 07:21:20AM -0700, Phil Steitz wrote:
>> On 9/10/11 2:51 PM, Gilles Sadowski wrote:
>>> Hello.
>>>
>>> Coming back to this with a simple idea that may hopefully satisfy everyone.
>>>
>>> What do you think of having one class that performs all operations by
>>> directly applying the computational formulae, without worrying about NaN
>>> or infinities. This would be represent the complex field, would be simple
>>> and most efficient for general use (not involving limiting cases), would be
>>> documented as "producing undefined results in limiting cases" or "producing
>>> the results expected from direct application of the formulae". The latter
>>> would probably automatically keep track of all combinations of NaNs and
>>> infinities (as seems to be the case in Octave).
>>>
>>> In a subclass of the above one, we would attempt to get a completely
>>> consistent representation of the extended complex numbers (one point at
>>> infinity). It would thus contain all the special handling of the limiting
>>> cases of the current "Complex" class (plus all the missing ones and related
>>> bug fixes).
>> I agree that to make everyone happy we are going to have to do
>> something like this, but I would suggest that either we need a third
>> implementation or the second one should try to implement C99x [1],
>> preserving signed infinities. I have never seen a fully consistent
>> implementation of the Riemannian space and if what we want is
>> consistency with C-based packages, we are better off biting the
>> bullet and implementing C99x. That could be done by either someone
>> using their employer or other resource to get hold of the spec or
>> reverse engineering a C-based OSS implementation like GCC or R. So
>> I am +1 to
>>
>> 0) strip out the recoding / checks in trunk, reverting to previous
>> "apply formulas and return the results" approach, documenting as the
>> trig functions now do. (If we do this, we should remember to reopen
>> any tickets that led to the checks in trunk and either close them as
>> WONT_FIX or refer to the proposed second implementation as the
>> proposed fix)
>> 1) implement C99x in a subclass
>>
>> If we choose to implement something other than C99x in the subclass,
>> we need to agree on the spec for it. Given the vagueness in at
>> least the draft version of the spec, even in 1), it may turn out to
>> be best to choose a reference implementation to emulate. In either
>> case, full documentation of behavior in the javadoc will be necessary.
>>
>> As I have said before, I am also fine - and would prefer- doing
>> nothing, i.e. staying with the documented contracts that are in the
>> trunk now, realizing that they are not consistent with either the
>> full Riemannian view or C99x. I see both of these as having
>> pitfalls and the value of these changes as not worth users of the
>> main class having to make changes to their exception management code
>> to accommodate the change. I can see I am in the minority here, so
>> I am OK with the split implementation idea above.
> To avoid (or delay) any burden on satisfied users of the "Complex" class, we
> could leave it as-is for now and create a new "BasicComplex" that will
> contain the "apply formulas and return the results" approach.
>
> Then, if time and motivation allows, gradually implement an
> "ExtendedComplex" class and/or a "C99Complex" class.
>
> Only when that work is done (after the hair-splitting and all), can it be
> decided to deprecate "Complex" (telling users that they will be better off
> using one of the new classes).
Sounds good to me. When all is said and done, we might think about
extracting the (by then stable) interface and just allowing the
multiple impls to all exist. Or have the Complex class expose
factory methods to create instances with the "basic" or "extended"
behavior. In any case, we don't have to decide that yet.
Phil
>
>
> Gilles
>
>> [1] Quite likely, whatever is approved by now is called something
>> like "Annex X of C00.y" - what I am referring to is whatever
>> "informative" or normative guidance the current C spec provides for
>> complex arithmetic and standard functions.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sun, Sep 11, 2011 at 07:21:20AM -0700, Phil Steitz wrote:
> On 9/10/11 2:51 PM, Gilles Sadowski wrote:
> > Hello.
> >
> > Coming back to this with a simple idea that may hopefully satisfy everyone.
> >
> > What do you think of having one class that performs all operations by
> > directly applying the computational formulae, without worrying about NaN
> > or infinities. This would be represent the complex field, would be simple
> > and most efficient for general use (not involving limiting cases), would be
> > documented as "producing undefined results in limiting cases" or "producing
> > the results expected from direct application of the formulae". The latter
> > would probably automatically keep track of all combinations of NaNs and
> > infinities (as seems to be the case in Octave).
> >
> > In a subclass of the above one, we would attempt to get a completely
> > consistent representation of the extended complex numbers (one point at
> > infinity). It would thus contain all the special handling of the limiting
> > cases of the current "Complex" class (plus all the missing ones and related
> > bug fixes).
>
> I agree that to make everyone happy we are going to have to do
> something like this, but I would suggest that either we need a third
> implementation or the second one should try to implement C99x [1],
> preserving signed infinities. I have never seen a fully consistent
> implementation of the Riemannian space and if what we want is
> consistency with C-based packages, we are better off biting the
> bullet and implementing C99x. That could be done by either someone
> using their employer or other resource to get hold of the spec or
> reverse engineering a C-based OSS implementation like GCC or R. So
> I am +1 to
>
> 0) strip out the recoding / checks in trunk, reverting to previous
> "apply formulas and return the results" approach, documenting as the
> trig functions now do. (If we do this, we should remember to reopen
> any tickets that led to the checks in trunk and either close them as
> WONT_FIX or refer to the proposed second implementation as the
> proposed fix)
> 1) implement C99x in a subclass
>
> If we choose to implement something other than C99x in the subclass,
> we need to agree on the spec for it. Given the vagueness in at
> least the draft version of the spec, even in 1), it may turn out to
> be best to choose a reference implementation to emulate. In either
> case, full documentation of behavior in the javadoc will be necessary.
>
> As I have said before, I am also fine - and would prefer- doing
> nothing, i.e. staying with the documented contracts that are in the
> trunk now, realizing that they are not consistent with either the
> full Riemannian view or C99x. I see both of these as having
> pitfalls and the value of these changes as not worth users of the
> main class having to make changes to their exception management code
> to accommodate the change. I can see I am in the minority here, so
> I am OK with the split implementation idea above.
To avoid (or delay) any burden on satisfied users of the "Complex" class, we
could leave it as-is for now and create a new "BasicComplex" that will
contain the "apply formulas and return the results" approach.
Then, if time and motivation allows, gradually implement an
"ExtendedComplex" class and/or a "C99Complex" class.
Only when that work is done (after the hair-splitting and all), can it be
decided to deprecate "Complex" (telling users that they will be better off
using one of the new classes).
Gilles
>
> [1] Quite likely, whatever is approved by now is called something
> like "Annex X of C00.y" - what I am referring to is whatever
> "informative" or normative guidance the current C spec provides for
> complex arithmetic and standard functions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Phil Steitz <ph...@gmail.com>.
On 9/10/11 2:51 PM, Gilles Sadowski wrote:
> Hello.
>
> Coming back to this with a simple idea that may hopefully satisfy everyone.
>
> What do you think of having one class that performs all operations by
> directly applying the computational formulae, without worrying about NaN
> or infinities. This would be represent the complex field, would be simple
> and most efficient for general use (not involving limiting cases), would be
> documented as "producing undefined results in limiting cases" or "producing
> the results expected from direct application of the formulae". The latter
> would probably automatically keep track of all combinations of NaNs and
> infinities (as seems to be the case in Octave).
>
> In a subclass of the above one, we would attempt to get a completely
> consistent representation of the extended complex numbers (one point at
> infinity). It would thus contain all the special handling of the limiting
> cases of the current "Complex" class (plus all the missing ones and related
> bug fixes).
I agree that to make everyone happy we are going to have to do
something like this, but I would suggest that either we need a third
implementation or the second one should try to implement C99x [1],
preserving signed infinities. I have never seen a fully consistent
implementation of the Riemannian space and if what we want is
consistency with C-based packages, we are better off biting the
bullet and implementing C99x. That could be done by either someone
using their employer or other resource to get hold of the spec or
reverse engineering a C-based OSS implementation like GCC or R. So
I am +1 to
0) strip out the recoding / checks in trunk, reverting to previous
"apply formulas and return the results" approach, documenting as the
trig functions now do. (If we do this, we should remember to reopen
any tickets that led to the checks in trunk and either close them as
WONT_FIX or refer to the proposed second implementation as the
proposed fix)
1) implement C99x in a subclass
If we choose to implement something other than C99x in the subclass,
we need to agree on the spec for it. Given the vagueness in at
least the draft version of the spec, even in 1), it may turn out to
be best to choose a reference implementation to emulate. In either
case, full documentation of behavior in the javadoc will be necessary.
As I have said before, I am also fine - and would prefer- doing
nothing, i.e. staying with the documented contracts that are in the
trunk now, realizing that they are not consistent with either the
full Riemannian view or C99x. I see both of these as having
pitfalls and the value of these changes as not worth users of the
main class having to make changes to their exception management code
to accommodate the change. I can see I am in the minority here, so
I am OK with the split implementation idea above.
Phil
[1] Quite likely, whatever is approved by now is called something
like "Annex X of C00.y" - what I am referring to is whatever
"informative" or normative guidance the current C spec provides for
complex arithmetic and standard functions.
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
Coming back to this with a simple idea that may hopefully satisfy everyone.
What do you think of having one class that performs all operations by
directly applying the computational formulae, without worrying about NaN
or infinities. This would be represent the complex field, would be simple
and most efficient for general use (not involving limiting cases), would be
documented as "producing undefined results in limiting cases" or "producing
the results expected from direct application of the formulae". The latter
would probably automatically keep track of all combinations of NaNs and
infinities (as seems to be the case in Octave).
In a subclass of the above one, we would attempt to get a completely
consistent representation of the extended complex numbers (one point at
infinity). It would thus contain all the special handling of the limiting
cases of the current "Complex" class (plus all the missing ones and related
bug fixes).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division WASRe [jira] [Commented] (MATH-657)
Division by zero
Posted by Arne Ploese <ap...@gmx.de>.
I added the file ComplexOctaveTest.java to JIRA MATH-620.
What really will happen, if Inf and NaN values com up I dont know at
this point - the complex signal path is in its infancy at the moment ...
(I currently have no need for that)
Arne
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division WASRe [jira] [Commented] (MATH-657)
Division by zero
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Mon, Sep 05, 2011 at 02:15:30PM +0200, Arne Ploese wrote:
> 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.
It seems that the above outputs result from a direct application of the
computational formula (whereas.
As I suggested on JIRA, a complete set of comparisons, as a unit test, would
be most helpful to check where the discrepancies occur.
> 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 ;-)).
What would be really interesting is to know when the final result of the
DSP algorithm differ between Octave and the Java translation using CM.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division WASRe [jira] [Commented] (MATH-657)
Division by zero
Posted by Arne Ploese <ap...@gmx.de>.
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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division WASRe [jira] [Commented] (MATH-657)
Division by zero
Posted by Arne Ploese <ap...@gmx.de>.
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division
Posted by Phil Steitz <ph...@gmail.com>.
On 9/4/11 7:22 AM, Gilles Sadowski wrote:
> Hello Luc.
>
>>>>> [...]
>>>>>> The mathematical question is do we view our class as representing
>>>>>> the extended complex numbers. If we agree that the answer to that
>>>>>> question is yes,
>>>>> If you say "no", then my understanding is that the "Complex" class does not
>>>>> represent the complex number concept, unless *all* operation that encounter
>>>>> infinities result in "undefined behaviour" (i.e. return NaN).
>>>> Not necessarily. The Complex field does not include any "point at
>>>> infinity." There is a topological space that can be formed from the
>>>> Complex numbers by adding a point at infinity and extending
>>>> functions to include that point. This is what is sometimes called
>>>> the extended complex numbers and a common topology for the space is
>>>> represented by the Riemann Sphere. It is not obvious to me that it
>>>> is best for us to try to model this (sorry to repeat myself, but
>>>> this is the key point). If you really want to be *consistent* and
>>>> insist that it is a *bug* to return NaN for division by complex
>>>> zero, then you are insisting that we adopt this view. To be
>>>> consistent in that view, we need to change equals, all arithmetic
>>>> operations, and the exponential and trig functions as well. Our
>>>> implementations of those functions are based loosely on C99x, which
>>>> does not consistently represent the compactified space.
>>> No, I'm not insisting that we adopt one or the other view. I'm insisting
>>> that by having an "INF", it looks like the class represents the extended
>>> complex numbers. In which case, it is a bug.
>>> My main point is to not treat only _selected_ infinities as equal, but
>>> either not treat any infinities at all (complex field; doing as if Java
>>> did not provide "Double.POSITIVE_INFINITY") or treat them _all_ to be equal
>>> (compactified sphere; consistency with Java "double"; self-consistency).
>>>
>>>>>> The added "isZero" attribute is part of the performance
>>>>>> hit.
>>>>> Really? How much? What tests? Can I emit the possibility that testing a
>>>>> "boolean" might be a tiny bit faster than testing equality with "0.0"
>>>>> twice?
>>>> The hit is in the constructor, where every complex instance has to
>>>> run the code to set the property.
>>>>>> This, btw, is yet another reason to separate commits.
>>>>> OK, I take this as: You would have only "cleanly reverted" the Javadoc
>>>>> change, if it would have been separate. I'll thus commit back the rest.
>>>> Please do not add back the extra property.
>>> If performance is so central that you can't suffer an additional flag, we
>>> should *seriously* consider dropping the other two flags "isNaN" and
>>> "isInfinite" and let the computational formulae do their work: In most
>>> use cases, the result will be correct (at least, as correct as returning NaN
>>> for division by zero) and the performance will be *greatly* enhanced
>>> (comparing to the cost of my additional flag which you seem to consider as
>>> the straw that broke the camel's back).
>> I'm on the fence on this. I like both specific handling on
>> infinities and NaN, and performances. In fact, I would very much
>> like to have a complex primitive type directly supported by the
>> language and following C99 conventions, but it does not seem to
>> happen anytime.
>>
>> In the recent changes in [math], we have introduced several features
>> to deal with infinities and NaNs, so I guess our current focus is
>> towards completeness and the extended Complex set is the more
>> consistent with this.
> I'd just like to remind, after all the fuss, that the crux of the matter
> (leaving aside the additional flag issue) was to replace:
> ---CUT---
> final double c = divisor.getReal();
> final double d = divisor.getImaginary();
> if (c == 0.0 && d == 0.0) {
> return NaN;
> }
> ---CUT---
> with
> ---CUT---
> final double c = divisor.getReal();
> final double d = divisor.getImaginary();
> if (c == 0.0 && d == 0.0) {
> return (real == 0.0 && imaginary == 0.0) ? NaN : INF;
> }
> ---CUT---
>
> How this change could hurt existing users of "Complex" (and require a
> "clean" revert and endless arguing) is beyond me. There was a test case
> exercising the new behaviour and the old behaviour could be recovered easily
> if, in the end, the unobvious/inconsistent behaviour was to be retained
> (which would have entailed the addition in the Javadoc of a complete
> explanation as to why it was decided to be so).
>
>>> Please explain the rationale behind your insistence for not fixing this tiny
>>> issue (I don't mean going for complete consistency with the "compactified"
>>> view but just return INF for division by zero) on the basis of performance
>>> but find it nice to have dozens of unnecessary checks (because they are
>>> useful only for limiting cases similar to division by zero).
>>>
>>> Let me add that I find quite rude your indiscriminate reverting of my
>>> work. Whatever criticism you have with my additions in the "main" area, that
>>> did not mean that you could erase the changes in the "test" area.
>>> As for your rule with "-1 a commit" I maintain that it was not warranted
>>> here, where you could simply remind me to change what had to be, without
>>> touching the rest. That would just mean being polite. There are recent
>>> examples where changes were made without a JIRA issue and without discussion
>>> here; what would you say if I were to go and revert those just because there
>>> is such a rule?
>>> I would also be glad to read the opinion of others on this administrative
>>> question.
>> Please, don't overreact on this, both of you.
>>
>> All of us, Gilles, Phil, Bill, Mikkel, Greg, Sébastien, Ted, Dietmar
>> and others are trying to have a good math library. All of us have
>> different goals, different main topics of interest and different
>> views. There are far more things we share than things we disagree
>> upon and we should focus on these commons things.
>>
>> *Nobody* should take a different view, or a criticism, or even a -1
>> as a personal aggression.
> I took it so because I've never seen such a thing occur for anyone else.
> Was there a security breach that warranted the urgent deletion?
I apologize, Gilles. I honestly thought I was helping. By not just
doing a revision-based revert, you missed the javadoc change that
left the code in an inconsistent state. I did not think you would
be offended by this. I am sorry.
>
>> Text-based exchanges on a mailing list
>> lack tone, gesture, behavior that help understand the state of mind
>> of the peer with which we discuss.
> This is all the more reason to be careful about one's actions. Minimal
> respect for other team members should refrain from deleting their work,
> even if the usefulness is dubious.
>
>> I have met both of you
>> personally; I appreciate both of you. I know for sure that we go
>> forward much efficiently when we cool down than when we argue on
>> personal or behavioral ground.
> I agree; thank you for those appeasing words.
>
>
> Best regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello Luc.
> >>>[...]
> >>>>The mathematical question is do we view our class as representing
> >>>>the extended complex numbers. If we agree that the answer to that
> >>>>question is yes,
> >>>If you say "no", then my understanding is that the "Complex" class does not
> >>>represent the complex number concept, unless *all* operation that encounter
> >>>infinities result in "undefined behaviour" (i.e. return NaN).
> >>
> >>Not necessarily. The Complex field does not include any "point at
> >>infinity." There is a topological space that can be formed from the
> >>Complex numbers by adding a point at infinity and extending
> >>functions to include that point. This is what is sometimes called
> >>the extended complex numbers and a common topology for the space is
> >>represented by the Riemann Sphere. It is not obvious to me that it
> >>is best for us to try to model this (sorry to repeat myself, but
> >>this is the key point). If you really want to be *consistent* and
> >>insist that it is a *bug* to return NaN for division by complex
> >>zero, then you are insisting that we adopt this view. To be
> >>consistent in that view, we need to change equals, all arithmetic
> >>operations, and the exponential and trig functions as well. Our
> >>implementations of those functions are based loosely on C99x, which
> >>does not consistently represent the compactified space.
> >
> >No, I'm not insisting that we adopt one or the other view. I'm insisting
> >that by having an "INF", it looks like the class represents the extended
> >complex numbers. In which case, it is a bug.
> >My main point is to not treat only _selected_ infinities as equal, but
> >either not treat any infinities at all (complex field; doing as if Java
> >did not provide "Double.POSITIVE_INFINITY") or treat them _all_ to be equal
> >(compactified sphere; consistency with Java "double"; self-consistency).
> >
> >>>>The added "isZero" attribute is part of the performance
> >>>>hit.
> >>>Really? How much? What tests? Can I emit the possibility that testing a
> >>>"boolean" might be a tiny bit faster than testing equality with "0.0"
> >>>twice?
> >>
> >>The hit is in the constructor, where every complex instance has to
> >>run the code to set the property.
> >>>
> >>>>This, btw, is yet another reason to separate commits.
> >>>OK, I take this as: You would have only "cleanly reverted" the Javadoc
> >>>change, if it would have been separate. I'll thus commit back the rest.
> >>
> >>Please do not add back the extra property.
> >
> >If performance is so central that you can't suffer an additional flag, we
> >should *seriously* consider dropping the other two flags "isNaN" and
> >"isInfinite" and let the computational formulae do their work: In most
> >use cases, the result will be correct (at least, as correct as returning NaN
> >for division by zero) and the performance will be *greatly* enhanced
> >(comparing to the cost of my additional flag which you seem to consider as
> >the straw that broke the camel's back).
>
> I'm on the fence on this. I like both specific handling on
> infinities and NaN, and performances. In fact, I would very much
> like to have a complex primitive type directly supported by the
> language and following C99 conventions, but it does not seem to
> happen anytime.
>
> In the recent changes in [math], we have introduced several features
> to deal with infinities and NaNs, so I guess our current focus is
> towards completeness and the extended Complex set is the more
> consistent with this.
I'd just like to remind, after all the fuss, that the crux of the matter
(leaving aside the additional flag issue) was to replace:
---CUT---
final double c = divisor.getReal();
final double d = divisor.getImaginary();
if (c == 0.0 && d == 0.0) {
return NaN;
}
---CUT---
with
---CUT---
final double c = divisor.getReal();
final double d = divisor.getImaginary();
if (c == 0.0 && d == 0.0) {
return (real == 0.0 && imaginary == 0.0) ? NaN : INF;
}
---CUT---
How this change could hurt existing users of "Complex" (and require a
"clean" revert and endless arguing) is beyond me. There was a test case
exercising the new behaviour and the old behaviour could be recovered easily
if, in the end, the unobvious/inconsistent behaviour was to be retained
(which would have entailed the addition in the Javadoc of a complete
explanation as to why it was decided to be so).
> >
> >Please explain the rationale behind your insistence for not fixing this tiny
> >issue (I don't mean going for complete consistency with the "compactified"
> >view but just return INF for division by zero) on the basis of performance
> >but find it nice to have dozens of unnecessary checks (because they are
> >useful only for limiting cases similar to division by zero).
> >
> >Let me add that I find quite rude your indiscriminate reverting of my
> >work. Whatever criticism you have with my additions in the "main" area, that
> >did not mean that you could erase the changes in the "test" area.
> >As for your rule with "-1 a commit" I maintain that it was not warranted
> >here, where you could simply remind me to change what had to be, without
> >touching the rest. That would just mean being polite. There are recent
> >examples where changes were made without a JIRA issue and without discussion
> >here; what would you say if I were to go and revert those just because there
> >is such a rule?
> >I would also be glad to read the opinion of others on this administrative
> >question.
>
> Please, don't overreact on this, both of you.
>
> All of us, Gilles, Phil, Bill, Mikkel, Greg, Sébastien, Ted, Dietmar
> and others are trying to have a good math library. All of us have
> different goals, different main topics of interest and different
> views. There are far more things we share than things we disagree
> upon and we should focus on these commons things.
>
> *Nobody* should take a different view, or a criticism, or even a -1
> as a personal aggression.
I took it so because I've never seen such a thing occur for anyone else.
Was there a security breach that warranted the urgent deletion?
> Text-based exchanges on a mailing list
> lack tone, gesture, behavior that help understand the state of mind
> of the peer with which we discuss.
This is all the more reason to be careful about one's actions. Minimal
respect for other team members should refrain from deleting their work,
even if the usefulness is dubious.
> I have met both of you
> personally; I appreciate both of you. I know for sure that we go
> forward much efficiently when we cool down than when we argue on
> personal or behavioral ground.
I agree; thank you for those appeasing words.
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division
Posted by Phil Steitz <ph...@gmail.com>.
On 9/4/11 4:50 AM, Luc Maisonobe wrote:
> Hi Gilles,
>
> Le 04/09/2011 12:28, Gilles Sadowski a écrit :
>>>> [...]
>>>>> The mathematical question is do we view our class as representing
>>>>> the extended complex numbers. If we agree that the answer to
>>>>> that
>>>>> question is yes,
>>>> If you say "no", then my understanding is that the "Complex"
>>>> class does not
>>>> represent the complex number concept, unless *all* operation
>>>> that encounter
>>>> infinities result in "undefined behaviour" (i.e. return NaN).
>>>
>>> Not necessarily. The Complex field does not include any "point at
>>> infinity." There is a topological space that can be formed from
>>> the
>>> Complex numbers by adding a point at infinity and extending
>>> functions to include that point. This is what is sometimes called
>>> the extended complex numbers and a common topology for the space is
>>> represented by the Riemann Sphere. It is not obvious to me that it
>>> is best for us to try to model this (sorry to repeat myself, but
>>> this is the key point). If you really want to be *consistent* and
>>> insist that it is a *bug* to return NaN for division by complex
>>> zero, then you are insisting that we adopt this view. To be
>>> consistent in that view, we need to change equals, all arithmetic
>>> operations, and the exponential and trig functions as well. Our
>>> implementations of those functions are based loosely on C99x, which
>>> does not consistently represent the compactified space.
>>
>> No, I'm not insisting that we adopt one or the other view. I'm
>> insisting
>> that by having an "INF", it looks like the class represents the
>> extended
>> complex numbers. In which case, it is a bug.
>> My main point is to not treat only _selected_ infinities as
>> equal, but
>> either not treat any infinities at all (complex field; doing as
>> if Java
>> did not provide "Double.POSITIVE_INFINITY") or treat them _all_
>> to be equal
>> (compactified sphere; consistency with Java "double";
>> self-consistency).
>>
>>>>> The added "isZero" attribute is part of the performance
>>>>> hit.
>>>> Really? How much? What tests? Can I emit the possibility that
>>>> testing a
>>>> "boolean" might be a tiny bit faster than testing equality with
>>>> "0.0"
>>>> twice?
>>>
>>> The hit is in the constructor, where every complex instance has to
>>> run the code to set the property.
>>>>
>>>>> This, btw, is yet another reason to separate commits.
>>>> OK, I take this as: You would have only "cleanly reverted" the
>>>> Javadoc
>>>> change, if it would have been separate. I'll thus commit back
>>>> the rest.
>>>
>>> Please do not add back the extra property.
>>
>> If performance is so central that you can't suffer an additional
>> flag, we
>> should *seriously* consider dropping the other two flags "isNaN" and
>> "isInfinite" and let the computational formulae do their work: In
>> most
>> use cases, the result will be correct (at least, as correct as
>> returning NaN
>> for division by zero) and the performance will be *greatly* enhanced
>> (comparing to the cost of my additional flag which you seem to
>> consider as
>> the straw that broke the camel's back).
>
> I'm on the fence on this. I like both specific handling on
> infinities and NaN, and performances. In fact, I would very much
> like to have a complex primitive type directly supported by the
> language and following C99 conventions, but it does not seem to
> happen anytime.
>
> In the recent changes in [math], we have introduced several
> features to deal with infinities and NaNs, so I guess our current
> focus is towards completeness and the extended Complex set is the
> more consistent with this.
I am not so sure this is the best path and I am now wondering
whether it may be best to revert to the "use simple computational
formulas and let the chips fall where they may" approach that we
used to have. The reason for this is that when you peel the onion,
you find a whole lot of changes necessary to try to model the
compactified space with any kind of mathematical reasonableness.
Also, as Gilles points out, we have already added a fair amount of
ad hoc stuff that has a performance cost. Finally, C99x does not
do really do this and I worry about apps that really do want to
maintain distinct infinities. Its too bad we don't have more vocal
users who actually use this class in applications or any of the
contributors to C99x who can chime in here.
I know the new C++ spec was just ratified and I am not sure what the
status of Annex G ended up there. When I last checked, it had not
been accepted as a standard yet and it was not universally loved.
Does anyone know? Here is a public link to a fairly recent draft
[1]. There is also a fair amount of publicly available commentary
(e.g. [2], [3], [4]). The draft spec is a little vague, but if you
read the sample code, it looks like the intent for z/0 is to return
a signed infinity (so my recollection that they are not really
"simply" modelling the Riemann sphere is correct). There are some
(apparently) strange treatments of NaNs as well - "recovering"
infinities from them and collapsing some values onto inf + infi.
The discussion in [2] brings out a little of the futility of trying
to maintain complete mathematical consistency when implementing
Complex functions in finite value spaces. This is what led me to
the conclusion back in the 1.x days that it would be best to just
stick with simple formulas and document clearly exactly what we compute.
I guess another option is to do what some C compilers do, which is
to enable some sort of "strict" compile time flag that could be
turned on for strict spec compliance and off for performance.
Another piece of research that we could do here is to look at what
gcc and python and other packages do. I did a comparison against R
and Colt before 1.1 [5], but I notice now that the current version
of R is a little less "NaN-happy."
Phil
[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1494.pdf
[2] http://drdobbs.com/cpp/184404993
[3] ftp://ftp.win.ua.ac.be/pub/preprints/03/criticism.pdf
[4] http://www-uxsup.csx.cam.ac.uk/courses/Arithmetic/paper_99.pdf
[5] http://wiki.apache.org/commons/math/1.1ReleasePlan
>
>>
>> Please explain the rationale behind your insistence for not
>> fixing this tiny
>> issue (I don't mean going for complete consistency with the
>> "compactified"
>> view but just return INF for division by zero) on the basis of
>> performance
>> but find it nice to have dozens of unnecessary checks (because
>> they are
>> useful only for limiting cases similar to division by zero).
>>
>> Let me add that I find quite rude your indiscriminate reverting
>> of my
>> work. Whatever criticism you have with my additions in the "main"
>> area, that
>> did not mean that you could erase the changes in the "test" area.
>> As for your rule with "-1 a commit" I maintain that it was not
>> warranted
>> here, where you could simply remind me to change what had to be,
>> without
>> touching the rest. That would just mean being polite. There are
>> recent
>> examples where changes were made without a JIRA issue and without
>> discussion
>> here; what would you say if I were to go and revert those just
>> because there
>> is such a rule?
>> I would also be glad to read the opinion of others on this
>> administrative
>> question.
>
> Please, don't overreact on this, both of you.
>
> All of us, Gilles, Phil, Bill, Mikkel, Greg, Sébastien, Ted,
> Dietmar and others are trying to have a good math library. All of
> us have different goals, different main topics of interest and
> different views. There are far more things we share than things we
> disagree upon and we should focus on these commons things.
>
> *Nobody* should take a different view, or a criticism, or even a
> -1 as a personal aggression. Text-based exchanges on a mailing
> list lack tone, gesture, behavior that help understand the state
> of mind of the peer with which we discuss. I have met both of you
> personally; I appreciate both of you. I know for sure that we go
> forward much efficiently when we cool down than when we argue on
> personal or behavioral ground.
>
> Luc
>
>>
>>>> [...]
>>
>> Gilles
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi Gilles,
Le 04/09/2011 12:28, Gilles Sadowski a écrit :
>>> [...]
>>>> The mathematical question is do we view our class as representing
>>>> the extended complex numbers. If we agree that the answer to that
>>>> question is yes,
>>> If you say "no", then my understanding is that the "Complex" class does not
>>> represent the complex number concept, unless *all* operation that encounter
>>> infinities result in "undefined behaviour" (i.e. return NaN).
>>
>> Not necessarily. The Complex field does not include any "point at
>> infinity." There is a topological space that can be formed from the
>> Complex numbers by adding a point at infinity and extending
>> functions to include that point. This is what is sometimes called
>> the extended complex numbers and a common topology for the space is
>> represented by the Riemann Sphere. It is not obvious to me that it
>> is best for us to try to model this (sorry to repeat myself, but
>> this is the key point). If you really want to be *consistent* and
>> insist that it is a *bug* to return NaN for division by complex
>> zero, then you are insisting that we adopt this view. To be
>> consistent in that view, we need to change equals, all arithmetic
>> operations, and the exponential and trig functions as well. Our
>> implementations of those functions are based loosely on C99x, which
>> does not consistently represent the compactified space.
>
> No, I'm not insisting that we adopt one or the other view. I'm insisting
> that by having an "INF", it looks like the class represents the extended
> complex numbers. In which case, it is a bug.
> My main point is to not treat only _selected_ infinities as equal, but
> either not treat any infinities at all (complex field; doing as if Java
> did not provide "Double.POSITIVE_INFINITY") or treat them _all_ to be equal
> (compactified sphere; consistency with Java "double"; self-consistency).
>
>>>> The added "isZero" attribute is part of the performance
>>>> hit.
>>> Really? How much? What tests? Can I emit the possibility that testing a
>>> "boolean" might be a tiny bit faster than testing equality with "0.0"
>>> twice?
>>
>> The hit is in the constructor, where every complex instance has to
>> run the code to set the property.
>>>
>>>> This, btw, is yet another reason to separate commits.
>>> OK, I take this as: You would have only "cleanly reverted" the Javadoc
>>> change, if it would have been separate. I'll thus commit back the rest.
>>
>> Please do not add back the extra property.
>
> If performance is so central that you can't suffer an additional flag, we
> should *seriously* consider dropping the other two flags "isNaN" and
> "isInfinite" and let the computational formulae do their work: In most
> use cases, the result will be correct (at least, as correct as returning NaN
> for division by zero) and the performance will be *greatly* enhanced
> (comparing to the cost of my additional flag which you seem to consider as
> the straw that broke the camel's back).
I'm on the fence on this. I like both specific handling on infinities
and NaN, and performances. In fact, I would very much like to have a
complex primitive type directly supported by the language and following
C99 conventions, but it does not seem to happen anytime.
In the recent changes in [math], we have introduced several features to
deal with infinities and NaNs, so I guess our current focus is towards
completeness and the extended Complex set is the more consistent with this.
>
> Please explain the rationale behind your insistence for not fixing this tiny
> issue (I don't mean going for complete consistency with the "compactified"
> view but just return INF for division by zero) on the basis of performance
> but find it nice to have dozens of unnecessary checks (because they are
> useful only for limiting cases similar to division by zero).
>
> Let me add that I find quite rude your indiscriminate reverting of my
> work. Whatever criticism you have with my additions in the "main" area, that
> did not mean that you could erase the changes in the "test" area.
> As for your rule with "-1 a commit" I maintain that it was not warranted
> here, where you could simply remind me to change what had to be, without
> touching the rest. That would just mean being polite. There are recent
> examples where changes were made without a JIRA issue and without discussion
> here; what would you say if I were to go and revert those just because there
> is such a rule?
> I would also be glad to read the opinion of others on this administrative
> question.
Please, don't overreact on this, both of you.
All of us, Gilles, Phil, Bill, Mikkel, Greg, Sébastien, Ted, Dietmar and
others are trying to have a good math library. All of us have different
goals, different main topics of interest and different views. There are
far more things we share than things we disagree upon and we should
focus on these commons things.
*Nobody* should take a different view, or a criticism, or even a -1 as a
personal aggression. Text-based exchanges on a mailing list lack tone,
gesture, behavior that help understand the state of mind of the peer
with which we discuss. I have met both of you personally; I appreciate
both of you. I know for sure that we go forward much efficiently when we
cool down than when we argue on personal or behavioral ground.
Luc
>
>>> [...]
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > [...]
> >> The mathematical question is do we view our class as representing
> >> the extended complex numbers. If we agree that the answer to that
> >> question is yes,
> > If you say "no", then my understanding is that the "Complex" class does not
> > represent the complex number concept, unless *all* operation that encounter
> > infinities result in "undefined behaviour" (i.e. return NaN).
>
> Not necessarily. The Complex field does not include any "point at
> infinity." There is a topological space that can be formed from the
> Complex numbers by adding a point at infinity and extending
> functions to include that point. This is what is sometimes called
> the extended complex numbers and a common topology for the space is
> represented by the Riemann Sphere. It is not obvious to me that it
> is best for us to try to model this (sorry to repeat myself, but
> this is the key point). If you really want to be *consistent* and
> insist that it is a *bug* to return NaN for division by complex
> zero, then you are insisting that we adopt this view. To be
> consistent in that view, we need to change equals, all arithmetic
> operations, and the exponential and trig functions as well. Our
> implementations of those functions are based loosely on C99x, which
> does not consistently represent the compactified space.
No, I'm not insisting that we adopt one or the other view. I'm insisting
that by having an "INF", it looks like the class represents the extended
complex numbers. In which case, it is a bug.
My main point is to not treat only _selected_ infinities as equal, but
either not treat any infinities at all (complex field; doing as if Java
did not provide "Double.POSITIVE_INFINITY") or treat them _all_ to be equal
(compactified sphere; consistency with Java "double"; self-consistency).
> >> The added "isZero" attribute is part of the performance
> >> hit.
> > Really? How much? What tests? Can I emit the possibility that testing a
> > "boolean" might be a tiny bit faster than testing equality with "0.0"
> > twice?
>
> The hit is in the constructor, where every complex instance has to
> run the code to set the property.
> >
> >> This, btw, is yet another reason to separate commits.
> > OK, I take this as: You would have only "cleanly reverted" the Javadoc
> > change, if it would have been separate. I'll thus commit back the rest.
>
> Please do not add back the extra property.
If performance is so central that you can't suffer an additional flag, we
should *seriously* consider dropping the other two flags "isNaN" and
"isInfinite" and let the computational formulae do their work: In most
use cases, the result will be correct (at least, as correct as returning NaN
for division by zero) and the performance will be *greatly* enhanced
(comparing to the cost of my additional flag which you seem to consider as
the straw that broke the camel's back).
Please explain the rationale behind your insistence for not fixing this tiny
issue (I don't mean going for complete consistency with the "compactified"
view but just return INF for division by zero) on the basis of performance
but find it nice to have dozens of unnecessary checks (because they are
useful only for limiting cases similar to division by zero).
Let me add that I find quite rude your indiscriminate reverting of my
work. Whatever criticism you have with my additions in the "main" area, that
did not mean that you could erase the changes in the "test" area.
As for your rule with "-1 a commit" I maintain that it was not warranted
here, where you could simply remind me to change what had to be, without
touching the rest. That would just mean being polite. There are recent
examples where changes were made without a JIRA issue and without discussion
here; what would you say if I were to go and revert those just because there
is such a rule?
I would also be glad to read the opinion of others on this administrative
question.
> > [...]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division
Posted by Phil Steitz <ph...@gmail.com>.
On 9/4/11 6:01 AM, Gilles Sadowski wrote:
>>> [...]
>> The hit is in the constructor, where every complex instance has to
>> run the code to set the property.
> In fact, not only! If one can trust the mini-benchmark performed with
> "PerfTestUtils", the constructor with the additional flag is 2% slower.
> But using the flag in "divide" makes it also _slower_ (3 per 1000 even for
> division by zero), contrary to my expectations. [All of these operations
> taking the order of 10 to 60 microseconds, relativizing the loss of
> performance.]
The constructor hit is what I was most worried about, since it
impacts every instantiation. The other thing that I was thinking
explains the counter-intuitive result on the flag. Assuming you are
using stochastically generated values, the probability that the
first comparison in the flag-less code will succeed is miniscule
(zero actually, mathemtically but 1/(number of representable
doubles) in practice), so given the short-circuit evaluation and the
fact that a double equality check is probably optimized to be not
much if at all more expensive than a test on a boolean, it makes
sense that adding the flag won't improve performance in most cases
and the overhead of the method call to read it might actually
hurt. This is a little unfair because I expect exact 0's to be
more likely in practice.
Phil
>
>>>> This, btw, is yet another reason to separate commits.
>>> OK, I take this as: You would have only "cleanly reverted" the Javadoc
>>> change, if it would have been separate. I'll thus commit back the rest.
>> Please do not add back the extra property.
> I apologize for not having heeded to the advice that timing results do not
> always agree with what the code would seem to imply for a naive reader.
>
> [A wild guess would be that comparing with 0.0 is more apt to optimization
> by the JVM than a boolean check (?). Or could it vary from processor to
> processor and from JVM to JVM and from JVM version to JVM version? Then,
> if we are below some reasonable performance quality (i.e. relative to all
> the other operations required from an "average" and "useful" application);
> I think that it is all the more worth improving the consistency of the
> "Complex" class (even if just to avoid those time-consuming discussions to
> pop up again in the future!).]
>
> It would be useful to hear others on this last point, in order to start (or
> not) a reflexion on a global policy for code improvement along several axes
> (consistency vs performance vs readability vs self-documenting vs ...) which
> would maybe result in objective rules that will help to decide whether a
> change is acceptable, based on clearly defined trade-offs.
> That would hopefully be helpful to avoid such situations where one makes a
> change because he likes it, and another refuses the change because he does
> not like it; if you see what I mean.
>
> In my opinion, a necessary step in that direction would be to set up a
> "framework" for performance tests with baseline acceptable values for
> selected sets of realistic use-cases. I think that many committers here
> could readily come up with such use-cases.
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > [...]
>
> The hit is in the constructor, where every complex instance has to
> run the code to set the property.
In fact, not only! If one can trust the mini-benchmark performed with
"PerfTestUtils", the constructor with the additional flag is 2% slower.
But using the flag in "divide" makes it also _slower_ (3 per 1000 even for
division by zero), contrary to my expectations. [All of these operations
taking the order of 10 to 60 microseconds, relativizing the loss of
performance.]
> >
> >> This, btw, is yet another reason to separate commits.
> > OK, I take this as: You would have only "cleanly reverted" the Javadoc
> > change, if it would have been separate. I'll thus commit back the rest.
>
> Please do not add back the extra property.
I apologize for not having heeded to the advice that timing results do not
always agree with what the code would seem to imply for a naive reader.
[A wild guess would be that comparing with 0.0 is more apt to optimization
by the JVM than a boolean check (?). Or could it vary from processor to
processor and from JVM to JVM and from JVM version to JVM version? Then,
if we are below some reasonable performance quality (i.e. relative to all
the other operations required from an "average" and "useful" application);
I think that it is all the more worth improving the consistency of the
"Complex" class (even if just to avoid those time-consuming discussions to
pop up again in the future!).]
It would be useful to hear others on this last point, in order to start (or
not) a reflexion on a global policy for code improvement along several axes
(consistency vs performance vs readability vs self-documenting vs ...) which
would maybe result in objective rules that will help to decide whether a
change is acceptable, based on clearly defined trade-offs.
That would hopefully be helpful to avoid such situations where one makes a
change because he likes it, and another refuses the change because he does
not like it; if you see what I mean.
In my opinion, a necessary step in that direction would be to set up a
"framework" for performance tests with baseline acceptable values for
selected sets of realistic use-cases. I think that many committers here
could readily come up with such use-cases.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division
Posted by Phil Steitz <ph...@gmail.com>.
On 9/3/11 5:06 PM, Gilles Sadowski wrote:
>> The problem is that it is not obvious that INF is "the right answer."
> The real problem is *inconsistency*.
> The current code chooses to consider a point at infinity for some situations
> but not for others. It is thus quite understandable that people are
> wondering what is going on with some limiting cases, like using infinities:
> They assume something to understand one result, and the opposite assumption
> must be made to understand another.
>
> You are making the same kind of argument as for "RegulaFalsiSolver" which
> boils down to "The Javadoc says so and so, and the code is good enough for
> me."
> As Sebb (IIRC) pointed out in another discussion, when unobvious results
> are returned, their documentation should mention the rationale that led to
> the chosen behaviour, because this
> ---
> If {@code divisor} equals {@link #ZERO}, {@link #NaN} is returned.
> ---
> simply looks wrong, unless you are going to maintain that it is perfectly
> reasonable and completely obvious that this test:
> -----
> final double rAsComplex = Complex.ONE.divide(Complex.ZERO).getReal();
> final double rAsDouble = 1d / 0d;
> Assert.assertEquals(rAsComplex, rAsDouble, 0);
> -----
> should fail.
>
> I maintain that this is an obvious and trivial *bug*. And, however happy the
> current users of the class are, it should be fixed.
>
>>> Maybe that we can _decide_ that any manipulation of a "Complex" instance
>>> containing infinities is mildly meaningless (in the applications where CM
>>> is used) and return NaN for any operation involving them (?). That would
>>> probably simplify several methods (and make them more efficient). Unless I'm
>>> mistaken that would just cost a comment like
>>> "Manipulating instances with infinities will result in undefined results."
>> That is a defensible view. See comments below.
> This at least is *consistent*, saying that
> "We don't handle infinities. Period."
> while the current code is confusing.
>
> Once again, a user is asking for information about a strange behaviour, and
> you insist that he justifies further his request. His issue could be just
> that: Inconsistency.
>
> Now, if the justification is efficiency. Then why not go for it, and just
> not care for infinities, checking for NaN, and tell it explicitly:
> "We don't handle infinities because in most use cases, the efficiency cost
> is not worth it."
>
>>>>> 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.
>>> As you say yourself below, having an INF is to assume that the "Complex"
>>> class represents elements from C U {"point at infinity"}. At least that's
>>> how I interpret it.
>>> Had there not be a special handling of instances that have an infinity in
>>> their real or imaginary part, I'd say that the NaN result would be normal,
>>> as the output of the computational formulae.
>>> But this would entail to let operations produce their expected results,
>>> which is not the case with "z.multiply(z)", as reported by Arne:
>>> https://issues.apache.org/jira/browse/MATH-620?focusedCommentId=13096432&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13096432
>>>
>>>> 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),
>>> Did you measure it?
>>> Are you sure that performance is not _improved_ for division? :-)
>>>
>>>> but I worry a
>>>> little about losing the ability to represent directed infinities if
>>>> we decide to really aim for "consistency" here.
>>> What are the use-cases for those?
>>> When looking for references, I only stumbled on the usefulness of _one_
>>> "point at infinity".
>> When a sequence of iterates diverges in modulus to infinity, it
>> might in some cases be useful to know that the divergence was along
>> a specific vector, like for example the real or imaginary axis. I
>> have - almost - needed this in applications that track orbits of
>> points under iterated functions, but I don't have a specific
>> application use case for this personally.
>>>> 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.
>>> If you have applications that deal with any "directed" infinities, don't you
>>> need polar coordinates too? That seems to be missing in class Complex
>>> (talking about new API...).
>>> Then, would the "argument attribute" be the angle?
>> Yes, the argument would effectively be the angle.
>>>> At this point, I would like to see r1164756 reverted until we have
>>>> agreed on this change.
>>> Well, that is done. And, IMHO, there is an identified bug (or at least
>>> an inconsistency worth removing) there. I would like to see use cases that
>>> justify keeping the inconsistency. A mathematical explanation will do too
>>> ;-).
>> The mathematical question is do we view our class as representing
>> the extended complex numbers. If we agree that the answer to that
>> question is yes,
> If you say "no", then my understanding is that the "Complex" class does not
> represent the complex number concept, unless *all* operation that encounter
> infinities result in "undefined behaviour" (i.e. return NaN).
Not necessarily. The Complex field does not include any "point at
infinity." There is a topological space that can be formed from the
Complex numbers by adding a point at infinity and extending
functions to include that point. This is what is sometimes called
the extended complex numbers and a common topology for the space is
represented by the Riemann Sphere. It is not obvious to me that it
is best for us to try to model this (sorry to repeat myself, but
this is the key point). If you really want to be *consistent* and
insist that it is a *bug* to return NaN for division by complex
zero, then you are insisting that we adopt this view. To be
consistent in that view, we need to change equals, all arithmetic
operations, and the exponential and trig functions as well. Our
implementations of those functions are based loosely on C99x, which
does not consistently represent the compactified space.
> As that would arguably be considered not backward-compatible, that leaves
> only "yes" as the answer.
>
>> then "the right answer" for the one division
>> instance being considered here is to return INF. If we don't, then
>> NaN is a better answer. If we agree yes, then we should also modify
>> equals and there are likely other changes required to other
>> arithmetic operations.
> That would certainly be more consistent with how a "double" represent a real
> number. At which point I'm repeating that you chose to do so in MATH-164; so
> why would it be different now?
> The code is inconsistent and, judging how MATH-164 was resolved and you want
> to resolve this issue, the CM's decision-making process seems to be also.
>
>> IIRC, we tried to find a compromise between efficiency, ease of
>> understanding the javadoc, C99x compliance and mathematical
>> correctness when defining the contracts for the complex arithmetic
>> operations that are documented in the javadoc now. We could fiddle
>> with these contracts endlessly and add lots more ad hoc tests and
>> attributes to try to make them "more correct" or "consistent with X"
>> where X can be defined variously as "the way Doubles work", "IEEE
>> Floating Point specs," "C specs" or your favorite other package.
>> Given that changes carry a cost for all users of the current code, I
>> think the onus is on those who want to make changes to explain in
>> practical terms why the proposed change is worth making. I don't
>> (yet) see this one as worth making. What would be really great
>> would be some input from users who can provide examples why
>> different contracts would be more (or less) useful in applications.
> I'm talking about self-consistency. That could mean: Avoid contradicting
> behaviours that need confusing documentation.
Sorry, I disagree. I personally don't think it is possible to have
complete "consistency" in the way that you seem to want. I am sure
you could find "inconsistency" in the C99x spec or pretty much any
implementation, even after convoluting the javadoc and killing
performance. If others agree with your view, then we can change the
contracts and implementation. But I really would like to know what
the practical reason is.
>
>>>
>>> Thanks,
>>> Gilles
>>>
>>> P.S. I've just seen that you completely removed changes that I find useful
>>> _independently_ of the decision to change or not the behaviour of
>>> division by zero:
>>> * factoring out multiple tests into separate test methods,
>>> * keeping track of test cases that correspond to an issue, and
>>> * using a flag "isZero" in the "divide" method.
>>> Thus, they were left on purpose, as supposed enhancements similar to
>>> those which several people commit informally from time to time.
>>> Is it customary to pull the rug out from under someone's feet?
>> I asked that the commit be reverted.
> The change of behaviour was reverted; I just forgot to change back the
> Javadoc accordingly.
>
>> I just completed the reversion
>> because I saw that the javadoc contract change had not been
>> reverted. I just used svn merge with revision numbers to do a clean
>> revert.
> Why was a "clean revert" necessary?
> My changes were not a mistake, to be treated as they never occurred.
> Could I respectfully request that you let the concerned people do the
> cleanup instead of forcefully (pardon, "cleanly") erase their work?
Here is how it works. Any committer can -1 a commit. When that
happens, the commit gets reverted. To do that, it is easiest to
just use svn merge with revision numbers. I just completed the
reversion.
>> The added "isZero" attribute is part of the performance
>> hit.
> Really? How much? What tests? Can I emit the possibility that testing a
> "boolean" might be a tiny bit faster than testing equality with "0.0" twice?
The hit is in the constructor, where every complex instance has to
run the code to set the property.
>
>> This, btw, is yet another reason to separate commits.
> OK, I take this as: You would have only "cleanly reverted" the Javadoc
> change, if it would have been separate. I'll thus commit back the rest.
Please do not add back the extra property.
Phil
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
>
> The problem is that it is not obvious that INF is "the right answer."
The real problem is *inconsistency*.
The current code chooses to consider a point at infinity for some situations
but not for others. It is thus quite understandable that people are
wondering what is going on with some limiting cases, like using infinities:
They assume something to understand one result, and the opposite assumption
must be made to understand another.
You are making the same kind of argument as for "RegulaFalsiSolver" which
boils down to "The Javadoc says so and so, and the code is good enough for
me."
As Sebb (IIRC) pointed out in another discussion, when unobvious results
are returned, their documentation should mention the rationale that led to
the chosen behaviour, because this
---
If {@code divisor} equals {@link #ZERO}, {@link #NaN} is returned.
---
simply looks wrong, unless you are going to maintain that it is perfectly
reasonable and completely obvious that this test:
-----
final double rAsComplex = Complex.ONE.divide(Complex.ZERO).getReal();
final double rAsDouble = 1d / 0d;
Assert.assertEquals(rAsComplex, rAsDouble, 0);
-----
should fail.
I maintain that this is an obvious and trivial *bug*. And, however happy the
current users of the class are, it should be fixed.
> > Maybe that we can _decide_ that any manipulation of a "Complex" instance
> > containing infinities is mildly meaningless (in the applications where CM
> > is used) and return NaN for any operation involving them (?). That would
> > probably simplify several methods (and make them more efficient). Unless I'm
> > mistaken that would just cost a comment like
> > "Manipulating instances with infinities will result in undefined results."
>
> That is a defensible view. See comments below.
This at least is *consistent*, saying that
"We don't handle infinities. Period."
while the current code is confusing.
Once again, a user is asking for information about a strange behaviour, and
you insist that he justifies further his request. His issue could be just
that: Inconsistency.
Now, if the justification is efficiency. Then why not go for it, and just
not care for infinities, checking for NaN, and tell it explicitly:
"We don't handle infinities because in most use cases, the efficiency cost
is not worth it."
> >
> >>> 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.
> > As you say yourself below, having an INF is to assume that the "Complex"
> > class represents elements from C U {"point at infinity"}. At least that's
> > how I interpret it.
> > Had there not be a special handling of instances that have an infinity in
> > their real or imaginary part, I'd say that the NaN result would be normal,
> > as the output of the computational formulae.
> > But this would entail to let operations produce their expected results,
> > which is not the case with "z.multiply(z)", as reported by Arne:
> > https://issues.apache.org/jira/browse/MATH-620?focusedCommentId=13096432&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13096432
> >
> >> 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),
> > Did you measure it?
> > Are you sure that performance is not _improved_ for division? :-)
> >
> >> but I worry a
> >> little about losing the ability to represent directed infinities if
> >> we decide to really aim for "consistency" here.
> > What are the use-cases for those?
> > When looking for references, I only stumbled on the usefulness of _one_
> > "point at infinity".
>
> When a sequence of iterates diverges in modulus to infinity, it
> might in some cases be useful to know that the divergence was along
> a specific vector, like for example the real or imaginary axis. I
> have - almost - needed this in applications that track orbits of
> points under iterated functions, but I don't have a specific
> application use case for this personally.
> >
> >> 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.
> > If you have applications that deal with any "directed" infinities, don't you
> > need polar coordinates too? That seems to be missing in class Complex
> > (talking about new API...).
> > Then, would the "argument attribute" be the angle?
>
> Yes, the argument would effectively be the angle.
> >
> >> At this point, I would like to see r1164756 reverted until we have
> >> agreed on this change.
> > Well, that is done. And, IMHO, there is an identified bug (or at least
> > an inconsistency worth removing) there. I would like to see use cases that
> > justify keeping the inconsistency. A mathematical explanation will do too
> > ;-).
>
> The mathematical question is do we view our class as representing
> the extended complex numbers. If we agree that the answer to that
> question is yes,
If you say "no", then my understanding is that the "Complex" class does not
represent the complex number concept, unless *all* operation that encounter
infinities result in "undefined behaviour" (i.e. return NaN).
As that would arguably be considered not backward-compatible, that leaves
only "yes" as the answer.
> then "the right answer" for the one division
> instance being considered here is to return INF. If we don't, then
> NaN is a better answer. If we agree yes, then we should also modify
> equals and there are likely other changes required to other
> arithmetic operations.
That would certainly be more consistent with how a "double" represent a real
number. At which point I'm repeating that you chose to do so in MATH-164; so
why would it be different now?
The code is inconsistent and, judging how MATH-164 was resolved and you want
to resolve this issue, the CM's decision-making process seems to be also.
> IIRC, we tried to find a compromise between efficiency, ease of
> understanding the javadoc, C99x compliance and mathematical
> correctness when defining the contracts for the complex arithmetic
> operations that are documented in the javadoc now. We could fiddle
> with these contracts endlessly and add lots more ad hoc tests and
> attributes to try to make them "more correct" or "consistent with X"
> where X can be defined variously as "the way Doubles work", "IEEE
> Floating Point specs," "C specs" or your favorite other package.
> Given that changes carry a cost for all users of the current code, I
> think the onus is on those who want to make changes to explain in
> practical terms why the proposed change is worth making. I don't
> (yet) see this one as worth making. What would be really great
> would be some input from users who can provide examples why
> different contracts would be more (or less) useful in applications.
I'm talking about self-consistency. That could mean: Avoid contradicting
behaviours that need confusing documentation.
>
> >
> >
> > Thanks,
> > Gilles
> >
> > P.S. I've just seen that you completely removed changes that I find useful
> > _independently_ of the decision to change or not the behaviour of
> > division by zero:
> > * factoring out multiple tests into separate test methods,
> > * keeping track of test cases that correspond to an issue, and
> > * using a flag "isZero" in the "divide" method.
> > Thus, they were left on purpose, as supposed enhancements similar to
> > those which several people commit informally from time to time.
> > Is it customary to pull the rug out from under someone's feet?
>
> I asked that the commit be reverted.
The change of behaviour was reverted; I just forgot to change back the
Javadoc accordingly.
> I just completed the reversion
> because I saw that the javadoc contract change had not been
> reverted. I just used svn merge with revision numbers to do a clean
> revert.
Why was a "clean revert" necessary?
My changes were not a mistake, to be treated as they never occurred.
Could I respectfully request that you let the concerned people do the
cleanup instead of forcefully (pardon, "cleanly") erase their work?
> The added "isZero" attribute is part of the performance
> hit.
Really? How much? What tests? Can I emit the possibility that testing a
"boolean" might be a tiny bit faster than testing equality with "0.0" twice?
> This, btw, is yet another reason to separate commits.
OK, I take this as: You would have only "cleanly reverted" the Javadoc
change, if it would have been separate. I'll thus commit back the rest.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division
Posted by Phil Steitz <ph...@gmail.com>.
On 9/3/11 2:17 PM, Gilles Sadowski wrote:
> On Sat, Sep 03, 2011 at 08:10:59AM -0700, Phil Steitz wrote:
>> 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.
> That's why I posted the mail referred to above...
>
>> We should not be trying to
>> have discussions on API changes on JIRA tickets. That is not what
>> JIRA is for.
> Hmm, I thought I was doing the right thing by following the example of
> https://issues.apache.org/jira/browse/MATH-164
>
> By the way, it shows that following a older dicussion on JIRA is much more
> convenient than hopping from one post to another on ML archive, with the
> myriad of quotes, double-quotes, triple-quotes, ...
>
>> 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.
> Sorry if I broke an old and venerable rule. It was not the intention;
> for me, it was just solving a trivial bug in the same manner I did already
> before, and not a unilateral decision to "change the API".
>
>>> 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?
> Not wanting to answer for Arne; just my own two cents: Why not give the
> right answer?
The problem is that it is not obvious that INF is "the right answer."
> Maybe that we can _decide_ that any manipulation of a "Complex" instance
> containing infinities is mildly meaningless (in the applications where CM
> is used) and return NaN for any operation involving them (?). That would
> probably simplify several methods (and make them more efficient). Unless I'm
> mistaken that would just cost a comment like
> "Manipulating instances with infinities will result in undefined results."
That is a defensible view. See comments below.
>
>>> 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.
> As you say yourself below, having an INF is to assume that the "Complex"
> class represents elements from C U {"point at infinity"}. At least that's
> how I interpret it.
> Had there not be a special handling of instances that have an infinity in
> their real or imaginary part, I'd say that the NaN result would be normal,
> as the output of the computational formulae.
> But this would entail to let operations produce their expected results,
> which is not the case with "z.multiply(z)", as reported by Arne:
> https://issues.apache.org/jira/browse/MATH-620?focusedCommentId=13096432&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13096432
>
>> 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),
> Did you measure it?
> Are you sure that performance is not _improved_ for division? :-)
>
>> but I worry a
>> little about losing the ability to represent directed infinities if
>> we decide to really aim for "consistency" here.
> What are the use-cases for those?
> When looking for references, I only stumbled on the usefulness of _one_
> "point at infinity".
When a sequence of iterates diverges in modulus to infinity, it
might in some cases be useful to know that the divergence was along
a specific vector, like for example the real or imaginary axis. I
have - almost - needed this in applications that track orbits of
points under iterated functions, but I don't have a specific
application use case for this personally.
>
>> 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.
> If you have applications that deal with any "directed" infinities, don't you
> need polar coordinates too? That seems to be missing in class Complex
> (talking about new API...).
> Then, would the "argument attribute" be the angle?
Yes, the argument would effectively be the angle.
>
>> At this point, I would like to see r1164756 reverted until we have
>> agreed on this change.
> Well, that is done. And, IMHO, there is an identified bug (or at least
> an inconsistency worth removing) there. I would like to see use cases that
> justify keeping the inconsistency. A mathematical explanation will do too
> ;-).
The mathematical question is do we view our class as representing
the extended complex numbers. If we agree that the answer to that
question is yes, then "the right answer" for the one division
instance being considered here is to return INF. If we don't, then
NaN is a better answer. If we agree yes, then we should also modify
equals and there are likely other changes required to other
arithmetic operations.
IIRC, we tried to find a compromise between efficiency, ease of
understanding the javadoc, C99x compliance and mathematical
correctness when defining the contracts for the complex arithmetic
operations that are documented in the javadoc now. We could fiddle
with these contracts endlessly and add lots more ad hoc tests and
attributes to try to make them "more correct" or "consistent with X"
where X can be defined variously as "the way Doubles work", "IEEE
Floating Point specs," "C specs" or your favorite other package.
Given that changes carry a cost for all users of the current code, I
think the onus is on those who want to make changes to explain in
practical terms why the proposed change is worth making. I don't
(yet) see this one as worth making. What would be really great
would be some input from users who can provide examples why
different contracts would be more (or less) useful in applications.
>
>
> Thanks,
> Gilles
>
> P.S. I've just seen that you completely removed changes that I find useful
> _independently_ of the decision to change or not the behaviour of
> division by zero:
> * factoring out multiple tests into separate test methods,
> * keeping track of test cases that correspond to an issue, and
> * using a flag "isZero" in the "divide" method.
> Thus, they were left on purpose, as supposed enhancements similar to
> those which several people commit informally from time to time.
> Is it customary to pull the rug out from under someone's feet?
I asked that the commit be reverted. I just completed the reversion
because I saw that the javadoc contract change had not been
reverted. I just used svn merge with revision numbers to do a clean
revert. The added "isZero" attribute is part of the performance
hit. This, btw, is yet another reason to separate commits.
Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Complex division
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sat, Sep 03, 2011 at 08:10:59AM -0700, Phil Steitz wrote:
> 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.
That's why I posted the mail referred to above...
> We should not be trying to
> have discussions on API changes on JIRA tickets. That is not what
> JIRA is for.
Hmm, I thought I was doing the right thing by following the example of
https://issues.apache.org/jira/browse/MATH-164
By the way, it shows that following a older dicussion on JIRA is much more
convenient than hopping from one post to another on ML archive, with the
myriad of quotes, double-quotes, triple-quotes, ...
> 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.
Sorry if I broke an old and venerable rule. It was not the intention;
for me, it was just solving a trivial bug in the same manner I did already
before, and not a unilateral decision to "change the API".
> >
> > 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?
Not wanting to answer for Arne; just my own two cents: Why not give the
right answer?
Maybe that we can _decide_ that any manipulation of a "Complex" instance
containing infinities is mildly meaningless (in the applications where CM
is used) and return NaN for any operation involving them (?). That would
probably simplify several methods (and make them more efficient). Unless I'm
mistaken that would just cost a comment like
"Manipulating instances with infinities will result in undefined results."
> >
> > 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.
As you say yourself below, having an INF is to assume that the "Complex"
class represents elements from C U {"point at infinity"}. At least that's
how I interpret it.
Had there not be a special handling of instances that have an infinity in
their real or imaginary part, I'd say that the NaN result would be normal,
as the output of the computational formulae.
But this would entail to let operations produce their expected results,
which is not the case with "z.multiply(z)", as reported by Arne:
https://issues.apache.org/jira/browse/MATH-620?focusedCommentId=13096432&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13096432
> 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),
Did you measure it?
Are you sure that performance is not _improved_ for division? :-)
> but I worry a
> little about losing the ability to represent directed infinities if
> we decide to really aim for "consistency" here.
What are the use-cases for those?
When looking for references, I only stumbled on the usefulness of _one_
"point at infinity".
> 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.
If you have applications that deal with any "directed" infinities, don't you
need polar coordinates too? That seems to be missing in class Complex
(talking about new API...).
Then, would the "argument attribute" be the angle?
>
> At this point, I would like to see r1164756 reverted until we have
> agreed on this change.
Well, that is done. And, IMHO, there is an identified bug (or at least
an inconsistency worth removing) there. I would like to see use cases that
justify keeping the inconsistency. A mathematical explanation will do too
;-).
Thanks,
Gilles
P.S. I've just seen that you completely removed changes that I find useful
_independently_ of the decision to change or not the behaviour of
division by zero:
* factoring out multiple tests into separate test methods,
* keeping track of test cases that correspond to an issue, and
* using a flag "isZero" in the "divide" method.
Thus, they were left on purpose, as supposed enhancements similar to
those which several people commit informally from time to time.
Is it customary to pull the rug out from under someone's feet?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org