On May 8, 2012, at 3:18 AM, Gregory Weston wrote:
> How about simply being able to test for equivalence?
Then it shouldn’t claim to support ordering, i.e. it would just be
- (BOOL) localizedCaseInsensitiveIsEqualToString: (NSString*)str;
—Jens
___
Martin Wierschin wrote:
>> If I understand Quincey correctly, that's exactly what he's saying: the
>> semantics of localizedCaseInsensitiveCompare: might be such that it is not
>> appropriate for such algorithms.
>
> As Jens mentioned, that doesn't make any sense. What good is a localized
> co
>> I'm sliding over the details of what you said because they're irrelevant for
>> my purposes.
>
> OK, but I'd *really* appreciate it if you'd avoid calling my replies
> senseless:
I never said your replies are senseless. The sequence was:
>> On 2012.05.05, at 4:51 PM, Kyle Sluder wrote:
>> I
On May 7, 2012, at 16:07 , Martin Wierschin wrote:
> I'm sliding over the details of what you said because they're irrelevant for
> my purposes.
OK, but I'd *really* appreciate it if you'd avoid calling my replies senseless:
>> On May 7, 2012, at 13:35 , Martin Wierschin wrote:
>>
>>> As Jens
>> As Jens mentioned, that doesn't make any sense. What good is a localized
>> comparison method if not for sorting a list for display? I suppose you could
>> be implying that Cocoa's sorting methods aren't optimized to assume
>> comparisons are transitive (or special cases problematic
>> strin
On May 7, 2012, at 13:35 , Martin Wierschin wrote:
> As Jens mentioned, that doesn't make any sense. What good is a localized
> comparison method if not for sorting a list for display? I suppose you could
> be implying that Cocoa's sorting methods aren't optimized to assume
> comparisons are tr
> So even if we get the right compare options,
> 'localizedCaseInsensitiveCompare:' may not be viable for strings *not* in the
> language of the current locale.
That seems extremely unlikely and would be short-sighted of Apple, considering
multilingual users and international information exchan
>>> If I'm right, then sort order and search order are different, and you can't
>>> expect to use a binary search here. (Not unless you originally used
>>> pair-wise 'localizedCaseInsensitiveCompare' to manually sort the list of
>>> strings.)
>>
>> All comparisons, including those used for the
On May 5, 2012, at 10:06 PM, Quincey Morris wrote:
> However, even in pure ASCII strings, 'localizedCaseInsensitiveCompare:'
> doesn't support sorting via (say) a binary search. Strings such as "a" and
> "A" are *equal* according to this method. Binary search doesn't work if
> sorted elements
On 5/6/12 12:18 AM, Quincey Morris wrote:
However, when the second word doesn't have "ss" in corresponding position,
then the order is determined by pure character collating sequence for the
language. In your case (which I'm guessing is English), 'ß'< 's'. In
Markus's case (which I'm guessing is
On 5/5/12 11:56 PM, Ken Thomases wrote:
On May 5, 2012, at 4:46 PM, Markus Spoettl wrote:
Markus, how did you set the locale?
I used the system preferences, setting it to de_AT, restarting Xcode after that
and redoing the test.
Regards
Markus
--
__
Mar
On May 5, 2012, at 19:45 , Jens Alfke wrote:
> On May 5, 2012, at 4:51 PM, Kyle Sluder wrote:
>
>> If I understand Quincey correctly, that's exactly what he's saying: the
>> semantics of localizedCaseInsensitiveCompare: might be such that it is not
>> appropriate for such algorithms.
>
> But t
On May 5, 2012, at 4:51 PM, Kyle Sluder wrote:
> If I understand Quincey correctly, that's exactly what he's saying: the
> semantics of localizedCaseInsensitiveCompare: might be such that it is not
> appropriate for such algorithms.
But that doesn’t make sense, because the main purpose of -com
On Sat, May 5, 2012 at 6:53 PM, Jens Alfke wrote:
>
> On May 5, 2012, at 3:18 PM, Quincey Morris wrote:
>
>> "ß" within a string probably compares equal to "ss" at the corresponding
>> position, independently of the language. (This makes sense, I think.)
>> Therefore "laßt" > "lasso" always.
>
>
On May 5, 2012, at 15:43 , Martin Wierschin wrote:
> All comparisons, including those used for the original sorting, were done
> using the same comparison method/locale. And the sort order and search order
> need to be same, otherwise any algorithms that rely on the transitive nature
> of compa
On May 5, 2012, at 3:18 PM, Quincey Morris wrote:
> "ß" within a string probably compares equal to "ss" at the corresponding
> position, independently of the language. (This makes sense, I think.)
> Therefore "laßt" > "lasso" always.
I don’t know about this specific case, but these rules defin
On May 5, 2012, at 3:43 PM, Martin Wierschin wrote:
>> If I'm right, then sort order and search order are different, and you can't
>> expect to use a binary search here. (Not unless you originally used
>> pair-wise 'localizedCaseInsensitiveCompare' to manually sort the list of
>> strings.)
>
> If I'm right, then sort order and search order are different, and you can't
> expect to use a binary search here. (Not unless you originally used pair-wise
> 'localizedCaseInsensitiveCompare' to manually sort the list of strings.)
All comparisons, including those used for the original sorting,
> Are you sure your debugger isn't lying to you?
The code behaves the same in the built application.
> Maybe you have category on NSString that does that?
No, but I also tried the CFStringCompareWithOptionsAndLocale with the same
results. I suppose that could call through to an NSString overrid
On May 5, 2012, at 14:07 , Martin Wierschin wrote:
> For example, consider the following sorted list of strings:
>
> "aaa" < "laso" < "lasso" < "zzz"
>
> I would expect that any new string I want to insert into this list would
> compare so that it has just one point of insertion. But this
On Sat, May 5, 2012 at 4:46 PM, Markus Spoettl wrote:
> On 05.05.12 23:07, Martin Wierschin wrote:
>>
>> So, when using a binary search, I get different answers depending on the
>> other strings in the list!
>
>
> Seems to work for me:
I was using F-Script to investigate this, but I'm seeing the
On May 5, 2012, at 4:46 PM, Markus Spoettl wrote:
> On 05.05.12 23:07, Martin Wierschin wrote:
>> So, when using a binary search, I get different answers depending on the
>> other strings in the list!
>
> Seems to work for me:
>
> On 10.7.3, Xcode 4.3.1, for both locale en_US and locale de_AT I
On 05.05.12 23:07, Martin Wierschin wrote:
So, when using a binary search, I get different answers depending on the other
strings in the list!
Seems to work for me:
On 10.7.3, Xcode 4.3.1, for both locale en_US and locale de_AT I get:
(lldb) p (NSComparisonResult)[@"laßt" localizedCaseInsens
Hello everyone,
I'm using NSString's localizedCaseInsensitiveCompare to maintain a data
structure sorted by some keys, which are strings that will be displayed to the
end-user. For this question it's enough to think of an array of sorted strings,
on which binary searches are run. The problem is
24 matches
Mail list logo
