As the comments in the heapq module says, in most of the cases
(probability 0.837 [from knuth vol3]) the the new inserted element
whose initial location is end of the array, which means that it will
be larger than the `pos` children. So the old version and new version
code is same in these cases be
wow, that's great.
you read a comment in the code, and you test it, to only find that it
is indeed true,
sounds ok, but feels great. :)
Just experimenting a bit, I swaped the lines _siftdown and _siftup and something
strange happened the number of comparisions in both the versions remained same.
I
again for the list:
###
import random
from xheap import RemovalHeap
class X(object):
c = 0
def __init__(self, x):
self.x = x
def __lt__(self, other):
X.c += 1
return self.x < other.x
n = 10
for jj in range(5):
items = [X(i) for i i
Hi srinivas,
I wrote this simple benchmark to measure comparisons:
import random
from xheapimport RemovalHeap
class X(object):
c =0 def __init__(self, x):
self.x = x
def __lt__(self, other):
X.c +=1 return self.x < other.x
n =10 for jjin range(5):
items = [X(i
On Fri, Feb 5, 2016 at 8:12 PM, Sven R. Kunze wrote:
> On 05.02.2016 02:26, srinivas devaki wrote:
> What do you think about our use-case?
>
Oh, the logic is sound, every element that we have inserted has to be popped,
We are spending some *extra* time in rearranging the elements only to be
sure t
On 02/05/2016 12:55 PM, Sven R. Kunze wrote:
On 05.02.2016 15:48, Bernardo Sulzbach wrote:
On 02/05/2016 12:42 PM, Sven R. Kunze wrote:
PS: I do competitive programming, I use these modules every couple of
days
when compared to other modules. so didn't give much thought when
posting to
the mai
On 05.02.2016 15:48, Bernardo Sulzbach wrote:
On 02/05/2016 12:42 PM, Sven R. Kunze wrote:
PS: I do competitive programming, I use these modules every couple of
days
when compared to other modules. so didn't give much thought when
posting to
the mailing list. sorry for that.
Competitive progr
On 02/05/2016 12:42 PM, Sven R. Kunze wrote:
PS: I do competitive programming, I use these modules every couple of
days
when compared to other modules. so didn't give much thought when
posting to
the mailing list. sorry for that.
Competitive programming? That sounds interesting. :)
I wonder
On 05.02.2016 02:26, srinivas devaki wrote:
as I come to think of it again, it is not subheap, it actually heap cut at
some level hope you get the idea from the usage of _siftup. so even though
the `pos` children are valid the _siftup brings down the new element (i.e
the element which is at first
On Feb 5, 2016 5:45 AM, "Steven D'Aprano" wrote:
>
> On Fri, 5 Feb 2016 07:50 am, srinivas devaki wrote:
>
> > _siftdown function breaks out of the loop when the current pos has a
valid
> > parent.
> >
> > but _siftup function is not implemented in that fashion, if a valid
> > subheap is given to
On 05.02.2016 01:12, Steven D'Aprano wrote:
On Fri, 5 Feb 2016 07:50 am, srinivas devaki wrote:
_siftdown function breaks out of the loop when the current pos has a valid
parent.
but _siftup function is not implemented in that fashion, if a valid
subheap is given to the _siftup, it will bring
On Fri, 5 Feb 2016 07:50 am, srinivas devaki wrote:
> _siftdown function breaks out of the loop when the current pos has a valid
> parent.
>
> but _siftup function is not implemented in that fashion, if a valid
> subheap is given to the _siftup, it will bring down the root of sub heap
> and then
_siftdown function breaks out of the loop when the current pos has a valid
parent.
but _siftup function is not implemented in that fashion, if a valid subheap
is given to the _siftup, it will bring down the root of sub heap and then
again bring it up to its original place.
I was wondering why it
13 matches
Mail list logo
