Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.210.43 as permitted sender)
Message-ID: <4E1C7547.6030007@gmail.com>
Date: Tue, 12 Jul 2011 09:24:39 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] add Complex.toString()   and  Howto handle NaN values
 properly
References: <1310459527.5050.11.camel@knuffelchen>
	 <20110712142400.GB3310@dusk.harfang.homelinux.org>
 <1310485747.3170.15.camel@knuffelchen>
In-Reply-To: <1310485747.3170.15.camel@knuffelchen>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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