chrchang523

This is, of course, known as the Anthropic Principle…

and you CAN use static_cast to convert from void*; this silently keeps working if you refactor the void* into a matching-type pointer later, while raising a compilation error if you refactor to a different-type pointer.

Other things worth noting about denormal numbers:

- It’s not just ‘old’ FPUs that handle them verrry slowly. Benchmark this aspect of your target processors if this detail matters.

- Most modern processors provide a “flush to zero” denormal handling mode (and sometimes you can separately specify “denormals are zero”, relevant when e.g. loading old data). However, math libraries usually haven’t been written with this mode in mind, so you need to be careful with this.

Note that BGZF solves gzip’s speed problem (libdeflate + parallel compression/decompression) without breaking compatibility, and usually the hit to compression ratio is tolerable.

Yes, though I think tooling could be better; if I had more spare time I'd write a linter which flagged defers in loops that didn't come with an accompanying comment.

The problem with cgo is the high function-call overhead; you only want to use it for fairly big chunks of work. Calling an assembly function from Go is a lot cheaper.

https://pkg.go.dev/github.com/grailbio/base/simd has some work I’ve done in this vein.

I found it useful to walk through evaluation of a few elementary instances of this class using simpler methods, to put the main result in perspective. Specifically, replace the initial 3 exponent with 0 or 1.

If the exponent is 0, then you have the sum 1/2 + 1/4 + 1/8 + 1/16 + 1/32 + ..., from Zeno's most famous paradox (https://en.wikipedia.org/wiki/Zeno%27s_paradoxes ). If you are fortunate, you previously learned that this converges to 1, and played around with this enough in your head to have a solid understanding of why. If you are less fortunate, I recommend pausing to digest this result.

Then, if the exponent is 1, you have the sum 1/2 + 2/4 + 3/8 + 4/16 + 5/32 + ... .

What happens if we subtract (1/2 + 1/4 + 1/8 + 1/16 + 1/32 + ...) from it? We have (1/4 + 2/8 + 3/16 + 4/32 + ...) left over.

Then, if we subtract (1/4 + 1/8 + 1/16 + 1/32 + ...) from the latter, we still have (1/8 + 2/16 + 3/32 + ...) left over.

Then, if we subtract (1/8 + 1/16 + 1/32 + ...) from the latter, we still have (1/16 + 2/32 + ...) left over.

Continuing in this fashion, we end up subtracting off

(1/2 + 1/4 + 1/8 + 1/16 + 1/32 + ...) + (1/4 + 1/8 + 1/16 + 1/32 + ...) + (1/8 + 1/16 + 1/32 + ...) + (1/16 + 1/32 + ...) + (1/32 + ...) + ...

and this converges to the main sum. And, from the exponent-0 result, we know this is just 1 + 1/2 + 1/4 + 1/8 + 1/16 + ...

Two-bit values are common in bioinformatics, and I’ve found the ability to efficiently convert between packed arrays of 1- and 2-bit values to be valuable in that domain.

One question: it is possible for the XOR of two consecutive floating-point numbers to have 32-63 leading zeros; the numbers 32-63 do not fit in 5 bits. I imagine this is treated by Gorilla like 31 leading zeros?

(2008)

The mod 1000 is actually a consequence of the test format: all answers are integers in [0, 999], you fill in 3 digit-bubbles.

Suppose the value of a network to an individual user is proportional to the number of users. Then the total value of the network, summed across all its users, is proportional to the square of the number of users.

See also https://en.wikipedia.org/wiki/Network_effect .

Yup, and that's why I'd consider this a "101" essay. The larger exponential-growth trends (e.g. Moore's Law) practically always have a microstructure with many sigmoid curves. After you've encountered your first exponential, the "201" lesson about saturation becomes important.

The slave-owners were slave-owners because they had military control over the slaves. (Most of the time, anyway; some slave revolts were successful.)

It is not clear how long humans will retain control over AIs.

Yup. This 24-year-old game was so culturally significant in the Eastern Bloc that there was a piano concert in Warsaw dedicated to it last month: https://gmfest.com/2023/06/19/paul-anthony-romero-heroes-pia...

No, the idea is that you manually make some allocations downward from the top and some allocations upward from the bottom. The bumping code is as simple as in the unidirectional case.

The tricky part is choosing in a way that puts you noticeably ahead of the unidirectional allocator re: what problems you can solve, without putting excessive mental load on yourself. I've found a pattern of "long-lived allocations on one end, short-lived allocations on the other" to work well here (which, yes, doesn't always coincide with the numerous vs. infrequent axis mentioned in my previous comment).

Incidentally, you can choose to bump in both directions. It's more complicated (you need to keep track of which end you allocated each data structure on), but in exchange, the allocator becomes sufficient for many more use cases.

Given a choice, the OP implies that you should position small-but-numerous allocations next to the top, and larger infrequent allocations next to the bottom.

I recently started running HOMM3 HD on my Mac with Porting Kit, which has been working great: https://www.portingkit.com/game/236 .

Sure, but there isn't even an offhand remark about how hacky this kind of polling is. It's presented as if it's a completely normal way to do things in reliable software.

Agree, I'm shocked at how ugly the recommended alternative is. This does not make MS look good.

Raymond Chen has been providing an inside perspective on this for decades: https://devblogs.microsoft.com/oldnewthing/

(2015)

The possibilities you mention are definitely worth keeping in mind. However, they are not an exhaustive list; there are positive scenarios that are better than "trying to squeeze a few more dollars by telling the tale".

The hard part is recognizing them in the midst of a lot of chaff.

Do you? I don’t like it, but the government is allowed to pay off the debt with inflated dollars.

Rare virtue, but I wouldn’t say it was unprecedented: https://en.m.wikipedia.org/wiki/Lucius_Quinctius_Cincinnatus

There are games where the final score is primarily based on taking as little time as possible (e.g. the Heroes of Might and Magic series, which had its debut around the same time as Diablo); this tends to keep exponential leveling mechanics in check.

An important catch here is that he was eight years too early, not two. See https://news.ycombinator.com/item?id=33538742 .

I don’t know how long this will last, but I started doing this recently with Vanguard’s VUSXX (short-term Treasury) fund when I realized it had significantly higher after-tax yield than high-interest savings accounts without the hassle of manually rolling over T-bills, and it looks like many other people have been moving in this direction.

This does depend a bit on the calculator. embedded_hiker's anecdote has made me update in the direction of exposing my daughter to Wolfram Alpha before Python...

+1. I recently gave an internal presentation encouraging everyone on my (rather heterogeneous) team to look at that.