tspiteri

You are reducing the number of carries. The article explains it clearly. If you're not convinced by the article, I won't try to convince you. (Edit: the last thing I'll add: you are reducing the number of carries for 64-bit additions. When adding 13 51-bit numbers, that does not count as carries instruction-wise, as it's still add, not adc.)

I don't think so. If a core is busy, it's going to be consuming almost the same amount of power whether it's using one ALU or four. So the best strategy is to finish your processing as fast as possible so that you can idle, where the significant power saving happens. Basically, if the processing finishes faster, you save energy.

You're grouping carries. If you have 13 spare bits, you can accumulate 13 additions before you have to take care of carries. Then you have to add some overhead for bit manipulation, but the article's point is that the parallelism gains more than make up for the bit manipulation.

But the carry propagation blocks parallelism. So by reducing the need to carry, you are getting the parallel gains.

> Aside: Why 13 bits instead of 12? For our purposes, we’re going to ignore the carries in the most significant limb, allowing numbers to wrap when they overflow past 2^256 - 1 (just like how unsigned addition works in C with normal size integer types). As a result, we can assign 52 bits to the most significant limb and ignore the fact that it will run out of room for carries before the other limbs do.

If you're going to wrap, you could go all the way and assign 64 bits to the most significant limb; that way you save 12 bits which you can spread to the other four limbs. You can go from {52, 51, 51, 51, 51} to {64, 48, 48, 48, 48}, so you have a spare 16 bits instead of 13 bits.

Yeah, and then there are some jerks that think that by throwing a hissy fit in a meeting they're the next Steve Jobs. Well, they're not. Jerks.

They can be made to be convicted of perjury. If you have enough trials, you're going to be falsely convicted a few times.

One of those four features is dereferencing pointers, and unlike references, pointers are not checked by the borrow checker. So you could bypass the borrow checker using unsafe code in a way, though most probably you should not.

It would have been good to get a Dune 7, because the more the better of course. But if there was a Dune 7, it would not have closed all the ends; if something comes to a complete finish, it means it's dead. As long as life goes on, there are always new things.

And about the Brian-Herbert-and-Kevin-Anderson things; I once found a comment on them which I really liked: "Pass on them. As in pass waste. Defecate."

Book 1 is in a class of its own. Books 2 and 3 are a little slower than 1. Book 4 is very slower as you say.

Book 4 brings out the most different reactions: some people even prefer it to 1, some just find it too slow. If you don't like the beginning, I don't think you'll like the rest as it doesn't change its pace. Maybe the problem is reading it in quick succession after 1, 2 and 3. The first time I read it it was after a break from the other 3 and it turned out I now love it (though I still prefer 1). If you're finding it frustrating a third of the way through, I would recommend dropping it now. Then if you feel like it, maybe restart after some time, maybe then it would work, and maybe it wouldn't.

Then books 5 and 6 pick up the speed once more, I find them very fast paced.

Only if there was UB, and the point is that there probably isn't. (I'm not really knowledgeable on the C standard, so I might have misinterpreted something.)

That says used, not read. And indeterminate, not unspecified. My point was on reading a value, not on acting on the value. I know it looks like nit-picking, and you should just not read uninitialized memory, but I don't think it's consistent with the standard to say that reading uninitialized memory is always UB.

Your code is

    int x;
    if(x == 0) foo();
    if(x != 0) foo();

That is reading the uninitialized value twice. Since it is unspecified, it does not have to be consistent, so you could get the same behavior as non-zero for the first reading, and zero for the second reading. Changing your code to:

    int x;
    if(x == 0) foo();
    else foo();

will give different output (same if you use !=).

As far as I know (and I could be wrong), reading uninitialized memory in C is not UB, but gives an indeterminate value, which may be either an unspecified value or a trap representation. If it is a trap representation, accessing it is indeed UB, but if all possible values of your memory are valid, e.g. if you have an unpadded integer where every bit representation means something valid, then it is not UB, though it is still an unspecified value which does not even have to be consistent: you could get different values when reading the same uninitialized location twice.

Edit: Some excerpts from the C standard:

6.7.8 Initialization

10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate.

3.17.2 indeterminate value

either an unspecified value or a trap representation

3.17.3 unspecified value

valid value of the relevant type where this International Standard imposes no requirements on which value is chosen in any instance

6.2.6 Representation of types

6.2.6.1 General

5 Certain object representations need not represent a value of the object type. … Such a representation is called a trap representation.

2% of 2 billion is 40 million. So perhaps it was 2% of the whole population.

Or use the C-u 0 prefix to repeat till there is an error, possibly at the end of buffer. And if you don't want to go on to the end of the buffer, narrow to the required region (C-x n n) and widen afterwards (C-x n w).

The example won't compile because nickname is just a reference to the first three bytes of name, but then name is cleared, so nickname would be a bad reference. That are two ways to go around this:

1. Print the nickname before clearing the name so that nickname is still valid when you print it (swap lines 4 and 5).

2. Make nickname a copy of the first three bytes of name, rather then a reference to the first three bytes of name.

    let nickname = String::from(&name[..3]);

> What I know from personal experience is that poverty makes one care less about the future. And make stupid decisions like voting for the guy who gives out $1 bread, sprays money in the air and ends up stealing $10mil.

What do you mean by personal experience? That you were poor and made the named stupid decisions? Or that you know of poor people who made the named decisions?

The restrictions are so reasonable that even the GPL would allow supplementing similar terms (if I understand it correctly):

https://www.gnu.org/licenses/gpl-3.0.en.html#section7

Quoting the relevant bit:

Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:

…

c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or

…

e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or

…

Oh, by field I meant it as a field in a record, not an area of study. For example in some reports I had to check a box for unambiguous text but I had no check box for grammar or spelling. That's some ambiguous text from my part! :)

There's a difference between bad grammar/spelling and ambiguity; ambiguity is the worse issue. Some journals have fields in their review report where reviewers can say if the text is unambiguous, but no field about grammar or spelling in general.

If he wanted to switch to GPL, he wouldn't have to relicence all the code; just the code that is by him alone. The contributions by others are in a permissive license that is compatible with the GPL, so they could remain in their current state; but the whole project would contain GPL code so anyone redistributing the project would have to do abide with the terms of the GPL.

And the news here to me is that the Spanish contractor was caught spying. So while it can be argued that the US spying is no news story, the spying by the security company is.

Using that reasoning, there was no story when Klaus Fuchs was caught spying on the Manhattan Project for the Soviet Union: Of course the Soviet Union intelligence were spying on the Manhattan Project, if they weren't spying on it they'de be derelict in their most basic of duties.

It was 121 seconds faster than his own world record.

No, they cannot all be 9 bits, they have higher minimums.

https://en.wikipedia.org/wiki/C_data_types#Basic_types

> If you’re gripping a laptop in one hand, a thinner body is easier to hold.

Is it though? If you're trying to hold six closed laptops in the same hand, thinner might be better, but when holding one laptop in one hand, it's weight not thickness that matters.

How about "Forty-two"?

> Isn't horse racing gambling a ripe area for the Hong Kong protesters to disrupt?

That is a very bad idea. The protestors are already against one powerful actor. If they are against a second powerful actor, and something sinister happens to protestors, it will be easy to cast doubts on who did the sinister act.

Word of warning, the entire series of books should be considered the six books written by Frank Herbert, not any of the poor worse-than-fan-fiction by Brian Herbert + Kevin J Anderson.