K^2

Trouble with QC is that a single quantum gate is kind of useless. You need at least 6 working in tandem to start doing interesting things. 10 if you want really interesting things. So far, I've only seen optical and spin-resonance systems manage that. There's also that D-Wave QC, but it's Adiabatic, which is very limited. This is encouraging, though. If they can make a gate, odds are, someone will figure out how to make multi-spin system that actually does something useful soon enough.

That is not correct. An accelerating belt can exert quite a bit of force on an airplane, because of the wheels' moment of inertia. Which is precisely what the belt has to do if it's too constantly match airplane's wheel rotation speed. It will be accelerating. If we simply take the "myth" at its wording, and assume that speed is measured same way as for the car, so we require that belt speed always matches rotation of the landing gear, we can actually solve this constraint problem, so long as we assume real wheel with real moment of inertia. The solution, however, produces quite insane acceleration for the belt. Something like 10g for an ultralight at full throttle, and even much higher for larger planes. But if our only requirements is that we match the "myth" briefly, this is feasible to set up for a light plane, and an accelerated belt would, in fact, keep the plane completely stationary despite engine running at full power. Very briefly. Then the relative speed between plane and conveyor belt will get above safe limits, landing gear will disintegrate, and you'll destroy the plane. Or more plausibly, you'll run out of juice in whatever it was that you used to yank the belt from under the plane. Either way, the whole thing will last a few seconds tops.

Soviets have built a torpedo that does much the same thing. So the technology for it is actually proven. Building it on larger scale and with any sort of significant range, however, is a colossal challenge. VA-111 Shkval

This is weighted by number of each kind of engine. So index runs for all engines, even if some values repeat. But yes, this is the right formula.

There is no experiment that we can't do in a vacuum chamber that we can do in orbit. The simplest way we could test this is by running the drive for a long time and seeing if thrust diminishes. Trouble is, nobody has yet built one out of components that can survive vacuum long enough. So if nobody has made a test unit that can even perform equivalent operation in a vacuum on the ground, with no radiation to worry about, what makes you think that it'd be easier to make a unit that can operate in actual orbit and launching it there. We don't have enough people who think it's a worthwhile investment to even do the full rante of testing that needs to be done on the ground before putting it in orbit.

That would produce very noticeable symmetry violations, which would be detectable in one of hundreds of finely tuned experiments designed specifically to probe these symmetries. You aren't going to generate measurable thrust with a microwave magnetron, when no deviation was detected in far, far more precise experiments, both ones that are set at far greater energies and these set at far greater ranges. We can safely discard any possibility of violations of momentum conservation in EM case, for same exact reason why we can safely discard any possibility that the guy on YouTube who claims to have built a perpetual motion machine with magnets. In fact, EMDrive was "invented" by an equally crazy person.

Because long explanation involves a lot of math and concepts from field theory, let me just say that there is a very good reason why this experiment was carried out in a crystal, and not vacuum. The fact that crystal lattice can absorb excess momentum is the key factor in allowing these fluctuations to be detectable. EMDrive, supposedly, works in vacuum, where none of this applies. Minor correction. Infinitely many such diagrams. Always. Locations of vertices alone have infinitely many possibilities. But you also have two, three, four... photon exchanges that contribute to the same interaction. In fact, in low-energy collisions, the many-photon interactions dominate.

Yeah, I don't know how it scales either. But the equilibrium on idle for a 172 is much slower than 20 knots. Though, it will carry on at that speed for quite some time before slowing down significantly, sure. That's kind of how it tends to work when you have a heavy object with very low friction and very low idle thrust.

Not true. An airplane in idle travels at a brisk walking pace on the ground, due to friction in wheels. Which, incidentally, about the same for a car in first gear. Both can stay put on a conveyor belt of just about any sane speed by adjusting the throttle.

That's a very strange interpretation of the "myth". Why did you make the "car" always turn the wheel at constant speed, but have the "plane" just apply maximum thrust regardless? Have the "car" apply constant torque on its wheel and try again.

The amount of angular momentum in bike's wheels is actually pretty small. It's not what keeps the bike upright, contrary to popular myth.

You are falling into the same fallacy as everything else. Pushing against moving things takes a bit more power, but it doesn't cancel anything. A car on a moving treadmill will drive off JUST AS EASILY as an airplane. There is absolutely no difference between an airplane and a car as far as this problem goes. For both, it is a stupid problem. For either one in idle, a slowly moving conveyor will keep them in place. For either one at full throttle, no conveyor speed will keep them put. It's seriously that simple. Only people who understand nothing about basic physics of motion, which is by far most people, keep trying to see a difference.

