I wonder if there is more fp drift from extra math that makes it LESS accurate in the case where the simple equation suffices? I'm impressed that satellites even have eccentricities so close to 1.0 that this makes sense, but I guess from, generically, an orbital planning perspective this make sense.
the yuan has major currency controls. there is a real threat of capital flight destabilization if policies change which is why nobody sane would peg tp the yuan as it is now. that said, countries definitely make bad choices.
I'm afraid you may have misunderstood. The SDR is a time-varying basket of USD, EUR, RMB, GBP, and JPY. At time of writing Afghanis are not part of SDR, even though Afghanistan owns some SDR.
Thanks for the clarification. The hyperlink you gave was to the general IMF website and did not contain an in-page search hit for "RMB," "Renminbi," or "China". Where can one find the size of the RMB allocation?
Presumably the IMF is not bound by the typical RMB capital controls that limit its utility for commercial entities and individuals.
I found that information at the top of the linked page, which I just checked again was indeed the page about SDRs. Maybe they're doing some stupid redirection that's browser dependent.
arguably the O-1B is more necessary than the O-1A. If you didn't have an O-1B you couldn't have a bjork come and give a concert in the US and get paid for it, you couldn't have an emma thompson come and shoot for a hollywood film and get paid for it, you couldn't hold ANY major international sporting events, etc.
It's harder than you'd expect. Depending on what kind of bucketing an arena does (by size or by type), a stale reference may end up pointing to another piece of memory of the correct type, which is still wrong, but more subtly than a crash.
I'm not familiar enough with Zig to want to dive into architecture, the point I wanted to make is general to arenas in any language that can have a stale reference.
I once had a stale stack reference bug in C that lived for a year, because the exact same object was created at the exact same offset every time it was used, which is a similar situation.
So, I'm noodling around with writing a borrow checker for zig, and you don't get to appreciate this working with zig on a day to day level, but the internals of how the zig compiler works are AMAZING. Also, the io refactor will (I think) let me implement aliasing checking (alias xor mutable).
What is your attack model here? Each request lives in its own arena allocator, so there is no way for any potentially malicious JavaScript to escape and read memory owned by any other request, even if there is a miscode. otherwise, VM safety is delegated to the V8 core.
Believe it or not, using arenas does not provide free memory safety. You need to statically bound allocations to make sure they don't escape the arena (which is exactly how arenas work in Rust, but not Zig). There are also quite a lot of ways of generating memory unsafe code that aren't just use after free or array-out-of-bounds in a language like Zig, especially in the context of stuff like DOM nodes where one frequently needs to swap out pointers between elements of one type and a different type.
Already answered there: I’m using bakers yeast, not lab yeast (store-bought S cerevisiae). It’s not haploid, often it’s tetraploid. HR doesn’t guarantee homozygous transformation.
Same answer for electroporation vs spheroplasty. I’ve found with wild yeasts or less tamed yeasts (pichia), sometimes just nuking the damn thing with kV will just work, whereas those chemical methods can be way more finicky. Time is money
The likelihood that top-two is close enough to be hardware dependent is pretty low. IIUC It's more of an issue when you are using other picking methods.
reply