You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Arne Ploese <ap...@gmx.de> on 2011/07/12 10:32:07 UTC
[math] add Complex.toString() and Howto handle NaN values
properly
Hi,
I try to add the method toString() to Complex. 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?
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()...
Arne
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] add Complex.toString() and Howto handle NaN values
properly
Posted by Arne Ploese <ap...@gmx.de>.
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
Re: [math] add Complex.toString() and Howto handle NaN values
properly
Posted by Phil Steitz <ph...@gmail.com>.
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.
> 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
Re: [math] add Complex.toString() and Howto handle NaN values
properly
Posted by Arne Ploese <ap...@gmx.de>.
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-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] add Complex.toString() and Howto handle NaN values
properly
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
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
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.
> 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.
Thanks,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org