No. And in fact it annoys me greatly that our work IT department forces a reboot once a month.
My desktop is like an actual desktop. I have my tools laid out exactly how I want them for the task I'm working on. I want to come back to them in exactly the same place when I pause for the night or weekend.
I have to clean it up occasionally, to close out things that I'm no longer working on or forgot about. But I'd rather do that incrementally than all at once. Forcing a reboot is like tipping over a physical workbench with a bunch of tools and in-progress projects on it. Just awful, and often takes hours to set back to its original position (at least browser tabs restore reliably these days).
Cheat answer: velocity is a vector, and can be negative, while KE is a scalar and has to be positive. Therefore you have to square v to get rid of the minus sign.
Why not take the absolute value? Nature hates those, probably because the derivative is undefined at 0. So squaring it is.
Why isn't the shifter built with a log2 arrangement, shifting 32-16-8-4-2-1 bits? Takes fewer sub-stages and doesn't require a separate decoder for the input.
The article mentions it already has a two-stage design, shifting bits and then bytes, so it can't be about shifting more than one bit at a time. Anyone know why?
Sometimes you have to optimize other people's code. Also, sometimes code behaves unexpectedly depending on the data, say over a certain size threshold. And sometimes it behaves differently on different hardware. You don't always find these things out until production.
Doh! You are correct. I had been looking at a previous paper (which this new paper references). The previous paper showed that you can use any non-linearity in QM to solve NP-complete problems, and the new one shows that semi-classical gravity + QM has such a non-linearity. The earlier paper: https://arxiv.org/pdf/quant-ph/9801041
Yes, I think that was implied in my original post, that if you define |0> as logical 1 then it works as an AND. It just seems confusing and unnecessary when they could have framed it to be consistent with classical logic.
I was skimming the paper and came to this:
> This transformation is like an AND gate - it ignores the index qubit and places the flag qubit in the state |1> if and only if either of the original components had the state |1> for the flag qubit.
Shouldn't that be an OR gate? Not only does the description above say "if and only if either of the original components had the state |1>", which is an OR, but the truth table listed above shows the same thing for the flag qubit.
Of course, one could say it's an AND on the |0> states, which is just De Morgan's law, but that's pretty awkward phrasing.
We always try to inform game devs about correctness issues, but generally we can push out a driver fix before the devs can fix things on their side, so that pretty much always happens. Many things can be fixed quickly by app profile (detecting executable name). And we have a pretty good relationship with most game devs and usually get some feedback. Of course, we don't have infinite resources, so bigger game devs get more attention to tiny ones.
I'm not sure what fraction of devs actually fix things on their side, though. Once there's a driver workaround, and we've informed the devs, it's off our plate.
Performance is more of a gray area. We contact devs if there's something we can't work around, of course. And if there's something truly breaking. But for things that aren't exactly bugs, just things that could be improved, and we can improve on our own... well, we'll probably keep that for the competitive advantage.
There are many, many, cases like this, including correctness fixes. One recent example I remember had a shader that computed:
x = a / b * b
The optimizer was allowed, but not obligated, to transform that into:
x = a
However, in this case, b was sometimes 0. And if so, the unoptimized version computed:
x = a / 0 * 0 = Inf * 0 = NaN
So badness ensued if the that particular path didn't get optimized, which could happen under various circumstances. We had to add some code to ensure that transformation always happened on that game.
The article mentions that thin-walled copper tube can be used, but then says a precision lathe is required. But you can easily buy off-the-shelf copper tube with 1.6 or 2.0 mm diameter and 0.5 mm wall thickness. Is that not thin enough? If not, could one chemically thin the walls (acid, electrolysis) until it is enough?
Numerous times now, using Tesla FSD, I've found the car seemingly drifting from the center of the lane, only to have motorcycles buzz by at high speed on the opposite side. It's very polite toward motorcyclists.
Boron always seemed like an under-studied element to me. Starting from the bottom, hydrogen of course is very well understood, helium not useful for much, lithium used for many things, and beryllium interesting but unfortunately toxic. Next is boron. Low toxicity, light weight, interesting electron configuration. Compounds like boron nitride and boron carbide have remarkable properties, but seem to get less attention than carbon. Not sure why.
There are a number of ways of looking at this, which others have answered, but here's another:
The kinetic and potential energy of a 1 kg mass in orbit is around 33 MJ. The chemical energy of 1 kg of methane+oxygen propellant is only about 11 MJ.
Alternately, perfectly combusted methane-oxygen propellant has an exit velocity of around 3500 m/s. But you need about 7800 m/s to get into orbit.
Chemical energy is just very weak compared to the energy of things in orbit. It's really shocking that we can do it at all.
The result of this is that your vehicle is going to be almost entirely propellant. You simply can't just build a big, beefy rocket that's, say, only half propellant, with lots of extra safety margin for things that go wrong. Cars and bridges and things have immense margins. Airplanes, a bit less so, but still more than rockets. Rockets live right on the edge of what's possible, and as long as we use chemical thrust it'll always be that way.
Which isn't to say that rockets won't get more reliable. The Falcon 9 has had hundreds of flights since the last failure, and it isn't as optimized as it could be. But there will be a lot more failures before we get there.
That's already how civilization works. There's no one person that knows everything about (say) modern food production, from top to bottom. If it ever stopped working (because too much knowledge was lost somehow), most people would die. And yet the system seems fairly resilient. Mostly, only local knowledge ever seems to be necessary to keep the whole thing running. Super-intelligence (or even just super-normal-intelligence) might expand the scope of what constitutes local knowledge but it will still run into limits somewhere.
The ship computers in the old game Privateer (and probably Wing Commander) had a pretty nice pixel font. Most of the characters were 3x4, but with a few niceties: descenders (j, p, q) could go below the normal outline, and wide glyphs like m/n/w were more than 3 pixels wide. Overall, pretty readable for uppercase/lowercase/numerics, and included a few "futuristic" touches.
Early versions of Unreal Engine had these animated procedural textures that would produce sparks, fire effects, etc. The odd part is that when you paused the game, the animated textures would still animate. Presumably, the game would pause its physics engine or set the timestep to 0, but the texture updater didn't pause. I suspect it was part of the core render loop and each new iteration of the texture was some sort of filtered version of the previous frame's texture. Arguably a very early version of GPU physics.
Modern games can have the same issue. Even taking a capture of the exact graphics commands and repeating them, you'll sometimes see animated physics effects like smoke and raindrops. They're doing the work on the GPU where it's not necessarily tied to any traditional physics timestep.
Starship "making LEO" is not a significant challenge--the existing flights have explicitly targeted a (very slightly) suborbital trajectory. They could have done otherwise at any point, but for now it's more important to guarantee that the stage comes down immediately. None of their current objectives require more than ~1/2 of an orbit.
Starship v3 flying will be a significant leap, though. It's the first with the Raptor v3 engines and has many other improvements as well, such as updated grid fins and hot staging ring. It will be the first that achieves close to the intended capacity of ~100 tons.
Propellant transfer is indeed a significant challenge. They have already demonstrated internal transfers between tanks, but not between spacecraft.
There were 19 successful unmanned Dragon 1 missions before Crew Dragon, and an unmanned Crew Dragon mission before the first crewed one (actually two missions, but one didn't reenter from orbit). The heat shield material and design was essentially the same and so there was a great deal of flight heritage.
That doesn't seem right to me. Sodium (and mercury) vapor lamps are the color they are due to physics, and were chosen because they're very efficient (and long lasting). Low-pressure sodium is the best and worst of these; essentially monochromatic but fantastic efficiency. Their only advantage, color-wise, is that the light can be filtered out easily (they used to be widely used in San Jose because Lick Observatory could filter out the 589 nm light).
My desktop is like an actual desktop. I have my tools laid out exactly how I want them for the task I'm working on. I want to come back to them in exactly the same place when I pause for the night or weekend.
I have to clean it up occasionally, to close out things that I'm no longer working on or forgot about. But I'd rather do that incrementally than all at once. Forcing a reboot is like tipping over a physical workbench with a bunch of tools and in-progress projects on it. Just awful, and often takes hours to set back to its original position (at least browser tabs restore reliably these days).