https://glizen.com/radfordneal/ftp/xsum.pdf

As someone that has used module systems from dojo to CommonsJS to AMD to ESM with webpack and esbuild and rollup and a few others thrown in ... this statement hits hard.

An emulator can operate on many different levels of trying to match the behavior of the underlying hardware. CPU emulators can emulate at the opcode level (easier) or try to increase accuracy by emulating the CPU pipeline cycle by cycle (harder).

In this particular case, the distinction between an "emulator" and a "hardware emulator" seem apt because the article discusses that the required fixes needed to start tracking the state of individual pins of the hardware chips. This, to me, represents that the emulation needed to "go down another level" and model the physical hardware to a certain degree to gain the needed accuracy.

Having a way to mark that difference is useful.

  The states decided to add one digit to these numbers to further subdivide
  them. They did it differently, of course, and some didn't subdivide at all.
  Some of them have typos with "O" in place of "0" in a few places. Some
  states dropped the leading zeroes, and then added a suffix digit, which is fun.

In my own work I see this all the time with FIPS codes and parcel identifiers -- mostly because someone has round-tripped their data through Excel which will autocast the identifiers to numeric types.

Federal GEOIDs are particularly tough because the number of digits defines the GEOID type and there are valid types for 10, 11 and 12-digit numbers, so dropping a leading zero wreaks havoc on any automated processing.

There's a lot of ways to create the garbage in GIGO.

[1] https://retrocomputing.stackexchange.com/a/2541/3653

At the time I was doing a lot of simulation work, so methods for bridging discrete and continuous domains were interesting.

https://github.com/duckythescientist/SmoothLife

Ended up going with playwright for the “batteries included” browser support and because we use .Net Core for the backend.

dotnet doesn’t always get the best support from pure JS/TS projects, so it seemed like a reasonable hedge.

As a side-effect of the precision needed to spatially locate the mosquitoes, they could detect different wing beat frequencies that allowed target discrimination by sex and species.

A couple of pull-quotes from the paper to summarize:

Much work has been done on trying to improve the accuracy of summation. Some methods aim to somewhat improve accuracy at little computational cost, but do not guarantee that the result is the correctly rounded exact sum.

Many methods have been developed that instead compute the exact sum of a set of floating-point values, and then correctly round this exact sum to the closest floating-point value. This obviously would be preferable to any non-exact method, if the exact computation could be done sufficiently quickly

Exact summation methods fall into two classes — those implemented using standard floating point arithmetic operations available in hardware on most current processors, such as the methods of Zhu and Hayes (2010), and those that instead perform the summation with integer arithmetic, using a “superaccumulator”.

I present two new methods for exactly summing a set of floating-point numbers, and then correctly rounding to the nearest floating-point number. ... One method uses a “small” superaccumulator with sixty-seven 64-bit chunks, each with 32-bit overlap with the next chunk, allowing carry propagation to be done infrequently. The small superaccumulator is used alone when summing a small number of terms. For big summations, a “large” superaccumulator is used as well. It consists of 4096 64-bit chunks, one for every possible combination of exponent bits and sign bit, plus counts of when each chunk needs to be transferred to the small superaccumulator.

On modern 64-bit processors, exactly summing a large array using this combination of large and small superaccumulators takes less than twice the time of simple, inexact, ordered summation, with a serial implementation

The naïve way of adding numbers one-by-one in a loop is an obvious way, but there are more sophisticated methods that give better bounds of the total accumulated error; Kahan summation[1] being one of the better-known ones.

Like most things, it can get complicated depending on the specific context. For streaming data, adding numbers one at a time may be the only option. But what if one could use a fixed-size buffer of N numbers? When a new number arrives what should be done? Take a partial sum of some subset of the N numbers in the buffer and add that to a cumulative total? If a subset if chosen, how? Are there provable (improved) error bounds for the subset selection method?

Fun stuff.

[1] https://en.wikipedia.org/wiki/Kahan_summation_algorithm

Wisconsin stands out at 25.29% of the population labeled as excessive drinkers due to the large amount of dark red, but South Dakota is at 22.43% -- less than 3% difference, but that state is mostly orange.

For a county example, Hardin, TX is 19.13% and Rusk, WI is 20.82%. A difference of just under 1.7%, but the Wisconsin county is bright red and the Texas county is orange.

Let's use some hot tools to solve a problem. Sorta solve a problem. Well, AI doesn't actually know abstract strategy, so maybe it'll work later with a different AI. But it autogenerated some basic logic that only had a few bugs!

[1] https://ravimohan.blogspot.com/2007/04/learning-from-sudoku-...

Yes, Emergency SOS. This was the feature that allowed a family to be located and rescued recently during the Hawaii fires.

https://www.macworld.com/article/2027967/iphone-14-emergency...

https://dialup.cafe/@vga256/110609250159276517

The motivation follows from the same problem the author points out in the original softmax formulation that it always "forces a choice" when it may be more useful to put a "Not Applicable" option into the model itself.

https://link.springer.com/article/10.1007/s10260-021-00578-2

Instead, they were the ones buying the MBSs and taking on the long-duration risk.

https://github.com/Esri/calcite-components

One of the only legit use cases for mocks that I have personally come across is validating things like a sequence of API calls to an external service, or queries to a database where there is a check that certain efficiencies are guaranteed, e.g. verify that an N+1 select problem doesn’t creep in, or knowing that a app-level caching layer will prevent redundant API calls.