spectrums_coherence

Okay, this cannot be real…

Sexy

Brother never understood conditional probability.

bandcamp

No I think you are thinking of calyx. Graphene repeatedly asserted that they won’t support fairphone because of the slow update.

I feel this way precisely because I keep doing new and novel things: there are so much to learn, think, and try out, I feel I am constantly in a rush.

When I was younger, I either have well-defined tasks or I would hit technical blocks forcing me to stop for a long time. Now, I get to work on all the hard problems to my heart’s desire, and is also more skilled, thus hits way less blocks. I am in a constant race against my own ideas and desires to try new things…

It is cool and fulfilling, but also terribly exhausting most of the time :(

I see your point, but to give that particular game scene plenty of benefit of the doubt: that pod transports a spartan. It is possible that he intensionally disabled the slow deceleration, because he can handle the impact.

They do slow down after a bit:

Once nearing the ground, drop pods activate a drag chute (more formally termed a “Drogue Panel”[10]) formed from the upper-most panels. The chute deploys and begins to slow down the pod’s descent. Once about 1 kilometre (0.62 mi) from the ground, a series of computer-controlled retrothrusters engage and rapidly decelerate the pod such that it can impact safely.

Also most (not all) drop pod deployments are used by specialized troop like ODST or spartans:

Of these, the UNSC are particularly reliant on the use of drop pods thanks to the aptly-named Orbital Drop Shock Troopers; specialised shock troops who specialise in the use of drop pods to insert behind enemy lines and conduct special missions.[7][8] Although the ODSTs are the primary users of drop pod insertions in the UNSC, both Spartans and regular Marine forces may also use them.[9]

https://www.halopedia.org/Drop_pod

!nottheonion

For people who are not aware, “Yao-Shun-Yu” are the first three (half-mythical) kings of China. They are famous for their altruism and kindness.

At this point, I am not even sure naming robots after human rulers is dystopian or not.

Let’s imagine that AI will become cheaper and more efficient, it will not differ from humans in terms of the quality of its work, it will replace almost all intellectual workers.

You can say the same thing in the first industrial revolution: “let’s imagine the machine will replace all physical labor.”

But till this day, they have not been able to do that.

D-Bus Daemond is superceded by systemd-busd

But I do need to write code from time to time :(

This might be controversial, but I want yet another code editor.

Hear me out, I write very little code, but when I do, they are usually in widely different programming languages, and many of them have a comparatively small user base, like Haskell, Ocaml, Lean, Agda, and Rocq. Most of the time I write LaTeX and/or Typst all day, so I need:

1. an editor that sandbox really well, there is no way I am trusting all my coding environment with my entire user space.
2. an editor that don’t require much tinkering: if it can get to 80% there, I am willing to learn the rest, but I don’t want an editor that get 20% there and force me to pull 80 different package just to do things.
3. preview LaTeX and Typst within the sandbox, ideally just in editor, so I don’t need to configure synctex.
4. reasonable support for comparatively obscure languages
5. not controlled by a big tech like Microsoft.

So far, I am only able to find vscodium in flatpak that is close to my desire, but it is still mostly controlled by Microsoft.

happy cake day!

I am sorry but do goat actually float?

That is the thing about formal proof: if the definition is correct, which usually is relatively short and should be written by human, there is almost no chance of the prove being wrong. The only exception are when the LLM exploits a bug in the proof assistant kernel, and these kernel are usually designed to be exceptionally small, thus making bugs unlikely.

That being said, opus 4.6 found a bug that eventually lead to the proof of false (opus is unable to produce the proof of false, hence unlikely to exploit it): https://github.com/rocq-prover/rocq/issues/21682

However, like I said, the code quality of the llm is usually not on par with an expert, and they have a tendency to produce unnecessary lemmas and complications that will need to be cleaned up by human.

Also, we have a very detailed pen and paper proof, which are designed to be easily translatable to proof assistants. We have also setup all the lemma and theorems to reach the end goal. All of these are done by humans, without these, I don’t believe any LLM can make much progress on this project.

Yeah LaTeX is a bit different, think about describing a process in MS Word, v.s. writing a program that performs such process on a computer: LaTeX is more like description aimed for human consumption, where as formal proof is more like a program that computers can rigorously execute.

Proof assistant have only attracted the attension of mathematicians very recently, thanks to the organization surrounding MathLib in Lean, and the promption of Terance Tao.

It also rides the AI train quite a bit, as AI have a tendency to confidently be wrong, having a computer to check its proof can be very useful.

There are proof assistants https://en.wikipedia.org/wiki/Proof_assistant that would encode a mathematical proof as code, and verify its correctness for you.

Writing completely formal proof is very painstaking, because it means we will need to flash out a lot and a lot of details (which are mostly trivial for experts) for computers to accept it, and we also need to know how to work with proof assistants.

Human proofs often ignore these details to make it readable, yet also make it more prone to mistakes. Whereas formalized prove in proof assistant can very rarely be wrong (unless there is an unlikely bug in the assistant kernel), but mostly unreadable (unless the proof is incredibly elegant).

So in general, translating good human proof to computer proof requires more expert labor than huge conceptual innovation, yet it usually require the steep learning curve of understanding the ins and outs of a proof assistant, which can take years of experience.

LLM used to be pretty bad at this because even filling in trivial details can quickly derail them. Recently a few flagship coding model are finally able to do this, albeit with a large amount of token consumption in thinking.

Many academics around me have a paid plan of LLM of some sort, most are on $100 plan some are on $200, all of them are getting reimbursed for their plan.

Most of them uses it to optimize code, generate visualization, or formalize pen and paper proof.

I hated it, and don’t use much of it myself. But it seems too useful for these people and it is hard to stop them. As an example, formalizing a pen and paper proof can take an expert weeks, if not month of work, whereas it only takes codex a week.

But I do feel this success is tied to the nature and value of academia, and might not transfer to other fields or industrial projects:

• we usually have tiny codebases: it is not uncommon to have a 10-line algorithm with a 70-page paper explaining its correctness
• 90%, if not more, of the codes are proof of concepts, without the expectation for long term maintainance.
• the work is highly specialized, everyone is running out of time, and there is high expectation of the outcome of the work: in our recent work, we do have an expert in formalization, but he doesn’t have enough time, so the grad student formalized the project using codex. The overall architecture is probably much much worse than what would have been done by the expert. One interesting outcome is that codex is able to prove a more general result than the expert intended: not because it found a better proof, but because it is much better at bruteforcing a solution than human.