chombier

> Rotations don't commute, so the concept of average as we understand it doesn't normally apply to them.

It does apply, considering that the Euclidean mean minimizes the sum of squared lengths to samples there's a fairly obvious generalization to Riemannian manifolds using geodesic distance.

There are some reasonable assumptions to be made on the manifold and/or sample distribution to ensure convergence but in practice it works pretty well.

Funny, I was there last Thursday and our guide said "supposed to finish in 2026, more like 2035 if you ask me!"

So I guess this a way for Google to gather (more/fine-grain) data on paper skimming/research interest?

Yes, you need to keep track of which is which (most likely using the type system) but you don't risk adding vectors to covectors without converting explicitly. Each of vectors/covectors is 3 dimensions, but there is no 6-dimensional space in which vectors/covectors are allowed to mix.

IIUC this is unlike GA/exterior algebra where scalars/vectors/bi-vectors/... can be added together, just like one can add a scalar to a pure imaginary quaternion in the quaternion algebra.

Off-topic, but this whole website is a gold mine. I just finished reading "Coordinate-Free Linear Algebra" and "Hamiltonian and Lagrangian Mechanics", making tensor products, Lie derivatives and Poisson brackets finally click. Thermodynamics is next on my list.

If the author ever lurks here, thank you so much for putting these online!

A somewhat simpler way of keeping track in the case of normals is to use row vectors for, well, covectors, which is what normals are anyways.

What GA brings is the ability to express linear combinations of scalars, vectors, bi-vectors ... Whether this is actually useful/desirable in practice is another story though.

I remember reading somewhere that the amount of caffeine in the cup is also proportional to the brewing time, therefore an espresso may not actually contain that much caffeine in the end (for the same initial amount of ground coffee, of course)

For those interested, the ACM page for the paper has a good introductory video https://dl.acm.org/doi/abs/10.1145/3485513

This article is about a technique "Copy-and-Patch" for just-in-time (JIT) compilation that is both fast to compile, produces reasonably efficient machine code, and is easier to maintain than writing assembly by hand.

The section "Copy-and-Patch: the Art of Repurposing Existing Tools" describes the heart of the method, which is to use an existing compiler to compile a chunk of c/c++ code corresponding to some bytecode instruction, then patch the resulting object file in order to tweak the result (e.g. to specify the instruction operands) in a similar fashion to symbol relocation happening during link.

Given a stream of bytecode instruction, the JIT compilation reduces to copying code objects (named "stencils") corresponding to bytecode instructions from a library of precompiled stencils then patching the stencils as needed, which is very fast compared to running a full-blown compiler like LLVM from the syntax tree.

Of course, the resulting code is slower than full-blown Ahead-of-Time (AOT) compilation, but the authors describe a few tricks to keep the execution speed within a reasonable margin of AOT. For instance, they leverage tail calls to replace function calls with jumps, compile sequences of frequently associated bytecode instructions together, and so on.

Nope, sarcasm was pretty obvious from the "iceberg jumping at the boat" part.

> I’ve used nonlocal 0 times ever.

Same here, but I got bitten by weird scoping rules quite a few times.

Separating variable definition from assignment (e.g. with 'let') would probably help a lot in this case.

I would say Python won because IIRC it was meant to be a glue language between C libraries (something between C and bash) from the beginning.

This made it fairly easy for anyone to provide Python bindings for existing C libraries, so users could enjoy a large number of packages in order to get stuff done quickly.

Then of course, numpy/pandas etc.

To compose generators I use `yield*` (or `yield from` in python) https://developer.mozilla.org/fr/docs/Web/JavaScript/Referen...* (note that last star is actually part of the link)

The main drawback with this approach is that it is easy to blow the stack, but it is not too hard to implement trampolining on top of it (by yielding the continuation to a wrapper generator)

To use the generator I send its inputs using `.next()` and obtain current state information, as shown on your library webpage.

When I need something lightweight I usually implement state machines using generators/coroutines when the language provides them, as they compose well and I find it easier to follow to control flow anyways.

Here's the video of the talk: https://www.youtube.com/watch?v=yUtZwdGhxhw

The method described looks similar to [0] which extends Euclidean spline curves to Lie groups using the exponential map (here the conversion from/to scaled-angle-axis)

[0]: A general construction scheme for unit quaternion curves with simple high order derivatives https://dl.acm.org/doi/10.1145/218380.218486

This is my understanding as well. There a somewhat accessible introductory video I found useful [0].

