rho_soul_kg_m3

What's at the top of the list?

It's not conscious if a nice person wouldn't feel bad torturing it.

And I didn't say it does. Intelligence is not necessarily deterministic, and being random is not the problem with LLMs. The problem is that they are not intelligent: they statistically mimic reasoning and logic, which still could have been acceptable except that they don't generalize well and have double-digit (at best single-digit) error rate percentages.

They also have the worst possible failure mode imaginable: Producing erroneous output that looks perfectly fine and expertly-crafted.

Imagine a food synthesizer machine. You press a button. 80% of the time you get a chicken sandwich, 20% of the time it beeps an error. That's OK. With the LLM version of that, 80% of the time you get a sandwich, 20% of the time you get what looks like a perfect sandwich except that it contains bits of plastic and metal, and you have to start eating it to find the pieces.

"You're absolutely right! Food shouldn't contain bits of plastic. Let me synthesize that again."

I wouldn't have problems with AI-generated code, but LLMs are not AIs, they are random sentence generators. They don't have logic, yet programs are logical constructs. So let's call this what it is: randomly-generated code, kinda sorta filtered by humans and tests. It's not because the output distribution has a good match with the expected distribution that it's not random. An LLM that is "hallucinating" is still working perfectly well and isn't doing anything different, in the same way that a straight-line fit through data points isn't "hallucinating" where it isn't overlapping the data points exactly.

All AI companies should be forced to re-train their models without the offending materials, and this should also extend to all LLMs distilled from models exposed to copyrighted works. Also cover code under licences such as GPL as well. Not to mention patents and designs. This whole LLM business is a giant IP laundromat.

Hello :) Glad to hear the talk was useful.

You say you're using Linux as the underlying OS, but you must have looked at bare-metal embedded usage as well.

How feasible would you say it is, today, to use OCaml with MirageOS (or something similar) on a bare-metal target, say a small softcore RISCV32 with 256kB of RAM?

In general, if it works, leave it alone; but I can think of two reasons to stop using OCaml:

1) You have been ordered to directly interface with some external library that has a complicated C ABI, and you can't isolate it in a separate process and do IPC, and the FFI would be too clunky or slow.

2) You really need to manipulate lots of bits or bytes or floats very fast, or there are lots of them, and speed or memory footprint is becoming an issue. You need to multicore and/or SIMD, you need efficient abstractions, and you do that kind of thing all over the place, not just in a few functions that you separately implement in C or whatever.

As a bonus here's a good reason for NOT leaving OCaml: You can quickly bootstrap the compiler and run it on small embedded machines. I remember using OCaml on a Cyrix 686 with 64 megs I think, it was perfectly fine. Today, the lights dim a bit when I start cargo build.

Thanks. Regarding open-sourcing, well no, it's not up to me, and it would be kind of proprietary.

The size variants for floats and integers is definitely appreciated.

For the "read-only BigArrays": At the time I didn't know any Rust, but today that would simply be passing a mutable or immutable reference. Similar to the Fortran in/out designators in some way. I think that's pretty important when you have some complicated numerical code, sometimes with in-place modification.

Since there is a "zero_alloc checker", maybe a similar kind of annotation exists or could be added? Something like

  let foo (x : [@readonly]) = ... 
    x.{0} <- 1.23

  ^ Attempt to write to read-only array

Not a problem, LLMs can be very efficient at controlling social unrest.

Yes see above.

OCaml was very much part of the GHG measurements. On the satellite it was controlling the cameras, acquiring the images, losslessly compressing them, encrypting them and transferring them to the platform controller using a clunky but mandated CSP-based file tranfer protocol. On the ground, OCaml was running almost the entire data processing chain, including spectroscopy, image corrections, retrievals and post-retrieval ad hoc bias corrections, as well as simulations.

I simply used an mmap()'d Bigarrays to do parallel processing (back then OCaml wasn't multi-core.)

At a later stage I replaced a few bits of code (e.g. some sparse matrix routines) with Fortran. The only processing-related part that wasn't OCaml (besides the shells scripts to glue the things together) was the image alignment algorithm which was written by someone else in C++. I even had a job scheduling system written in OCaml.

If you must know, I'm writing a real-mode 16-bit x86 assembly to C translator in Common Lisp to be able to run that 3-sector inference engine, which was posted the other day, outside of QEmu, currently I'm debugging it. I'm doing this because it's fun but I can rationalize it as follows: It allows me to simultaneously learn Common Lisp, as I'm otherwise an OCaml & Scheme guy; 16-bit x86 assembly, since I grew up learning 68k assembly and segments are otherwise disgusting; and also slop generator architecture, right now I don't feel like reading a summary paper, those always leave out details. This is 100% hand-written in Emacs in Evil mode, and with SLIME. I guess that counts as a coding assistant, and it's written in LISP and LISP=AI, so that I can claim that I am familiar with generative AI technologies for coding when applying to jobs.

Knowledge retrieval. Something where I could ask a question, say in natural language, and I would get an answer. Of course the responses have to make sense and not be made up.

I think one of the earlier OCaml versions of the Rust compiler would be lean enough to be usable on a mid-90's PC.

Language models are good at translation and retrieval. This also extends to computer languages. LLMs translate from GPL to other licenses the same way Google translate turns French to English, except that the source material is implicitly stored in the LLM.