March 27, 2016 § Leave a comment
[The following is the final installment of a science-fiction serial I started writing at Matterport, where I worked from May to December of 2015. Someday I will get the rights to publish the entire story, but for now, enjoy this little vignette.]
Stark Realty #20: Redemption
“He didn’t kill your mother, Tanya.” panted the newly-arrived Jane Hathaway. “I did.”
Tanya Bain stared at the petite, matronly woman in shocked disbelief. Tony Stark, his hands nailed to the concrete wall with Q-carbon spikes, screamed “Jane, no!”
The demolecularizing grenade Tanya had placed over her father’s arc reactor-powered heart dropped from suddenly nerveless fingers. With a supreme effort, Tony levered himself against the spikes and drop-kicked the grenade against the far wall, where it harmlessly vaporized a quarter-inch of foamed concrete.
“Tanya,” he gasped. “Please. Don’t believe her. It was all my fault.”
His estranged daughter stared at him blankly, sinking slowly to the ground. She, with help from the anonymous cyber-dwarf Rumplestilskin, had put herself through hell to destroy Iron Man for killing her mother. Had her whole life been based on a lie?
January 20, 2016 § Leave a comment
Live chat support software is a great way to ensure visitors to your SaaS site are successful – or at least tell you what went wrong. An in-page widget with a friendly human being on the other side is much more approachable than a link to anonymous forum!
Unfortunately, few startups are able to guarantee 24×7 coverage, which means you need a easy-to-use tool with a good fallback user experience for when nobody is available to chat. Here is what appear to be the best options as of January 2016.
November 20, 2015 § Leave a comment
- Vision: What does success look like?
Humanity: What do you need to succeed?
Process: How do we ensure everyone gets what they need?
November 10, 2014 § Leave a comment
He’s my hero. THIS is how I dream of running my own projects / company.
Earlier this year I confronted the painful realization that my baby framework grew into a mature ecosystem – one I no longer had the capacity to maintain on my own. It started with dragging open issues for more than a few days, to a growing pile of sticky notes on my monitor of ideas I’d like to try, to (and most problematic) no longer remembering how big chunks of the code work.
The problem is, how to successfully move from a one-man-show to a community driven project, without giving up on the stability, consistency, and philosophy of the framework.
I believe the only practical model for running a successful open source project is the Consensus-Dictator-Fork (CDF) model. It’s a fancy name for how most open source projects work. Decisions are made by consensus whenever possible. This usually covers 95% of the decisions by the simple mechanism of proposing a…
View original post 932 more words
June 17, 2014 § Leave a comment
The mechanics of jobs will be automated, which is why the jobs of the future will rely on us being more human to each other.
THE ROBOT TWEETSTORMS by @PMARCA
One of the most interesting topics in modern times is the “robots eat all the jobs” thesis. It boils down to this: Computers can increasingly substitute for human labor, thus displacing jobs and creating unemployment. Your job, and every job, goes to a machine.
This sort of thinking is textbook Luddism, relying on a “lump-of-labor” fallacy – the idea that there is a fixed amount of work to be done. The counterargument to a finite supply of work comes from economist Milton Friedman — Human wants and needs are infinite, which means there is always more to do. I would argue that 200 years of recent history confirms Friedman’s point of view.
If the Luddites had it wrong in the early 19th century, the only way their line of reasoning works today is if you believe this time is…
View original post 1,771 more words
June 15, 2014 § Leave a comment
We hold certain positions because of what we:
A. Experience -> B. Encode -> C. Evaluate -> D. Emphasize -> E. Express
August 9, 2013 § Leave a comment
A Function of Scale
Draft 1, Ernest Prabhakar, 2013-08-08
The Sequel to “The Minion Machine“
Real systems aren’t linear, but have scales where the cost is fixed below, but astronomical above.
Extend/Restrict the Minion Machine to capture what it means to operate at “optimal scale”.
Define a Multi-Minion Machine as a Minion Machine with the following changes:
- There is one minion for each bin (and thus each object) (M = N)
- Minions never move; they just shoot objects to other minions.
- The N objects are arranged in a ring of radius R, so “1” is next to “N”.
- The objects travel on independent tracks of size r << R, so they don’t collide, but take effectively the same distance to a given bin.
Assume the minions are smart enough to figure out the optimal route from one bin to another. Instead of specifying a distance, we can thus just specify a destination (and not have to worry about ‘overflow’ or ‘underflow’).
Our primitive commands only need specify the initial (b_i) and final (b_f) bins, giving a size of:
S1 = 2 log(N) := 2 k
All other quantities are the same, except that the average distance d will be less (half?) due to the ring topology.
Let us use bold characters to represent an action tuple (E, t) whose norm is E times t. For example, operation L has the action A_L = (E_L, t_L). The action of our system can be decomposed into C for the communicator and M for movement.
If solving the puzzle requires n commands of size S1 and average distance d, we can write our action as:
A0 = n S1 C + n M(d)
[Errata: parallel operations could complete in a time proportion to max(d), independent of n. There is a complex dependency on the relative values of C_t and M_t which I overlooked].
Now we can ask: would higher order commands reduce the action?
To start, let us introduce a program with per-command cost T that interprets a command as a transposition instead of a move. For example, if N = 8, the command 0x1f is split into 0x1f and 0xf1 and executed in parallel.
For a set of disjoint transpositions that would normally take n moves to solve, the action is now:
A1 = n/2 S1 C + n/2 M(d) + n/2 T
For this case, it is a net win when (substituting k = log(N) = S1 / 2):
T < 2 k C + M(d)
which is a net win for sufficiently large k.
However, that advantage only holds for disjoint permutations. Conjoined permutations (e.g., cycles) take the same number of steps as before, but most now pay the penaltyT.
To solve that, we could replace T with a program L that describes loops (cycles) rather than mere transpositions. This gives us, for all (?) permutations:
A2 = n/2 S1 C + n/2 M(d) + n/2 L
with a similar constraint:
L < 2 k C + M(d)
A particular command/program specification can be interpreted as a “strategy”.
For example [as Christy suggested], imagine two players Satan and God.
- Each of them is given a Multi-Minion box for which they devise a fixed strategy behind closed doors.
- When the curtain comes up, Satan & God get to see each other’s strategies.
- Satan secretly feeds commands into his box to entangle a set of balls.
- Those balls are teleported into God’s box, where he must dis-entangle them.
Every command costs some number of “action points” (great name, Christy. The winner is the player who spends the fewest action points.
This leads to a number of interesting questions:
- Are there optimal strategies for God and Satan? Is the optimal strategy the same for both players? Is there a meta-strategy for which commands Satan should use, after finding out God’s strategy?
- Does one player have an intrinsic advantage in this case? What about the case where the entanglement isn’t simple permutations, but some NP-complete problem?
- How should we calculate the per-command cost P for the program used to implement the strategy? Naively, L ought to be bigger than T, but by how much? Can we break all possible strategies down into a “basis” of simpler components, allowing cost comparisons between them?
- Do any of these results change in interesting ways if we add baseline costs for any of the elements?
I’m not sure if we learned anything about scale, but we did develop a useful concept of strategy. It also implies that the action (which is perhaps closer to “difficulty” rather than mere “complexity”) depends on interactions between the instruction set chosen and details of the input vectors.
Then again, maybe that is why we have different scales: to allow optimal instruction sets for different levels of representing a problem…