tspiteri

Automatic updates can be turned off.

Under Manage Your Content and Devices, Preferences, there is an Automatic Book Updates item which you can turn off. Then if you want you can update books individually, or not.

Are you implying that if we don't know all the details of something, then we just don't know it? That is, are you implying that if we don't know all the details about our evolution, then we should just say that we know nothing and ignore all the things we actually do know are very very likely?

That would leave you without any empirical sciences, because there has always something we do not know. When Newtonian mechanics where the best we had, they were incomplete, but they are still extremely useful even now that we know they are incomplete. All empirical sciences are essentially some theory that fits the empirical evidenc, but never completely and perfectly.

In my post I'm assuming acceptance of what is commonly accepted in the theory of evolution. If you don't accept that, there is absolutely no point in continuing this discussion.

We basically have common ancestors with all animals, but:

* We are way closer to a bird than to an amoeba, so our shared ancestors with birds are closer in time than our shared ancestors with amoebas.

* We are way closer to a cat than to a bird, so our shared ancestors with cats are closer in time than our shared ancestors with birds.

* We are way closer to an ape than to a cat, so our shared ancestors with apes are closer in time than our shared ancestors with cats.

Sticking to trade wars, let's say country A is the current leader and country B is catching up. A might start a trade war knowing that it will be worse off right now, but B will lose more, and A will remain the leader. The competition from a stronger B could be even more costly to A than the trade war.

And also, yes, some consider relative wealth more important than absolute wealth; "I'd rather have $100 and my neighbor $10, than I have $150 and my neighbor $140."

Just like wars, in trade wars one side gets hit worse than the other, which is kinda the point I guess.

Also, just like trade wars, wars come at great costs to both sides, but they still happen.

-ize is correct in British English as well; if anything it is more "original" as it comes from the Greek -izo (iota, zeta, omega), which is the origin of the suffix. In fact Oxford English Dictionary (OED) spelling, and the Hart's Rules guide, are for organize, not for organise. (On the other hand, analyze is American while analyse is British.)

But you wouldn't say "The my reliance", so why would you say "The Liverpool Football Club's reliance"?

Calories should not be considered as just "a nutrient to limit" in such a way that the number is only a maximum. I sometimes used to look at the energy value to choose a ready meal that had at least enough energy so that I would not remain hungry after eating; providing significantly less energy would leave me hungry.

Have things changed recently? The way I remember it (a few years back) was that you didn't need a licence to watch non-live iPlayer, so you could watch yesterday's programmes on iPlayer without the need for a licence.

I think it's in large part due to documentation and fonts. For example in my Fedora, I only have part of texlive installed. My /usr/share/texlive/texmf-dist is 1.3G, of which 428M are inside the doc subdirectory and 639M are in the fonts subdirectory.

Then there are many packages that contain pictures or logos. As a single random example, texmf-dist/tex/latex/fithesis is 2.4M, of which 2.1M are in fithesis/logo.

That would still break existing code: you have to change it for it to compile. And if you are going to change the code, it makes more sense to change the code to use pre_exec in an unsafe block than to use before_exec with an #[allow] annotation.

This comment is confusing two completely separate concepts: zero cost abstractions and run time bounds checks. Rust does provide zero cost abstractions: if you do something explicitly/manually instead of using the abstraction you get the same generated code.

If you want to combine the two concepts, I guess you could go for an example like this:

    if index >= vec.len() {
        panic!("out of bounds");
    }
    let value = unsafe { vec.get_unchecked(index) };

which can be rewritten using higher level abstractions as:

    let value = vec[index];

The second is more abstract, and that abstraction is zero cost, you do not pay for using the abstraction more than the explicit code above it.

It also highlights an example of a security bug introduced during rewriting; highlighting that rewriting any significantly large piece of software is bound to introduce bugs.

I said reduce the risk, not eliminate it; or make the probability distribution narrower, not collapse it to one value.

With insurance, the expected worth for you has to be negative, otherwise how would insurance companies even survive? The value of insurance is not reducing the average loss, but reducing the risk. For example you lose $10 at a probability of 100% instead of $1000 at a probability of 0.5% (that is losing $5 on average). If you look at the probability distribution of your losses, you are not moving it to the left (lower average), you're just making the distribution narrower, that is you reduce the chance that you lose large amounts.

