anon946

Sufficient if all else were equal. But the human brain and artificial neural networks are clearly not equal. This is setting aside the whole question of whether we hope to equal human performance or exceed it.

Isn't this a little bit of a category error? LLMs are not a language. But prompts to LLMs are written in a language, more or less a natural language such as English. Unfortunately, natural languages are not very precise and full of ambiguity. I suspect that different models would interpret wordings and phrases slightly differently, leading to behaviors in the resulting code that are difficult to predict.

The irony here is that universities are struggling to teach writing skills, due to massive cheating with AI.

Note that many universities still have DEI offices. I believe that they are interpreting as described here: https://www.governmentcontractorcomplianceupdate.com/2025/08.... So as long as they can show that they are not doing any of those, they seem to believe that they will be okay.

How are other kinds of engineers such as automotive engineers treated at companies like Ford, or aerospace engineers such as at Boeing?

I agree that the goals are worthwhile, and also feel that requiring every proposal to include this is not efficient and/or very effective. They should take all the funds and time spent on this every year as part of every award, and just fund programs specifically designed to attract inner-city kids to science, or funnel talented, low-income, high school students to be mentored, taught advanced classes, etc.

I would be happy to spend time mentoring URM, etc. But it'd work a lot better if others managed such a program, thought about how to attract them, etc. Specialization is good.

Add some extra information, and it gets confused. This is 4o.

https://chatgpt.com/share/67759723-f008-800e-b0f3-9c81e656d6...

One might argue that it's impossible to compress air using known engineering, but that would be a different kind of answer.

The bank is context that gives us a prior probability. However, MLE does not consider a prior. So MLE can give results that are not very helpful in the real world. All it does is answer: What parameter value (in case the probability) of a head, makes the observed outcome most likely? But it considers all parameter values equally likely. In reality, we know that it is highly likely that a random coin from a bank is a fair coin. Thus, if we flip two heads, we are almost certain that it's still a fair coin. If, on the other hand, we flipped 10 heads in a row, we might start to wonder if somehow the bank gave you a trick coin. MAP is an alternative to MLE, arguably better in many situations: [https://www.cs.cmu.edu/~aarti/Class/10701_Spring23/Lecs/Lect....

