Jeff Epler's blog

About me

I've been a computer programmer since I first started typing in program
listings on a Commodore Vic 20 when I was about 8. My hobbies include
electronics, CNC manufacturing, photography, beer and winemaking.

I live with my wife, cat, and lots of left-over parts from unfinished
projects in Lincoln, Nebraska, USA.

It remains unclear to me whether effective quantum computing -- which I think of as something that can implement algorithms like Grover's and Shor's -- is a mere matter of engineering, or whether it requires one or more scientific breakthroughs. So many companies doing public-facing research in the area act like it's the former, but authors like Mikhail Dyakonov who know much more than me act like it's the latter. The thing about scientific breakthroughs is that it's hard to put timelines on them; the hoped-for breakthrough might never come.

As bad as C/C++ can be, particularly for systems that have to be secure in the face of untrusted input, it's simply not financially possible for companies to transition their legacy systems to anything else. Take some random and unnamed commercial codebase for example -- while 'sloccount' isn't the Word of God, here's a big application that it says would cost just north of $100 million to write from scratch. But it also depends on any number of file format libraries; just one of them, sloccount reports, is $43 million in its own right. There are maybe 3 or 4 such libraries, and they're all in C++. And then there's the one that the company buys in binary-only form, so you're stuck into a single C++ ABI unless you fork over a 5- or 6-digit quantity of money for a fresh build with a different toolchain! You simply can't rewrite this in rust or other "safe" language, not even your core codebase. You also have to grow 5 or 6 people who are such domain experts that they can write, from scratch, file format libraries for formats where the (complicated × niche) product is huge. And again, whole 'sloccount' is not the word of god, it might say your schedule for just the two subtasks above is 10 years for a staff of 100, which already dwarfs your current development staff. May the address-space layout randomizer have mercy on us all.

The Gaia spacecraft is pretty amazing. Run a gigapixel camera, in space, for 5 years and somehow get the data on billions of stars home on a mere 3Mbit/s link. "only a few dozen pixels around each object can be downlinked". The in-space processing must be pretty sophisticated and high performance.

"[T]here’s the AI trained to identify toxic and edible mushrooms, which simply picked up on the fact that it was presented with the two types in alternating order. This ended up being an unreliable model in the real world."

I thoroughly disagree with the author's assertion of the equal epistemic(?) status of the two fields "date of birth" and "sex/gender" of a birth certificate. I am at home with a world where a 5-second or even 50-year investigation of the shape of a body can't accurately reveal this (once assumed to be objective and unchanging) characteristic. Just think of it like pronouncing a baby a habitual criminal based on the debunked science of phrenology! On the other hand, the truth of passing days and years seems just about as objective as anything; and find nothing particularly sinister in the way we codify it into a civil calendar which in turn enables legal contracts like "the term of the lease shall be 12 months from November 8, 2018". Hopefully we some day arrive in a world where even if there's some reason to write down quick notes on the shape of baby genitals (one weird trick for telling babies apart with ~P(0.5)!), nobody insists on printing anything about it on our everyday ID cards, or imagines it should inform our use of pronouns or whether we should prefer white wine or lite beer.

at a first guess I'm at or above that 321 hour average, based on 8000 yearly miles driving and 25mph average rate gives 320 hours, not including whatever I do in rental cars. On the other hand, we have made a choice to do driving vacations the last few years, racking up 1200 miles at a go; that driving at least brings much greater rewards than the drive to work! ETA: Average people get 120 hours of vacation?

Chris was kind enough to pass along to me a
commercial WWVB receiver.
This module was a bit of a pain to develop for, because most of the time the
interference from a nearby laptop computer is enough to seriously compromise
reception, and almost all of the time having a USB cable running from the
microcontroller to the laptop will kill reception outright.

A few weeks ago, I posted about a WWVB timecode
generator written in C. Unfortunately, this timecode generator did not
have a clear license permitting modification or redistribution, so I
felt I was unable to incorporate it into a project of my own.

Thus was born my own timecode generator, called wwvbpy. Its primary
output mode is compatible with the "wwvb2.c" that inspired it. It also
has a few features that wwvb2.c didn't: automatic handling of DST, DUT1,
and leap seconds. DST is handled according to the operating system's
rules for Denver. DUT1 and leap seconds are handled using data from
IERS (As a result, my program's DUT1 does not exactly match past
broadcast data on WWVB, as the data NIST broadcasts is "an average value
for an extended range of dates").

It also has a set of tests of interesting times, such as the first and
second days after a DST change, the last and last-but-one days of leap
and non-leap years, a historical leap second, etc. (where possible,
these test vectors were originally generated by wwvb2; however, some of
the tests—such as the DST tests—had to be hand-generated, as wwvb2
couldn't generate them; besides this limitation, I also uncovered a bug
in wwvb2 where non-leap years were treated as having 364 days and
leap-years were treated as having 365!)

An option to output the timecode data to a serial device is contemplated
but not finished; ultimately, this would work together with an
Arduino/AVR firmware to produce a logic-level and/or 60kHz modulated
version of the signal for testing hardware devices.