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-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
