"The real answer is clearly because hashes are faster than b trees."
I got on the phone with the engineer responsible for the firmware and sent him my code, but I never did find out what the problem was (sorry for the letdown, maybe someone at Parallax remembers and reads Hacker News?). They acknowledged it as a bug, and made a fix. Unfortunately the fix made was to always draw 300uA at sleep!
Fast forward 18 years (!) and from their website it looks like their latest modal draws 50uA, so it was a happy ending after all. The end.
SO actually allows this, Q and A from the same account. Some people use sock-puppets though.
If I do end up figuring out a solution, I definitely post it, and I'm glad that SO allows this, otherwise there would still be no answer to some of these questions online... One of these issues previously only turned up a single bash mailing list post from a decade ago with no resolution. Now searching for a few relevant search terms turns up my answer/solution in the top few results for all of them.
I don't care about imaginary internet points, I just figured I'd help the next guy out.
You have a cross between misinterpreting what something means, on obscure hardware, with a useless error message and you are normally stuck for days.
Why would people use sock-puppets, I don't know. It seems that the SO team has special ways to detect voting frauds.
Also, while voting fraud is against the guidelines and actively countered, creating sock puppet accounts is not.
You're right. For anyone interested here is the relevant post: http://meta.stackexchange.com/q/57682/297429
> There are some answers that come from hard learned experience. T.J. and I (since we are friends) grew up in the days of the Apple ][ and the zx80/81. There was no built in word wrap back then. So we both ended up writing our own — more than once. And those lessons stick with you, they get burned in to your lizard brain. But if you leaned to code after that, when your environment word wraps everything, or you do it manually prior to runtime, it is harder to run into the issues with word wrap. – JockM
Then the 1000x engineer explains:
"You are confused because you do not understand Tao. Only a fool expects rational behavior from his fellow humans. Why do you expect it from a machine that humans have constructed? Computers simulate determinism; only Tao is perfect.
The rules of programming are transitory; only Tao is eternal. Therefore, you must contemplate Tao before you receive Enlightenment."
"But how will I know when I have received Enlightenment?" asks the 100x engineer.
"Your program will run correctly," replies the 1000x engineer.
Sure, anyone can find the answer if they already know where to look.
FWIW, I always start with a full system profile including all thread states when debugging mysterious performance issues, precisely because "the problem is in another process" is such a common occurrence. This is also why it's important to use a sampling profiler specifically.
It may be better to try a generally good algorithm first, then if it fails after X iterations to fall back to an algorithm with a better bound on the worst case.
I don't know how it works but it's insanely fast.
You might like to read the rationale section of PEP 471:
And when it doesn't, if you're not at least a little familiar with what's going on, it can be a deeply confusing and obscure little world.
The first thing I can think of is that if you're writing a flood-filling algorithm (finding connected components) you should fill with #s instaed of Bs, even if filling with Bs is more conventional. Specially if you're doing competitive programming and need to overkill the optimization process in order to pass the run time.
As for production coding, I can't think of anything. Any ideas?
BTW, this is probably speculation, but it's still worth discussing in my humble opinion.