HN user

lscharen

521 karma
Posts3
Comments136
View on HN

If you ask permission for spending, it's a very onerous and frustrating process. If you just deploy stuff and get billed for it, it's much easier!

This point is underappreciated as it appears in many forms and can really help reconcile things that seems obviously wasteful (they may actually be wasteful, but sometimes financial structure makes this hard to determine in an honest capacity).

Capital costs and operational costs are a similar dichotomy. When I was in graduate school, the university was breaking ground on new buildings at the same time that staff layoffs were underway. On its face this seems grossly unreasonable, but staff salaries were paid from one funding bucket and capital improvements (new buildings) were funded by a completely independent state-level allocation process and those buildings that were breaking ground had essentially been locked in 5 to 10 years prior.

Notice I have changed the extension from .js to .mjs. Don’t worry, either extension can be used. And you are going to run into issues with either choice

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.

I can see the point of trying to make a distinction, but it is muddy.

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.
Any identifier that is comprised of digits but is not a number will have a hilariously large amount of mistakes and alterations like you describe.

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.

Vitest vs. Jest 2 years ago

I just recently did a website conversion that used vite and took a look at both vitest and playwright.

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.

Reminds me of Intellectual Venture's Optical Fence developed to track and kill mosquitoes with short laser pulses.

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.

I was not aware of this (2015) work -- very nice!

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

Surprisingly there are different algorithms for doing something as simple as summing up a list of numbers.

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

Agreed, the differences aren't as stark as the map seems. Almost all of the states fall between 15% and 25% percent of the population.

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.

This is similar the the (old) trick of adding a Uniform distribution component to a Mixture of Gaussians model. It doesn't really change the math wrt parameter optimization and probability evaluation, but provides a place to capture "background" or "unimportant" data points and improve the model robustness to outliers.

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

If SVB were originating mortgages then, yes, that should have helped because then, like every other originator, they would have immediately sold the mortgage into the secondary market where it would be turned into a Mortgage-Backed Security and SVB would have cash on-hand and unloaded the long-duration risk.

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

That’s a great point. Seeing lots of mocks and assertions that certain functions are called is often much ado about nothing since no actual code functionality is exercised. I do sometimes see the return value functionality of mocks used as a stub, just because the dev hasn’t internalized the distinction and can “make it work” with a mocking library.

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.

I think even more so than “If I can put things eloquently enough, perhaps they'll understand why I did what I did.", it can be motivated as “I don’t think I’m a bad person and I didn’t intend to cause harm; if people are still mad at me, it must be because they don’t understand and I should explain harder.”

We replaced a 25+ year-old propane furnace with a high-efficiency natural gas furnace two years ago. The difference in waste heat is astonishing.

The old furnace vented through a vertical chimney vent and the exhaust was so hot that touching the metal pipe would burn your hand.

The new furnace is direct vented with PVC pipes and the exhaust outside the house feels barely warm — that’s a lot of additional heat that stays in the house instead of being wasted.

Between the cost difference of propane vs natural gas, better efficiency and a programmable thermostat, we easily reduced our fuel bill $$ by 50% with no noticeable change in comfort level. I did not track the difference in therms.

For more 16-bit 65816 context -- other than for space-savings, these instructions are never used when performance is needed due to the low effective throughput of 7 cycles per byte. A basic unrolled loop using 16-bit instructions is 20 - 30% faster and specialized graphics routines that are able to use the stack can approach 3 cycles per byte using the PEA and PEI instructions.

Having done plenty of interviews, it's surprising how many candidates list every technology they may have touched for the briefest of moments. For me, "grilling" someone on something like a programming language is about determining if they've _really_ used it or not.

If a candidate lists multiple languages on their resume, I'll often ask them to do a compare and contrast -- what do they think are the strengths and weaknesses of the languages? What did you use language X for? Do you think language Y would have been better/worse/same to attack the same problem?

I'm not looking to trip them up, just find out if their resume is an accurate reflection of their experience.