commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [math] Complex division
Date Sat, 03 Sep 2011 21:17:53 GMT
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


Mime
View raw message