K^2

Mode C transponder is required within 30nm of Class B airport, which is going to be majority of places where drone delivery is practical. Id est, large cities. So traffic avoidance isn't a problem. FAA regs are already pretty drone-friendly, and are getting improved. For short hauls, drones are already fairly efficient, so this can be economical. I don't see any regulation or tech issues. The only obstacle is lack of infrastructure, which is something that's going to get built. This isn't a matter of decades. It's a matter of years.

Oh, I know. I've built my share of model rockets that vote a resolute "undecided!" on the question of stability. Anyone who thinks they fly in a completely random direction has never launched one.

We've had a 152 come back with holes in the wings. Some redneck was bothered by them practicing slow turns over his farm. So yeah, I'm sure it will happen. But I don't think it will happen often enough to be a problem. Credit card fraud is also a thing, and I'm sure a few decades ago somebody thought it was a rock solid argument that there is now way credit cards will become popular.

Most rockets in KSP don't need any stability fins. There are two exceptions. Sometimes, you don't have enough vectored thrust to provide good control in mid-ascent. I've had this happen, and adding fins improved performance. This might be a case with some real rockets as well. Second is purely a KSP problem. The way thrust vectoring works is that it assumes engine is placed behind center of mass. If for some reason center of mass ends up bellow center of thrust, your ship's controls will be reversed. Except ASAS doesn't know that, so if you keep it on, it will throw the rocket into a spin. If this is the case, you can disable gimballs on engines and try to make it on fins and RCS alone. This shouldn't happen to a real rocket, unless programmers screwed up.

I'm not saying an SRB thrust can't oscillate, but it's not POGO. Resonances in SRB are more similar to how a whistle works. You can get these in liquid fuel engines as well. These tend to be higher frequency, which makes them less dangerous to the general structure of the rocket, but much more dangerous to the engine itself.

Yeah, shifting CoP for a rocket can be pretty much disregarded until you start talking about large displacement angles or precision control.

Neil, as I pointed out in an earlier post, center of pressure for a descending capsule is bellow center of mass. So capsule stability is a far more interesting problem. If CoP was fixed relative to the capsule, it'd flip. Fortunately, CoP shifts as capsule tilts. And it shifts in such a way as to provide a region of dynamic stability.

Speed doesn't build up. Gravity-induced speed boost for a ballistic warhead is minimal. On the other hand, the thing is already traveling at 5km/s+. So it's all about deceleration profile. Atmosphere gets thinner exponentially with altitude, so going into thick atmosphere with a bit more speed lets you reach much thicker atmosphere still carrying a lot of speed. Starting to decelerate early lets you avoid that. Maneuvering warheads were deployed on ICBMs in USSR.

POGO is due to changes in fuel flow. Solid motor is immune to that by definition. Increase in combustion pressure in solid motor leads to an increase of the burn rate, not a decrease as on the liquid motor.

They'll probably have a crew standing by on Gliese 581 to document the arrival of the first interstellar probe. I seriously shouldn't jump the gun on this. We should focus on our own system while we're stuck with propulsion techniques we have.

One other thing that's called "Galilean" is a type of telescope. I'm going to let you work out the connection. Edit: That might have come out more mean than I intended it to be. Sorry, I just couldn't miss this setup. On the more useful note, Galilean moons are going to be somewhere in the 4.5 - 5.5 magnitude range when optimal for viewing. That's right at the edge of human vision. The viewing angle is going to be in the .5 - 2 x 10-3. Which is also right at the edge of human vision. If it were just the moons, a person with absolutely perfect vision, on an absolutely clear, moonless night, with absolutely no light pollution, would be just able to make out that there is something there. Being able to say, "Oh, there are four points of light in arrangement consistent with Galilean moons," would already be superhuman. But even this hypothetical ability to make out that there is something there is completely ruined by the fact that Jupiter is going to be something like -2.5 magnitude, or about 1,000 times brighter than the moons. Optical aberrations from Jupiter's light will overpower any light from the moons. Sorry. It's absolutely impossible without using some kind of optics other than your eye.

