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.... 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. 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
