Desired functionalities before registration

[serenity4]

Before we register this package, we should define minimal functionality that may be helpful to others.

Here is a list (kept up to date) of the different features that we are targetting:

• Define empty functions for common operators in geometric algebra, meant to be extended by implementations:
  • geometric product
  • inner product
  • outer product
  • scalar product
  • commutator product
  • hodge star
  • reversion operator
  • norm
  • left and right contractions
  • grade projection
  • dual operator
• Define non-unicode functions for all the operators above (e.g. inner, outer, commutator, ...).
• Define core interface functions that may be useful in context of geometric algebra, declaring functions that are not already declared in Base or LinearAlgebra. They can then be used when validating implementations. These functions include:
  • dim: Dimension of the real space that the AbstractMultivector is embedded within.
  • grades: Grades of the nonzero k-vector components of an AbstractMultivector.
  • Base.zero: Return the additive identity.
  • Base.iszero: Return whether an AbstractMultivector is the additive identity.
  • Base.one: Return the multiplicative identity.
  • Base.isone: Return whether an AbstractMultivector is the multiplicative identity.
  • Base.:(-): Return negation of AbstractMultivectors.
  • Base.:(==): Return whether two AbstractMultivectors are equal.
  • Base.isapprox: Return whether two AbstractMultivectors are approximately equal.
  • Base.getindex(M, k): Return the k-vector component of the AbstractMultivector M.
• Document all functions, describing their behavior and semantics.
• Define a test harness for implementations to use, based on the functions defined in this package. This testing utility would validate that implementations possess correct behavior with regard to these functions, by validating most algebraic identities.
• README documentation describing the intended role of this package, stating our goals for a somewhat official geometric algebra library and describing our decision to let one (or more) implementations come to maturity before committing to any of them in this package.

[eschnett]

The dot product \cdot is already exported by LinearAlgebra. We should extend that function instead of defining a new one.

[eschnett]

We should also define (or extend) a few helper functions such as ndims, size etc.

We might also want to define indexing to get at individual components of a multivector. We could keep this optional, but could then still define a standard for how to index multivectors.

• Should multivectors be an AbstractArray? (Probably not.)
• Should they implement the iterator interface? (Probably yes.)

[serenity4]

The dot product \cdot is already exported by LinearAlgebra. We should extend that function instead of defining a new one.

Indeed, and it also exports the cross product \times (which we could take as the commutator product). I see that those are aliases to dot and cross respectively though, and are not functions. It would have been better if those were not aliases but functions that dispatch to dot and cross. We might prefer to define proper functions instead of aliases for all operators, otherwise the names are misleading. About conflicts with LinearAlgebra, I don't know if one would try to use it along GeometricAlgebra; I'd rather think that GeometricAlgebra would have LinearAlgebra as a backend. And otherwise dealing with imports manually would not be as bad as having aliases be misleading. What do you think?

We should also define (or extend) a few helper functions such as ndims, size etc.

We might also want to define indexing to get at individual components of a multivector. We could keep this optional, but could then still define a standard for how to index multivectors.

* Should multivectors be an `AbstractArray`? (Probably not.)

* Should they implement the iterator interface? (Probably yes.)

Good point about these helper functions. We can define the functions that are not defined in Base (so, things other than ndims and size, maybe grade for example) for implementations to extend.

I also agree that multivectors should not necessarily be AbstractArray.

About iteration, although I think they should implement the iterator interface I think there are multiple iteration orders for vectors (other than (dually) single-graded) and multivectors in general, so it would be hard to write tests against that. Indexing would be easier to handle, e.g. we can provide functions for indexing from a linear index into a structured index and vice-versa (a bit similar to CartesianIndex but along grades which have a non-uniform length)

[eschnett]

I often have code that uses both linear algebra and higher level representations. I would try to stay away from conflicts. This would also make it more difficult for people to rewrite existing low-level functions to using higher level representations (geometric algebra). LinearAlgebra is a very basic package, it's difficult to stay out of its way.

We could choose a new name, e.g. times, and make this an alias (or a function calling) cross.

I would use the iterator interface mostly for functions such as map, i.e. to apply element-wise operations. Maybe I really want the broadcasting interface instead.

[serenity4]

I often have code that uses both linear algebra and higher level representations. I would try to stay away from conflicts. This would also make it more difficult for people to rewrite existing low-level functions to using higher level representations (geometric algebra). LinearAlgebra is a very basic package, it's difficult to stay out of its way.
We could choose a new name, e.g. times, and make this an alias (or a function calling) cross.

