K^2

Yeah, except CPU does all of that in its internal hardware using an SSE instruction. So it gives you full double floating point precision in about half the time, because instead of using general computation instructions that you would need, it literally uses a specialized circuit that only does square roots. You will not be able to beat that.

Because ln((M+m)/M) is only approximately m/M for M >> m. Take a look at first plot here, with M = 5 as an example. Note that while m is small, the two are almost identical. But as m gets larger, they start to diverge quite significantly.

If a plugin has to be in C++, just roll with it. There are some nuances, but for your purposes, you can write C code in C++ and it will compile, execute, and probably run either just as fast or close enough. Plus, you can use some of the neat C++ features, like new operator instead of malloc. On the other hand, you don't have to. So if you don't want to declare a single class, don't. Oh, that could be a plugin to dev environment.

"Oh, look, that enemy warship that adjusted course to intercept, then changed course again. Hm, we should probably maintain trajectory until the would-be-intercept." Problem is, anything you do with projectiles gives your enemy a huge amount of time to react. To hit anything in space, we need projectiles that travel at relativistic speeds. And that means beam weapons of some kind. Be it photon, gas/plasma, or even nanoparticle beams. We still have to put all the energy into a tiny amount of mass (potentially zero), and launch it at the enemy at near light speed, so that they can't react. Oh, hey, look at that. X-Ray lasers torch these missiles right through these silly mirrors. What were these guys thinking?

Well, this is why when you wish to build something really complex, you never use just one language. For example, the games in the studio I work at are written primarily in C. But some of the more abstract libs have to be C++ or it'd just be too crazy to work with. (Primary reason for C over C++ is compiler time, btw, not so much performance.) On the other hand, most of the code I work with is low level engine stuff. So I write a lot of code with intrinsics, which is very close to writing Assembler code. Either VC greatly improved since 2009, or somebody did not know how to configure the optimization settings. And yes, these simple test algorithms tend to perform pretty close, because your limiting factor is branch prediction, which will be just about the same between native and good JIT. I would have liked to see them try running skeletal animation and ragdolls on C#/Java, though. Among common use algorithms, it's the most brutal abuse of branching, cache, and raw computational performance, which typically makes JIT cry.

PB666, your basic complaint is that you write bad code, and C# makes it more difficult to do so than VB. Don't feel bad, this is a common problem for VB programmers. I was the same way when I used to write in VB two decades ago. In the words of one comp-sci professor, "It's alright if some of you never programmed before. It's much worse if you know BASIC." These are bad programming practices, and you should get rid of them. You'll code better in either language once you do. In style. But not in how it works. Again, C/C++ compile to native binaries. C# compiles to byte code. So does Java. C/C++ do not do garbage collection. C#/Java do. List goes on. But stylistic similarities between C# and C++ do mean that a lot of optimization techniques work for both, which is part of the reason why C# is pretty decent in speed. The other part is JIT in CLR, which is much better than JVM's JIT. But I'm getting off topic. So first of all, C# runs on CLR. So does VB. You can actually run VB binaries on Linux. There are ways to do that. I don't know how good Mono's JIT, though. (You are talking about running C# via Mono, right?) So performance could be a problem. But again, secondary concern. Biggest issue here is that it's the wrong choice of language. If you're after performance, performance, and performance, your code should be written in C. Not C#, not C++. Plain old C. There are ways to incorporate C sub-routines in a VB program. That's your best bet for staying with familiar VB for high level logic and still getting performance of a C program. Also, if your C sub-routines have platform-dependent code, you're doing it wrong. Your C portions should be written to be platform-independent. That way the same binaries will run on Windows or Linux machine. And if you ever need to compile for Android, or what have you, it will be up to compiler to take care of these differences. You should be indenting your code. It's absolutely impossible to miss a matching brace if you properly indent. And yeah, sometimes it helps to comment the closing brace to remember exactly what you are closing. Some times it matters. But simply remembering to indent each time you open a brace will already resolve almost all of your problems. Code segments actually have compilation effect. They define scope, and scope defines what's happening to your stack. If you are writing deeply recursive code, these unqualified {} blocks can save you a ton of stack, allowing deeper recursion without a crash. This is how functions work in C and C++. It's only C# that does that messed up thing with everything requiring a class. That does provide better type-safety, but I don't like it either. Also, if you're worried about performance, using strings for function input/output is NOT the way to go. When you create a string, it's allocated on the heap, which requires a few hundred cycles in the best case. That can easily run into thousands if heap needs to be expanded. And then you have to generate the actual string, which is thousands more cycles. And that's without the overhead of garbage collection on top of this if you're doing VB/C#/Java. Of course, if you're writing this in C, absolutely all of this is explicit, so you know precisely what you're wasting your cycles on. Also, there are far, far better ways of handling multiple outputs. C's favorite way is passing in references to output variables. C++ can return structs. How the later is handled depends on implementation and optimization options. Again, just one more reason to go with C/C++. You can create a bare function in these languages, which will exist on the stack only, meaning it can be called in parallel from as many threads as you like without fretting over race conditions. In C, there is no such thing as a class, much less an instance of it. In C++, you'd have a choice how to do this. In C#, you can actually make sure that all of the parameters you are interested in are passed in as actual parameters, or ride on top of a struct you pass in by reference. Believe it or not, you actually have way more control in C/C++/C# than VB. You are just used to having no control, and so your complaints are all of the type, "Why doesn't it just do what I want it to do." The answer is, you haven't told it to. What do you mean they don't work? The comments? Or are you trying to have them do something other than just being comments? P.S. And we haven't even gotten to the meat of the problem. How do you make your C code run fast, especially with multiple threads on multiple machines? This is a whole separate topic, and part of the answer is, "By not writing it like you do in VB."

