"Rate" implies that the denominator is a timespan. This does not make sense, as there are many slopes which are not rates and which are not presented as rates.
It's kind of a silly thing to worry about, but Khan's answer is unequivocally better.
144 karma · joined January 13, 2010
"Rate" implies that the denominator is a timespan. This does not make sense, as there are many slopes which are not rates and which are not presented as rates.
It's kind of a silly thing to worry about, but Khan's answer is unequivocally better.
RPC rarely lives up to this promise. Starting simple is certainly a good approach, but don't fool yourself about how hard it's going to be when you need to deal with latency and partial failure later.
SPARQL is harder to learn and set up, but allows for more complicated queries that might require offline processing.
(I designed the first version of MQL)
Better to say that "present-day publishers work hard to make the cover something you can sell a book by."
http://nixweb.com/dust/ is my version, for the SF Bay Area only. It was 15 years ago so pardon my Java applet.
A normal video camera records a frame at a time, this one records a scanline-sized movie at a time. The raw data is noisy but the scene is static so they can sample the same line over many flashes.
After a few minutes of scanning they have a trillion fps video where you can see a wavefront propagate at the speed of light. Amazing.
The Open Exhibits Gesture Library is another option. It looks like they broke the old link at http://openexhibits.org/gesturelibrary but you can see an example gesture at http://openexhibits.org/support/gestures/35/two-finger-scale and click around for the rest.
The Cue icons will be clearer at small point sizes, but if you have enough pixels the (mostly) graceful hands in the Open Exhibits library feel more appealing than Cue's big fingernail.
Lots of interesting stuff here on factors affecting reaction time: http://biae.clemson.edu/bpc/bp/Lab/110/reaction.htm#Type%20o...
Your experiment must have been set up differently though - the fastest time they mention is 180msec for teenagers.
liquefaction hazards for SF: http://gmw.consrv.ca.gov/SHMP/download/pdf/ozn_sf.pdf other PDFs: http://gmw.consrv.ca.gov/SHMP/html/pdf_maps_no.html
The Objective-C language (Smalltalk in C) was a nice idea (in the 80s...) but newcomers to iOS should be aware that the non-UI parts of the Cocoa/UIKit libraries are garbage compared to what C programmers have built over the past thirty years. I've had to replace enough of the ObjC libraries I've used with plain C that I just start with the C code now.
See http://en.wikipedia.org/wiki/Diatonic_scale#Prehistory - which also says that the circle of fifths was described much earlier than I thought.
This is my somewhat fuzzy recollection from a paper I read a long time ago. Someone out there can check with three lines of R, right?
Meanwhile Brendan was doing the work of ten engineers and three customer support people, and paying attention to things that mattered to web authors, like mixing JS code into HTML, instant loading, integration with the rest of the browser, and working with other browser vendors to make JS an open standard.
So now JS is the x86 assembler of the web - not as pretty as it might be, but it gets the job done (GWT is the most hilarious case in point). It would be a classic case of worse is better except that Java only looked better from the bottom up. Meanwhile JS turned out to be pretty awesome. Good luck trying to displace it.
SWF was the other interesting bytecode contender, but I don't know much about the history there. Microsoft's x86 virtualization tech was also pretty cool but they couldn't make it stick alone.
You're not compiling to C here: "the stack" may be a chain of heap-allocated activation records that are still live as far as GC is concerned. What you're describing might work but you'd want to test it to be sure.
EDIT: On reflection I agree that the setTimeout() approach should free the stack, however it's implemented.
ECMA doesn't require efficient tail recursion. Caveat programmer.
The best book I know of about this is Jacques Hadamard's The Psychology of Invention in the Mathematical Field. He asked this same question of the important mathematicians of his day - and because he was Jacques Hadamard, they answered. Einstein's response in particular is fascinating. Although math is published in symbolic form, nearly all the mathematicians surveyed reported that they thought in images, sounds, or movements. Only Polya believed that his creative process involved symbol manipulation.
Seymour Papert's Mindstorms is good reading too - the Logo turtle was very deliberately designed to transfer physical expertise into programming skill.
+1 on the importance of fenders and mudflap. Road water is nasty.
This mapping is needed because the fragment string is never passed to the server, so it has to be encoded elsewhere and the query section is the only available place.
The "!" is needed because otherwise crawlers would start fruitlessly hammering all the existing sites that use '#' but don't support the '?escaped_fragment=" hack.
This is simply incorrect, as are most of the conclusions that follow from it. Basically, many muscles can trade off individual contractile fibers to remain under tension all day without perceived tiredness.
You are not a stack of blocks and you can hurt yourself by pretending that you are. Your body includes tensile as well as compressive structures and the whole thing is tied together with a control system. You are not meant to stand up without reflex muscle contraction! (You also aren't meant to sit or stand in one position for very long, but that's a longer discussion).
I trained as an Alexander Technique Teacher, but for the technically inclined I'd recommend reading Moshe Feldenkrais's Awareness Through Movement as an antidote to this way of thinking. See Understanding Balance by Tristan Roberts for more detailed information about postural reflexes.
This looks like a good place to start: http://en.swpat.org/wiki/Bilski:_analysis_of_Supreme_Court_d...
That said, if you haven't used something like ML or Haskell you can't possibly imagine how many subtle bugs can be caught by a type checker, particularly edge and corner cases that will eventually dominate your test suite - in the unlikely event that your code lives that long.