K^2

You again? Boat detected traveling through single slit is evidence that boat interacted at just one of the two locations. It says nothing about boat's actual location. And you need to learn basic logic before trying to argue about quantum mechanics.

If you actually want to look at it as a control problem, matching wheel rotation speed, then the conveyor belt does stop the plane. It's a simple constraint problem. You just need to remember to include torque on the wheel, its moment of inertia, and the fact that the belt is accelerating. Resulting accelerations end up being impractically high, but again, as a pure theoretical control problem, it has solution for both car and plane, and in both cases, the vehicle stays put. It's a fun little problem to solve, but if you'll need me to run through the equations, I will.

The three most common mistakes of a theoretical physicist are missing pi, factor of 1/2, or wrong sign. Yes, it's the other way around. Sorry about any confusion.

I'm not sure what you're trying to say here. Yeah, in QFT, there are no problems with particle/wave duality, because there isn't really a duality. Everything is a field, and "particle" representation is nothing more than mathematical trick to represent the same field in a different basis. It still, ultimately,describes the same field. Also, as a small correction, EM wave cannot constructively interfere in vacuum to produce a particle-antiparticle pair because that does not conserve momentum. It must scatter from matter that's already there. Now, if you happen to have at least an electron, and you hit it with a powerful enough beam of EM radiation, sure, you can produce a bunch more particles. But something has to be there. Just EM and vacuum won't cut it.

Well, I hate to throw yet another language at you, but if straight up integration with minimal branching is your task, and you have no access to a cluster, then CUDA is your friend. GPU is way better than CPU at that sort of thing. Way, way better if you are happy with single precision. Up side, it's just like writing in C. Downside is that it's just like trying to program for thousand computers. In C. And it is annoying to set up. (But there are video tutorials on Youtube.) Holly transistors it is fast, though. Like, "I can't believe you just did four hours of math in a minute," fast. Well, depending on your graphics card. But even on low end it is unbelievably fast. It is like having your own cluster. One that is only good for this kinds of task, but if that is all you need to do, that is good enough.

A while back, I've seen some "unlocked" GPS units from China. These don't have normal altitude/velocity limits and will continue to report position and altitude with precision of a few meters. I would strongly recommend finding one of these. For pressure, just find a lab-grade sensor. They have enough precision. The trick is that you might end up needing a heater to keep it operational. Same might go for much of your instrumentation. In general, I would recommend housing electronics well insulated, leaving just a narrow channel for pressure sensor.

It's even worse than that. I was working on a cluster that had 500 nodes with dual Titans on them. So I could have ran two layers of parallel computing. I already had the data split into coarse almost independent blocks that were perfect for processing on individual nodes in an MPI environment. And that brought computation time down from several months to 1-2 days per run. By running all of my numerical integration steps on graphics hardware, I would have been able to bring it down to mere hours of execution time. I've ran the tests and was happy with the results. But it would still take easily a week of my time to set it up and make sure it works correctly in full scale. And despite the fact that I ended up running the code with full data sets at least a dozen times, I've never bothered finishing that optimization. Because time taken by cluster to do computations while I'm asleep or doing something else is way less valuable than my time actually digging in code trying to speed it up. But yeah, this was a clear example of a case where a bottleneck was obvious as well. If you're running complex-valued integrals in 7 dimensions, that's always a safe bet. Life isn't always so simple, though. Especially when you've grown bored of academia, and it is now your day job to make sure that hundreds of thousands of users are getting a good framerate in their favorite (hopefully) game. Edit: There is one thing on which I have to categorically disagree, though. This goes both for scientific software and game dev. There are cases where optimizer won't do jack for you. Write your best version of C code to multiply two quaternions, for example. Then write the same code with SSE intrinsics and watch performance go up by a factor of 2-3. Same goes for a lot of the heavy lifting, and if you write your code this way from the start, it's virtually no extra effort on your part.

Because converting thermal energy to kinetic is much easier harder than kinetic to thermal. Edit: Sorry about that silly mistake.

Depends entirely on the environment. It's always cheaper to bring heat from another object than create it, and destroying heat is impossible, so you have to extract it out of an object to make it colder. In both cases, differences in temperature between object and environment will determine efficiency.

And what do you think is inside these complex things? Anything complex in a computer is just a complex arrangement of simple instructions. But no matter. If all you have is a few complex algorithms, it's even more important to profile to know which one is the bottle neck. Then you dive inside and you profile the simple things it's built out of to see why. The threads can be running in different processes on different CPUs in different rooms on a supercomputer cluster. That doesn't make any difference. You still have to profile each thread to know what actually needs improvement. For all practical purposes, a static __inline will always get inlined. Has to do with scope. You should never, ever rely on optimizer to make these sorts of decisions for you. If it should be inlined, inline it. If it shouldn't, don't. Pretty simple. Now, if you wanted to be clever about this argument, you'd bring up something like loop unrolling, which is entirely up to optimizer and can still have significant impact. But even that's fairly easy to predict if you understand what optimizer is optimizing. So I will reiterate. If your profiling code upsets optimization, you are doing it wrong. You need to go back and learn low level optimization. Or at least, let someone who know what they are doing write the profiling code.

I would err on the side of, "A lot more powerful". Even if you drill the hole to the center, I wouldn't expect this to work without at least 100x the minimum energy. But that's still a surprisingly feasible amount... 400MT, while tricky, is something we can build with existing tech. Drilling ~6km into the rock to place the device is also doable. I don't know why you'd want to, but yeah, it sounds like we could totally blow the crap out of Deimos.

