Looking for that internationally savvy palindrome checker....

you will get better performance (for a non-opitimizing compiler) and a more reaable code if you manually move the calculation of the for loop length before the for loop:

...
int nComparision = ((count % 2 != 0) ? count - 1 : count) / 2;
for (int i = 0; i < nComparisons; i++) {
...

Now, it is easy to see that the first line above is the same as (assuming count is >= 0):
...
int nComparision = count / 2;
...


I do not know about the details of StringInfo functions, but you can get better performance if it is possible to precompute the SubsStringByTextElements(j, 1) for all consecutive values of j, in less time than computing SubsStringByTextElements(j, 1) in some random order. That is, I would write the following code (I also like to consider zero length strings as palindromes):

bool IsPalindrome(string st) {
StringInfo si = new StringInfo(st);
int count = si.LengthInTextElements;

TextElementEnumerator k=si.GetTextElementEnumerator(st);

vector <string *> precomp_st;
int count=0;
do {
precomp_st[count++] = k.GetTextElement();
} while (k.MoveNext());

int nComparision = count / 2;

for (int i = 0; i < nComparisons; i++) {
if (CultureInfo.CurrentCulture.CompareInfo.Compare(*precomp_st[i], *precomp_st[count-i-1]) != 0)
return(false);
}

return (true);
}

Thank you - I suspect you would have done very well in that interview!

The classes you used look like a very neat way of handling this sort of problem. I guess in a lot of cases, working with strings in this way should be the preferred (or at least more correct) option over using array indexing even if internationalisation isn’t an immediate goal.

I've written a test-driving app for palindrome-checking using any combination of CompareOptions:
http://channel9.msdn.com/ShowPost.aspx?PostID=63167#63167

Also see my follow-up posts to your post linked above

-- Interesting -- of course creating another object (a text element enumerator) when you already did the work to create an object that has the divisions might negatively impact some of the perf gains....

Not in C or C++. And I do not know enough about C# or VB to claim otherwise. However, I am going to provide you running times using VS .NET 2003 in a few minutes.

-- Also, there was a recent blog post on Brad Abram's blog at http://blogs.msdn.com/brada/archive/2005/04/23/411321.aspx which suggests that caching outside the loop can hurt performance.

Yep, I had read it, the premise was that if the JIT cannot deduce the range of the index variable at runtime, it will try to perform range checking for every access. However, my experince with compiler are that they are not that smart to deduce the effective range of slightly complex expression like the one you used.

Moreover, I believe the code behaves correctly for the cases with the odd lengths. Unless you point me to a case where it does not!

Now, back to the TextEnumerator ... As I wrote before, I do not know the details of StringInfo, but my educated guess is that everytime you use its length or substring functions, it will scan the string from its beginning. So, for a string of length N, the code gave about is O(N^2). However, it becomes O(N) if a textenumerator is used.

Besides, this annoying perf improvements. If you precomputer the text elemnts, using the collating functions could be much faster.

--Do you get the job if you optimize the code in a way that makes it not work and potentially slower? :-)

Was this an interview question ? Oh no! I should have reviewed my code before I hit the submit button then. :)

--
I do not know the details of StringInfo, but my educated guess is that everytime you use its length or substring functions, it will scan the string from its beginning
--

Hmmm... I'd guess that it builds an array of text elements, similarly to the way I use the TextElementEnumerator to build a String[]
http://channel9.msdn.com/ShowPost.aspx?PageIndex=5&PostID=63246#63246

If that is in fact the case, then it wouldn't need to rescan.

-- Basically, StringInfo is a wrappear around ParseCombiningCharacters. It calls the method once and never calls it again unless you change the string.

Great! I rest the case then. All I was trying to do was what StringInfo will do by itself.

However, you should be able to see that the two expression:
((count % 2 != 0) ? count - 1 : count) / 2
and
count / 2
evaulate to the same number for all positive integer values of count.

...

The difference in using
((count % 2 != 0) ? count - 1 : count) / 2
versus
count / 2
as a loop upper bound is neglibile when optimizing the code.

But with nonoptimized code, the difference is
observable:

((count % 2 != 0) ? count - 1 : count) / 2
Total Time: 0.9375

count / 2
Total Time: 0.859375

Oh, I see... ParseCombiningCharacters stores the byte offset of the *i*th grapheme in offset[i], allowing for a fast lookup. If the data is seven-bit, or all single-byte Unicode, then offset[0] == 0, offset[1] == 1, ... offset[i] == i - but if any graphemes are multibyte (2 bytes, 3 bytes, 4 bytes...) then offset[i] > i...

Do you perform another internal optimization and store offset_optimal[i] as offset[i] - i? So if the data is all single-byte, offset_optimal[i] == 0 for all i... and in general offset_optimal[i] is the number of "extra bytes" in graphemes 0 through i - 1
?

well, neither your code nor mine, compares the middle character to itself. Say, for count == 7, nComparisons will be (7 / 2) = 3. The compared grpahemes are then:

0 and 6
1 and 5
2 and 4

and the loop stops right here.

BTW, why is not there a preview button on the comments form?