It's debated because people, including Myth Busters, don't understand simple things like constraints of motion and coordinate systems. If you take a car moving at 60mph on a highway and put it on a conveyor belt running 60mph backwards, guess what? Car will still move forward. Because for a car, like an airplane, the dominant force on a freeway is aerodynamics. And its wheels can spin at way more than 60mph. The whole "myth" comes from people insisting measuring car's speed by its speedometer, which is based on wheel rotation. If we put the same constraint on the airplane, it won't move either. Sure, the "conveyor" will have to accelerate at a mechanically impossible rate, quickly disintegrating the landing gear, but if your constraint is that wheel speed matches belt speed, then then the object cannot be moving forward by definition. Be it a plane or a car. This isn't even physics. It's just mat However, such constraint is practically impossible to enforce for both plane and a car. No matter how fast the belt is moving, if the driver is gunning the throttle, the car will either be moving forward, or you'll destroy the car's engine/transmission/wheels. Not unlike the case with the airplane.

It's not a bad language, but isn't great for learning. If you want to learn a script, I'd start with Python. Depending on what your goals are, however, it might be a better idea to just start with C. It's a simple enough language, and it will be far more useful in the long run.

Without checking the math to see if that's right, just pointing out that entering ^-4 will cause a lot of parsers to throw an error. Always enter it as ^(-4) to avoid problems.

Yeah... Now implement the garbage you've written vs code that Jouni wrote and time it. Watch your code thrash around miserably because it ended up being unoptimized. Sure, if you can't write the "proper way" properly, everything looks like it needs goto. But that's, once again, just your inability to write good code. And many are not. Some loops are going to be completely unrolled by an optimizer. Many bits of code will be moved around, so that the jumps have a completely different structure. Unless you are actually coding in assembly, the code you are writing and machine code you will get are going to be pretty different. If you understand how optimizer works, you can predict that and help it out to get faster code. If you don't, your best bet is to not interfere with it. And getting "clever" with goto statements is exactly that sort of interference. So do yourself a favor, and learn to write proper code. That's what optimizer expects, and that's what will have better performance despite your misconceptions. Of course, the main reason to write proper code is the fact that it's easier to read and debug. Again, see Jouni's solution. The fact that it will also run better is just a bonus in this case.

That only works if you magically will the whole thing into being. I mean, it wouldn't stop time dilation. It'd still be the largest bomb ever that's already exploding, but it could take a few hundred billion years for that explosion to actually expand from so near Rs. Fortunately, there is no such thing as magic. So one needs to figure out how one of these came into existence. 1) The body consisted of ordinary matter that somehow decayed to e±. Well, nothing else will have nearly the same degeneracy pressure, so it would have collapsed before it'd have the chance. Not to mention, decay to e±, by whatever process, would be influenced by same dilation. 2) An e± cloud condensed into this body. That would annihilate long before it got to that density. So either way, an e± cloud is an impossibility, making the paper a mathematical curiosity at best.

All of the good things I can say about Basic, I can also say about PHP and Python, for example. But I can also say far, far fewer bad things about them. I can sort of buy that, oh, 30 years ago, BASIC had its place as a learning tool or a quick fix-up tool. We had it on school machines, the old variety where you had to put line numbers for each line, and it made sense. It was that or jumping straight into Turbo C or Turbo Pascal, which had a much steeper learning curve. Today, though? There is no good reason for Basic. And I can point you to some libraries in Fortran that I had to give up on, because I couldn't figure out how they worked, because the entire logic was a mess of GOTO statements. I know they were just nested loops with occasional breaks, but short of printing out all 100 or so pages, decorating walls with them, and drawing arrows all over the place, there was no way to make sense of the code. Ok, so absolutely every single variable having names consisting of the same letter repeated arbitrary number of times did not help, but I could have worked around that if control paths made sense. I was able to compile them, and cross-link them into my C code, but if I needed to change anything about that library, it was a fool's quest. So I ended up either replacing them with C libraries or writing my own. And again, you might think you're helping execution efficiency with a goto statement, but unless you're writing an Assembly program, you're ultimately working hand-in-hand with an optimizer. And optimizers don't play well with goto loops. Were you enjoying that use of a register as a loop counter, which sped up your tightest loop by a factor of three? Well, it's gone now, because optimizer could not predict all consequences of that goto, and now the counter has to be placed on the stack. In fact, if you think you can come up with any example where optimized code runs faster with a goto statement, I would be happy to see it. I think you'll find that your perception doesn't match behavior of modern compilers.

You mean like this?

You'd need a few files written in Assembly to talk to the hardware, but that's true of any language. And sure, between C and F77 for writing an OS, it's C hands down. But you totally could write an OS in F77. For something simple like loading from a floppy drive and browsing a partition on the same, I could write the code in an afternoon. I'll take a look at how flash drive access works from BIOS. Maybe I can do the same with one of these as a proof of concept. Because it's a terrible language, with absolutely no structure for optimizer to work with. All it's good for is not punishing you for being bad at programming, which is why it has so many fanboys. I don't have a problem with early languages mimicking jump instructions in assembly, which are reflection of architecture. I have a problem with seeing goto statements in F90 and C, which are modern languages with structured loops. If you are using goto statement in one of these, you are doing it wrong. You are a terrible programmer, and you should either learn not to do this or do something else. Not only does it make code harder to read and debug, but it makes it impossible for optimizer to do its job. There is zero excuse for using goto in modern languages.

