Can somebody explain why a square root is also considered a flop? Surely that involves more work than the other four operations the article listed. Is there some hardware algorithm for the square root that is as fast as (e.g.) division?
Square root is pretty much equivalent to division in complexity, and computed by similar techniques (digit-by-digit methods or newton-raphson or goldschmidt iterations). Division is often a little more efficient, but square root has fewer messy edge cases (it never overflows nor underflows).
Division and square root are generally slower than the other arithmetic operations, in both latency and throughput. They are finally partially pipelined in recent CPUs (a result every two or three cycles), but were totally unpipelined in mainstream designs for many years before that. A decade ago, they might take a few tens of cycles, now they’re generally somewhere around ten cycles latency on “real” CPUs, vs 3-5 cycles latency for the other floating point arithmetic instructions.
A question that I am not quite smart enough to figure out. The fast inverse square root works via a giant hack. hand waving a bit here but it has to do with because floats are stored as an exponential structure bit shifting one does magic math things to it. however note that bit shifting a float is not an implemented instruction. so you have to hack it by casting to an int.
Anyway the question is. If you implemented fast inverse square root with out the hack. (i don't know, perhaps packing your own bits, or it might be screwball enough you only assembly could do it.) would it be as fast?
It's not much of a "hack", it's literally how the number format works. If you implemented it without the "hack", you'd just be at the mercy of the compiler to see through your arithmetic on the float bit patterns and reconstitute it.
It's not actually that fast, either. Every mainstream architecture from the last 15 years (except maybe RISC-V, since it's exactly the sort of thing they would forget to add) has a "approximate square root" instruction with single-cycle throughput, and they're all both more accurate and more efficient than this. It was good for its time, but it's time has passed.
Guess: It's one of the operations specified in IEEE 754, and traditionally the implementation is supplied by your hardware vendor rather than implemented by you (even if that implementation is "really" a software algorithm).
I think people are misunderstanding this; it's pedagogical. From the link:
'I want to use it as an exercise for you in finding hacks, attacks, defects, and bugs by going through "K&R C" to break all the code...When you are done doing this, you will have a finely honed eye for defect.'
He's trying to train his readers to think about places code can break.
In at least two articles about the X-37B, I've read about it changing orbit. But isn't that an energetically expensive operation? In a previous article (http://www.csmonitor.com/Science/2010/0824/Secret-Air-Force-...) the change seemed to be one of altitude/elevation (sorry if I'm using the wrong orbital mechanics terms ), rather than a plane change. But isn't that still relatively expensive, even with a Hohmann transfer or something? I can't imagine the X-37B can do very many orbit changes - can anyone provide more information on the physics behind this?
Trivia: this was the first spot googling "energy cost change orbital plane". I almost didn't click the link "Standard Orbit, Mr Sulu!" but was very glad I did. Bing had Wikipedia as the first spot, not nearly as engaging.
I think you're missing the post's author's point. He isn't saying "after wars the DJIA goes up", he's saying "after periods of inflation, the DJIA goes up" (see the title of the graph).
Note he still doesn't mention 1929-1933, which seems like a big omission, although it doesn't directly contradict the assertion.
The wired article was all-around poorly conceived and written. The author advocates open information sharing - but it's a fucking spy plane! Does he have no idea how the spy industry works? Not like the US and USSR shared data on the SR-71 or equivalents.
This isn't a spy plane - it's a potential space minelayer.
The nice thing about the SR71 was that it wasn't that secret, you knew from the speed and altitude that it was an SR71.
But suppose your spyplane flew at the same height and speed as a B52 and was the same size as a B52 - the other guys might be a little more nervous, and more likely to react, when it flew over their territory.
This is smaller than the space shuttle so you should also be able to uniquely identify it as it passes overhead. Might not be in the same spot each time, but it is a spy (multi-purpose) plane afterall.
But you don't know what it is doing.
The problem with space - and the reason we have avoided militarizing it - is that it's difficult to stay out of other people's territory.
You wouldn't allow an anonymous N. Korean/ Chinese/ Russian/ Fredonian warship to wander around US waters unchallenged but you have to allow a satellite to pass overhead - thats orbital mechanics.
Now if you start doing things with your space plane, the other side decides it's going to have to defend itself by shotting down anything that passes over it's territory, and 20 minutes later you shoot down their stuff when it passes over your head.
Pretty soon nobody has any satellites. We realized this didn't really work on the high seas several hundred years ago and came up with the idea of laws and flags.
I liked the plots they had in that chapter. Did they mention elsewhere how to generate plots like that? Would something like gnuplot work?
Edit: conciseness.