In summary, if losing $25k is no big deal to you, you can on average save money by not buying insurance. If losing $25k is life changing, you should pay some money to reduce the risk.

Although the numbers are 0.92.4 and 1.0 alpha, Inkscape has been good for a long time. The release notes for the 1.0 alpha release (https://inkscape.org/release/inkscape-1.0alpha0/) look very much like what I would expect for say a 6.0 or 8.0 version.

My main point was that to my knowledge there has never been a case of forced further distribution.

About termination, what you mention is kind of stopping further violation of the terms and maybe compensation for the past violations. What I wanted to mention (but wasn't at all clear about) is that after termination, you cannot even distribute if you intend to abide by the terms unless you are forgiven by the copyright holder. (In the case of the GPL version 3 there is some grace period during which for the first violation, if you abide within that period, you are explicitly permitted to resume distribution under the license terms.)

The outcome of violating the GPL is license termination: you cannot distribute it any more. I don't think there has ever been a case of enforced further distribution or disclosure.

> Same way an actual, legitimate newbie to Rust is going to have much more difficulty processing why :: is the namespace delimiter or why you need curly braces to deliniate scope than how having the option to declare your function const would.

I disagree. :: and curly braces are just a shallow bit of syntax: you see it, learn it and it doesn't interact with anything. It is the easy part of learning the language. For example Go has curly braces too, and it is one of the fastest languages to get started with.

Maybe const functions are not visible immediately, but then as a beginner you would start looking at some documentation, and you'll see const there in API documentation and not understand it, so that makes the language look like it has these opaque features you do not understand. I'm not saying const functions are not worth the cost, I'm just saying that they do have a cost and add complexity in a way :: and curly braces do not.

Even today in the first rapid, there was a comment (from Svidler/Giri) that early on Caruana played a move too fast, as if he was already in blitz mode, when he should have thought a bit more and found a better move.

Even for classic time control, 15 minutes per move is too much; they get about 3 minutes per move on average: 120 minutes for the first 40 moves is quite common. In this championship, they each had 100 minutes + 30 seconds bonus/move for the first 40 moves, which adds up to 120 minutes if they reach move 40 anyway. Of course, some moves are played very fast and the players do take 15 minutes, or more, in some tricky situations where they have to make a key decision.

And also, Caruana would have had to trap his knight in a corner to get the win. To quote Kasparov:

The computer shows Black wins with 68..Bh4 here. But had Caruana played the incredible 69.Bd5 Ne2 70.Bf3 Ng1!! they would request metal detectors immediately! No human can willingly trap his own knight like that.

https://twitter.com/Kasparov63/status/1063576827850096640

At https://2700chess.com/ you can see the live rating with the effect of each game since the last periodic FIDE update. Expanding either Carlsen's or Caruana's rows will show you a list of the seven games since the last update, with a change of 0.0 next to each.

One problem is that although OpenCL can run on both CPU and GPU, OpenCL code that performs well on CPU and OpenCL code that performs well on GPU can be different.

Sometimes I would run to that guard and jump through him and finish the level very quickly. On a small but significant fraction of the times, his sword strike would miss so it was possible to skip him without luring/climbing. Since the success rate is low, this only makes sense for that guard, as losing to that guard has a low cost: you just restart the game.

I never interpreted "listen to your body" as "give in to all your body's whims", it's more like: if in your experience you feel better after doing X, then X is probably good for you.

Without context, that is not a helpful statement. For starters, a 60 day fast will lead to a very large loss of weight, so unless the faster is exceedingly above the ideal weight at the start, it sounds dangerous.

And when parallelization and vectorization come into play, iteration is a much better fit, at least in my intuition.

You're right, I confused the interchange formats with extended and extendable precisions. And the standard only recommends the extended and extendable precisions "for extending the precisions used for arithmetic beyond the basic formats", not for interchange.

The article uses "commercial" when it should really use "proprietary". The open source projects mentioned are all very much commercial software.