I see, I agree that it would be best to not have two different versions of the same unicode operators. But my concern is that we'd force implementations to extend dot and cross instead of more appropriate functions. dot is most likely ok but the cross product actually has a different meaning than the commutator product (for one, it produces a vector, instead of a bivector). Also, in general I think that extending aliases is confusing because we think we're extending a function while in reality we're extending the aliased one.

Then, we can of course have our own aliases, but my concern is about what functions we're fundamentally extending. The dot product and cross product are quite specific to linear algebra. If \times and \cdot were functions, there wouldn't be any issue, but we can't change that in LinearAlgebra.

On the user side, a way to solve this conflict would be to define your own function \times or \cdot which calls either the one from LinearAlgebra or from GeometricAlgebra. Something like

×(x, y) = LinearAlgebra.:×(x, y)
×(x::GeometricAlgebraType, y::GeometricAlgebraType) = GeometricAlgebra.:×(x, y)

or, to show that it's two fundamentally different things:

×(x, y) = LinearAlgebra.cross(x, y)
×(x::GeometricAlgebraType, y::GeometricAlgebraType) = GeometricAlgebra.commutator(x, y)

and same for \cdot. It's not ideal, but I think that avoiding confusion about semantics would be preferable. For the time being, if an implementation wishes to use the same \times as LinearAlgebra, nothing prevents it from doing so with something like

using LinearAlgebra
import LinearAlgebra: ×
using GeometricAlgebra

GeometricAlgebra.:×(x::MyType, y::MyType) = ×(x, y)
×(x::MyType, y::MyType) = ...

which I think can be a good temporary solution. We can revisit that once we have an official implementation in this package.

I would use the iterator interface mostly for functions such as map, i.e. to apply element-wise operations. Maybe I really want the broadcasting interface instead.

That makes sense for vectors, but for multivectors there are no well-defined elements. Making a distinction would likely require setting up abstract type hierarchies, and I don't think that's a good idea right now. I think it's best to let implementations define it for their own types for the time being, and not deal with it in this package.

[ktchu]

I agree with the original proposal, and all of the comments sound reasonable.

I have a couple of thoughts regarding definition of operators, types, etc. in the interface definition.

• I think it might be useful to separate different geometric algebra issues into different GitHub issues so that work on each issue can progress independently.

• Extending Operators from LinearAlgebra. I think there may be an option here that could address several of our concerns regarding semantics and operator aliases. It involves a combination of several of the previous comments.

  • Define an AbstractMultivector type (just a single entry point for the abstract type hierarchy).

  • Import the alias from LinearAlgebra and export it from GeometricAlgebra. For instance: \times.

  • Define an exported function that we want the alias to point to with our desired name. For instance: commutator()

  • Import the aliased method to LinearAlgebra, but don't export it. Define a non-exported version of the method that takes AbstractMultivector arguments and dispatches it to our exported function. Document the function to indicate its purposes. For instance:

    # `cross()` is a non-public method that exists solely to connect the `\times` alias to the `commutator()` function.
    cross(x::AbstractMultivector, y::AbstractMultivector) = commutator(x,y)
    

• Abstract Type Hierarchy. I agree that we don't want to impose a complex type hierarchy on developers of GeometricAlgebra implementations. That said, I think it wouldn't be unreasonable to include the following two abstract types in the general interface because they are so fundamental to geometric algebra and likely to be included in most implementations.

  • abstract type AbstractMultivector end
  • abstract type AbstractBlade <: AbstractMultivector end

• Core GeometricAlgebra Interface

  Here is a list of functions (binary operations excluded) that I think could be a reasonable start for an interface for the AbstractMultivector type.

  • dim: dimension of the real space that the AbstractMultivector is embedded within. Not present in Base.
  • grades: grades of the nonzero k-vector components of an AbstractMultivector. Not present in Base.
  • norm: norm of the AbstractMultivector. Extends LinearAlgebra.norm
  • dual: dual of the AbstractMultivector. Not present in Base.
  • reverse: Return the revserse of a AbstractMultivector. Extends Base.reverse
  • zero: Return the additive identity. Extends Base.zero
  • iszero: Return whether an AbstractMultivector is the additive identity. Extends Base.iszero
  • one: Return the additive identity. Extends Base.one
  • isone: Return whether an AbstractMultivector is the multiplicative identity. Extends Base.isone
  • :(-): Return negation of AbstractMultivectors. Extends Base.:(-)
  • :(==): Return whether two AbstractMultivectors are equal. Extends Base.:(==)
  • isapprox: Return whether two AbstractMultivectors are equal. Extends Base.isapprox
  • getindex(M, k): Return the k-vector component of the AbstractMultivector M. Extends Base.getindex

  Here is a list of functions (binary operations excluded) that I think could be a reasonable start for an interface for the AbstractBlad type.

  • grade: grade of the AbstractBlade. Not present in Base.
  • volume: signed volume of the AbstractBlade. Not present in Base.
  • inv: mulitplicative inverse of the AbstractBlade. Extends Base.inv(), which makes expressions like B^-1 possible.

