Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Ok, after coming to my senses, here's a non-ridiculous version of <code>window_iter_fill</code>. My previous version (visible in edits) was terrible because I forgot to use <code>izip</code>. Not sure what I was thinking. Using izip, this works, and, in fact, is the fastest option for small inputs!</p> <pre><code>def window_iter_fill(gen, size=2, fill=None): gens = (chain(repeat(fill, size - i - 1), gen, repeat(fill, i)) for i, gen in enumerate(tee(gen, size))) return izip(*gens) </code></pre> <p>This one is also fine for tuple-yielding, but not quite as fast. </p> <pre><code>def window_iter_deque(it, size=2, fill=None, fill_left=False, fill_right=False): lfill = repeat(fill, size - 1 if fill_left else 0) rfill = repeat(fill, size - 1 if fill_right else 0) it = chain(lfill, it, rfill) d = deque(islice(it, 0, size - 1), maxlen=size) for item in it: d.append(item) yield tuple(d) </code></pre> <p>HoverHell's newest solution is still the best tuple-yielding solution for high inputs.</p> <p>Some timings:</p> <pre><code>Arguments: [xrange(1000), 5, 'x', True, True] ============================================================================== window HoverHell's frankeniter : 0.2670ms [1.91x] window_itertools from old itertools docs : 0.2811ms [2.02x] window_iter_fill extended `pairwise` with izip : 0.1394ms [1.00x] window_iter_deque deque-based, copying : 0.4910ms [3.52x] ia_with_copy deque-based, copying v2 : 0.4892ms [3.51x] ia deque-based, no copy : 0.2224ms [1.60x] ============================================================================== </code></pre> <p>Scaling behavior:</p> <pre><code>Arguments: [xrange(10000), 50, 'x', True, True] ============================================================================== window HoverHell's frankeniter : 9.4897ms [4.61x] window_itertools from old itertools docs : 9.4406ms [4.59x] window_iter_fill extended `pairwise` with izip : 11.5223ms [5.60x] window_iter_deque deque-based, copying : 12.7657ms [6.21x] ia_with_copy deque-based, copying v2 : 13.0213ms [6.33x] ia deque-based, no copy : 2.0566ms [1.00x] ============================================================================== </code></pre> <p>The deque-yielding solution by agf is super fast for large inputs -- seemingly O(n) instead of O(n, m) like the others, where n is the length of the iter and m is the size of the window -- because it doesn't have to iterate over every window. But I still think it makes more sense to yield a tuple in the general case, because the calling function is probably just going to iterate over the deque anyway; it's just a shift of the computational burden. The asymptotic behavior of the larger program should remain the same.</p> <p>Still, in some special cases, the <code>deque</code>-yielding version will probably be faster.</p> <p>Some more timings based on HoverHell's test structure. </p> <pre><code>&gt;&gt;&gt; import testmodule &gt;&gt;&gt; kwa = dict(gen=xrange(1000), size=4, fill=-1, fill_left=True, fill_right=True) &gt;&gt;&gt; %timeit -n 1000 [a + b + c + d for a, b, c, d in testmodule.window(**kwa)] 1000 loops, best of 3: 462 us per loop &gt;&gt;&gt; %timeit -n 1000 [a + b + c + d for a, b, c, d in testmodule.ia(**kwa)] 1000 loops, best of 3: 463 us per loop &gt;&gt;&gt; %timeit -n 1000 [a + b + c + d for a, b, c, d in testmodule.window_iter_fill(**kwa)] 1000 loops, best of 3: 251 us per loop &gt;&gt;&gt; %timeit -n 1000 [sum(x) for x in testmodule.window(**kwa)] 1000 loops, best of 3: 525 us per loop &gt;&gt;&gt; %timeit -n 1000 [sum(x) for x in testmodule.ia(**kwa)] 1000 loops, best of 3: 462 us per loop &gt;&gt;&gt; %timeit -n 1000 [sum(x) for x in testmodule.window_iter_fill(**kwa)] 1000 loops, best of 3: 333 us per loop </code></pre> <p>Overall, once you use <code>izip</code>, <code>window_iter_fill</code> is quite fast, as it turns out -- especially for small windows. </p>
    singulars
    1. This table or related slice is empty.
    1. POIterate over a ‘window’ of adjacent elements in Python
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USsenderle
    1. USsenderle
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COIterating over a deque is faster than iterating over a tuple, though, so it makes sense to return a deque if you're going to iterate. [Here's a recent answer](http://stackoverflow.com/questions/6822725/rolling-or-sliding-window-iterator-in-python/6822761#6822761) in which I timed a few windowing iterators and considered the deque vs. tuple/list question.
      singulars
      1. PO
      1. USkindall
    2. COFunny that window_itertools is a little bit slower. Also, deque is faster if you're going to iterate, but tuple seems faster if you're unpacking.
      singulars
      1. PO
      1. USHoverHell
    3. COEr, actually tuple just *seemed* faster when unpacking - deque is approximately as fast in such case. See my answer for some timings.
      singulars
      1. PO
      1. USHoverHell
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload