You misunderstood the problem. The problem isn't that programmers can't write loops that are easy to optimize. It's rather that, in practice, they don't write loops that are easy to optimize. That's ultimately a problem with the C language.
The easiest way to write the loop is the way that is hard to optimize. This is a fact that is beyond dispute: empirically, programmers use int to index over arrays in for loops without writing asserts. That is in fact a problem with the language.
When designing tools for use by humans, you need to accept the fact that humans, with all our failings, will be the ones using the tools. So tools should be made resilient against typical ways in which humans fail.
We've been paying for shortcomings in C's design for decades with bugs and security failures that simply don't happen in other languages. That you refuse to see this is baffling to me.
When a common idiom becomes the wrong way to do something, someone messed up pretty badly (and preexisting idiom at that).
Arguably the designers of amd64 should have caught this before releasing the ABI or the language design could have been specified so this wasn't an issue in the first place.
Can assert() actually function this way? Can you use assert to tell the optimizer it can assume something is true?
I've noticed that memcpy(x, y, 4) on x86 can generate very efficient code (register move), but on ARM it expands to something much more verbose because the addresses might not be aligned.
Could this effectively function as a way of promising to the compiler that the addresses are aligned?
Interesting! This assert_and_assume() seems strictly better than vanilla assert() for any predicates that don't have side effects. But I guess you have to be sure that the compiler is able to deduce that there aren't side effects and feels comfortable optimizing away the predicate in release mode.
Recent compilers support some extensions that can do it better. GCC and CLang use __builtin_assume_aligned(), and ICC uses __assume_aligned() (haven't tested the synonym).
For the scramble suit to work, publicly available 'mixing' stations would have to be available, which would work like a black box, you could only surveil input and output.
And exits from your house would have to somehow be connected to those stations, or have your house change locations randomly.
The latter could work if houses were mostly in form of larger modular worldwide-compatible shipping containers. Also no windows, we would have VR.
In terms of sociologic development the middle-eastern countries are considered backwards with their stone-age laws, ingrained religion, and treating women like lesser beings, and yet we may soon be wearing 'burka' like clothing to protects our identity. Of course apart from the physical look, there is no connection between the two.
Now this is my type of dystopian future; those are very cool, like something straight out of Bladerunner. Fashion with a function, all that's missing is a clear raincoat.
Correct me if I'm wrong, but in this scale model, I think the part of the building marked with a black rectangle (upper left) is what is currently being built.
Check out the flight profile on Flightclub.io -- I'm not sure how accurate their instantaneous data is but they're showing ~12g acceleration upon landing the booster. Seems more like what I'd expect.
TheVehicleDestroyer (who makes FlightClub) actually commented [1] to say that the 12G is an error due to how he models the deployment of the landing legs.
Ugh sorry, there's a bug of some sort in Flight Club there. There's no way it was that large. A constant deceleration down from terminal velocity over 6 seconds is
So it looks like that peak is due to the sudden increase in drag during my landing legs deployment. I deploy them at 500m altitude which is a time when the stage is probably still moving a bit too fast. It's a really large increase in cross-sectional area, but I'm probably not treating it correctly. I'll revise before Thaicom-8
Impatient to know if the 1st stage is reusable after a 12g phase. The entire concept hangs on this and it looks like we don't have a firm confirmation yet.
12g but empty. A structure meant to survive being filled with 10+ times (fuel+upper stage) it's own weight will survive 10+Gs without effort. In other words, the stress of a 12g acceleration isn't much different than the stress of the stage sitting on the pad a few minutes previously.
The overall structure actually goes through all sorts of stresses, not all of which are measured in G. The combination of push from the rocket and air resistance compresses the rocket from both ends, something that isn't reflected in G numbers.
I think this is only sort of true. Yes, the fueled rocket is much, much heavier. But not all parts of the rocket are load bearing as it sits on the pad waiting for launch. All parts of the rocket experience the 12g (or whatever it was) deceleration.
Also, rocket skins are really, really thin (relative to their size, the forces they endure, etc.) I've read that without the fuel inside to reinforce the rocket, it is quite fragile - think of trying to crush an empty soda can vs a full one. This is part of why rockets which deviate too far from prograde on launch are ripped apart mid-air.
Regarding your last part, some rockets have balloon tanks, which means that the tank requires pressurization to keep its shape.
The Falcon 9 has a sort of partial balloon tank. It's strong enough for ground handling without pressurization, but it requires pressurization to handle flight loads.
Note however that it's pressure, not fuel, that provides the extra strength. These tanks are still pressurized even when almost empty.
I would say that ionizing radiation isn't the cause of most genetic mutations. It is just too rare and most of it doesn't penetrate the skin anyway, the rest has to be really lucky to hit the cell in the right place at the right time.
DNA copying not being perfect would be the main cause in my opinion.
There is one error on average for every billion pairs copied. The human DNA has 3 billion pairs. So every time a single(!) cell is copied, three mistakes are made.
It certainly could be, but I think most mistakes are made because of how the process is 'designed'; sometimes an incorrect molecule jiggles (literaly) into a place where it is improbable that it should.
I still haven't seen anyone write what those fraudulent acts are exactly. Since Craig Wright (let's not call him what he isn't) apparently has several companies, these should be some clue about that?
There are articles that do so (https://www.nikcub.com/posts/craig-wright-is-not-satoshi-nak...). The gist is that Australia via their tax authorities pays R&D credits in cash. Wright set up a corporate vehicle funded by the transfer _on paper_ of Bitcoins that are not proven to even exist. He used these to mostly buy software from himself and claimed a AU$3.1m R&D cash tax refund.
(3) Pay off tax authorities with VC to avoid going to jail; swap angry tax authorities for angry VCs. The former are criminal charges with nasty penalties, while the latter are civil and/or easier to defend criminal charges. At the very least you've kicked the can down the road.
There is no evidence to believe the post reflects upon his real emotions, and since the man is untrustworthy[0], the post cannot be taken as evidence about his emotional state.
[0]:Whether he is willfully or maliciously deceptive is irrelevant. Even if he has the best of intentions, his behavior is still untrustworthy.
I don't know, but based on the last line I err on the side of caution. People don't react well to world-wide humiliation. I agree that he is completely untrustworthy and can't be relied upon to give an accurate representation of his own mental well-being.
The second example causes unexpected behavior (and probably ub later) if: min + step > MIN_TYPE_MAX
The last example causes undefined behavior if: max - min < step - 1.