RossBencina

Would like to hear more about the performance characteristics. Do you perfect hash to a contiguous range and then use a jump table, or do you perfect hash directly to relative offsets to basic blocks?

But misspelled Plücker coordinates in the abstract.

You could try a search over network switching research, e.g. some consider ADHD a problem with switching between (or concurrent activation of) default mode network and task-focused network. Not sure how many other networks have been identified.

You have been able to return a struct by value in C since at least C89:

    typedef struct {
        double d;
        int err;
    } Ret;

    Ret foo(void) {
        Ret r = { 0.0, 43};
        return r;
    }

    int main() {
        Ret r = foo();
    }

You can't return a bare fixed-size array though.

It's a niche use, but if backlit screens trigger migraines (as they do for mine), then high-speed e-ink is almost a pre-requisite for using traditional interactive UI. At ~15fps typing is OK but using a mouse cursor sucks. Outdoor use is a bonus. RLCD is another option.

I think the standard drivers take temperature into account.

Awesome work. I wonder whether the four grey-level calibration could have been fully automated rather than keeping human in the loop.

Here's my technically grounded response:

As far as I understand, inspecting the compiled binaries in any way would violate clean-room principles. At a minimum you'd need (A) one set of agents documenting the behavior of the executing binaries, e.g. manipulating the UI, and reviewing documentation and training manuals, and (B) a second set of agents whose only input is the output of the first set of agents. I'm not sure whether testing the real and AI generated agent side by side with equivalent inputs would constitute clean-room, although it might be legal.

I agree that a large part of the value of a product stems from "thousands of tiny design, engineering, and product decisions." But I don't agree with your conclusion. If the goal is to replicate the behavior of an existing piece of software then all you need to do is observe the behavior and replicate it. You don't need to engineer it in the same way, or arrive at it by making the same engineering and design decisions. Of-course in the end all you have is the replica, not the engineering and design heritage, product management, or the teams to carry the work forward. But that is the same problem open source "clones" of commercial products have often suffered from.

> most devs don't want to do formal verified system development.

That may be true. Serious question though: even if most devs wanted to develop formally verified code, do you think that it is reasonable to suggest that the typical systems developer could do it with today's tools? I don't mean verified protocols (TLA+) or verified algorithms (SPIN) I mean end-to-end verified code, a-la seL4. I got the impression that this is still very specialised work. Perhaps things have advanced since I last checked.

Numerical Recipes in C does that.

As far as I know Aaron never distributed that which was collected in the MIT data closet.

The first thing to note is that papers vary wildly in terms of their information density and in terms of their accessibility and relevance to you as a reader. I can easily imagine reading some papers many times because I really want to understand all the details.

That said, the depth that I read at mostly depends on why I am reading something. Most papers I don't read in depth, but whether I initially only read the abstract or skim the whole paper depends a lot on a lot of factors (paper content, length, ease of access to full text, whether I am triaging a lot of papers at once, how interested I am in the specific paper (usually based on the title and/or authors, maybe the abstract), etc.).

I read in multiple passes of increasing depth. Zeroth reading is more-or-less triage: is the paper worth reading at all? First reading would generally be start-to-finish. I underline and/or mark up the margins with particularly interesting/important sections and also star key references based on the author's commentary.

If it's an algorithm or math-heavy paper either I only care about the gist and I don't go deeper, or I dig in with further readings and study to properly understand the details. That could be relatively quick, or it could be a whole rabbit hole if I need to learn some background. Sometimes it takes a while for the importance of a paper to dawn on me, in which case I come back later and read in more depth.

With the references I generally only follow those with relevance to my research goals. For example the authors might have detailed a technique in an earlier paper, or they might have cited other relevant work that I was not aware of.

An abstract and an introduction are two different things. For me, as a reader, the main role of the abstract is to help me to decide whether to even look at the rest of the paper, let alone read it. I want to know what is in the paper that I will not find in other papers that are competing for my time. Everything should be very clear: the context, the main research contributions and/or findings, novel aspects of the approach, limitations; plus any other information that in the author's view should motivate me to read the paper. Then if I do read the paper, there should not be any surprises: the content that the abstract promised should be present and, ideally, all of the valuable content in the paper should have been advertised in the abstract.

Different fields use different standard forms or styles for abstracts. If you have not already done so you can get a feel for this by looking at a random sample of the top 100 most-cited papers in your field (or your target conferences, journals, arxiv categories) and quickly compare to top 100 in a couple of disparate fields (e.g. biochemistry, economics, anthropology, mathematics).

Of course, there are good reasons to read a paper besides the quality and content of the abstract. Consequently, there are well known papers with non-standard abstracts. I recommend mastering the basics first.