Yes, but then it is no longer MLE, but rather MAP: [https://www.cs.cmu.edu/~aarti/Class/10701_Spring23/Lecs/Lect....

My favorite MLE example: Suppose you walk into a bank and ask them to give you a quarter. You flip the quarter twice and get two heads. Given this experiment, what do you estimate to be the probability p of getting a heads when you flip this coin? Using MLE, you would get p = 1. In other words, this coin will always give you a heads when you flip it! (According to MLE.)

Only if you let the mistake go unmentioned. I do a version of this where I glibly include a mistake, like:

    // Examples of dereference operator.
    int i, *ip = ..., **ipp = ...;
    i = *ip; // Assuming ip has been correctly initialized.
    i = **ipp; // Likewise.
    // The address-of operator is the opposite.
    ip = &i;
    ipp = &&i;

I actually talk through the last line. Almost no one ever questions it. I then ask students to look at that last line again, and ask them if an address has an address, and if so, what does that mean, could it ever be useful?

Yes, used in the past. I don't currently use them, though I think they are cool mechanical marvels, especially IBM Selectrics. Those were way too expensive to own personally, but were common in offices. My personal typewriter was a much cheaper Smith Corona electric.

Oh, I personally don't currently use them. This was in the past, starting from playing around with my Dad's manual typewriter. Took typing course in 8th grade on a manual. Owned a Smith Corona electric in high school. Used IBM Selectrics for school newspaper, etc. I'm old. :-)

I have used multiple typewriters in my life, and agree. In addition, the look of film/tape vs cloth/nylon is very different, and tape ribbon can look very crisp: https://en.wikipedia.org/wiki/Ink_ribbon#Single-pass_(polyme....

Bemused (https://www.merriam-webster.com/grammar/can-bemuse-mean-amus...) is another word that is often understood "incorrectly".

Completely reasonable. I'd probably edit your blog post a bit to indicate that.

Did you add output of the results to the C code?

IMO, not using any optimization flags with C is somewhat arbitrary, since the compiler writers could have just decided that by default we'll do thing X, Y, and Z, and then you'd need to turn them off explicitly.

FWIW, without -O, with -O, and with -O4, I get 2500ms, 1500ms, and 550ms respectively. I didn't bother to look at the .S to see the code improvements. (Of course, I edited the code to output the results, otherwise, it just optimized out everything.)

For the discrete case, it seems that a better thing to do is consider the likelihood of getting that number of heads, rather than the likelihood of getting that exact sequence.

I am not sure how to handle the continuous case, however.

Is all UB silly? E.g., wouldn't fully defining what happens when one goes beyond the end of an array impose a non-trivial performance hit for at least some code?

Seems that ideally, there would be a standard based on viral inactivation/removal rate, rather than targeting specifically ACH. Companies and builders could then decide what combination of filtration, ventilation, and UV deactivation they will use to achieve this rate.

Seems to be more about holding chopsticks. But two ways to use chopsticks that might be less known:

Opening a bottle: https://www.youtube.com/watch?v=CPLrGfAbhnw

Also, I couldn't find a video, but at least in my Asian family, we will sometimes cut food like, say, an eggroll by using the chopsticks as a scissors.

Lastly, a chopsticks hack is that they are great way to eat food like buttered popcorn without getting your fingers greasy. :-)

If you use university resources, they almost certainly will have a claim to the IP. Best to just buy a personal laptop, and use only personal resources.

We have had a compiler elective before, but it was never required, and currently we don't offer it. I don't think there is a lot of demand from students for it, for better or worse. We also don't do networking fundamentals as a requirement, like sliding window protocol, CSMA/CD, how routing works, etc., but we do have an elective that I believe covers these things.

We do require architecture, and still even do Karnaugh maps. I do believe that every CS person should have a fundamental understanding of cache, instruction fetch, decode, MESI, etc., but probably don't need a semester's worth of architecture. If I had my druthers, I would consolidate a number of separate courses into maybe a 2-semester sequence that would basically be: "What every computer scientist should know", and basically cover the coolest and most seminal topics from different areas of CS.

I'm a professor at a R1 university in the CS dept. I wire-wrapped a PDP-8 in school as part of a CS degree, and thought it was super-interesting and fun, and part of me agrees with you.

But the reality is that you can only cram so much into a 4-year degree and wire-wrapping a 68000 seems like it would take many hours. I already feel like there is so much that we are leaving out. For example, our undergrads don't implement a compiler as part of their degree.

*EDIT: Also, it's arguably more computer engineering than computer science, but the my main point is that the undergrad CS curriculum is already super-crowded.

That's interesting and somewhat surprising. I'm not knowledgeable about battery design by any means, but I would have thought that there would be a better way to make a battery pack for a car than connecting thousands of small batteries together.

Kind of depends on what we mean when we use the word "Internet". If we mean internet as a social/economic revolution, then sure, BBSs were relevant. If we mean Internet as a set of protocols, software that implements them, and hardware to run them on, then I don't see that BBSs had a lot of relevance (though they used sliding window protocols for file transfer such as ZMODEM/YMODEM).

Agree. You could use the argument that argument against almost any teaching example. Like, when's the last time you ever needed to integrate x from 0 to 1? I've never needed to do that. Or when is the last time you needed to know how long a 1 kg ball will take to fall from 1 m? At least in my opinion, the way the author thinks recursion should be taught seems to needlessly complicate it.

That seems unlikely to happen in the near to medium term. For that to happen, everything would have to be rewritten using a quantum algorithm and language, and run on quantum hardware. Imagine writing a web browser in a quantum language, within a quantum computing software ecosystem. It's hard to see how that would have any benefit.

If you are talking 100 years out, though, who knows?

For languages like C, C++, and Rust, the bottleneck is going to mainly be system calls. With a big buffer, on an old machine, I get about 1.5 GiB/s with C++. Writing 1 char at a time, I get less than 1 MiB/s.

    $ ./a.out 1000000 2000 | cat >/dev/null
    buffer size: 1000000, num syscalls: 2000, perf:1578.779593 MiB/s
    $ ./a.out 1 2000000 | cat >/dev/null
    buffer size: 1, num syscalls: 2000000, perf:0.832587 MiB/s

Code is:

    #include <cstddef>
    #include <random>
    #include <chrono>
    #include <cassert>
    #include <array>
    #include <cstdio>
    #include <unistd.h>
    #include <cstring>
    #include <cstdlib>

    int main(int argc, char **argv) {

        int rv;

        assert(argc == 3);
        const unsigned int n = std::atoi(argv[1]);
        char *buf = new char[n];
        std::memset(buf, '1', n);

        const unsigned int k = std::atoi(argv[2]);

        auto start = std::chrono::high_resolution_clock::now();
        for (size_t i = 0; i < k; i++) {
            rv = write(1, buf, n);
            assert(rv == int(n));
        }
        auto stop = std::chrono::high_resolution_clock::now();

        auto duration = stop - start;
        std::chrono::duration<double> secs = duration;

        std::fprintf(stderr, "buffer size: %d, num syscalls: %d, perf:%f MiB/s\n", n, k, (double(n)*k)/(1024*1024)/secs.count());
    }

EDIT: Also note that a big write to a pipe (bigger than PIPE_BUF) may require multiple syscalls on the read side.

EDIT 2: Also, it appears that the kernel is smart enough to not copy anything when it's clear that there is no need. When I don't go through cat, I get rates that are well above memory bandwidth, implying that it's not doing any actual work:

    $ ./a.out 1000000 1000 >/dev/null
    buffer size: 1000000, num syscalls: 1000, perf: 1827368.373827 MiB/s