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 c
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
> 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.
--
Bes
On Wed, Sep 19, 2012 at 2:17 AM, Dwight Hutto 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" has been reduced
>
> 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.
--
http://mail.python.org
>>> 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
On Tue, Sep 18, 2012 at 11:12 AM, Ethan Furman 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 m
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?
You're
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
--
http://mail.pyt
*plonk*
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 17, 2:05 pm, Chris Angelico 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 power
disparities
On Mon, Sep 17, 2012 at 11:11 AM, alex23 wrote:
> On Sep 15, 1:10 pm, Dwight Hutto 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".
>>
>>
On Sep 15, 1:10 pm, Dwight Hutto 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 should err on the
On Fri, Sep 14, 2012 at 6:43 PM, Prasad, Ramit
wrote:
> Dwight Hutto wrote:
>> On Fri, Sep 14, 2012 at 4:20 AM, alex2find-work-home/3
>> wrote:
>> > On Sep 14, 6:04 pm, Dwight Hutto wrote:
>> >> > Using foreign names derogatively is a common tactic of the racist.
>> >>
>> >> Not really. But nic
On Sep 6, 4:04 am, Oscar Benjamin wrote:
> On Thu, 06 Sep 2012 06:07:38 -0400, Dave Angel 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 s
Dwight Hutto wrote:
> On Fri, Sep 14, 2012 at 4:20 AM, alex23 wrote:
> > On Sep 14, 6:04 pm, Dwight Hutto 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 o
Dwight Hutto wrote:
> On Thu, Sep 13, 2012 at 5:17 PM, Mark Lawrence
> wrote:
> > On 13/09/2012 21:34, Joshua Landau wrote:
> >>
> >> On 13 September 2012 20:53, Mark Lawrence
> wrote:acci sequence
> >>
> >>> On 13/09/2012 19:39, Prasad, Ramit wrote:
> >>>
> Dwight Hutto wrote:
>
>
[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
> 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
On Sep 14, 6:53 pm, Dwight Hutto 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 sure it'd
be a wast
On Fri, 14 Sep 2012 01:20:53 -0700, alex23 wrote:
> On Sep 14, 6:04 pm, Dwight Hutto wrote:
[snip]
Please don't feed the trolls.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Sep 14, 2012 at 4:20 AM, alex23 wrote:
> On Sep 14, 6:04 pm, Dwight Hutto 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.
>
Not if there name is
On Sep 14, 6:04 pm, Dwight Hutto 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 do ya big
> pansy,
>> 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 l
On Sep 14, 3:39 pm, Dwight Hutto 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 really, no.
--
http:
On Fri, Sep 14, 2012 at 12:54 AM, alex23 wrote:
> On Sep 14, 2:46 pm, Dwight Hutto 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.
Please explain any logic
On Sep 14, 2:46 pm, Dwight Hutto 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 Thu, Sep 13, 2012 at 11:48 PM, alex23 wrote:
> On Sep 14, 5:37 am, Dwight Hutto 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?
--
Best Regards,
David Hutto
CEO:
On Fri, Sep 14, 2012 at 1:39 PM, Steven D'Aprano
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 extremely generous too; these posts get ar
On Sep 14, 5:37 am, Dwight Hutto 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 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 on
On Thu, Sep 13, 2012 at 5:17 PM, Mark Lawrence wrote:
> On 13/09/2012 21:34, Joshua Landau wrote:
>>
>> On 13 September 2012 20:53, Mark Lawrence
>> wrote:acci sequence
>>
>>> On 13/09/2012 19:39, Prasad, Ramit wrote:
>>>
Dwight Hutto wrote:
> Why don' you just time it,eit lops thr
On 13/09/2012 21:34, Joshua Landau wrote:
On 13 September 2012 20:53, Mark Lawrence 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
On Thu, Sep 13, 2012 at 4:34 PM, Joshua Landau
wrote:
> On 13 September 2012 20:53, Mark Lawrence 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 h
On 13 September 2012 20:53, Mark Lawrence 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, I've
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 con
On Thu, Sep 13, 2012 at 2:39 PM, 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
Why don't you read the OP:
Let's assume you're testing two strings for equal
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 9/11/2012 6:40 AM, Oscar Benjamin wrote:
On 11 September 2012 10:51, Duncan Booth mailto:duncan.booth@invalid.invalid>> wrote:
Oscar Benjamin mailto:oscar.j.benja...@gmail.com>> wrote:
>> What interning buys you is that "s == t" is an O(1) pointer compare
>> if they are equal.
On 11 September 2012 10:51, Duncan Booth wrote:
> Oscar Benjamin 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
> >> Pyth
Oscar Benjamin 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 then s != t as w
Steven D'Aprano 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 other string. And due to some weir
On 2012-09-10, Dan Goodman 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) part of com
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 migh
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 2012-09-10, 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
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 s
On Tue, Sep 11, 2012 at 12:43 AM, Oscar Benjamin
wrote:
> On 2012-09-10, Oscar Benjamin 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 literals
>> in any byte-compiled module are intern
On 2012-09-10, Oscar Benjamin wrote:
> On 2012-09-10, Chris Angelico wrote:
>> On Tue, Sep 11, 2012 at 12:06 AM, Oscar Benjamin
>> wrote:
>>> On 2012-09-10, Steven D'Aprano wrote:
What interning buys you is that "s == t" is an O(1) pointer compare if
they are equal. But if s and t diff
On 2012-09-10, Chris Angelico wrote:
> On Tue, Sep 11, 2012 at 12:06 AM, Oscar Benjamin
> wrote:
>> On 2012-09-10, Steven D'Aprano 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
>>> sti
On Tue, Sep 11, 2012 at 12:06 AM, Oscar Benjamin
wrote:
> On 2012-09-10, Steven D'Aprano 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 t
On 2012-09-10, Steven D'Aprano wrote:
> On Mon, 10 Sep 2012 08:59:37 +, Duncan Booth wrote:
>
>> Gelonida N wrote:
>>
>> so at the expense of a single dictionary
>> insertion when the string is created you can get guaranteed O(1) on all
>> the comparisons.
>
> What interning buys you is that
On Mon, 10 Sep 2012 08:59:37 +, Duncan Booth wrote:
> Gelonida N 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 cha
Gelonida N 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 O(N) or
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 O(1
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, b
On 2012-09-08, Steven D'Aprano wrote:
> On Fri, 07 Sep 2012 19:10:16 +, Oscar Benjamin wrote:
>
>> On 2012-09-07, Steven D'Aprano
>> wrote:
>>
>>
>> Would you say, then, that dict insertion is O(N)?
>
> Pedantically, yes.
>
> But since we're allowed to state (or even imply *wink*) whatever
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 Fri, 07 Sep 2012 19:10:16 +, Oscar Benjamin wrote:
> On 2012-09-07, Steven D'Aprano
> wrote:
>>
>>
>> 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
On Fri, Sep 7, 2012 at 5:59 PM, Dwight Hutto 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
> iterative item.
>
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:* *http://www.hitwebdevelopm
On 2012-09-07, Oscar Benjamin wrote:
> On 2012-09-07, Steven D'Aprano wrote:
>>
>
> 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 as the
> average complexity of both. For random strings the fr
On 2012-09-07, Steven D'Aprano wrote:
>
>
> 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 equal, a == b will always compare a
On Thu, 06 Sep 2012 06:07:38 -0400, Dave Angel wrote:
> On 09/06/2012 04:33 AM, Steven D'Aprano 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
On Fri, 07 Sep 2012 00:39:33 +1000, Chris Angelico wrote:
> On Thu, Sep 6, 2012 at 11:37 PM, Johannes Bauer
> 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'
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:
>>>
>>> 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
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 compare
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 Thu, Sep 6, 2012 at 11:37 PM, Johannes Bauer 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 of every character
On 06.09.2012 16:23, Dave Angel wrote:
> On 09/06/2012 09:43 AM, Johannes Bauer wrote:
>>
>> 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
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:
>>
>> 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
On 09/06/2012 09:43 AM, Johannes Bauer wrote:
>
> 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 a
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.
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
n Thu, Sep 6, 2012 at 10:13 PM, Roy Smith wrote:
> In article <50485fca$0$29977$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano 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) ob
In article <50485fca$0$29977$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano 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 character fails to match).
The best
On Thu, 06 Sep 2012 06:07:38 -0400, Dave Angel 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,
with
replacement.
On 09/06/2012 04:33 AM, Steven D'Aprano 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, but I can't
> find that reference now, so possibly
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
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
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
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 r
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 assumpt
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 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
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
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 **
>> ...
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 wi
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)
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 lar
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 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
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
In article <-9cdnaqjtk6nktvnnz2dnuvz_gedn...@westnet.com.au>,
Neil Hodgson wrote:
> The memcpy patch was controversial as it broke Adobe Flash
An added benefit!
--
http://mail.python.org/mailman/listinfo/python-list
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. This
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 prioritiz
On 4 September 2012 22:59, Chris Angelico wrote:
> On Wed, Sep 5, 2012 at 2:32 AM, Johannes Bauer
> 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
On Wed, Sep 5, 2012 at 2:32 AM, Johannes Bauer 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 first character
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.
> >
>
1 - 100 of 111 matches
Mail list logo
