anyfoo

Yeah, but that still doesn’t mean there aren’t theoretical bugs. Testing every input would effectively mean testing every stimulus, which is combinatorially impossible. You might still have subtle timing bugs, bugs with very uncommon instruction sequences etc.

But my point was exactly that the (extremely vastly) smaller subset of tests that you performed is more than enough to proclaim a CPU to be “working”.

Do you test every possible input/output combination on any CPU?

No, because that would be impossible.

You perform a series of more specific tests. In this case, it's "working" in so far as that Super Mario Bros. appears to be playable, for example.

Does not mean that it behaves perfectly according to some spec, or identical to another CPU (like the NES's 6502), of course, but it's clearly a working CPU to some 6502-compatible extent.

This moving of goal posts whenever correctness through type systems is being discussed is a bit tiresome, because it quickly leads to such ad absurdum corner cases.

Yes, you are all correct. The compiler may have a bug. And if it does net, then the type system may have a problem. And if it is formally verified, then the theorem prover might have issues. And if it does not, then the very math it relies on may be wrong.

But what do we contrast this to, what is the alternative to correctness through the type system? Almost every time, when it isn't "nothing", it's "tests". We rely on tests to test whether the program behaves correctly.

And as we all know, quite in contrast to type systems and their checkers, tests are always error-free, complete, and sensible?

Did you give him the ability?

That's for the FM baseband signal, not the audio. Among other things you're doing here, you're basically treating a stereo signal (plus a pilot that effectively contains no information, plus an extremely low bitrate RDS stream in an extremely inefficient way) as one monaural signal.

But maybe there's a use case for replacing an AES192 signal carrying the full FM baseband signal over ETH-67? I'm not sure it's the correct fit, though.

No, I'm not misunderstanding, and you are pushing goalposts. The majority of programs above a certain size would benefit tremendously if they were "matching a specification". Sure, the specification itself may not be fully correct, but a lot, if not most bugs, are code that would go against such a specification.

> Also, just think about this: what bugs have you had in your software historically? How many of those do you believe would've been prevented by a type system like Haskell's??

I program Haskell all the time, and I encounter "non-bugs" where the compiler prevented me from doing something, which other languages would not have, on the regular.

> (though I do use typed languages like Java and Kotlin)

Those are not even close to a Hindley-Milner based type system like the one in Haskell.

How so?

I don’t use this one, because I remember when long, long ago it was in some random IP address block belonging to someone, and this particular address didn’t reply to ping.

Likely for good reason, even back then there would have bound to be lots of misconfigured endpoints trying to access 1.1.1.1, so just blocking it at the earliest point possible kept at lot of the annoyance away. Nowadays, it’s an anycast address, so it’s slightly less bad.

But for me, old habits die hard.

Can you produce those studies? Genuinely interested. Intuitively, I would have thought properly used Haskell prevents a lot of bugs by virtue if its type system, which allows for encoding internal constraints to a certain degree.

The extreme end of this is dependent types, which is so strong that it can be used as a foundation for mathematics itself, and is the principle that the Lean, the proof assistance, is used on. A Lean "program" is effectively proven to be bug-free.

That is insightful, thanks. I didn’t start caring about models until very late, so I genuinely thought GPT-2 was only a single tiny model originally.

And I now tried using it more as a “text completer”, and results are much better.

Be sure to send them an email first, so that you can arrive at the proper time for them to give you a tour. It is very, very worth it. One of the best museum experiences so far.

I've been playing with it for a bit, and I'm a tiny little bit surprised that they decided to continue pursuing that direction of research at all. What I'm getting from it looks like it could just be arbitrary sentence and paragraph fragments from the Internet, pasted together Markov-chain like.

I'm not sure I would have ever believed that something useful would come out of it, yet here we are.

It is, in every sense, incorrect. Which statement in this short snippet is "semantically correct"? (Better LLMs get this right, of course.)

I mean, they were both.

It’s interesting though that composite PAL/NTSC (especially NTSC) has a massive effect on the picture, owed to the fact that the color carrier was embedded into the luminance spectrum, so a re-digitized PAL/NTSC signal will still look very different from a digital-output-first signal, or a re-digitized VGA or component signal.

There’s some evidence that console games of the era were sometimes designed for the effect composite NTSC has on the overall picture: https://nerdlypleasures.blogspot.com/2015/03/the-case-for-co...

Unlikely, as the quote about >230k misattributed people comes from the article itself. So even without taking into account that I generally expect more from the BBC, the author of this article seems to be at least aware of the fact.

Be it as it may, and even if that's an AI-generated article (which I don't think so), the point is that the article is reporting on the Japanese government:

    Japanese authorities have called the trend an "existential crisis" with Prime Minister Sanae Takichi describing the decline as a "quiet emergency".

