On Wed, Sep 5, 2012 at 2:32 AM, Johannes Bauer dfnsonfsdu...@gmx.de wrote:
How do you arrive at that conclusion? When comparing two random strings,
I just derived
n = (256 / 255) * (1 - 256 ^ (-c))
where n is the average number of character comparisons and c. The
rationale as follows: The
On 4 September 2012 22:59, Chris Angelico ros...@gmail.com wrote:
On Wed, Sep 5, 2012 at 2:32 AM, Johannes Bauer dfnsonfsdu...@gmx.de
wrote:
How do you arrive at that conclusion? When comparing two random strings,
I just derived
n = (256 / 255) * (1 - 256 ^ (-c))
where n is the
Roy Smith:
I'm wondering if it might be faster to start at the ends of the strings
instead of at the beginning? If the strings are indeed equal, it's the
same amount of work starting from either end.
Most people write loops that go forwards. This leads to the
processor designers
On 05/09/2012 03:18, Neil Hodgson wrote:
Roy Smith:
I'm wondering if it might be faster to start at the ends of the strings
instead of at the beginning? If the strings are indeed equal, it's the
same amount of work starting from either end.
Most people write loops that go forwards.
In article -9cdnaqjtk6nktvnnz2dnuvz_gedn...@westnet.com.au,
Neil Hodgson nhodg...@iinet.net.au wrote:
The memcpy patch was controversial as it broke Adobe Flash
An added benefit!
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, Sep 3, 2012 at 9:54 PM, Roy Smith r...@panix.com wrote:
There's been a bunch of threads lately about string implementations, and
that got me t
On
hinking (which is often a dangerous thing).
Let's assume you're testing two strings for equality. You've already
done the obvious
On Tue, Sep 4, 2012 at 11:54 AM, Roy Smith r...@panix.com wrote:
I'm wondering if it might be faster to start at the ends of the strings
instead of at the beginning?
I'm also not sure how this work with all the possible UCS/UTF encodings.
With some of them, you may get the encoding semantics
On Mon, 03 Sep 2012 21:54:01 -0400, Roy Smith wrote:
Let's assume you're testing two strings for equality. You've already
done the obvious quick tests (i.e they're the same length), and you're
down to the O(n) part of comparing every character.
I'm wondering if it might be faster to start
On 9/3/2012 9:54 PM, Roy Smith wrote:
There's been a bunch of threads lately about string implementations, and
that got me thinking (which is often a dangerous thing).
Let's assume you're testing two strings for equality. You've already
done the obvious quick tests (i.e they're the same
On 2012-09-04 at 02:17:30 +,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Besides, then somebody will say Yes, but what about the cases where
the prefix and the suffix are both equal, but the middle will be
different? and propose a third string-equality operator and
101 - 110 of 110 matches
Mail list logo