[serenity4]

This sounds great. Regarding extending operators from LinearAlgebra, I am still a bit put off by having

julia> using GeometricAlgebra

julia> ⋅
dot (generic function with 42 methods)

julia> ×
cross (generic function with 1 method)

while the fundamental operators are much more than the standard dot and cross products, but if that's only me I can get behind the suggestion by @ktchu.

Otherwise, I find reasonable the suggestions for the type hierarchy and the core operations defined for them. As a minor comment, I would believe that inv, dual, reverse, single-argument - and maybe (less sure about those) ==, isapprox are operators in themselves (though not always binary) in that they are required for performing core operations.

[ktchu]

@serenity4 I agree that the aliases are off-putting. Two thoughts on how to address that issue.

1. (short-term) Include a docstring for our exported version of the \cdot and \times operators so that they at least show up in the help for \cdot and \times.

2. (long-term) After the general GeometricAlgebra.jl becomes more mature and if it has reasonably wide adoption, I don't think it would be unreasonable to propose to the maintainers of the LinearAlgebra package that we transition \cdot and \times to function calls instead of aliases to avoid the confusion that you pointed out in the REPL.

[ktchu]

As a minor comment, I would believe that inv, dual, reverse, single-argument - and maybe (less sure about those) ==, isapprox are operators in themselves (though not always binary) in that they are required for performing core operations.

Agreed that these could be considered operators. Clarification question about terminology: are we using the term "operator" for both the long-form function name and the unicode operator function names? Or is there a different way that we are distinguishing operators from "interface functions"?

[serenity4]

After the general GeometricAlgebra.jl becomes more mature and if it has reasonably wide adoption, I don't think it would be unreasonable to propose to the maintainers of the LinearAlgebra package that we transition \cdot and \times to function calls instead of aliases to avoid the confusion that you pointed out in the REPL.

Unfortunately LinearAlgebra is in the standard library, so I am afraid that option is not available.

are we using the term "operator" for both the long-form function name and the unicode operator function names? Or is there a different way that we are distinguishing operators from "interface functions"?

I would personally think of operators as "functions that perform core logic essential in the geometric algebra framework", as opposed to interface functions that are here to provide additional metadata/utilities/integration with other interfaces. In that sense, I wouldn't differentiate between the unicode name and the standard name, even if the unicode symbol is (most of the time) an infix operator. Though it's more of a personal terminology, I think the term is otherwise rather blurry as it may have slightly different meanings in different contexts (in mathematics vs programming for example).

[Jollywatt]

Hello all,

I'm enthusiastic to get this project rolling, but would like to get some clarity on how to start.
I have a working implementation of multivector types over at https://github.com/Jollywatt/GeometricAlgebra.jl. My current understanding is that the next steps for me should be:

1. Rename to something like Multivectors.jl or even EuclideanMultivectors.jl or DenseMultivectors.jl depending on how specialised I want my package to be. (At the moment, it works with any metric signature, and supports SparseArrays, but it may be better to pick something specific and do it well instead of trying to do everything.)
2. Restructure code to use JuliaGeometricAlgebra/GeometricAlgebra.jl and extend its methods.
3. Once the implementation reaches near-maturity, transfer ownership of the project to this organisation.

Some things I'm unsure about:

• I want to avoid making an opinionated package, but my implementation will inevitably have design decisions that other users might dislike. How do I be courteous to other possible implementations? Should I avoid a snatching up Multivectors.jl from the package namespace for myself, or should I claim it and avoid unwieldy names like BasicMultivectors.jl? I know that the end user would rather do using Multivectors than something weird-sounding.
• How does transferring ownership to JuliaGeometricAlgebra work?
• Is there anything else I should be aware of or be careful to get right?

Edit:
The package https://github.com/digitaldomain/Multivectors.jl already exists. From glimpsing the source, my implementation differs in that:

• there is no distinction between covariant and contravariant vectors
• geometric multiplication of blades is done at run-time, not compile time
• $k$-vectors and multivectors are just wrappers for component arrays, rather than collections of Blades, or KVectors.
• multivectors are displayed in a way which tries to mirror how basic Vectors are displayed in the REPL, rather than with a succinct mathematical notation (e.g., ⟨0.65⟩₀ + ⟨10.0e₁₃,10.0e₂₃⟩₂)
• most things are slower
• generally, my package is aimed at pedagogy, rather than research

[Jollywatt]

