François Pinard wrote:

>  Of course, I presume that `f' is efficient itself,
>  probably based on a
>  dictionary of some sort say.  dictionary lookup is
>  slightly more than O(1),
>  but I hope it is O(1) enough for your purpose.  Else, you
>  have to implement
>  another way.  If `f' is more than O(1), your problem
>  cannot be solved.

Thx.

f will be *slow*. The list entries are tuples and the tuple 
entries are strings. Then f is "in" for strings, that is it 
checks, if one string contains another one. What I want to 
implement, is a list view with incr4emental search. There 
will be up to 250000 entrie in the list view at the moment 
(for example all headers of the news group 
alt.binaries.mp3.classical) and this number is going to 
increase in the  future as news servers become bigger and 
bigger. I thought that when f is slow, then at least the 
merging should be as fast as possible.

J.B.

>  All in all, I think that you will pay a high multiplicator
>  price for being strictly O(n), and you could achieve
>  something much faster _in practice_ by relaxing this
>  constraint.

I thought that as have many entries, O(n) should mean "as 
fast as possible".

-- 
Janos Blazi


-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
   http://www.newsfeed.com       The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
-- 
http://mail.python.org/mailman/listinfo/python-list