You can code high level logic in whatever you want. Even Prolog. If you need to compute something, you write your algorithm in C and call it from Python. And no, you don't just call math functions from Python algorithm, because then you lose all of the compiler optimization, and your code runs at about 1/10th the speed at best. There are times when you don't care, but then you don't go around complaining that your computations take too long. And the fact that I'm referring to BASIC as not a real language has very little to do with the fact that it's interpreted. It's garbage. It has bad syntax, it forces you to use bad programming practices, it's abysmal in performance even for an interpreter, and when something goes wrong in BASIC code, figuring out is next to impossible. The idea that BASIC could have ever beaten out FORTRAN is ludicrous. For starters, you can write an operating system in FORTRAN. Fortran is dying out in labs, and for a very good reason. There are much better libraries for C/C++ these days, and most of the old code written in Fortran, including some of the libraries, are absolutely atrocious. Specifically because in F77, it was very difficult to avoid bad programming practices, and while F90 is quite decent, many Fortran programmers carried their bad habits over. To put it plainly, I've seen goto statements in F90 libraries. That's bad. That shouldn't happen. Like I've said earlier, though, Fortran could have easily been where C is if there was no C. Out of languages currently out there, barring all C-like languages, Fortran is the next best choice for building OSes and computation libraries.

F77 produces linkable binaries. It has performance comparable to C. It's a real programming language. BASIC and QBasic are interpreted languages. They run like snails on sedatives. If C-family of languages has not emerged, you can bet your rear that every single operating system right now would be written in F77 or F90. There are no alternatives that can compete in performance with C and F77. The next best thing is Pascal, but it never had the same optimizations that went into C and F77. Everything else is hopelessly outdated for writing anything like a modern OS. The only reason F77 has lost is because of its syntax, which is much closer to BASIC than C, and that's a very bad thing. Again, you're arguing from pure ignorance, having zero understanding of how the code is executed and what it involves. You are entirely out of your depth. That should be clear even to you. Why do you insist on continuing to argue? I understand if you were asking questions, but you keep pretending that you know better, when it's demonstrably false.

Fortran would have no trouble competing with Basic for the same reason that C did. It was a real programming language. If something killed Fortran, it was most positively C. Because C actually punishes you for bad programming practices that Fortran and Basic encouraged. Anyone who ever attempted to port a Fortran library will tell you the same. On a side note, why in the world would you want to port a computationally heavy code to ARM. That is just a silly idea.

If this was the only reason, we'd probably be having this discussion about Fortran 77, or something. There are reasons why C became this de facto standard.

Not exactly. VS defaults to using SSE instructions as far back as 2010, at least. In fact, optimized code will replace sqrt() function calls with the appropriate intrinsic. You need to set a switch if you want to use AVX features, though. GNU compiler requires a switch to compile SSE instructions, but again, it's quite capable. You don't need a fancy compiler for this. Also, there are SSE instructions for both 32 and 64 bit floating point. However, with 64 bit, you can only do two numbers at a time, unless you are using AVX. With AVX, you can do full 4-dimensional vector math with double precision. All current CPUs support these features, and we do actually make use of these in game dev whenever possible. Any modern CPU will support SSE and SSE2 instructions. I don't recall which of the two rsqrtss belongs to, but it's one of these. This is completely independent of the operating system. Furthermore, intrinsics are implemented in a similar way on both GNU and Microsoft compilers. Same code should compile on both. There is something to keep in mind about the rsqrt, however. It has MUCH lower precision than sqrtss or sqrt(). It's something like 11 binary places, I think. So the precision is a little better than 3 decimal places. If you're happy with that, by all means run with it. But that's the reason why it's faster than sqrtss. The code for using this flavor would look something like this. #include <stdio.h> #include <emmintrin.h> static __inline float sqrt_fast(float x) { float ret; __m128 y = _mm_set1_ps(x); y = _mm_mul_ps(_mm_rsqrt_ps(y), y); _mm_store_ss(&ret, y); return ret; } int main(void) { float x = 2.0f; printf("sqrt(%.2f) = %.3f\n", x, sqrt_fast(x)); return 0; } Yes, there's a good reason to use _ps instructions instead of _ss instructions here, although the speed gain is tiny. P.S. The method above runs through an array at an average rate of 7.5 cycles per sqrt. Using _mm_sqrt_ps() does the same work in about 15 cycles per sqrt. So using reciprocal with multiplication is actually twice as fast. Using a function call from math.h is 50 cycles per sqrt. All times are averaged from 1,000 operations, compiled on VC++ with /O2 flag set. P.P.S. Same deal with GNU compiler, using -O2 -msse2 switches. The fast sqrt computed in less than 5 cycles per operation. The sqrtps one still came in at 15, and math.h one managed 35.