If you look at the graphs there is nothing like an 'inflection point' or qualitative change in the graph behaviour.
The Allied line goes slowly down and the Axis line goes slowly up. At one point they cross, but there's nothing particularly significant about that crossing point. Nothing happened in the month that they crossed other than the two numbers were equal momentarily.
But you're now talking about a much smaller group within the US Air Force. Obviously if you zoom in on any small unit of any force, you can find units with extremely high casualty rates.
I disagree that this argument makes it less likely to have very low prices much of the time. I think it makes it more likely.
If peak to trough is a large gap, say 60% of peak, this tends to make it less likely that peak will be met by overproduction, since that would involve very large capital costs.
The picture you paint above would suggest a very small gap between peak and trough, say 2% of peak. This means that almost certainly there would be enough over capacity to more than meet peak demand. Therefore the total daily demand would be more than met by capacity, leading to some energy being thrown away. So at all times except the peak, the marginal cost would be zero.
You have given an accurate argument for why demand would be elastic at trough. But you haven't given any reason why overall demand would be very elastic.
Isn't it possible that such a system will over-produce 99% of the year and that therefore, the marginal cost will almost always be $0?
'Take my energy and allow me to stop accelerating my flywheels which regulate production' seems more plausible than 'someone would always like more heat for something' (what?)
Or possibly 'take my energy and I'll cut off some of the people using spare energy to do low priority, low value computation for free'?
Yes, but remembering the multiples of 10 is vastly easier: they are 10, 20, 30, 40, etc. Remembering the multiples of 16 is quite a lot easier: 16, 32, 48, 64 etc. You probably already know them.
Now to convert from miles to km replace a multiple of 10 by a multiple of 16. 70 mph becomes 112 km/h.
To convert in the opposite direction do the opposite. 130km/h is 128 km/h + 2 km/h = 80mph + 1 mph (rounding down since you don't want to have to justify this calculation at the side of the road, to a gendarme, in a foreign language).
1.6 km = 1 mile is just as accurate as using 1.618.., the golden ratio. (Enough for driving, not enough for space travel.) And using the Fibonacci method is less accurate than the golden ratio since small Fibonacci numbers are only approximately the golden ratio apart.
The only possible justifications for the Fibonacci method are:
1. You want people to know that you know what the Fibonacci sequence is.
2. You enjoy overengineering.
3. You're one of quite a few people who believe, for whatever reason, that the golden ratio appears all over the place like in measurements of people's belly buttons, the Great Pyramids, and so on, and that this has some spiritual or mathematical significance.
The company that 'owns' Redis or Elastic also do not need to develop the software they are selling. They already have it, since its creation for free on a non-commercial basis.
Without competition, they are free to charge any rent they like for it.
If you think that the person that originally wrote Redis or Elastic should have an exclusive license to charge people to use that software, that's a totally valid opinion and a totally valid licensing/business model. However, it has nothing to do with open source software.
This is literally what open source is. If you don't support this, you don't support open source.
There isn't a 'purer' form of open source which does exactly what you want with respect to big companies using the code.
You can be in favour of licensing that restricts Amazon or Microsoft's right to use your work. But that position is detrimental to, not supportive of, open source, since such a license would not be open source.
Whatever you think of those companies in a wider sense, it's totally inaccurate to suggest that Microsoft, Google or Amazon haven't given anything back to open source.
Yes, except that since Amazon have infinite resources, the friction didn't stop them doing anything, and the fork was always going to be perfectly viable.
But it restricts your ability to use a commodity product based on Elastic, provided by a third party who will compete on price or bundle it with other cloud services.
They need landlords to stick to the numbers they pass on, in order that those numbers remain valuable to all of their other landlord clients.
Suppose that you're a big landlord in some area, such that your submitted prices can affect rents for that property type across the area. You might be tempted to submit high prices, wait for your competitors to follow suit, and then reduce your actual rents to undercut them. They (the competitors) naturally wouldn't be happy with this. So RealPage has to be able to show people that they know their numbers are the actual ones.