Big-Q notation is exactly the same as Big-O notation, except for the understanding that the constant multiplier for the asymptotic bound function is greater.
For example Big-O is defined as:
f(x) <= C * g(x)
Big-Q notation could be defined as:
from cloudsearch import connect_cloudsearch, get_document_service | |
endpoint = 'paste your doc service endpoint here' | |
service = get_document_service(endpoint=endpoint) # Get a new instance of cloudsearch.DocumentServiceConnection | |
# Presumably get some users from your db of choice. | |
users = [ | |
{ | |
'id': 1, |
// put this in a bookmarklet | |
// click it as required | |
javascript: (function () { | |
var style = document.createElement('style'); | |
style.innerHTML = '* { -webkit-text-size-adjust:auto; }'; | |
document.head.appendChild(style); | |
})(); |
$red: #B12125 | |
$ltred: #DC8B6A | |
$dkblue: #3E67B0 | |
$blue: #44ABDF | |
$yellow: #FCC10F | |
$ltyellow: #FCE598 | |
$teal: #379D92 | |
$ltteal: #9BCEC8 | |
$violet: #742E66 | |
$ltviolet: #993D88 |
// Here is a proposal for minimalist JavaScript classes, humbly offered. | |
// There are (at least) two different directions in which classes can be steered. | |
// If we go for a wholly new semantics and implementation, then fancier classical | |
// inheritance can be supported with parallel prototype chains for true inheritance | |
// of properties at both the class and instance level. | |
// If however, we keep current JavaScript prototype semantics, and add a form that | |
// can desugar to ES3, things must necessarily stay simpler. This is the direction | |
// I'm assuming here. |
#! /usr/bin/env python | |
import redis | |
import random | |
import pylibmc | |
import sys | |
r = redis.Redis(host = 'localhost', port = 6389) | |
mc = pylibmc.Client(['localhost:11222']) |
[ | |
{ | |
"keys": ["super+alt+shift+5"], | |
"command": "set_layout", | |
"caption" : "1-2 Grid", | |
"args": | |
{ | |
"cols": [0.0, 0.5, 1.0], | |
"rows": [0.0, 0.5, 1.0], | |
"cells": |
# This formula provide NodeJS v0.5.9 for Mac Homebrew | |
# | |
# Install this node-unstable.rb file in your `brew --prefix` directory | |
# Then: | |
# $ brew install node-unstable | |
# | |
# Formula was uploaded originally for v0.5.7 originally at: | |
# https://raw.github.com/bramswenson/homebrew/94c4104e50a95c111710ab7bc52cc2f7417db712/Library/Formula/node-unstable.rb | |
# | |
# Unfortunately, NodeJS 0.5.7 or 0.5.8 do not provide child_process.fork() |
var snail = '@__y' | |
, progress = 0 | |
, pad = function(x) { var str = []; for(var i = 0; i < x; ++i) { str.push(' ') }; return str.join('') } | |
var interval = setInterval(function() { | |
++progress | |
progress >= 100 && | |
(progress = 0) | |
process.stdout.write('\r') |
The generated-pth.py is what is created when installing a namespace package. These files are loaded on the auto-import of the site module to make sure Python knows where to find everything. There's a slight bug in this, however, that causes a problem. What happens if you have an __init__.py
file in one of the directories along the way?
We ran into this in Armstrong creating our armstrong.apps.audio.backends.*
packages. The code that's checks to see if there's an __init__.py
in the directory, and if there is it doesn't pre-populate it with a fake module. The problem is that those modules might not actually be imported and loaded yet. See where this is going yet?
This code creates the following in sys.modules
:
sys.modules["armstrong"] = types.ModuleType("armstrong")
sys.modules["armstrong"].apps = types.ModuleType("armstrong.apps")