Re: text compare takes very long...
- From: Co <vonclausowitz@xxxxxxxxx>
- Date: Sun, 14 Oct 2007 08:48:35 -0000
On 13 okt, 14:47, "Mike Williams" <m...@xxxxxxxxxxxxxxxxx> wrote:
"Co" <vonclausow...@xxxxxxxxx> wrote in message
news:1192270828.787010.50550@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Mike, Great stuff, just one remark. Could you add
another boolean so the user can choose if he wants
to run it case sensitive or not?
I've been wondering how long it would be before someone asked that question
;-) It is of course not quite so simple as "adding another Boolean", as I'm
sure you are aware, but it can certainly be done. In the original code (the
code that does not include the SAFEARRAY stuff) you could very easily make
the comparison case insensitive by simply changing the following:
b1 = StrConv(String1, vbFromUnicode)
b2 = StrConv(String2, vbFromUnicode)
to:
b1 = StrConv(LCase(String1), vbFromUnicode)
b2 = StrConv(LCase(String2), vbFromUnicode)
However, in the modified faster code it is not quite so easy. The simplest
way would be to perform an OR of the data words with the value 32, but
before doing that it would be wise to investigate which is the best place to
actually do that. In the earlier versions (where the loops in the main
algorithm were equal to the product of the two string lengths) it would be
best to do it two the two Integer arrays themselves, making sure that you
revert the contents of those arrays back to their original condition at the
end of the routine to avoid altering the String data in the calling
procedure (because the original strings will respond to any changes you make
to the Integer data). However, in the latest and fastest routine (where the
loops in the new algorithm are much less than the product of the two string
lengths) it might be best to instead do it in the algorithm itself. I think
before I wrote any amendments I might be inclined to place a loop counter
inside the new algorithm and test it on various different input strings to
see how many loops occur and how many ORs are required in each loop, and
then make the decision regarding the placement of the amendment on the basis
of whether or not the number of required OR's in the main algorithm (on
average) exceeded twice the sum of the two string lengths.
I haven't actually got time to look into any of that stuff at the moment
(Saturday and the weekend and all that, and of course the all important
England versus France rugby on TV here in the UK tonight) but perhaps others
here might have a go at it. It would certainly be interesting to investigate
both methods I have suggested, and perhaps other alternative methods, so
that we end up with a flexible and yet still fast routine. It's quite
interesting stuff, this :-)
Mike
So did you win?
Marco
.
- Follow-Ups:
- Re: text compare takes very long...
- From: Mike Williams
- Re: text compare takes very long...
- References:
- text compare takes very long...
- From: Co
- Re: text compare takes very long...
- From: Donald Lessau
- Re: text compare takes very long...
- From: Co
- Re: text compare takes very long...
- From: Donald Lessau
- Re: text compare takes very long...
- From: Mike Williams
- Re: text compare takes very long...
- From: Co
- Re: text compare takes very long...
- From: Mike Williams
- Re: text compare takes very long...
- From: Donald Lessau
- Re: text compare takes very long...
- From: Mike Williams
- Re: text compare takes very long...
- From: Donald Lessau
- Re: text compare takes very long...
- From: Mike Williams
- Re: text compare takes very long...
- From: Co
- Re: text compare takes very long...
- From: Mike Williams
- text compare takes very long...
- Prev by Date: Re: Trouble getting mixer volume on Vista
- Next by Date: FileCopy Permission denied
- Previous by thread: Re: text compare takes very long...
- Next by thread: Re: text compare takes very long...
- Index(es):
Relevant Pages
|