commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Ploese <aplo...@gmx.de>
Subject Re: [math] add Complex.toString() and Howto handle NaN values properly
Date Tue, 12 Jul 2011 19:22:46 GMT
Am Dienstag, den 12.07.2011, 09:24 -0700 schrieb Phil Steitz: 
> On 7/12/11 8:49 AM, Arne Ploese wrote:
> > Am Dienstag, den 12.07.2011, 16:24 +0200 schrieb Gilles Sadowski: 
> >> Hello.
> >>
> >>> I try to add the method toString() to Complex.
> >> I've created an issue for this:
> >>   https://issues.apache.org/jira/browse/MATH-614
> > I would prefer something like:
> >>>> return Double.valueOf(real) + imaginary < 0 ? " - " : " + "  +
> > Double.valueOf(Math.abs(imaginary)) + "i";<<<
> >
> > this would format the values in the same way any double would be
> > formatted. 
> >
> >> With the "ComplexFormat" class, the "toString" method should be trivial to
> >> add to the "Complex" class.
> >> [This is already done in my working copy of the code.]
> >> Please, let me know whether you agree with what I propose in the issue's
> >> description.
> >>
> >>> There some issues arise:
> >>>
> >>> If ether the real or imaginary part is NaN hashCode() will return the
> >>> same value. Complex.toString() should return Double.valueOf(Double.NaN).
> >>> Is thee a need to store the given values of the real/imaginary part? or
> >>> set both to Double.NaN in the constructor?
> >>> Maybe drop the constructor completely, make createComplex(...) public
> >>> and return in this case Complex.NaN which is then the marker for NaN
> >>> values?
> >> I don't understand how this affects the code of a "toString" method.
> > If two Objects are equal they should have the same hash code thus
> > toString() should be also equal, meaning that all properties equal....
> 
> Not necessarily.  Equals is an equivalence relation on object
> instances.  Equal instances can have different properties, as is the
> case for Complex instances that have NaN parts.  Per the javadoc for
> equals, we treat instances with NaN parts as equal, all collapsed
> into a single equivalence class that includes Complex.NaN.  Having
> toString show the different properties of equal instances is
> appropriate.
Example:

a = NaN + 3i
b = 6 + NaNi
c = NaN + NaN

if mathematically
a == b == c
one can change the constructor of Complex, that if any part is NaN both
will be set  to NaN.

Using hibernate to persist Complex for instance, will, if you put a
first in the database, b and c will get the same database id. Thats what
will happen with the current implementation. The user will get back a.
I have no problem with ether way - change equals|hashCode or set all to
NaN, but the current implementation is in my opinion wrong.  

Arne

> 
> > given the complex numbers 
> >
> > a = new Complex(Double.NaN, 3);
> > b = new Complex(6, Double.NaN);
> >
> > both are equals and have the same hash code.
> > Personally I think this is wrong in the first place because a is not
> > equal b. So equals() and hashCode() must be changed.
> 
> Here you are disagreeing with how we have defined equals for
> Complex.  We can talk about changing that in 3.0, but it would
> likely break some things, since the current definition has been in
> place since math 1.0.
> 
> Phil
> >
> > What should the outcome of a.toString() be?
> >
> > "NaN" or "NaN + 3i"?
> >
> >>> the methods add/subtract handle NaN values different one will return
> >>> Complex.NaN the other will calculate the result and result.isNaN() ==
> >>> true. This makes in my opinion no sense, because result.hashCode() ==
> >>> Complex.NaN,hashCode()...
> >> This is not clear to me.
> >> Please write different posts for different issues.
> > I think if we find a solution for the upper this can be fixed
> > accordingly...
> >
> >>
> >> Thanks,
> >> 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
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message