Anon_troll

An alternative wording for the same idea:

If you are at picture 1, you have 100% chance of selecting it as the current winner.

If you are at picture 2, you have 1/2 chance of selecting it as the current winner, or 1/2 chance of keeping the previous fairly selected winner.

At picture 3, 1/3 chance of picking it, or 2/3 chance of retaining the previous fairly-selected winner. There are two of them, so 1/3 chance of each.

At picture n, you have a 1/n chance of picking it, or an (n-1)/n chance of retaining the previous fairly-selected winner. There are n-1 previous pictures, so all of them have had 1/n chance of being picked.

At every single step, there is the invariant of all pictures being considered that far having had an equal chance of being selected, and the next step always retains the invariant.

The len(pics) can be O(n), especially if iterators are used like here. Also, an O(1) lookup would require a previous O(n) pass over the data anyway.

The picture selection algorithm's kind of single-pass iterator usage might have been more performant back in the XP days, as it avoids possibly expensive operations.

Modern CPU/other optimizations might make a multi-pass approach more performant due to better memory locality or other factors.

It's a shame the campaign of RA3 was boring. They got the theme and cutscenes right, but the campaign missions were rather slow, generic and forgettable.

It's the opposite of C&C3, which had a good campaign but the theme was a step back from the scifi of Tiberian Sun. Especially the GDI/NOD units were way less futuristic, and the alien ones were a bit too similar to each other in style. The cutscenes were also mostly boring compared to earlier games.

If I recall correctly, the expansion pack for C&C3 was much more interesting in these aspects, but the gameplay suffered.

The hash-based algorithm is only O(n) because the entry size has a limit. In a more general case, it would be something more like O(m(n * e)). Here n is the number of entries, e is the maximum entry size and m is a function describing how caching and other details affect the computation. With small enough data, the hash is very fast due to CPU caches, even if it takes more steps, as the time taken by a step is smaller. The article explains this topic in a less handwavey manner.

Also, memory access is constant time only to some upper limit allowed by the hardware, which requires significant changes to the implementation when the data does not fit the system memory. So, the hash algorithm will not stay O(n) once you go past the available memory.

The sorting algorithms do not suffer from these complexities quite as much, and similar approaches can be used with data sets that do not fit a single system's memory. The sorting-based algorithms will likely win in the galactically large cases.

Edit: Also, once the hash table would need to grow beyond what the hash function can describe (e.g. beyond 64 bit integers), you need to grow the function's data type. This is essentially a hidden log(n) factor, as the required length of the data type is log(n) of the maximum data size.

I encountered similar trouble with both Firefox and Chrome on Ubuntu.

Based on a quick Firefox performance report on the minified source code, most of the time seems to be spent in functionality looking like frame handling. There are some signs of time calculations.

One educated guess would be that something in frame time calculations goes off, possibly due to restricted time resolution to prevent timing related fingerprinting. This would cause next frame computation to start immediately instead of after the intended timeout.

Extracting text from DOCX is easy. Anything related to layout is non-trivial and extremely brittle.

To get the layout correct, you need to reverse engineer details down to Word's numerical accuracy so that content appears at the correct position in more complex cases. People like creating brittle documents where a pixel of difference can break the layout and cause content to misalign and appear on separate pages.

This will be a major problem for cases like the text saying "look at the above picture" but the picture was not anchored properly and floated to the next page due to rendering differences compared to a specific version of Word.

The comb walls are basically like chewing gum. It does not have much taste.

This sounds like https://bash-org-archive.com/?5273 (original website no longer exists).

One major problem here is the mixup of UX and technical implementation details. From UX point of view, the link example goes nowhere, it just opens a dialog. From that point of view it the fact it uses anchors to do so is not really relevant.

From purely technical point of view, the question would be rather irrelevant as the distinction between a button and link is mostly how a human perceives it, it does not matter for the program.

This is likely an explanation for the awkwardness that the author mentions feeling of this implementation, and is supported by it not making sense to open this kind of a "link" in a new tab (because it does not go anywhere).

> A more reasonable question would be, how many partially completed sudoku grids are there which have a unique solution. We don't know the answer to that.

If you interpret "unique" to mean that two puzzles that lead to the same solution count as one, the answer would be equal to the number of completed grids. Just remove one number and you get a partially completed grid, and there cannot be more.

The interpretation you mean is probably how many partially completed sudoku grids have only a single solution instead of multiple, which leads to a much more interesting question.

I don't think Firefox and Chrome run extensions/plugins in private windows without you first allowing them to run. That might be the case here.

The whitespace and formatting are not significant to the compiler, but they can provide a lot of information to the reader of the code.

You can often see where the writer put the most effort and thought by just seeing how they wrote it. This can help analyzing a codebase considerably.

If everything is normalized, you lose those valuable cues.

> Minecraft does doors right in comparably simple way, and I think few if any players have a problem with it

See https://bugs.mojang.com/browse/MC-149060 "Villagers "spam" doors by opening and closing them really fast"

Or https://bugs.mojang.com/browse/MC-69281?jql=text%20~%20%22do... to see the 6000+ bug reports related to doors.

Or watch https://www.youtube.com/watch?v=aiEq0bJcAz0 "Villager door spam"

  # Linux hard mode
  set -e

The tab completion integration is especially nice.