Kuala Lumpur gets (generous assumption) about 100 lightning strikes per square kilometer per year [0].
If a single drone could service a lot of square km, then it could conceivably collect a lot of electricity. E.g. if it could service 20 square km: 20 * 100 * 8mWh = 16gWh per year. Not bad, but an upper bound, and it hinges a lot on that first parameter (service area).
True that an offshore wind turbine can produce 15MW. But it can cost $100m+ just for 1 turbine (built and installed). If drones are going up anyway (to protect a city/citizens from strikes), then electricity generation is effectively free, and the marginal cost is equal to the hardware required to capture it (maybe relatively low).
You don't just need to cover the 350km² with drones though, you also need buffering and/or transmission capabilities for absurdly high amounts of power (=> but low amounts of energy).
If you wanted a single buffer for the whole 350km², you'd need transmission capability from any point (or any drone launch station) to your central buffer in the Terawatt range (currently our highest power grid links are in the ~10GW range, so this is pure fantasy already). Utilization (~ capacity factor) for the lighting capture infrastructure would also be abysmally low. You'd basically need to build a ~10TW (generous estimate!) system, where costs in a lot of components directly scale with power, just to get ~10MW of sustained power out.
There is no way you are ever gonna compete with that $100M wind turbine; you could literally have cheap, high-field, room temperature superconductors and be gifted several warehouses worth of supercapacitors, and the whole lighning capture boondoggle still would not make any economic sense.
One major downside is that it becomes really hard to do transactions, especially across multiple files. If you store mostly immutable data though like git (where except the refs every object is immutable, mutating creates a new object) it can work nicely.
Hmm... is the mutability of data really enough to create a need for transactions?
For example here on HN (which afaik also stores the data in files) you can change a comment you wrote. But that type of mutability does not call for transactions, right?
I for one enjoy the convenience of automatically installing python versions. Yes I know how to do it manually. Yes it is possible to install multiple versions. But that does not mean I want to do it every time, just to test how things behave in different python versions. For that, it's also okay if it does not install the most performant version of the interpreter.
>Yes it is possible to install multiple versions. But that does not mean I want to do it every time, just to test how things behave in different python versions
You only have to do it once per version with this approach. Then you can create venvs from that base, and it's basically instantaneous if you do it `--without-pip`.
Sure. We've had system package managers for decades. I install a major version once a year and it gets automatically upgraded to the latest patch version by my system package manager, just like everything else.
The limit could depend on a lot of other things. In theory, it's possible that you are paying 100% of revenue on debt service yet still the best option is to take on more debt. This is if you believe that investing the money raised via additional debt provides returns that outweigh the increase in debt service costs. So in that situation, additional debt can even lower the debt service / income ratio.
So this is meant to illustrate that the limit on debt is more a function of the concrete circumstances. In this line of argumentation, debt is not limited by a mathematical formula that just takes GDP and similar statistics as input.
Your analysis leaves out one teeny tiny little thing--the ~6 Trillion dollar federal budget!
If you're paying 100% of revenue on debt service, taking on more debt isn't optional. All other federal outlays must either cease or be funded by new debt. Given current levels of federal spending, that would mean increasing the national debt by ~20% of GDP, per year.
More debt --> higher debt service costs --> even more debt --> even higher debt service costs --> et cetera
Yes, that is a limitation. But this limitation is not too bad.
In many cases, a bug in the translation simply makes the proof impossible. Somebody then investigates why the proof does not go through and finds the bug in the translation.
We only have a problem if the bug in the translation specificially cancels a bug in the original code. If there is no systematic risk, it is quite unlikely that two bugs cancel each other in this way.
Let's say you want to check if use after free can ever occur. Your translation is bugged and translates the whole program to a single "nop". Then the verifier happily asserts that the translated program does not cause use after free.
I doubt the translation would be that bad but it could have more subtle issues of the same kind.
My argument is that you typically also check other properties, like properties describing what your program should do. These other properties likely wouldn't be satisfied by a nop program, and hopefully the same is true for many subtle issues.
Do you know if redispatch costs are included as part of your transmission costs and how much they are? Because if they are, then investing into the transmission lines can decrease transmission costs since the providers need to pay less for redispatch.
I am no economist but couldn't it be that raising pay in few sectors does not cause inflation? I would think that depends on what the people receiving more money spend it on. If they only spend it on things where we have no bottleneck and there is still excess capacity, how would that create inflation? Inflation should only happen if the increased paycheck is used to compete for scarce resources/products. So I think predicting inflation requires a more detailed analysis, especially you need to have a cycle of increased prices and pay.
Length and capacity are two different things; a slice is a pointer and a length, but a Vec<T> (and Go's slices) are a pointer, a length, and a capacity.
That Rust and Go both have "slices" that are slightly different is, unfortunate, but that's just how it goes sometimes.
Construct a TM which enumerates all possible variable assignments and checks if the SAT problem is satisfied then halts if so. You can construct this TM in polynomial time, and it halts exactly if the SAT problem is satisfiable. So this is a polynomial reduction from SAT to the halting problem.
I do not dispute this. My comment was about the linked paper [1] regarding equivalence of the halting problem and Kolmogorov complexity, not the SAT problem.
