chombier

Recording of the talk: https://www.youtube.com/watch?v=bXs56902ElY

A few weeks back there was this nice little database query language as a language library [1] posted on HN, with the constraint that everything had to be 6NF.

At the time I thought this would naturally fit in a data-oriented design/ECS system to run complex queries. I wonder whether anyone has tried this before and whether this actually works in practice?

[1] https://prela-lang.org/tutorial/

That of the underlying, hypothetical universal brain topology?

Talk starts as 6:01:10

IIRC there's a fairly natural positive definite quadratic form on GA (used as the canonical norm) that takes the scalar part of the geometric product of a multi-vector and its reverse.

On the other hand, there's the k-th exterior power of the metric where one asks that wedge/interior products be adjoint in order to extend the metric to higher-degree forms.

I was under the impression that these metrics are the same, but maybe I'm completely wrong? Assuming I'm not, then the GA approach seems more natural to me.

> pull out Hodge Duals every time you want to do something that involves the metric, but I'm also unconvinced that geometric algebra is the answer here.

I don't know, I recently tried to work out how the metric on vectors/1-forms induces a metric on higher-degree forms, and if the geometric product magically gives this for free I'd say it's a win (same for the Hodge star).

If you ever wondered how to write a programming language, this is probably the best resource to get started (and then of course Crafting Interpreters).

See also part 2 https://norvig.com/lispy2.html

Gimbal lock?

I was a bit curious to learn what the differences are between this and the actor model, and I found this lobste.rs discussion to be helpful: https://lobste.rs/s/gsjskz/behavior_oriented_concurrency_for

> In BoC, the equivalent of a message is received by multiple actors and operates with exclusive access to the message and all of the receivers.

(emphasis mine)

IIUC with actors, messages are processed by exactly one actor so it can be difficult to express transactions (e.g. transferring funds from A to B cannot be done atomically). Erlang somewhat fixes this with "selective receive" which re-introduces the possibility of deadlocks. BoC fixes both issues.

Apart from installation problems/crash issues, do you have some feedback about type checking with ty vs. pyrefly? Which is stricter, soundness issues, etc?

Both are rust/open-source/new/fast so it's difficult to understand why I should choose one over the other.

For inextensible cloth there's also "Efficient simulation of inextensible cloth" [0] that is particularly clever and efficient

[0] https://dl.acm.org/doi/10.1145/1276377.1276438

Also check out Jean Gallier's notes (available online) https://www.cis.upenn.edu/~jean/gbooks/manif.html

Nice! It would be interesting to visualize the total momentum vector, IIRC Verlet being symplectic should be good at preserving symmetries, whereas RK4 is good at conserving energy.

I've been programming in c++ for 25 years (15 professionally) and I really don't see any reason to keep using it apart from dealing with legacy codebases.

Most arguments in the article boil down to "c++ has the reputation of X, which is partly true, but you can avoid problems with discipline". Amusingly, this also applies to assembly. This is _exactly_ why I don't want to code in c++ anymore: I don't want the constant cognitive load to remember not to shoot myself in the foot, and I don't want to spend time debugging silly issues when I screw up. I don't want the outdated tooling, compilation model and such.

Incidentally, I've also been coding in Rust for 5 years or so, and I'm always amazed that code that compiles actually works as intended and I can spend time on things that matter.

Going back to c++ makes me feel like a caveman coder, every single time.

Thanks, I scanned through all the comments/links but this is the actual resource one wants to read to get familiar with Backpack.

my tl;dr: after reading the article:

- two 64-bits words representation

- fixed, 32 bits length

- short strings (<12 bytes) are stored in-place

- long strings store a 4 byte prefix in-place + pointer to the rest

- two bits are used as flags in the pointer to further optimize some use-cases

That was a nice read, thanks.

A quick comparison of the two languages would be interesting, in case anyone has experience with both.

The PLDI talk is also available: https://www.youtube.com/watch?v=CJi_Fcs4bak

pandoc has a reveal.js backend which I use it to build my slides from markdown (with a few ad-hoc inline css tweaks)

What I found hard with Nix is the sheer amount of things I had to get familiar with before it started to really click:

- nix, the command-line tool

- nix, the language

- nixpkgs with the general API/idioms (overriding, overlays)

- individual nixpkgs packages that sometimes deviate from common practices

- flakes (which I haven't properly looked into yet)

The Nix pills series [1] and nixpkgs documentation [2] do help a lot, but that is quite a lot to process.

[1] https://nixos.org/guides/nix-pills

[2] https://nixos.org/manual/nixpkgs/stable/

Yes, but from the canonical form of rotation matrices [1] I would expect such matrices to be represented as a sum of bi-vectors/rotors, which should take the same amount of data?

[1] https://en.wikipedia.org/wiki/Orthogonal_group#Canonical_for...

Geometric Algebra supporters keep advertising that rotors are great since they work in any dimension, which makes me wonder: would an arbitrary n-dimensional SVD-like decomposition benefit from using rotors instead of rotation matrices, and if so how? And if not, why?

> and also faster than it takes me to verify the answer given by the machine.

I always thought there was a kind of NP-flavor to the problems for which LLMs-like AI are helpful in practice, in the sense that solving the problem may be hard but checking the solution must be fast.

Unless the domain can accomodate errors/hallucination, checking the solution (by a human) should be exponentially faster than finding it (by some AI) otherwise there's little practical gain.

Not exactly the same: `x` is given a polymorphic type (in F) in Haskell (restricted to values in ML) whereas the unannotated let-over-lambda will give `x`a monomorphic type.

There is a kind of "do notation" in OCaml with binding operators [1] (let*) for monads and (let+) for applicatives that is actually quite pleasant in practice.

[1] https://ocaml.org/manual/5.2/bindingops.html

Besides, if you still want to skip learning there are escape hatches like Rc<RefCell> but these hint pretty strongly (e.g. clones everywhere) that something might be wrong somewhere.

> Of course you have to internalise the rules of a borrow checker

This is generally a good thing: the more you internalise the logic of borrow checking, the earlier you start thinking about "who owns what" instead of deferring the choice to later, which often ends up in a tangled mess of "incidental data structures" as it is sometimes called in the c++ world [1].

Of course in c++ this means you have to internalise this discipline the hard way, i.e. without the borrow checker helping you.

[1] https://isocpp.org/blog/2016/05/cppcon-2015-better-code-data...

I think this is because `mutable` qualifies the call operator of the lambda (like a reverse const qualifier) so by-value captures are effectively const during the call unless the lambda is marked `mutable`. References themselves are always const, but the referenced object may be modified through the reference depending on its constness even though the lambda is not `mutable`.

Is there a way to force capture by const-reference by the way?

> >Distances are canonically defined in the space of rotations

> I am sorry, but this is simply not true.

It is true, there is a canonical choice given by the bi-invariant Riemannian metric on compact Lie groups, such as rotations (in this case the shortest angle between rotations)

Whether or not you want this metric in practice is another problem, of course.

> The article we are discussing does not provide any means of "averaging" any more than two rotations,

The Karcher/Fréchet mean described in the original article does average more than two rotations