Any serious C# project will feature C/C++ integration. So yes, learning all three is valuable. And yes, if you want to have a boring job with a five figure salary, go ahead and learn just Java. Unless you know how to write C plugins for it, you won't be working on anything more exciting than app UI.

I can tell you've never had to write a game engine for modern consoles.

First of all, C, C++, and C# are three completely different languages with similarity in syntax and some historical parallels. They serve completely different purposes and should not be lumped together. Modern C and C++ compile directly to machine code, for example, while C# compiles to byte code that runs on CLR. Which means that even with JIT, C# should not be used for performance-critical tasks. BASIC, in contrast, takes its roots as an interpreted language. While VB also compiles to CLR, it still has a lot of the problems common to interpreted languages. Abysmal performance is just tip of the iceberg. It has poor type-safety, bad garbage collection, and object-oriented features that are bolted onto an outdated language. The most important thing to understand about a real programming language is that it's not about built-in functions. C has almost none. It comes with a pretty broad spectrum of standard libraries, for sure, but they are not really part of the language. More importantly, every single one of them can be replaced to fit a specific need. A good language is not a set of functions. It's a tool kit. Why is C a particularly good language? Because it translates almost directly to machine code. Which means you always have an idea how well your code is actually going to perform. If you cannot look at your code and tell what instructions it's going to turn into, you cannot write efficient code. And this is absolutely impossible to do with the languages like VB. But yes, C is archaic, which makes it unsuitable for a lot of modern tasks. That's why C++ exists. C++ has all of the features expected of a modern language, starting with objects and ending with meta-programming. That does, however, come at a cost of performance. Optimization of C++ code is nowhere near as straight forward, and takes much longer for compiler to perform. Which is why C has not been phased out. A high performance high complexity application will be written in a mix of C and C++. Fortunately, C-style linking is part of the C++ standard. Finally, C# is a completely different breed of languages. It is much closer to Java than C in almost every way. From code organization, to execution, to memory management. However, it also comes with a compatibility feature allowing it to call native code with C-style syntax. In that case, C/C++ code can effectively become a library for C# code to tap into for performance-intensive operations, while maintaining organization and safety of a higher level language. So even if we look at C#, which is a .NET language, just like VB, VB has not a fraction of the features, while performing far, far worse than C#. The only redeeming feature of VB is that you don't need to know anything about programming to write some simple code in it. But it is absolutely unsuitable for anything serious.

And the missiles will still get picked off one by one in transit using some sort of a rapid-firing laser. You simply can't launch enough missiles to overwhelm something that only needs a few ms to destroy a target, and has hours of tracking time. Until we figure out FTL travel, which would make close-range battles viable, the only way to fight in space is at light speed, so that your enemy has zero warning time. That basically means beam weapons.

Scott Manley is using an approximation to Rocket Formula. dV = ISPg ln((M+m)/M) ≈ ISPg m/M Where M is mass of the "rocket" and m is mass of the fuel. This is ONLY true whenever M >> m. Which is equivalent to saying dV << ISPg. Since for the rocket in question dV is only 280m/s and ISPg is nearly 8,000m/s, the approximation is fair. And you can compute fuel as m = (dV M) / (ISPg) = (280 x 124 trillion) / (800 x 9.8)

Muons are comparatively easy to shield from, since they have charge. Neutron radiation from a D-T event is a bit more energetic than from typical fission reactor, but still in that ballpark. So if we were to find a highly efficient source of muons, this would be a viable way to build reactors. And since they require muon production, they can potentially be far safer than fission reactors overall. The trouble is, of course, that nobody has figured out how to produce muons at anywhere near sufficient efficiency. Any reactions we know that do produce muons produce way more energy as other types of radiation, so it's far easier to just build a reactor on that. In fact, that's basically what we do with fission reactors. And the tiny fraction of energy released as muon radiation just isn't sufficient to bother with to even supplement the fission output. That said, there could be reactions we have not found yet. While we have a pretty good catalog of ground state decay modes, we've only scratched the surface on excited states.

AKA, just as Moon clears the horizon on the West Coast. Still, if it's going to be in total eclipse for an hour, it might make it up high enough in the sky before it's over. I'll look for it.

I have no idea what you are even trying to plot. Just do normal Cartesian plots of M(t), E(t), and θ(t), and I should be able to tell if they look right. Then your 2D plot of trajectory should simply be {r(θ(t)) cos(θ(t) + É), r(θ(t)) cos(θ(t) + É)} for t in [0, T], where r(θ) is given by equation you've posted above and É is the argument of periapsis.

