case insensitive sort

When someone asks for a case insensitive sort, they typically use code
like this in the Comparator

return a.x.compareToIgnoreCase( b.x );

However than will not give you what you really want. You probably
want this if you want tidy-looking results.

int diff = a.x.compareToIgnoreCase( b );
if ( diff != 0 ) return diff;
return a.x.compareTo( b.x );
--
Roedy Green Canadian Mind Products
http://mindprod.com
I can't come to bed just yet. Somebody is wrong on the Internet.

Roedy Green wrote:
> When someone asks for a case insensitive sort, they typically use code
> like this in the Comparator
>
> return a.x.compareToIgnoreCase( b.x );
>
> However than will not give you what you really want. You probably
> want this if you want tidy-looking results.
>
> int diff = a.x.compareToIgnoreCase( b );
> if ( diff != 0 ) return diff;
> return a.x.compareTo( b.x );

I think this needs more context. What is x? What are the types involved?
Why do you expect a.x and be to be comparable?

Patricia

Patricia Shanahan wrote:
> Roedy Green wrote:
> > However than will not give you what you really want. You probably
> > want this if you want tidy-looking results.
> >
> > int diff = a.x.compareToIgnoreCase( b );
> > if ( diff != 0 ) return diff;
> > return a.x.compareTo( b.x );
>
> I think this needs more context. What is x? What are the types involved?
> Why do you expect a.x and be to be comparable?

I think that's a typo and should read b.x, and assume x is String.

And the basic idea, to provide a consistent ordering within groups
of items that compare equal ignoring case, is worth keeping in mind.

--

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <v_borchert@despammed.com>

On Tue, 22 Nov 2011 21:59:50 -0800, Patricia Shanahan <pats@acm.org>
wrote, quoted or indirectly quoted someone who said :

>
>I think this needs more context. What is x? What are the types involved?
>Why do you expect a.x and be to be comparable?

The only beast I know of that takes a compareIgnoreCase is a String.
--
Roedy Green Canadian Mind Products
http://mindprod.com
I can't come to bed just yet. Somebody is wrong on the Internet.

On 23 Nov 2011 06:34:36 GMT, v_borchert@despammed.com (Volker
Borchert) wrote, quoted or indirectly quoted someone who said :

>I think that's a typo and should read b.x, and assume x is String.
>
>And the basic idea, to provide a consistent ordering within groups
>of items that compare equal ignoring case, is worth keeping in mind.

that's correct.
--
Roedy Green Canadian Mind Products
http://mindprod.com
I can't come to bed just yet. Somebody is wrong on the Internet.

Roedy Green wrote:
> On Tue, 22 Nov 2011 21:59:50 -0800, Patricia Shanahan <pats@acm.org>
> wrote, quoted or indirectly quoted someone who said :
>
>> I think this needs more context. What is x? What are the types involved?
>> Why do you expect a.x and be to be comparable?
>
> The only beast I know of that takes a compareIgnoreCase is a String.

I was confused by the typo, which made it look as though you were
applying compareIgnoreCase to something that has a field x.

Patricia

Roedy Green wrote:

> The only beast I know of that takes a compareIgnoreCase is a String.

What about Collator?

And the generalized idea - try to establish a time invariant total
ordering if possible - is also worth keeping in mind, for any objects:
If one attribute or comparator compares equal, additionally use another.

(If only to reliably avoid lock acquisition order problems.)

--

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <v_borchert@despammed.com>

On 23/11/2011 2:32 PM, Volker Borchert wrote:
> Roedy Green wrote:
>
>> The only beast I know of that takes a compareIgnoreCase is a String.
>
> What about Collator?

The *things being compared* are still Strings ...

> (If only to reliably avoid lock acquisition order problems.)

Software Transactional Memory.

dibs wrote:
> On 23/11/2011 2:32 PM, Volker Borchert wrote:
> > Roedy Green wrote:
> >
> >> The only beast I know of that takes a compareIgnoreCase is a String.
> >
> > What about Collator?
>
> The *things being compared* are still Strings ...

Yes. It was easy to misunderstand me, I agree. What I mean is -
is it "necessary" to augment Collator.compare(String,String)
and possibly Collator.equals(String,String) similarly?

--

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <v_borchert@despammed.com>

On 11/23/2011 12:06 AM, Roedy Green wrote:
> When someone asks for a case insensitive sort, they typically use code
> like this in the Comparator
>
> return a.x.compareToIgnoreCase( b.x );
>
> However than will not give you what you really want. You probably
> want this if you want tidy-looking results.
>
> int diff = a.x.compareToIgnoreCase( b );
> if ( diff != 0 ) return diff;
> return a.x.compareTo( b.x );

Assuming that whoever asked for a case insensitive sort did not mean
it but wanted a case insensitive sort with those case insensitive equal
sorted case sensitive.

It is certainly possible that it is what they want, but in
general developers should not change requirements to what they
think the requirements really are.