And my hope that they have taken that past mistake into account seems to have some ground, given that the 100k total number that the current figures cite is by itself well below the then-figure of 230k misattributions.

I grew up in Germany. For the past 13 years, I've lived in the US. Oh, how I wish I could go back to the "day in day out, everyday in public transit" instead of this car hell. In Germany, just like in Japan, I didn't feel that it was noisy at all. It was clean and quiet and soothing, I could just sit there and relax.

Everyone takes public transport, across all income ranges.

As a result, public life itself is more quiet and soothing, because you are not constantly surrounded by cars, even if just sitting outside a café.

As for the family you stayed at, they must eat differently from the Japanese families I know personally. Studies agree: https://www.livescience.com/54133-japanese-diet-longer-life.... https://chns.cpc.unc.edu/resources/publications/bib/2884/

Might I personally add, it is so hard to eat healthy here in the US, compared to Germany and my experience in Japan. (And German food is not necessarily healthy. But it's much easier and cheaper to eat healthy.)

I was also thinking about that, but that miscounting story is so old, notable, and well-known by now, that it's basically popular knowledge around the world. So I hope that the BBC, but especially also the Japanese government that the BBC was reporting on, are aware of that issue and have, by now, accounted for it.

Did you actually visit Japanese families, or is that assessment based on what you saw in convenience stores and similar? "Convenience" food and western style food has somewhat increased, but on average Japanese cuisine is very healthy.

I also agree on the stressful work part, but don't quite understand what you mean with "lots of commute on public transit". If you mean the Tokyo-style rush hour traffic where people are literally shoved into the train car, of course that's stressful. But at any other time apart from that, Japan's public transit is enormously soothing and stress-free, both because of culture and transit technology.

But our universe also has black holes.

So what then, is it black holes all the way down?

I don't know about JavaScript, but those statements are definitely not universally true in other languages.

> I failed a job interview once by using reduce() in a coding test. The reviewer didn't understand why I hadn't used a loop.

Honestly, sounds like the reviewer failed the interview, not the other way around.

I mean, sure, although the crashes could sometimes come with data loss as well.

You might now ponder whether a broken login screen, i.e. temporarily not being able to access data, is maybe better than downright losing it, but my point was more that I sometimes get the feeling that earlier MS DOS/Windows OSes are now seen through some kind of nostalgia glasses, that seem to make the OSes much more stable and put together than they actually were.

In my experience, most somewhat mainstream OSes were much less shoddy. This includes various Unixes and Unix-likes, but also OS/2 (which was jointly developed by Microsoft, with IBM).

I think people just forgot how insanely unstable and prone to breaking MS OSes were back then. Crashes and hangs that take down your entire machine were common, and “reinstalling the OS” was seen as a normal thing that you just had to do every once in a while.

Windows 95 was pretty much broken “by design”. This is truer than it seems, especially if you skip being charitable by taking the context into account, namely that Microsoft mainly designed Windows 95 for compatibility. (The contemporary Windows NT on the other hand was a much cleaner design, though still questionable above its kernel layer).

That’s ubiquitous in slightly lower level programming (pretty much every non-small C program probably does it in some way or other), but the problem with doing that in this database scenario is that you might run into atomicity issues.

To toggle a flag, you have to read the column, modify it, and write it back. If someone else does that to another flag at the same time, there’s a race that one of you might win, at the expense of the other flag’s new value.

Unless you employ a lock that would otherwise not be necessary.

Gödel effectively says ZFC must be incomplete, otherwise it would not be sound, but does that stop you from listing all mathematical propositions it can generate in some well-defined order?

Adding 32GB of RAM is vastly better than adding 32GB of swap, it’s not even close. However, it’s also vastly more expensive. That has always been the case, not just in the current insane situation.

We use swap because we have plenty of disk space, but (comparably) very little DRAM.

The same goes for another level on the hierarchy: If you could choose between 1GB of DRAM vs. 1GB of SRAM (which your CPU cache is), you’d definitely choose the SRAM. But you’d be paying out of your nose both with money and area, it’s not economical at all. My CPU has 96MB of cache, and that’s considered massive.

I’m not sure I understand. In your equations, why is swap taking away from RAM? It’s purely additive.

Say you have 64GB of RAM, of which 4GB are dirty pages that are never, or at least very rarely, accessed. With 64GB RAM + 4GB swap, you filled up your swap with them and have 64GB RAM left to use actively. With 64GB RAM + 0GB swap, you only have 60GB RAM left to use actively.

Fair enough, you looked and did the math. On my laptop (totally different use case), there is currently plenty of memory in the compressor.

Yes, only dirty (i.e. modified) pages profit from getting paged out to swap.

But while I don't have any hard data, I imagine that depending on the workload, there can be a punch of pages that are read during initialization, or a one-off workload, and never being read or freed up afterwards.

Just try activating a swap file, and see if it gets any usage, despite memory pressure being low.