If you can predict where cache and thread contention/thrashing happens in multi-threaded code that has both complex control structures and tight computational loops, you are a wizard, and laws of human logic do not apply to you. The rest of us need to do frame captures to identify problem areas, and that requires snippets of performance-tracking codes scattered throughout. Again, if your performance analysis code affects optimization, you don't know how to write performance analysis code.

Three are cache lines you can pretty much assume are going to be loaded - anything that contains current stack pointers for your process. An rdtsc call and a subtract to memory that's already in cache is going to cost you a few clock cycles, no additional latency, and no cache misses. It's as close as you can get to it being free and still have it do something. You can still mess up your timing by inserting this code in the middle of a tight loop, but if you are wrapping performance counters around something that takes less than 100 cycles to complete, you are just doing it wrong. With correct usage, the impact of profiling code is smaller than fluctuations you get due to variations in thread-switching and cache miss stalls during normal operation. If the impact you introduce is smaller than fluctuations, it will not affect the results. You will not suddenly see it stall in a place it did not before. But sure, if you use off-the-shelf profiling tools, and implement them haphazardly without understanding what they do, you'll get poor results. But it's your own fault then.

Plug in numbers for M, G, and R into formula? I'm not sure what the question is at this point.

That's usually an indicator that your performance tools weren't written by someone who understands how to profile things quietly. There are ways to profile code with as little overhead as you need. E.g., reading system clock and storing result in a variable requires multiple calls, branches, and potentially cache misses. Whereas a read from TSC to a register is almost free.

Just use the formula for spherical body of constant density (E = 3GM²/(5R)) using Deimos' mass and mean radius. It's not going to be exactly right, but correct answer requires a complicated integral that you couldn't probably even find all the input data for.

The problem with these is that the projectile has to withstand pi times the acceleration that it would experience from launch along the radius of the same circle. If you have magrail that can withstand it, a linear accelerator is actually easier to build. And if you aren't using a magrail, friction will probably tear things apart. That's before we even get to topic of air resistance, which is irrelevant to OP's question. Generally, linear accelerators make more sense. The only real exception are cyclotron accelerators, where a mag field is used to steer the beam, while RF in cavities is used to accelerate it.

You need to actually learn a few things about l-values vs r-values and scope. Passing parameter by reference has nothing to do with scope at all. You literally pass in a pointer to a memory location where relevant data is stored. Scope is irrelevant at this point. Life time of that data might be relevant. Here is an example of a thing you should NOT be doing. static int* var1; void function1(volatile int &var2) { var1 = (int*)&var2; } void function2(void) { volatile int var3 = 7; function1(var3); } void function3(void) { volatile int var4 = 12; printf("*var1 = %d\n", *var1); } int main(void) { function2(); function3(); return 0; } The "unexpected" behavior of this program is that it will print out "*var1 = 12". This has to do with the fact that var4 got allocated to the same place in stack as var3 used to occupy. So instead of printing val3, we're really asking the program to print var4. This is something to be aware of when passing variables by reference. But you have to get creative to actually break a program in this way.

C simply has "by value" as default mode. You can simply pass in a pointer, and then treat it as a by-reference call. In fact, C++ makes that explicit. void func(int &x) takes integer x as parameter passed by reference. // C++ style reference. void foo(int &x) { x = 5; } int main(void) { int y = 7; foo(y); printf("y = %d\n", y); return 0; } //C style reference. void foo(int *x) { *x = 5; } int main(void) { int y = 7; foo(&y); printf("y = %d\n", y); return 0; } And this is what code for foo would look like if you want to write it in assembly. .intel_syntax .global _foo _foo: push ebp mov ebp, esp mov edi, [ebp+8] mov eax, 5 mov [edi], eax mov esp, ebp pop ebp ret That one will have to be called in C style. void foo(int *); int main(void) { int y = 7; foo(&y); printf("y = %d\n", y); return 0; }

I would vote for anything mixed with Chrlorine Trifluoride. Supplementary reading.

How functions are called in C is not part of the spec, but this is the most common way, and what Visual Studio is going to work with. Except, you don't need to "remove" anything from the stack. You simply increment the stack pointer. It's literally one of the fastest operations you can perform on a CPU. Besides, Visual Basic will also use the stack under the hood, except, it's going to push a lot more information, requiring a huge overhead on function calls compared to C.

Induced (sourceless) artificial gravity will have all the same problems as magnetic force. You still get ∇·g ≈ 0 working against you. In contrast, if you have an object inside a sufficiently long magnetic coil, the magnetic force is essentially constant inside. That's how real world coil guns work.

You can. CRL supports execution of native code as a function call. I don't know specifics on how you'd go about linking Assembly/C code from VB, or even if you can do that directly, but what you certainly can do is compile and link your Assembly/C code into a dynamic library (DLL), and load it from your VB program. Then you can call your Assembly/C functions just like you would call any other dynamic library function from VB. I have done this with C# code. What you will need to be a little careful about is how variables get passed to your library. I see to recall needing to set up arrays of data in a special way. But it's straight forward enough.

Actually, it's a lot worse than that. Real magnets are dipoles. You can't have just the North pole of the magnet or just the South pole. You have to have both. (∇·B = 0) So the actual force from a magnet is going to drop as 1/r³. Which is why you don't really see magnets being used at range.

If the bottleneck in motor response is you being distracted, alcohol can still help. Whether you want to call it improving motor function or not is splitting hairs. Yes, research with things like fMRI will show the distinction, but it is results we are after. The bottom line is, no matter the activity, there are people out there who will perform it better with some quantity of alcohol. Not that I would recommend it as a regular way to improve performance.