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.

Well, I might have been the first to put OCaml in space, specifically on low-Earth orbit aboard GHGSat-D in 2016. I designed the payload software as a collection of SystemD services talking over DBus, and it included a CCSDS-to-DBus bridge to talk to the platform (the thing that hosts the payload, controls and steers the satellite). The payload also did perform symmetric-key encryption of the resulting data, as per regulations.

I gave a talk about the payload software at the Paris OCaml users group.

The reason for selecting that archicture was that I didn't expect to write the whole payload software by myself, and I assumed that when some other developers join in they would, obviously, not want to use a weird language like OCaml, and so they could write their portion in C/C++/whatever and the system could still work. Of course that didn't happen.

I'd be surprised if the company still uses OCaml, as the standad tendency is to revert to "industry-standard" languages to get industry-standard problems. The whole processing and simulation toolchain was also written in OCaml.

Today there is little reason not to use Rust and it can cover both the processing side and the payload software. But people still insist on using C/C++. I'm OK with that as long as I can invoice them.

EDIT: Found my slides https://lambda-diode.com/static/data/GHGSat_OCaml.pdf

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.

Why can't MY browser send some random JS to THEIR website? If it's safe for me to run some stranger's code, should it be safe for strangers to run my code?

For me, wasm is a godsend. I sure hope it doens't go away. I can write a reasonably complex GUI with Rust and egui and OpenGL and put it online without having to deal with browser/Javascript/TS nonsense. The only pain points for me, so far, are (1) network and local file access for which I had to write tiny amounts of wrapper JS (2) having to rewrite shaders for OpenGL ES and (3) executor gymnastics for manual cooperative scheduling of some background computations, apparently multithread support isn't quite there yet. Also it works perfectly fine under Firefox, Chromium and even on my cellular telephone (these things have browsers now!) with Vanadium and Firefox mobile.