Neil Hodgson wrote:
Ethan Furman:
*plonk*
I can't work out who you are plonking. While more than one of the
posters on this thread seem worthy of a good plonk, by not including
sufficient context, you've left me feeling puzzled. Is there a guideline
for this in basic netiquette?
On Tue, Sep 18, 2012 at 11:12 AM, Ethan Furman et...@stoneleaf.us wrote:
Neil Hodgson wrote:
Ethan Furman:
*plonk*
I can't work out who you are plonking. While more than one of the
posters on this thread seem worthy of a good plonk, by not including
sufficient context, you've left me
sufficient context, you've left me feeling puzzled. Is there a guideline for
this in basic netiquette?
www.woodgate.org/FAQs/netiquette.html
--
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com
--
http://mail.python.org/mailman/listinfo/python-list
You're right, my apologies. Dwight Hutto is the one I plonked.
You can call me David. I go by my middle name.
And it seem to me I made some valid points about a few simple trimming
of postings, that didn't seem necessary in the context of a small
quick conversation.
--
On Wed, Sep 19, 2012 at 2:17 AM, Dwight Hutto dwightdhu...@gmail.com wrote:
You're right, my apologies. Dwight Hutto is the one I plonked.
You can call me David. I go by my middle name.
You're most often going to be addressed by the name that's given in
your post headers. In this case David
You're most often going to be addressed by the name that's given in
your post headers. In this case David has been reduced to an
initial, and is visible only in your email address, whereas Dwight
My sig says David, but it was just to let him know he can call me by
my used name.
--
Best
On 18/09/2012 21:40, Dwight Hutto wrote:
You're most often going to be addressed by the name that's given in
your post headers. In this case David has been reduced to an
initial, and is visible only in your email address, whereas Dwight
My sig says David, but it was just to let him know he
On Tue, 18 Sep 2012 12:17:40 -0400, Dwight Hutto wrote:
You can call me David. I go by my middle name.
If you want to be known as David, why do you give your name as Dwight? In
your email client or newsreader, set your name as David and attributions
will be to David, and people will know to
On Sep 17, 2:05 pm, Chris Angelico ros...@gmail.com wrote:
I would hate to see people leaned
hard on to make their speech entirely politically correct. Use common
sense, on both sides. Don't be offensive, and don't be offended.
While I would like to agree, this would require there to be no
*plonk*
--
http://mail.python.org/mailman/listinfo/python-list
Ethan Furman:
*plonk*
I can't work out who you are plonking. While more than one of the
posters on this thread seem worthy of a good plonk, by not including
sufficient context, you've left me feeling puzzled. Is there a guideline
for this in basic netiquette?
Neil
--
On Sep 15, 1:10 pm, Dwight Hutto dwightdhu...@gmail.com wrote:
On Fri, Sep 14, 2012 at 6:43 PM, Prasad, Ramit
Since I was unsure myself if you were trying to be offensive or racist,
I would disagree with everyone can know it wasn't meant as racist.
If you're unsure if it was racist, you
On Mon, Sep 17, 2012 at 11:11 AM, alex23 wuwe...@gmail.com wrote:
On Sep 15, 1:10 pm, Dwight Hutto dwightdhu...@gmail.com wrote:
On Fri, Sep 14, 2012 at 6:43 PM, Prasad, Ramit
Since I was unsure myself if you were trying to be offensive or racist,
I would disagree with everyone can know it
On Sep 14, 3:39 pm, Dwight Hutto dwightdhu...@gmail.com wrote:
Please explain any logic whatsoever that would give you that conclusion.
Well, this:
I think you're referring to a play on words(ramit).
Using foreign names derogatively is a common tactic of the racist.
Ain't I so punny.
Not
I think you're referring to a play on words(ramit).
Using foreign names derogatively is a common tactic of the racist.
Not really. But nice spin on my pun to make me look bad.
Keep trying, and maybe you'll come up with an insult/ propaganda
that's less obvious to the viewer that you're a
On Sep 14, 6:04 pm, Dwight Hutto dwightdhu...@gmail.com wrote:
Using foreign names derogatively is a common tactic of the racist.
Not really. But nice spin on my pun to make me look bad.
It actually *is* common behaviour of racists.
It's similar to if I said, this is real 'queer' of you to
On Fri, Sep 14, 2012 at 4:20 AM, alex23 wuwe...@gmail.com wrote:
On Sep 14, 6:04 pm, Dwight Hutto dwightdhu...@gmail.com wrote:
Using foreign names derogatively is a common tactic of the racist.
Not really. But nice spin on my pun to make me look bad.
It actually *is* common behaviour of
On Fri, 14 Sep 2012 01:20:53 -0700, alex23 wrote:
On Sep 14, 6:04 pm, Dwight Hutto dwightdhu...@gmail.com wrote:
[snip]
Please don't feed the trolls.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 14, 6:53 pm, Dwight Hutto dwightdhu...@gmail.com wrote:
Not if there name is ramit. What if your name was john? I'd say I'll
be right back, I have to go take a crap on the john. It's a joke about
a name, not where it originates.
I'd recommend reading up on white privilege but I'm pretty
I'd recommend reading up on white privilege but I'm pretty sure it'd
be a wasted suggestion.
Not really, I tend to like interdisciplinary study. But I'm a little
of everything if you like Darwin.
It's similar to if I said, this is real 'queer' of you to do ya big
pansy, and next you'll be
[snip]
Please don't feed the trolls.
You're down here under the bridge with the rest of us trolls too, Steven. 24/7
--
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com
--
http://mail.python.org/mailman/listinfo/python-list
Dwight Hutto wrote:
On Thu, Sep 13, 2012 at 5:17 PM, Mark Lawrence breamore...@yahoo.co.uk
wrote:
On 13/09/2012 21:34, Joshua Landau wrote:
On 13 September 2012 20:53, Mark Lawrence breamore...@yahoo.co.uk
wrote:acci sequence
On 13/09/2012 19:39, Prasad, Ramit wrote:
Dwight Hutto
Dwight Hutto wrote:
On Fri, Sep 14, 2012 at 4:20 AM, alex23 wuwe...@gmail.com wrote:
On Sep 14, 6:04 pm, Dwight Hutto dwightdhu...@gmail.com wrote:
Using foreign names derogatively is a common tactic of the racist.
Not really. But nice spin on my pun to make me look bad.
It actually
On Sep 6, 4:04 am, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On Thu, 06 Sep 2012 06:07:38 -0400, Dave Angel d...@davea.name wrote:
For random strings (as defined below), the average compare time is
effectively unrelated to the size of the string, once the size
passes
some point.
On Fri, Sep 14, 2012 at 6:43 PM, Prasad, Ramit
ramit.pra...@jpmorgan.com wrote:
Dwight Hutto wrote:
On Fri, Sep 14, 2012 at 4:20 AM, alex2find-work-home/3 wuwe...@gmail.com
wrote:
On Sep 14, 6:04 pm, Dwight Hutto dwightdhu...@gmail.com wrote:
Using foreign names derogatively is a common
Dwight Hutto wrote:
Why don' you just time it,eit lops through incrementing thmax input/
What? Without context I have no idea what this means.
Ramit
--
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities,
On Thu, Sep 13, 2012 at 2:39 PM, Prasad, Ramit
ramit.pra...@jpmorgan.com wrote:
Dwight Hutto wrote:
Why don' you just time it,eit lops through incrementing thmax input/
What? Without context I have no idea what this means.
Ramit
Why don't you read the OP:
Let's assume you're testing two
On 13/09/2012 19:39, Prasad, Ramit wrote:
Dwight Hutto wrote:
Why don' you just time it,eit lops through incrementing thmax input/
What? Without context I have no idea what this means.
Ramit
You're wasting your time, I've been described as a jackass for having
the audacity to ask for
On 13 September 2012 20:53, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 13/09/2012 19:39, Prasad, Ramit wrote:
Dwight Hutto wrote:
Why don' you just time it,eit lops through incrementing thmax input/
What? Without context I have no idea what this means.
You're wasting your time,
On Thu, Sep 13, 2012 at 4:34 PM, Joshua Landau
joshua.landau...@gmail.com wrote:
On 13 September 2012 20:53, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 13/09/2012 19:39, Prasad, Ramit wrote:
Dwight Hutto wrote:
Why don' you just time it,eit lops through incrementing thmax input/
On 13/09/2012 21:34, Joshua Landau wrote:
On 13 September 2012 20:53, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 13/09/2012 19:39, Prasad, Ramit wrote:
Dwight Hutto wrote:
Why don' you just time it,eit lops through incrementing thmax input/
What? Without context I have no idea what
On Thu, Sep 13, 2012 at 5:17 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 13/09/2012 21:34, Joshua Landau wrote:
On 13 September 2012 20:53, Mark Lawrence breamore...@yahoo.co.uk
wrote:acci sequence
On 13/09/2012 19:39, Prasad, Ramit wrote:
Dwight Hutto wrote:
Why don' you just
On Thu, 13 Sep 2012 17:06:23 -0400, Dwight Hutto wrote:
Then there is the problem of people saying you posted too much of the
context, or not inline with the OP, just at the end, or top posting.
The solution to you quoted too much unnecessary verbiage is not quote
nothing. It is quote only
On Sep 14, 5:37 am, Dwight Hutto dwightdhu...@gmail.com wrote:
Why don't take the time to read the OP, and ramit in your head?
Please, don't be a dick.
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Sep 14, 2012 at 1:39 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
You're assuming that people read your posts immediately after they read
the post you replied to. Always imagine that your reply will be read a
week after the post you replied to.
And a week is
On Thu, Sep 13, 2012 at 11:48 PM, alex23 wuwe...@gmail.com wrote:
On Sep 14, 5:37 am, Dwight Hutto dwightdhu...@gmail.com wrote:
Why don't take the time to read the OP, and ramit in your head?
Please, don't be a dick.
For telling him to ramit into his head that you should read the OP?
On Sep 14, 2:46 pm, Dwight Hutto dwightdhu...@gmail.com wrote:
For telling him to ramit into his head that you should read the OP?
Yes. I'm not sure if it was intentionally racist, but you come across
as a bit of a dwight supremacist.
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Sep 14, 2012 at 12:54 AM, alex23 wuwe...@gmail.com wrote:
On Sep 14, 2:46 pm, Dwight Hutto dwightdhu...@gmail.com wrote:
For telling him to ramit into his head that you should read the OP?
Yes. I'm not sure if it was intentionally racist, but you come across
as a bit of a dwight
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
But for the record, in principle string comparisons *could* be the
bottleneck. Example: you have 1 strings, which are each created
once and stored in a list. Then you iterate over the list, comparing
every string against every
Oscar Benjamin oscar.j.benja...@gmail.com wrote:
What interning buys you is that s == t is an O(1) pointer compare
if they are equal. But if s and t differ in the last character,
__eq__ will still inspect every character. There is no way to tell
Python all strings are interned, if s is not t
On 11 September 2012 10:51, Duncan Booth duncan.booth@invalid.invalidwrote:
Oscar Benjamin oscar.j.benja...@gmail.com wrote:
What interning buys you is that s == t is an O(1) pointer compare
if they are equal. But if s and t differ in the last character,
__eq__ will still inspect every
On 9/11/2012 6:40 AM, Oscar Benjamin wrote:
On 11 September 2012 10:51, Duncan Booth duncan.booth@invalid.invalid
mailto:duncan.booth@invalid.invalid wrote:
Oscar Benjamin oscar.j.benja...@gmail.com
mailto:oscar.j.benja...@gmail.com wrote:
What interning buys you is that s == t
Gelonida N gelon...@gmail.com wrote:
On 09/07/2012 06:06 AM, Steven D'Aprano wrote:
On Thu, 06 Sep 2012 06:07:38 -0400, Dave Angel wrote:
Also of some interest is the best case: O(1) for unequal strings (they
differ at the first character) and O(N) for equal strings.
The worst case is
On Mon, 10 Sep 2012 08:59:37 +, Duncan Booth wrote:
Gelonida N gelon...@gmail.com wrote:
On 09/07/2012 06:06 AM, Steven D'Aprano wrote:
On Thu, 06 Sep 2012 06:07:38 -0400, Dave Angel wrote:
Also of some interest is the best case: O(1) for unequal strings (they
differ at the first
On 2012-09-10, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Mon, 10 Sep 2012 08:59:37 +, Duncan Booth wrote:
Gelonida N gelon...@gmail.com wrote:
so at the expense of a single dictionary
insertion when the string is created you can get guaranteed O(1) on all
the
On Tue, Sep 11, 2012 at 12:06 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
On 2012-09-10, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
What interning buys you is that s == t is an O(1) pointer compare if
they are equal. But if s and t differ in the last character, __eq__
On 2012-09-10, Chris Angelico ros...@gmail.com wrote:
On Tue, Sep 11, 2012 at 12:06 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
On 2012-09-10, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
What interning buys you is that s == t is an O(1) pointer compare if
they are
On 2012-09-10, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 2012-09-10, Chris Angelico ros...@gmail.com wrote:
On Tue, Sep 11, 2012 at 12:06 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
On 2012-09-10, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
What interning
On Tue, Sep 11, 2012 at 12:43 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
On 2012-09-10, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
I haven't looked at the source but my understanding was precisely that there
is an intern() bit and that not only the builtins module but all the
On 04/09/2012 03:54, 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 at the ends of the
On 2012-09-10, Dan Goodman dg.gm...@thesamovar.net wrote:
On 04/09/2012 03:54, 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
On 10/09/2012 18:33, Oscar Benjamin wrote:
Computing the hash always requires iterating over all characters in the string
so is best case O(N) where string comparison is best case (and often average
case) O(1).
Yep, but you already have O(N) costs just creating the strings in the
first place,
On 10/09/2012 18:07, Dan Goodman wrote:
On 04/09/2012 03:54, 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
On 2012-09-10, Dan Goodman dg.gm...@thesamovar.net wrote:
On 10/09/2012 18:07, Dan Goodman wrote:
On 04/09/2012 03:54, 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)
On 2012-09-08, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Fri, 07 Sep 2012 19:10:16 +, Oscar Benjamin wrote:
On 2012-09-07, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info
wrote:
snip
Would you say, then, that dict insertion is O(N)?
Pedantically, yes.
But
On 09/06/2012 10:33 AM, Steven D'Aprano wrote:
On Wed, 05 Sep 2012 22:47:14 +, Oscar Benjamin wrote:
I may have been overly-conservative earlier when I said that on average
string equality has to compare half the characters. I thought I had
remembered that from a computer science textbook,
On 09/07/2012 06:06 AM, Steven D'Aprano wrote:
On Thu, 06 Sep 2012 06:07:38 -0400, Dave Angel wrote:
Also of some interest is the best case: O(1) for unequal strings (they
differ at the first character) and O(N) for equal strings.
The worst case is O(N) or N characters
the average case is
On 2012-09-07, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
snip
After further thought, and giving consideration to the arguments given by
people here, I'm now satisfied to say that for equal-length strings,
string equality is best described as O(N).
1) If the strings are
On 2012-09-07, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 2012-09-07, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
snip
Since string comparison is only useful if the strings can be equal or unequal,
the average case depends on how often they are equal/unequal as well
With unequal strings/lists to match, it would seem that one would regex
through the larger string/list with the shorter string, and piece by piece
begin to match for partial percentage matches in relation to the longer
iterative item.
--
Best Regards,
David Hutto
*CEO:*
On Fri, Sep 7, 2012 at 5:59 PM, Dwight Hutto dwightdhu...@gmail.com wrote:
With unequal strings/lists to match, it would seem that one would regex
through the larger string/list with the shorter string, and piece by piece
begin to match for partial percentage matches in relation to the longer
On Fri, 07 Sep 2012 19:10:16 +, Oscar Benjamin wrote:
On 2012-09-07, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info
wrote:
snip
After further thought, and giving consideration to the arguments given
by people here, I'm now satisfied to say that for equal-length strings,
string
Why don' you just time it,eit lops through incrementing thmax input/
--
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com*
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, 05 Sep 2012 22:47:14 +, Oscar Benjamin wrote:
In news.gmane.comp.python.general, you wrote:
On Wed, 05 Sep 2012 16:51:10 +0200, Johannes Bauer wrote: [...]
You are making unjustified assumptions about the distribution of
letters in the words. This might be a list of long chemical
On 09/06/2012 04:33 AM, Steven D'Aprano wrote:
snip
I may have been overly-conservative earlier when I said that on
average string equality has to compare half the characters. I thought
I had remembered that from a computer science textbook, but I can't
find that reference now, so possibly I
On Thu, 06 Sep 2012 06:07:38 -0400, Dave Angel d...@davea.name wrote:
For random strings (as defined below), the average compare time is
effectively unrelated to the size of the string, once the size
passes
some point.
Define random string as being a selection from a set of characters,
In article 50485fca$0$29977$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
In any case, the *worst* case for string equality
testing is certainly O(N) (every character must be looked at), and the
*best* case is O(1) obviously (the first
n Thu, Sep 6, 2012 at 10:13 PM, Roy Smith r...@panix.com wrote:
In article 50485fca$0$29977$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
In any case, the *worst* case for string equality
testing is certainly O(N) (every character must be
On 05.09.2012 18:24, Steven D'Aprano wrote:
On Wed, 05 Sep 2012 16:51:10 +0200, Johannes Bauer wrote:
[...]
You are making unjustified assumptions about the distribution of
letters in the words. This might be a list of long chemical compounds
where the words typically differ only in their
On 06.09.2012 10:33, Steven D'Aprano wrote:
But you know, it really doesn't make a difference. Equality testing will
*still* be O(N) since the asymptomatic behaviour for sufficiently large
string comparisons will be bounded by O(N). Multiplicative constants
(half the string versus 0.001 of
On 09/06/2012 09:43 AM, Johannes Bauer wrote:
snip
Yes, worst-case is O(N), best case O(1). Average is O(n log n).
Can't see how you came up with an average of n log(n). Fourteen minutes
before you made this post, you demonstrated it was less than 2 for any N.
And I previously posted that for
On 06.09.2012 16:23, Dave Angel wrote:
On 09/06/2012 09:43 AM, Johannes Bauer wrote:
snip
Yes, worst-case is O(N), best case O(1). Average is O(n log n).
Can't see how you came up with an average of n log(n). Fourteen minutes
before you made this post, you demonstrated it was less than 2
On 06.09.2012 15:43, Johannes Bauer wrote:
Wrong, at least for randomized strings (i.e. every character with the
same probability). O(N) is worst-case, O(log N) is correct for
randomized strings.
^^
Here I write the right thing. Then further below...
Yes, worst-case is O(N), best case O(1).
On 06.09.2012 16:23, Dave Angel wrote:
On 09/06/2012 09:43 AM, Johannes Bauer wrote:
snip
Yes, worst-case is O(N), best case O(1). Average is O(n log n).
Can't see how you came up with an average of n log(n). Fourteen minutes
before you made this post, you demonstrated it was less than 2
On Thu, Sep 6, 2012 at 11:37 PM, Johannes Bauer dfnsonfsdu...@gmx.de wrote:
Not in my original post. If you read it again, you will clearly see that
I was talking about purely random strings. And since you like to
nitpick, I'll clarify further: I'm talking about bitstrings in which
every bit
On 06.09.2012 16:39, Chris Angelico wrote:
In any case, it'll be far FAR more useful than arguing from
totally random, or random word selection, or anything.
Who's game?
Okay, patched against Python 3.2.3: http://pastebin.com/PRRN53P6
To invoke display of the stats, compare the string
On 06.09.2012 17:36, Johannes Bauer wrote:
pleasedumpstats
And against a XML-reading C code generator that uses mako:
strCmpEq 39670
strCmpLt 2766215
strCmpGt 2744002
strCmpTc 37430821
strCmpCc 14048656
Compared strings: 5549887
Equal: 0.7%
Average wordlength: 6.74 chars
Average
On 09/06/2012 10:42 AM, Johannes Bauer wrote:
On 06.09.2012 16:23, Dave Angel wrote:
On 09/06/2012 09:43 AM, Johannes Bauer wrote:
snip
Yes, worst-case is O(N), best case O(1). Average is O(n log n).
Can't see how you came up with an average of n log(n). Fourteen minutes
before you made
On Fri, 07 Sep 2012 00:39:33 +1000, Chris Angelico wrote:
On Thu, Sep 6, 2012 at 11:37 PM, Johannes Bauer dfnsonfsdu...@gmx.de
wrote:
Not in my original post. If you read it again, you will clearly see
that I was talking about purely random strings. And since you like to
nitpick, I'll
On Thu, 06 Sep 2012 06:07:38 -0400, Dave Angel wrote:
On 09/06/2012 04:33 AM, Steven D'Aprano wrote:
snip
I may have been overly-conservative earlier when I said that on average
string equality has to compare half the characters. I thought I had
remembered that from a computer science
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 length), and you're
On Wed, Sep 5, 2012 at 6:29 PM, Peter Otten __pete...@web.de wrote:
comparing every pair in a sample of 1000 8-char words
taken from '/usr/share/dict/words'
head
1: 477222
2: 18870 **
...
Not understanding this. What are the
a random idea:
you could compare strings by their hashes..
print hash(randomstring) == hash(randomstring)
print hash(randomstring) == hash(randoMstring)
--
--
http://mail.python.org/mailman/listinfo/python-list
On 04.09.2012 20:07, Steven D'Aprano wrote:
A reasonable, conservative assumption is to calculate the largest
possible value of the average for random strings. That largest value
occurs when the alphabet is as small as possible, namely two characters.
In practice, strings come from a larger
On 04.09.2012 23:59, Chris Angelico wrote:
n = (256 / 255) * (1 - 256 ^ (-c))
where n is the average number of character comparisons and c. The
rationale as follows: The first character has to be compared in any
case. The second with a probability of 1/256, the third with 1/(256^2)
and so
On 05.09.2012 11:24, Johannes Bauer wrote:
Consider sorting a large dictionary. Sorting is in O(n log(n)), but this
assumes O(1) comparisons! If the comparison operation itself were in
O(n), the total sorting complexity would be O(n^2 log(n)), which is
definitely false. Most comparisons will
Chris Angelico wrote:
On Wed, Sep 5, 2012 at 6:29 PM, Peter Otten __pete...@web.de wrote:
comparing every pair in a sample of 1000 8-char words
taken from '/usr/share/dict/words'
head
1: 477222
2: 18870 **
...
tail
1: 386633
On 5 September 2012 10:48, Peter Otten __pete...@web.de wrote:
Chris Angelico wrote:
On Wed, Sep 5, 2012 at 6:29 PM, Peter Otten __pete...@web.de wrote:
comparing every pair in a sample of 1000 8-char words
taken from '/usr/share/dict/words'
head
1: 477222
On Wed, 05 Sep 2012 11:43:08 +0200, Johannes Bauer wrote:
On 05.09.2012 11:24, Johannes Bauer wrote:
Consider sorting a large dictionary. Sorting is in O(n log(n)), but
this assumes O(1) comparisons! If the comparison operation itself were
in O(n), the total sorting complexity would be
On 05.09.2012 04:18, Neil Hodgson wrote:
The memcpy patch was controversial as it broke Adobe Flash which
assumed memcpy was safe like memmove.
Adobe Flash was broken before, making an assumption that is not
guaranteed by the standard. The patch only showed the problem.
Regards,
Johannes
On 05.09.2012 16:30, Steven D'Aprano wrote:
Since these are *completely different Ns*, you can't combine them to get
O(N**2 log N) as the overall algorithmic complexity. Doing so is sheer
nonsense. If you state it like this:
Yes, you are correct here.
You are making unjustified
Oscar Benjamin wrote:
On 5 September 2012 10:48, Peter Otten __pete...@web.de wrote:
def count_common(a, b):
[sorry for seriously broken implementation]
This function will return 1 if the first character differs. It does not
count the number of common characters but rather the more
On Wed, 05 Sep 2012 16:51:10 +0200, Johannes Bauer wrote:
[...]
You are making unjustified assumptions about the distribution of
letters in the words. This might be a list of long chemical compounds
where the words typically differ only in their suffix. It might be a
list of people with
In news.gmane.comp.python.general, you wrote:
On Wed, 05 Sep 2012 16:51:10 +0200, Johannes Bauer wrote:
[...]
You are making unjustified assumptions about the distribution of
letters in the words. This might be a list of long chemical compounds
where the words typically differ only in their
On 04/09/2012 05:56, Dan Sommers wrote:
That said, if I really wanted bloodshed, I would propose = for the third
string-equality operator! ;-)
Dan
Dan agent provocateur Sommers? :)
--
Cheers.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
On 04/09/2012 02:54, 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
Roy Smith r...@panix.com writes:
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 04.09.2012 04:17, Steven D'Aprano wrote:
On average, string equality needs to check half the characters in the
string.
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
On Tue, 04 Sep 2012 18:32:57 +0200, Johannes Bauer wrote:
On 04.09.2012 04:17, Steven D'Aprano wrote:
On average, string equality needs to check half the characters in the
string.
How do you arrive at that conclusion?
Take two non-empty strings of the same length, N. If the strings are
On 4 September 2012 19:07, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Tue, 04 Sep 2012 18:32:57 +0200, Johannes Bauer wrote:
On 04.09.2012 04:17, Steven D'Aprano wrote:
On average, string equality needs to check half the characters in the
string.
How do you
1 - 100 of 110 matches
Mail list logo
