Thanks!

[mikeingold]

I just wanted to drop by and say thanks! As of tomorrow it looks like our package MeshIntegrals.jl may be the first in the General registry to set CliffordNumbers.jl as a dependency. 🎉

We use differential geometry to solve integrals over geometrically-defined domains by calculating the local differential element at each evaluated point. Originally this required a conditional step based on the number of dimensions being integrated, with everything above 3D throwing an error. However, after picking up a little bit of GA this year, I realized that all of this was mathematically equivalent to essentially norm(foldl(wedge, kvectors)). I had to apply a little bit of bridge code to link up Meshes.Vec vectors to CliffordNumber.KVector k-vectors, while keeping track of Unitful units, but the transition was pretty much seamless and it worked exactly like I hoped it might. I also appreciate that it's such a lightweight dependency, so it was a no-brainer to add to our deps.

Anyway, again, just wanted to pass along my thanks for your hard work!

[brainandforce]

This is great to hear! Honestly, I could see myself using MeshIntegrals.jl at some point in the near future, so thanks for letting me know about the package. If you come across any significant issues in CliffordNumbers code, or just need a new feature, feel free to open an issue or a PR.

I never really looked at interoperability between CliffordNumbers and Unitful until now, and I forgot that the allowed subtypes T of Unitful.Quantity{T,D,U} do permit the construction of a unitful AbstractCliffordNumber. However, some things don't work, like the wedge product, and that may be something I'll need to fix with a package extension. If that will simplify your code, let me know! I can prioritize that.

(I have some opinions on how Unitful.Quantity should work, but that's honestly material for either a 2.0 release or perhaps even a different package.)

[mikeingold]

This is great to hear! Honestly, I could see myself using MeshIntegrals.jl at some point in the near future, so thanks for letting me know about the package. If you come across any significant issues in CliffordNumbers code, or just need a new feature, feel free to open an issue or a PR.

I never really looked at interoperability between CliffordNumbers and Unitful until now, and I forgot that the allowed subtypes T of Unitful.Quantity{T,D,U} do permit the construction of a unitful AbstractCliffordNumber. However, some things don't work, like the wedge product, and that may be something I'll need to fix with a package extension. If that will simplify your code, let me know! I can prioritize that.

For reference, here's how I'm using k-vectors now. In this differential function I calculate a Jacobian matrix in the form of an NTuple{Dims, Meshes.Vec}. Then, after extracting units from the Vec to be handled separately, I use a utility function to convert the numeric components of the Vec into a CliffordNumbers.KVector.

I tried constructing a k-vectors directly with Unitful types, and had some limited success, but also found that wedge products threw errors. It would be nice if, for some collection kvs of KVector(a::Q, b::Q, c::Q) where {Q<:Unitful.Quantity}, I could just directly take norm(foldl(wedge, kvs)) and get the Unitful differential element size. If you'd like, I could open an Issue (feature request) with sort of a target-MWE describing this usage.

(I have some opinions on how Unitful.Quantity should work, but that's honestly material for either a 2.0 release or perhaps even a different package.)

Have you checked out DynamicQuantities.jl? I'm not sure what the "right" representation of dimensioned quantities is in the grand scheme, and maybe it's somewhere in the middle, but I've found it quite useful in certain cases. Unfortunately, since Meshes.jl geometries are built on inherently Unitful.Quantity data, I don't have the flexibility to choose between these packages in MeshIntegrals.jl.

[mikeingold]

I just wrote up #26 on this topic. The MWE fails at the constructor stage, and I was trying to remember how I’d gotten any further in troubleshooting, but just remembered. If you use a DynamicQuantity.RealQuantity which sub-types from Real instead of Number, then the k-vectors will construct, but then fail at the wedge product step. However, since I’d need Unitful compatibility specifically in MeshIntegrals.jl, that wouldn’t help me much there.