It's not. Jupiter is about 10-4 at closest approach, which means that even with optical 6x zoom, it's going to be just a dot. You need a stronger zoom before you can see that it has diameter. The fact that the spot on that image has some size is strictly an artifact of the optics and the way digital zoom was performed. You will not see any moons without a telescope. Edit: Ok, here we go. iPhone 4S and 5 resolve at about 3x10-4. (Older models are worse.) So I was a bit off. If that 6x zoom was optical, you'd be just able to see that it's not a point, assuming no problems with aberrations. But the zoom is digital, so the apparent diameter on the image is just an artifact.

Euler is pretty much the worst choice you can make for an orbital mechanics problem. (There are two ways to do Euler for second order, and one of them is the absolute worst way to integrate orbital motion.) If you want a method that's just as simple, yet gives you far, far better precision, go with Verlet.

That's a pretty standard miscondeption. It doesn't take a force for something to keep going. If Kerbin pulls on object that's trailing it around Kerbol, that object is accelerating towards Kerbin. It's not going to just hang a constant distance behind. The reason you are thinking of it in terms of bungie is that usually, when you need to pull something, there is friciton or drag, so you have to constantly supply force to keep the object moving. E.g. dragging a boat by the rope. But there is no friction in space. For an object to move behind Kerbin at the same speed, there has to be no force acting on it. It has to be coasting completely free. But there is pull of Kerbin, so it's going to accelerate towards Kerbin, and eventually fall.

Nobody's been arguing about programming languages for about a page. We've been talking architectures, compilers, and development tools in general.

A 500km planet would have an escape velocity roughly equal to speed of sound on Earth. That's typical velocity for molecules in air. So at 300K, atmosphere is going to boil off the planet almost instantly. And if you cool the atmosphere enough to keep it around for a little bit, every single one of the gases you've mentioned are actually going to be liquid or solid.

Keep in mind that surface pressure is (roughly) the weight of the atmosphere per surface area. So if you have a lot of atmosphere, but at a very low pressure, the only thing that can be happening is that gravity is very low. And vice versa. If you have just a little bit of atmosphere, to get high pressure, there has to be very strong gravity. In practice, however, worlds with low gravity won't be able to keep much atmosphere, and worlds with a lot of gravity will have a very thick atmosphere. So while there can be significant variation, like lajoswinkler said, no extremes.

And because they didn't exist, nobody wanted to compile for them. So the statement was still true. And since GCC compilers are being kept up to date to this day, the statement stayed true. Besides, you don't compile to the platform. You compile to an architecture. And as Nuke pointed out, ARM already existed in the 80s. As well as MIPS and x86, which are your other options on Android. iOS is strictly ARM or derivatives, if I'm not mistaken. The linker, of course, needs to know a few things about target platform to dress up your compiled code properly. And the linkers in GCC package have been able to make executable code for these mobile platforms, as well as many, many others, for pretty much as long as these platforms have been around. People who keep GNU up to date tend to be very good at making sure the functionality is updated as soon as there is new development in architecture or operating systems. Of course, if you happen to need code for a platform it can't link for, you still have options. You can get it to dump just binary that you can dress up for a particular OS yourself, or it can give you code compiled to assembly, but not assembled or linked, so you can use native assembler and linker. Et cetera. You'd be very hard pressed to come up with a modern platform, even an obscure one, that you can't build code for using GCC tools. GCC also gives you a choice of languages. C, C++, Objective-C, Ada, and Java are standard. A number of other languages are also available, including Pascal. It's not standard, but you can get it. Because it's part of the GCC package, it can compile and link to any platform that the other GCC compilers can handle. So yeah, you can already build iOS and Android code using GCC Pascal.

In fact, they are equivalent statements in this context. It doesn't really matter if you believe "In Principio Erat Verbum*," or "In Principio Erat Fragor Maximus**," or some combination. It's the "In Principio Erat" that is the question here. Of course, from modern perspective, it's even easier. We don't need to understand why universe happened. There is no "happening" in the grand scheme of things. Universe just exists as a 4-dimensional object. And from our perspective of time it always existed and always will exist, because there is no time outside of the universe. Nor is there an outside. And some people ask what was before the Big Bang, and by all symmetries, I'd have to say, most likely, the other side of the Big Bang. (Picture our expanding universe as a bunch of shells, each shell corresponding to a moment of time, together making up the hyper-sphere of the universe. If you go back in time, towards the center, as you pass the center, you just end up going forward again on the other side. Now, topology doesn't have to be spherical, but the point remains. Not that this is anything but conjecture, but it'd be the most elegant explanation for matter-antimatter imbalance.) But why it exists is still a question, which just happens to be completely beyond science in this form. Even if there is some external cause, we'll just want to know the cause of that. P.S. For these who don't read Latin. * "In the beginning was the Word" - Biblia Vulgata, John 1:1. (I give King James translation here.) ** "Big Bang"

