Chris Angelico writes:
> some point it'll need to be rebalanced, which could at worst case
> be O(n).
No, you use a structure like an AVL tree or red-black tree, so it's
within a constant factor of balanced after each insertion. You rewrite
O(log n) of the nodes, and juggle around a constant nu
On Thu, Jul 13, 2017 at 6:15 PM, Paul Rubin wrote:
> Chris Angelico writes:
>> some point it'll need to be rebalanced, which could at worst case
>> be O(n).
>
> No, you use a structure like an AVL tree or red-black tree, so it's
> within a constant factor of balanced after each insertion. You re
Chris Angelico writes:
> Maybe I'm completely on the wrong track here, but the last time I
> implemented a self-balancing tree, it usually involved a fair amount
> of mutation.
AVL trees are fairly simple to implement without mutation. Red-black
trees are traditionally implemented with mutation,
Paul Rubin :
> Chris Angelico writes:
>> Maybe I'm completely on the wrong track here, but the last time I
>> implemented a self-balancing tree, it usually involved a fair amount
>> of mutation.
>
> AVL trees are fairly simple to implement without mutation. Red-black
> trees are traditionally im
Marko wrote:
> Simple, yes, but is the worst case
> insertion/deletion time still within
> O(log n)?
Good point; and needs to be applied to Steven's
append-using OP as well
Yeah I know append method is supposedly O(1).
I find that surprising...
More so when the article
https://wiki.python.or
On Thu, 13 Jul 2017 10:10 pm, Rustom Mody wrote:
> Yeah I know append method is supposedly O(1).
> I find that surprising...
> More so when the article
> https://wiki.python.org/moin/TimeComplexity
> talks of average case Vs amortized-worst case(!) Whatever does that mean?
"Average case" refers
On 12/07/17 16:19, WoFy The 95s wrote:
On Wednesday, 12 July 2017 18:57:11 UTC+5:30, Peter Otten wrote:
WoFy The 95s wrote:
i tried from idle interpreter
from person import Manager
from person import Manager
Traceback (most recent call last):
File "", line 1, in
from person import Mana
On 7/13/17, Steve D'Aprano wrote:
> [1] Actually, CPython's lists initially quadruple the size of the array, up
> to a
> certain point, and then switch to doubling. This ensures that small lists
> have
> even fewer expensive resizes, at the cost of wasting a bit more memory, but
> its
> only a sm
Pavol Lisy wrote:
> IMHO problem is doubling size for huge lists.
> Or waste big memory for huge frozensets. I mean resize it to 2*N if
> its size is just N+1.
Couple that with the fact that space-time are not unrelated on any modern VM
based OS + cache based hw. Doubly so for "managed" langua
I have created one thread in python, and that thread is running in infinite
loop, but when I was trying to kill a process by making use of
subprocess.call("my ps command") Its not actually working
Here is the code,
import threading
import subprocess
def B():
while True:
cmd="ps
On 13/07/17 16:09, Rustom Mody wrote:
Pavol Lisy wrote:
IMHO problem is doubling size for huge lists.
Or waste big memory for huge frozensets. I mean resize it to 2*N if
its size is just N+1.
Couple that with the fact that space-time are not unrelated on any modern VM based OS +
cache base
On 13/07/17 16:42, sanky8...@gmail.com wrote:
I have created one thread in python, and that thread is running in infinite loop, but
when I was trying to kill a process by making use of subprocess.call("my ps
command") Its not actually working
Here is the code,
import threading
import subp
On Fri, 14 Jul 2017 01:09 am, Rustom Mody wrote:
> Couple that with the fact that space-time are not unrelated on any modern VM
> based OS + cache based hw. Doubly so for "managed" languages where gc buys
> space for time.
I don't understand that comment. Space/time have *never* been unrelated.
On Fri, 14 Jul 2017 12:59 am, Pavol Lisy wrote:
> On 7/13/17, Steve D'Aprano wrote:
>
>> [1] Actually, CPython's lists initially quadruple the size of the array, up
>> to a
>> certain point, and then switch to doubling. This ensures that small lists
>> have
>> even fewer expensive resizes, at th
On 7/13/17, Steve D'Aprano wrote:
> On Fri, 14 Jul 2017 12:59 am, Pavol Lisy wrote:
>
>> On 7/13/17, Steve D'Aprano wrote:
>>
>>> [1] Actually, CPython's lists initially quadruple the size of the array,
>>> up
>>> to a
>>> certain point, and then switch to doubling. This ensures that small lists
On Fri, Jul 14, 2017 at 2:26 AM, Steve D'Aprano
wrote:
> On Fri, 14 Jul 2017 01:09 am, Rustom Mody wrote:
>
>> Couple that with the fact that space-time are not unrelated on any modern VM
>> based OS + cache based hw. Doubly so for "managed" languages where gc buys
>> space for time.
>
> I don't u
On Thursday, July 13, 2017 at 10:59:52 AM UTC-4, Pavol Lisy wrote:
> On 7/13/17, Steve D'Aprano wrote:
>
> > [1] Actually, CPython's lists initially quadruple the size of the array, up
> > to a
> > certain point, and then switch to doubling. This ensures that small lists
> > have
> > even fewer e
From time to time, people discover that Python's string algorithms work on code
points rather than "real characters", which can lead to anomalies like the
following:
s = 'xäex'
s = unicodedata.normalize('NFD', s)
print(s)
print(s[::-1])
which results in:
xäex
xëax
If you're interested in this
Steve D'Aprano writes:
> From time to time, people discover that Python's string algorithms work on
> code
> points rather than "real characters", which can lead to anomalies like the
> following:
>
> s = 'xäex'
> s = unicodedata.normalize('NFD', s)
> print(s)
> print(s[::-1])
>
>
> which result
Very much interested...
0426465115
--
https://mail.python.org/mailman/listinfo/python-list
Ben Finney :
> Steve D'Aprano writes:
>> From time to time, people discover that Python's string algorithms
>> work on code points rather than "real characters", which can lead to
>> anomalies
>
> [...]
[unicodedata.name(c) for c in reversed(s1)]
> ['LATIN SMALL LETTER X',
> 'LATIN SMALL LE
21 matches
Mail list logo
