Basically, hash all your data items, keep track of the maximum number of leading 0 bits seen in a hash so far.
This is a decent proxy (but not without error) for how many distinct items you've seen so far since large numbers of leading zeros should be uncommon. Finding this means you probably saw a lot of other things to get to that point (intuitively, about N leading zeroes are expected after seeing 2^N items).
This is actually the same thing that a proof of work cryptocurrency does to control difficulty: change target number of leading zeros so miners have to do more/less work to find a match.
Of course, you could get "lucky" with a single counter and the resolution isn't great, so HLL first separates the values into buckets which are estimated separately and then combined to give a more robust estimate.
You might also try maximum instead of average. This is minimax and represents worst case scenarios for each guess.
This is mostly useful for optimal play against an opponent (which is not the case here). Imagine an adversarial version where the opponent doesn't have to commit to a word at the beginning but must reveal one matching all clues if you can't get it in 6 guesses (basically, they can change their word when you guess and you are trying to make that impossible).
You can get something somewhat similar with "always create merge commit" workflows (no fast forward) and changing your tooling to look at the first-parent-history by default. This view will have one commit per merge, but you can choose to follow the second+ parent history for a given commit to see what went into it.
Or just include a group name in the commit message. No need for empty merge requests in your history. Since most people use issue tracking systems, just prepend the issue number to each commit message in the group.
Due to the Leidenfrost effect, incidental contact of bare skin and LN2 is not usually a problem (it boils off locally and creates a gaseous N2 barrier). Other things superchilled by it will not be as forgiving, however.
Of course, even your example units don't always behave like you want. For velocities, 150 megameters/second + 150 megameters/second ≈ 240 megameters/second.
Sorry, can you explain why the velocities should add that way? I've always just seen velocities add like regular old vectors, so this looks very strange.
If you haven't seen Knuth's Dancing Links implementation of Algorithm X, I highly recommend it. It's based on the observation that updating a doubly-linked list in-place preserves enough information to make backtracking easy.
This make me want to dig up a version I did in Python (for Sudoku as it happens.) The algorithm is a bad fit for Python because attributes are not pointers, but have a look at this:
I feel like I may be missing something in comprehending that first up mathematical definition in the Exact cover wiki. How is it different from a partition of a set? (https://en.wikipedia.org/wiki/Partition_of_a_set).
UPDATE: think I may see it, sounds like in terms of partitions an exact cover is a subset of a set's partition.
If the extra initial scrutiny is perceived to streamline the process and avoid further hassles, many will hand it over without giving it a second thought.
For example, many people have voluntarily submitted fingerprints in order to enroll in TSA's PreCheck.
That's a very good example, but on the other hand fingerprints aren't likely to accidentally "incriminate" you.
Coming into the USA, if I saw that on a form my first instinct would be that not providing it reduces the risk of accidentally getting flagged for something ridiculous. I'd hate to be pulled aside for extra screening because a tweet from 6 years ago included the word 'explosion' in it.
ln -s HEAD .git/head