Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10185 > unrolled thread

case insensitive sort

Back to article view | Back to comp.lang.java.programmer

Contents

  case insensitive sort Roedy Green <see_website@mindprod.com.invalid> - 2011-11-22 21:06 -0800
    Re: case insensitive sort Patricia Shanahan <pats@acm.org> - 2011-11-22 21:59 -0800
      Re: case insensitive sort v_borchert@despammed.com (Volker Borchert) - 2011-11-23 06:34 +0000
        Re: case insensitive sort Roedy Green <see_website@mindprod.com.invalid> - 2011-11-23 02:49 -0800
      Re: case insensitive sort Roedy Green <see_website@mindprod.com.invalid> - 2011-11-23 02:46 -0800
        Re: case insensitive sort Patricia Shanahan <pats@acm.org> - 2011-11-23 05:23 -0800
        Re: case insensitive sort v_borchert@despammed.com (Volker Borchert) - 2011-11-23 19:32 +0000
          Re: case insensitive sort dibs <dibs@dobs.dabs> - 2011-11-23 15:11 -0500
            Re: case insensitive sort v_borchert@despammed.com (Volker Borchert) - 2011-11-24 05:03 +0000
    Re: case insensitive sort Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 21:26 -0500
      Re: case insensitive sort Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-26 14:23 +0000
        Re: case insensitive sort Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 21:56 -0500
          Re: case insensitive sort Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-04 10:43 +0000

#10185 — 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. 

[toc] | [next] | [standalone]

#10186

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

[toc] | [prev] | [next] | [standalone]

#10187

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>

[toc] | [prev] | [next] | [standalone]

#10191

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. 

[toc] | [prev] | [next] | [standalone]

#10190

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. 

[toc] | [prev] | [next] | [standalone]

#10193

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

[toc] | [prev] | [next] | [standalone]

#10195

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>

[toc] | [prev] | [next] | [standalone]

#10196

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.

[toc] | [prev] | [next] | [standalone]

#10199

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>

[toc] | [prev] | [next] | [standalone]

#10248

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

[toc] | [prev] | [next] | [standalone]

#10267

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.

[toc] | [prev] | [next] | [standalone]

#10456

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

[toc] | [prev] | [next] | [standalone]

#10483

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web