Meta-question: where is the best place to consult this group for opinions and feedback regarding my own implementation package? Should we have a wiki?

[serenity4]

I am personally busy with other projects at the moment, though happy to discuss directions for the project. Any efforts are appreciated to develop this package if it can be useful to you or others.

Your understanding seems correct. I would say that the transfer of ownership is optional, depending on whether you want to have the package be part of the organization or not. It is usually good practice to increase the confidence in projects (notably by potentially having more than a single maintainer), when you believe the package is in a decent state to be considered seriously for development and upkeep. Transfer of ownership is achieved by using the option "Transfer" in the repo settings. I guess that GitHub would then put some sort of automatic redirection in place for older versions.

For the naming, it seems somewhat analogous to automatic differentiation in Julia: there will be several implementations of the same thing. Instead of a descriptive name (as you suggested i.e. EuclideanMultivectors.jl, DenseMultivectors.jl or other), but that can't describe the core functionality as well as GeometricAlgebra.jl, I would suggest to use something a bit detached from the functionality (e.g. for AD this was Zygote.jl, Enzyme.jl, Diffractor.jl, ...). That is, only if you intend to register the package in the General registry, otherwise you can name it GeometricAlgebra.jl as that's completely fine.

I am not so sure right now that there will be one main package to elicit to take the place of a canonical GeometricAlgebra.jl; it would be nice if there was, but probably there will always be several approaches to implementing GA that will have different uses for different contexts. At some point I think we could rename this GeometricAlgebra.jl to GeometricAlgebraBase.jl. The name GeometricAlgebra.jl would be sort-of implicitly "forbidden" (just like I don't think there is any AutomaticDifferentiation.jl).

Regarding your meta-question, I think https://github.com/orgs/JuliaGeometricAlgebra/discussions can be a good place (can you create new discussions?), otherwise feel free to create a geometric-algebra stream on Zulip (could be more discoverable by other people).

@eschnett and @ktchu feel free to chime in if you have any thoughts on the matter.

[ktchu]

@Jollywatt Great to meet you! Thanks for restarting the conversation on the JuliaGeometricAlgebra/GeometricAlgebra.jl package. I think we've all gotten a bit busy over the summer.

I agree with @serenity4's comments. In case it's helpful, I'll add one other idea to the mix.

• Local Registries Using local registries (https://github.com/GunnarFarneback/LocalRegistry.jl) might be a good interim way to release the different implementations of GeometricAlgebra.jl. That's the current approach that @wgvozdjak and I have taken for our implementation. As the types, interfaces, and tests defined by JuliaGeometricAlgebra/GeometricAlgebra.jl mature, the current plan is to have our implementation "derive" off of the JuliaGeometricAlgebra package to ensure compatibility.

  The local registry approach also helps to address some of your other concerns.

  • avoids the need to introduce unwieldy names for package users
  • allows you to release your Multivectors.jl package even though the package name is already taken in the General registry

Eventually, we may need to sort out how to use packages with the same name from different registries, but I think this is a low probability event in the near-term.

[chrisjldoran]

Hi everyone. I wanted to extend a discussion to this thread that I've started with @Jollywatt. I have been working on GA in Julia for a few years now, and together with a collaborator we have a new, optimised library ready to release. https://github.com/MonumoLtd/GeometricAlgebra.jl. This has some commercial support from a company I am working with.

I talked about the library at ICACGA last year, originally intending to call it SimpleGA. (I am also due to talk on this at JuliaCon this summer.) But using acronyms in package names is not encouraged and seeing that GeometricAlgebra is not taken we decided to use that name. Then I came across @Jollywatt's work and this thread. So I wanted to see what people think about registering this name, given your plans. My thoughts are:

• The library we have developed is low level and optimised. I want to use it as the basis for graphics work where I am going next (and I'll be encouraging people to join this effort at JuliaCon).
• The library is also very simple. It just implements the geometric product, projection and a few other operations. The intention is that this will be good for teaching as people can build there own work on top of this.
• The philosophy of 'geometric product first' is important, I believe, and consistent with Hestenes' development of Geometric Algebra. Once you have the geometric product you can build the exterior product and other things.
• So, basically, I'm making a pitch that this library can start to form the basis as an entry point for the subject, while not taking the fun out of things by implementing everything you could possibly want.
• But, I appreciate everyone has their own views on the 'right' way to develop a GA package and the ambition to keep GeometricAlgebra as more of a portal to the subject is an interesting one. Though I'm not sure how that would work in practice.

Anyway, let me know what you think. Personally I would like to use the GeometricAlgebra package name and talk about this at JuliaCon. I think there is plenty of scope to grow applications on top of this library while keeping the core simple. And obviously I am keen to work with as many people as possible to develop this.