mtdewcmu

Looks like the hardware this runs on has only 64 KB RAM.

The common meaning of AI has changed since this book was last updated in 2013. The kind of AI Matt was referring to is the kind in the compressors listed in DCE itself. See section 5.3.2.1 Modeling Text [1].

[1] https://mattmahoney.net/dc/dce.html#Section_5321

I think that the common meaning of AI has changed since this was written. This book was written at least 14 years ago, long before anyone had heard of an LLM. Matt Mahoney incorporated neural networks in his compressors. Afaik they weren't pretrained. They were adaptive and made one pass over the plaintext, simultaneously learning and predicting. Decoding worked similarly.

Really nice guy, also.

When decompressing, you need to reproduce the output of the LLM exactly as it was during compression, otherwise the decompressor would output gibberish. Can you count on the LLM being that consistent?

Fabrice Bellard did something with neural nets and a transformer model [1] that was very successful.

I suspect that LLMs wouldn't be ideal to use as compressors, because they are large, consume a lot of resources, and are constantly changing. You need the model to produce exactly the same output at encoding and decoding time, or else you get gibberish.

[1] https://bellard.org/nncp/

Is sel4 an OS kernel created by Jane Street?

>> Retatrutide is incredible in a mind altering way

>> and all just love the way it makes you feel

Maybe it will turn out to be an antidepressant as well. That would be quite a coup.

You could write imperative code in Racket without much difficulty, as long as you don't mind the exclamation points.

Mine is GNU WoMan, an alternative to man.

https://www.gnu.org/software/emacs/manual/html_mono/woman.ht...

Racket has packages (1) that work quite well. Chicken Scheme has Eggs.

(1) https://docs.racket-lang.org/pkg/index.html

I think they also make money from people that don't know the difference and use it because, for instance, it's the default in Edge when you search from the URL bar.

This all reminds me of Bing. It already lost the technology race, but it serves MS's own interests to keep it around, apparently.

I started learning Common Lisp, but ASDF and Quicklisp threw me off. I couldn't tell if you were supposed to choose one or the other or they were used together. This might revive my interest in Common Lisp if I get around to reading it. But in the meantime I drifted off to Racket, which is relatively well documented and has extensive libraries and really unique features.

Let's see if I can state this properly. The atoms of the ship will pass right through the event horizon like nothing. To see the ship, though, photons have to travel from the ship to your eyes. As the ship goes deeper into the black hole's gravity, the photons will "appear to" be getting slowed down by the black hole's gravity well, each photon more than the last. So, an outside observer would have to wait longer and longer to get the next photon. In fact, he'd have to wait an infinitely long time to get all of them. It's like an optical illusion, except that a real physicist would say it's not an optical illusion; it's time dilation, etc.

So you don't see _everything_ that went in before you, mostly just the _last_ thing.

A single photon can't be seen multiple times, right? So, if photon A goes into Alica's retina, then Bob can't see photon A. If a big, opaque object passes through the event horizon right in front of you, it would absorb or scatter the photons in its path, and you would not see them.

I'm going to guess. From Bob's perspective, Alice's ship would still be able to block light. So he wouldn't be able to see what was ahead of him through the back of Alice's ship; Alice's ship would occlude his view.

It could have been carried by tax collectors.

Could there have been glass lenses over the holes and it was a kind of microscope? Here's my guess: it's a magnifier to examine coins.

Yes. Thanks for explaining.

> If speed is an issue then you want it near the most commonly accessed data.

Yes. You expect the seek time to dominate performance.

The reason that the swap was faster when placed at the beginning is likely because the filesystem is mostly empty and so the allocated portion is at the beginning of the partition.

If the filesystem was near capacity and the files are distributed throughout, then you would expect the performance of the swap at the end and the swap at the beginning to start to converge.