Ah, so it wil lfinally be able to do what GCC could do with C code since the 80s. About time.

Virtual machine has a lot of advantages. It's very useful to know how to code for one. Understanding garbage collection in Java and C# is also very useful for larger C++ projects. Memory management in general is an interesting subject.

You shouldn't mix definitions like that. If you insist that Democracy is a principle, and US is a Democracy, then US is a principle? Word itself can mean a principle or a form of government. It's the later we should be considering. Whether you want to consider US as a democracy differs a bit by definition, but typical definition involves "equal representation," which is not the case in United States. So it's entirely fair to say that U.S. is not, in fact, a democracy. It is, however, a democratic, federal, presidential republic. UK, in contrast, is a parliamentary monarchy. Whether or not it can be considered a representative democracy, I don't really know. I'm not sufficiently familiar with their system. It is not a republic on technicality only, however. Even though their system follows all of the same rules as a republic, the fact that they do have a monarch means we call it a constitutional monarchy instead.

Nah, don't worry. Transition from Borland Pascal to C or from Object Pascal/Delphi to C++ is extremely smooth. Get yourself a C++ Pocket Reference. That will let you quickly look up the syntax, and that covers almost all of the important differences. I'd start early, though. There is no reason why you can't be writing some simple C++ programs right now to be ready when you have to do this for class. C# is a bit different, because it compiles to CLR binary, rather than machine binary, which means memory management is a lot more like Java, and that leads to slightly different approach to programming. But still, for most introductory level stuff, it's going to feel like just a syntax difference. In fact, when you start doing more advanced things with memory, C# might seem way easier, because it's a lot better at making sure you aren't creating leaks or seg-faults.

I'm going to use the following notation. R = planet's radius. μ = GM = gravitational parameter. r = h + R = distance from center of the planet. h is altitude. ra = ha + R = apoapsis. rp = hp + R = periapsis. a = (ra + rp)/2 = semi-major axis. Using these, you can find velocity at any point along the orbit using virial. (You can derive this equation from energy and angular momentum conservation, but it takes a bit of work.) v² = μ(2/r - 1/a) This will work for apoapsis and periapsis velocities as well. Just substitute r = ra/p. (Note that this even works for hyperbolic trajectory if you use the convention where a < 0 for hyperbolic trajectories.) Angular velocity follows from angular momentum conservation, which essentially tells you that Ér² is a constant. This is equivalent to Kepler's Second Law. So you know that Ér² = Éprp². And at periapsis, angular velocity is just Ép=vp/rp, because r and v are orthogonal at apsides. That gives you general formula. É = vp rp/r² Again, since periapsis is defined for parabolic trajectories, this will work even if your craft is on an escape trajectory. And you should be able to compute everything else from that. Have fun.

Ohm's Law - 1827. Faraday's Law of Induction - 1829. Kirchoff's Circuit Laws - 1845. Maxwell's Equations - 1861. Bernoulli's Principle - 1738. Navier-Stokes Equations - 1822. Reynolds Number - 1851. Most of these predate Victorian Era. Rest are from early Victorian. They are sufficient to understand both electronics and aerodynamics. Now, they aren't sufficient to predict semiconductors, for example, because it's a quantum effect. But Kirchoff's Laws do describe transistors in a circuit as a non-Ohmic device. Similarly, the fact that flight is possible due to aerodynamics was absolutely clear. What was missing was understanding of circulation, which came about at the turn of the century. There have never been a case when engineering followed theory closely. What we have are a few examples of lucky discoveries that were soon followed by theory. Radiation, semi-conductors, super-conductivity. Even flight, technically. Kutta-Joukowski Theorem, while already conceptualized, has not been available to Wright Brothers.