lscharen

no profile record

comments

22 dni temudiscuss

> 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.

w zeszłym miesiącudiscuss

I’ve used Claude to help write development utilities to support my retro computing interests.

The most complete tool being this unit testing support library for Apple IIgs assembly language development.

https://www.npmjs.com/package/iigs-unit

2 miesiące temudiscuss

An interesting property of DAWGs is that the compact/compressed variation (CDAWG) can be built in linear time.

https://moodle2.units.it/pluginfile.php/718375/mod_resource/...

2 miesiące temudiscuss

I was halfway through the article and began thinking that his described data structure sounded very familiar to something I used about 20 years ago.

Sure enough, the first paragraph on the Wikipedia entry for DAFSA is:

DAFSA is the rediscovery of a data structure called Directed Acyclic Word Graph (DAWG)

5 miesięcy temudiscuss

An aside, but I recently learned -- if one is willing to use a very modest amount of memory -- summing floating-point numbers with no loss of precision is effectively a solved problem with the XSUM algorithm.

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

w zeszłym rokudiscuss

> 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.

w zeszłym rokudiscuss

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.

w zeszłym rokudiscuss

  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.

w zeszłym rokudiscuss

There are 8 screen hole bytes in the bottom 8 text rows (64 bytes total) and 8 expansions slots, so the screen hole byte at offset "N" was often used to store up to 8 bytes of data[1] (one byte in each of the rows' screen hole area) by the expansion card's firmware in Slot "N". Overwriting those bytes could result in system crashes and hardware hangs.

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

w zeszłym rokudiscuss

I thought that SmoothLife was fascinating when I found it.

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

2 lata temudiscuss

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.

2 lata temudiscuss

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.

2 lata temudiscuss

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

2 lata temudiscuss

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

2 lata temudiscuss

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.

2 lata temudiscuss

This is giving strong "Using TDD to build a Sudoku solver" vibes[1].

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-...

4 lata temudiscuss

CDAWGs. Compressed Directed Acyclic Word Graphs.

They are like tries but share prefixes and suffixes of a word corpus, can be built in linear time, and since they are graphs, one can define an inner product between two CDAWGs and use them for kernel-based machine learning algorithms.

https://hal-upec-upem.archives-ouvertes.fr/hal-00620006/docu...