Arne

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/23/2011 12:06 AM, Roedy Green wrote:
>> When someone asks for a case insensitive sort, they typically use code
>> like this in the Comparator
>> return a.x.compareToIgnoreCase( b.x );
>> However than will not give you what you really want. You probably
>> want this if you want tidy-looking results.
>> int diff = a.x.compareToIgnoreCase( b );
>> if ( diff != 0 ) return diff;
>> return a.x.compareTo( b.x );
>
> Assuming that whoever asked for a case insensitive sort did not mean
> it but wanted a case insensitive sort with those case insensitive equal
> sorted case sensitive.

Which I consider a pretty safe bet in practise.

From a javadoc-link quickly googled:
" The natural ordering for a class C is said to be consistent with equals
" if and only if (e1.compareTo((Object)e2) == 0) has the same boolean value
" as e1.equals((Object)e2) for every e1 and e2 of class C. Note that null
" is not an instance of any class, and e.compareTo(null) should throw a
" NullPointerException even though e.equals(null) returns false.

" It is strongly recommended (though not required) that natural orderings be
" consistent with equals. This is so because sorted sets (and sorted maps)
" without explicit comparators behave "strangely" when they are used with
" elements (or keys) whose natural ordering is inconsistent with equals. In
" particular, such a sorted set (or sorted map) violates the general
" contract for set (or map), which is defined in terms of the equals method.

This is just another example of where a comparability based only on
compareNoCase is likely a bad thing.

> It is certainly possible that it is what they want, but in
> general developers should not change requirements to what they
> think the requirements really are.

Roedy's hint was probably targetted to those who do define the
detail requirements themselves.

On 11/26/2011 9:23 AM, Andreas Leitgeb wrote:
> Arne Vajhøj<arne@vajhoej.dk> wrote:
>> On 11/23/2011 12:06 AM, Roedy Green wrote:
>>> When someone asks for a case insensitive sort, they typically use code
>>> like this in the Comparator
>>> return a.x.compareToIgnoreCase( b.x );
>>> However than will not give you what you really want. You probably
>>> want this if you want tidy-looking results.
>>> int diff = a.x.compareToIgnoreCase( b );
>>> if ( diff != 0 ) return diff;
>>> return a.x.compareTo( b.x );
>>
>> Assuming that whoever asked for a case insensitive sort did not mean
>> it but wanted a case insensitive sort with those case insensitive equal
>> sorted case sensitive.
>
> Which I consider a pretty safe bet in practise.
>
> From a javadoc-link quickly googled:
> " The natural ordering for a class C is said to be consistent with equals
> " if and only if (e1.compareTo((Object)e2) == 0) has the same boolean value
> " as e1.equals((Object)e2) for every e1 and e2 of class C. Note that null
> " is not an instance of any class, and e.compareTo(null) should throw a
> " NullPointerException even though e.equals(null) returns false.
>
> " It is strongly recommended (though not required) that natural orderings be
> " consistent with equals. This is so because sorted sets (and sorted maps)
> " without explicit comparators behave "strangely" when they are used with
> " elements (or keys) whose natural ordering is inconsistent with equals. In
> " particular, such a sorted set (or sorted map) violates the general
> " contract for set (or map), which is defined in terms of the equals method.
>
> This is just another example of where a comparability based only on
> compareNoCase is likely a bad thing.

Hm.

I read it as if you should also override equals.

>> It is certainly possible that it is what they want, but in
>> general developers should not change requirements to what they
>> think the requirements really are.
>
> Roedy's hint was probably targetted to those who do define the
> detail requirements themselves.

Maybe.

But I would not expect those to think in Java code.

Arne

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/26/2011 9:23 AM, Andreas Leitgeb wrote:
>> Arne Vajhøj<arne@vajhoej.dk> wrote:
>>> On 11/23/2011 12:06 AM, Roedy Green wrote:
>>>> When someone asks for a case insensitive sort, they typically use code
>>>> like this in the Comparator
>>>> return a.x.compareToIgnoreCase( b.x );
>>>> However than will not give you what you really want. You probably
>>>> want this if you want tidy-looking results.
>>>> int diff = a.x.compareToIgnoreCase( b );
>>>> if ( diff != 0 ) return diff;
>>>> return a.x.compareTo( b.x );
>>> Assuming that whoever asked for a case insensitive sort did not mean
>>> it but wanted a case insensitive sort with those case insensitive equal
>>> sorted case sensitive.
>> Which I consider a pretty safe bet in practise.
>> From a javadoc-link quickly googled:
>> " It is strongly recommended (though not required) that natural orderings be
>> " consistent with equals. [...]
>> This is just another example of where a comparability based only on
>> compareNoCase is likely a bad thing.
> Hm.
> I read it as if you should also override equals.

It surely depends on what the things are, that are being sorted.
You might want to sort items case-insensitively, which may have a
unique case-sensitive identity. (e.g. filenames on c.s. filesystems)
That's where Roedy's suggestion fits best, imho.