The algebra makes it possible to encode sets, key/value associations and sequences to build a knowledge base, and the dot product provides a similarity measure for querying the base.

IIUC the key is that for large space dimensions, any two random vectors (say with uniform distribution over {-1, +1}^d) are almost guaranteed to be near- orthogonal.

This makes it easy to add new items to the base (by sampling a new random vector and updating the base using algebraic operations with other items), yet the amount of noise introduced by near-orthogonality remains controlled and can be filtered out to keep the algebraic structure working as the base grows.

Honestly it seems a bit too good to be true, I'd be very interested to see what are the tradeoffs in practice.

[0] https://www.youtube.com/watch?v=oB_mHCurNCI

Indeed, with lambdas you don't need to deal with locks outliving the underlying object (though I think std::unique_lock has the same issue with the underlying mutex?)

The downside with lambdas is that you cannot lock across function boundaries e.g. give ownership of a lock to the caller.

There's a similar tradeoff for all "context managers" (in Python parlance) where you could either CPS your way around the control flow (the lambda approach) or use c++'s RAII mechanism.

My impression is that RAII feels a bit more idiomatic and puts the burden on library writers instead of users.

Or you could give `MutexLocker` pointer semantics to access the underlying object only through the lock, which would probably be more idiomatic c++ anyways.

To me, one of the best thing in Rust compared to C++ is that I no longer have to be super careful all the time to avoid common pitfalls, I just write stuff and fix compilation warnings/errors until the compiler is happy, and things mostly just work (apart from domain-specific bugs of course)

After getting used to the basics of Rust, I found the cognitive load to become much lower compared to C++. There's just no way I could write correct C++ code in such a careless fashion.

So now I can spend brain cycles on things that actually matter, and it's great.

Worth the read, thank you very much.

> I am not sure what stops you from using a wrapper script (in Python, portable) and invoking it as a custom target

Nothing, when applicable this works and we're doing it already, thank you.

But it doesn't as soon as one needs to abstract over CMake commands themselves (like add this target, set that target property, add this test and so on). Of course we could try to generate CMake files in wrapper scripts, but this is another level of CMake juggling entirely.

> CMake is quite more frustrating.

Could not agree more.

But even more frustrating than CMake programming is Meson checking almost all the boxes yet refusing to provide that last one bit of functionality that would make me switch to it (and giving a wrong justification for it).

> type inference

This means muon can fairly easily implement user-defined functions without making the language Turing complete. If they did this I would happily (re)consider switching from CMake.

Same story here: complex build scripts in CMake, horrible language but at least it has some form(s) of user-defined abstraction. Tried to look into Meson, bumped into this issue, and decided against it for the same reason.

I kinda get the rationale that no abstraction primitive should drive common patterns into the standard Meson distribution (an approach which has problems too, but at least it makes sense to me).

However, seeing function definitions rejected on the basis of Turing-completeness raised serious doubts about the project at the time, and things haven't changed much on this front apparently[1]

[1]: https://mesonbuild.com/Syntax.html#userdefined-functions-and...

> This is a very funny question, "Why use Comic Sans?" So, all my talks use Comic Sans and I frequently see remarks like 'Simon Peyton-Jones, great talk about Haskell but why did he use Comic Sans?' but nobody's ever been able to tell me what is wrong with it. It's a nice legible font, I like it. So until somebody explains to me ... Ah, I understand that it's meant to be a bit naff, but I don't care about naff stuff, I care about being able to read it. So if you have got a sort of ... some rational reasons why I should not then I'll listen to them. But just being unfashionable? I don't care.

source: https://graphicdesign.stackexchange.com/questions/38226/what...

If anything, I would say that geometric algebra (with its vector division) confuses the group/torsor situation even more since they're both part of the same algebra.

What does effect handling bring compared to building/evaluating an expression tree?

Is it faster/terser/more easily extensible?

What about ReScript? As far as I understand ReScript has a sound type system which would make it an even better foundation?

If one thinks of vectors as the matrix of some linear map over the scalars (and similarly covectors as linear maps to the scalars), and assuming the usual composition order of maps then it seems there is no choice as to the column/row representation: vectors have to be (n x 1) and covectors have to be (1 x n)

This doesn't say anything regarding their practical storage, but at least conceptually vectors/covectors are a bit more than just a collection of numbers.

This distinction is pretty useful in practice when encoded in types to avoid implicitly mixing things that are conceptually different.

Thank you so much, watching that talk finally made it click for me as well!