Gravity turn is pretty complicated even before you take aerodynamics into consideration. With aerodynamics, even numerical solutions are very difficult to achieve.

Yup. Just keep in mind that theta doesn't change uniformly with time. Theta is what's known as true anomaly. The parameter that changes uniformly with time is the mean anomaly. So if you want to plot actual position of the craft as a function of time, make sure to look up how to convert from mean anomaly to true anomaly. But if all you want is the shape of the orbit, that formula is all you need. Just plot theta from 0 to 2 pi.

Absolutely false. There is no such thing as "complete" or "incomplete" transition. There are situations where the quantum state of the incoming photon have to be considered also. A single photon might be interacting with multiple particles, resulting in a complex superposition. But there is absolutely no "backtracking" necessary if some other particle is found to have absorbed all the energy. All that tells you is that collapse has taken place. When you start a statement with, "you are missing one thing," I am already prepared for a face-palm. Creation/annihilation are inherently field-theoretical terms. You're seriously jumping the gun here. It's like trying to understand semiconductor physics without understanding what electrical current is. Learn basic Quantum Mechanics first. Understand what a superposition actually means. How the Hamiltonian describes the system. Why there are no jumps in QM, and then you can start learning about the field theory. Yes, the whole thing can be described in terms of particles being created and destroyed. In that description, rather than having particle transition from state to state, you destroy and create particles in their state. Particles don't even propagate by any means other than being destroyed and re-created at new position. And in oscillator description, it's the a†and a that become creator and annihilator operators respectively. But it's crucial to understand basic Quantum Mechanics to understand why that description is equivalent. This doesn't make particles jump between orbitals any more than presence of creator/annihilator operators in propagator makes particles travel through space in jumps. These are fields. Quantized fields, which is why we have particle representations, but they are still fields. And until you know how to work with most basic cases, you shouldn't be making arguments from your own mis-understanding of an over-simplified explanation you've heard from second-hand sources. That's dumb. You seem to have some very serious mis-understandings about how academia publishing works. I take it you've never published in a properly peer-reviewed journal. Each publication has a specific scope and audience in mind. The general audience for this particular piece was asked to skip to the pictures. The math was written for people who've actually taken some QM, and these people have been able to follow, based on responses I've gathered. For anyone who wants to follow this and can't, open up a QM text. This was never meant to be a lecture series.

Without more details, it's hard for me to be particularly assertive on this, but my knee-jerk reaction is that you aren't using GPUs right. Even for tasks like artificial NNs, GPU is by far more power efficient*. You just have to make sure none of your CUDA cores ever spin idle or locked on memory access. Which is an extra challenge in design, but I'm not aware of any branch of bioinformatics where GPU optimization isn't a solved problem. If you are positive that yours isn't, I would actually be very interested in hearing a bit more about it. * Power efficiency in GPU computations is the only reason they were economically viable for bitcoin mining for quite a while, for example. CPU consumed more power than you could buy with bitcoins you'd mine. Once you have your computations on rails, GPU is amazingly power-efficient. But if it keeps thrashing for data and access to it, all it's going to be generating is waste heat.

k is spring constant - standard physics notation. All that one needs to know about k and m is that ɲ = k/m. Same as in classical. p and x are, indeed, momentum and position, but they are operators. In coordinate notation, p = -iћ∂/∂x. Again standard notation. All of this is consistent with any introductory text on QM.

True that. Standard performance optimizations target 4-core systems. Except for consoles, but current generation of consoles has maneur for CPUs, so if the game was optimized for a console, any decent 4-core CPU will be more than adequate. P.S. I don't see a point in purchasing a high-performance CPU for anything other than gaming and maybe some AI tasks. For pretty much anything else, you want raw FLOPS, and you cant beat a good GPU for that.

Very unlikely. Even if Pluto-Charon itself has stable enough field at the barcenter, any minute perturbation would knock an object out of that point. And there is a lot of crap buzzing about in Pluto's vicinity. It's like trying to balance a pencil on its tip during an earthquake.

Universe Sandbox is a pretty terrible simulation as far as N-body sims go. A better example would be Orbiter, which has on-rails Sol System with N-body interactions for the craft. In principle, nothing prevents KSP from cheating and running the system on rails as well. But the benefits would still be marginal.

It is dynamically unstable either way. Plot the effective potential of the system.

The jump is a jump only in a sense that energy never takes a value between the two levels. The transition still takes time, and in that time, energy state is a superposition of the two energy states. If you happen to measure it in the middle of transition, you'll only be able to measure the lower or higher energy. But it's going to be probabilistic, and probability will change gradually. The probability distribution for the particle, in the same superposition state, has a much more interesting behavior. While orbitals themselves are static, time-independent solutions, their superpositions are dynamic. It's the same as the oscillator probability distribution starting to move above, while all of the eigen states, which are the analog of the orbitals for oscillator, are static.

Planet is massive. Artificial satellites are not. If you are considering two satellites orbiting a planet, forget about forces between satellites. The only forces that matter are between the planet (primary) and each of the satellites.