GAlgebra v.s. Kingdon

[arsenovic]

there is modern library actively maintained by tbuli , https://github.com/tBuLi/kingdon

which does symbolic and numerics.

what are peoples thoughts on concentrating efforts on kingdon, and deprecating clifford/galgebra?

pygae/clifford#443

[utensil]

Kingdon is a great library covering both symbolic and numeric use cases, but as for the symbolic part, it doesn't cover the complete feature set of GAlgebra, for one, Geometric Calculus, and for another, it can't serve as the companion library for readers of LAGA&VAGC, nor does it aim to.

While new libraries like Kingdon are valuable additions to the ecosystem, I respectfully disagree that this warrants deprecating existing projects like GAlgebra.

As a maintainer and user, I’m seeking clarity on what deprecation would entail. As a user, I still intend to use it in the future. As a maintainer, although I can only come back to work on it on a yearly basis, but I still manage to respond to issues, and intend to release 0.6.0 in near future with features and fixes. Could you clarify:

• Would this deprecation affect GAlgebra’s availability on PyPI?
• Does the pygae organization intend to remove or archive GAlgebra?
• What urgent concerns motivate this proposal now, given ongoing maintenance efforts?

In my view, raising deprecation discussions without first outlining specific technical or maintenance challenges may inadvertently send mixed signals to users.

This is a short and prompt reply, I'll have a longer reply to provide more context of the current status of GAlgebra later. In the meanwhile, may we learn more about the rationale behind the proposal?

[arsenovic]

i should have said 'migrate' instead of 'deprecate'.
there are no intentions of altering anything about GAlgebra without your agreement.
i was opening up the discussion for consolidation of redundant libraries in the same language. but it sounds like they are not redundant and/or it doesnt make sense to consolidate.
i will close the issue for now.

[utensil]

Sorry that I reacted before reading pygae/clifford#443 . I can now see that there are two concrete proposals:

1. make a link on the homepage
2. move future users/devs to kingdon to consolidate effort in the GA python space.

For 1, I had opened #523 #524 with the idea to make GAlgebra more familiar to kingdon users, if/after I have done that, I'll acknowledge kingdon and ganja.js .

For 2, unlike clifford (although I'm not sure about the situation of clifford), GAlgebra consumes little efforts from the community, including mine, because it's now at a very late stage of its lifecycle, so there is no actual benefit of deprecation or migration.

People will use GAlgebra if they need to evaluate more options of GA, or if they need to use GC. If they have issues, I'm still here to respond, while Hugo and Eric have grown past the stage of using GAlgebra. From what I can tell, Hugo is busy with work and makes time for new open-source projects, Eric is busy with work and active in the field of Lean 4 formalization of GA and much much more. Personally I am in a status that I could have more time for open-source projects, but I have so much more to learn and work on so I don't always have time to work on GAlgebra. For example, I wished to release 0.6.0 before the end of 2024 because the heavy work of aborbing Greg's work has been done in 2024, but unfortunately I haven't got around to do that yet.

There is also no need to call for a new maintainer. There are very few users nowadays and they use GAlgebra at the very special stage of their work, mostly to verify their manual calculation in research or other projects. GAlgebra has many hacks towards LaTeX, so there is only humans to see the result of the symbolic simplification, not code generation. Without this to make it more useful, the users will come and go. GAlgebra was a helpful tool when I was learning GA and GC, that's pretty much it. My passion for maintaining GAlgebra comes from appriciating the work of Alan, and wishing to make it more reliable and modern, and it will last for the entirety of my life, which still has many years to come, given that I'm 38 years old. I need to admit that I didn't work on it enough during 2021-2023, because of work and Lean, but I think the future work of GAlegrba should be evaluated by decades, and it will slowly modernize its unique feature sets, by me and future maintainers that are passionate users at the beginning.

[mxfactorial]

how is performance compared between these libraries?

features are tested in clifford/clifford/test and galgebra/test

but only https://github.com/tBuLi/kingdon/blob/master/tests/performance_check.py is available

GitHub

kingdon/tests/performance_check.py at master · tBuLi/kingdon

A symbolically optimized Geometric Algebra library with PyTorch/NumPy/SymPy/etc. compatibility and ganja.js visualization. - tBuLi/kingdon

[utensil]

@mxfactorial Please open a new issue for (further) performance discussions, and open the issue regarding clifford in the clifford repo. Thanks!

Here's a quick answer:

TL;DR They are performance incomparable per their design goals.

1. Per my understanding, Clifford is designed as a numeric GA library to be reasonably fast as a Python library (which is mostly meant for low-barrier prototyping and exploration, and less designed for production), based on that, it makes use of native acceleration such as numba, to run faster, not to run as fast as possible;
2. Kingdon is designed to make use of a meta performance optimization technique inspired by enki's work on GAmphetamine.js, i.e. it symbolically simplifies most GA operations significantly before executing the computation, and it also makes use of native acceleration techniques available at a later time than the period when Clifford was actively developed; as a result, it's reasonable to expect it has better performance than Clifford, significantly faster in the best cases where the symbolic simplification applies, slightly faster in the worst cases only due to potentially better native accelerations; based on that, it's also agnostic to the underlying type to calculate, and symbolic type happens to be one of these types it supports, it's a preliminary exploration but satisfies many users of GA who won't concern themselves with GC or other advanced usage of GA;
3. GAlgebra is not designed as a numeric library, nor a symbolic optimization library, it was designed to be used to assist manual formula derivation, so it might even choose a naive or heavy implementation, for (more interpretable) correctness, so it's not comparable on performance with numeric libraries like Clifford or Kingdon; indeed it suffers from its own performance issues, but the optimization opportunity comes from only the optimization of its underlying symbolic calculation engine; unfortunately, there is no chance to gain an expected performance boost except for a total rewrite without using SymPy; I, as a maintainer of GAlgebra, consider it only as a reference implementation nowadays, and strive for correctness and test coverage based on best efforts.

[utensil]

As a side note, I used to evaluate GAlgebra in GAlgebra.jl by verifying identities in https://arxiv.org/abs/1205.5935 . I chose to write those tests in Julia simply because I like how I can write the code like math formulas, not for any technical reasons. That's where I experienced GAlgebra performance issues, for higher dimensions that can't be included in such tests that run at every CI.

That is, to answer your question directly, there is no performance check for GAlgebra at the moment.

For benchmark in GA world, you might find ga-benchmark interesting, it benchmarks native GA libraries, this is the most up-to-date fork which additionally benchmarks gafro for their paper. Unfortunately the code doesn't run out-of-box, but easy to fix for someone familiar with C/C++.

[mxfactorial]

Please open a new issue for (further) performance discussions

keeping the x vs y info in its ticket spares everyone from chasing it down across multiple tickets

They are performance incomparable per their design goals

subjecting design goals to performance tests has value

thanks for the link

[mxfactorial]

subjecting design goals to performance tests has value

https://crates.io/crates/geonum

[utensil]

subjecting design goals to performance tests has value

https://crates.io/crates/geonum

It's an amazing library. Did you also benchmark operations of full multivectors of 1000D?

[mxfactorial]

go ahead and fork

hit it with your best shot

[utensil]

go ahead and fork

hit it with your best shot

on vacation, will do when I am near a computer

[mxfactorial]

@arsenovic

https://github.com/mxfactorial/geonum/blob/develop/tests/em_field_theory_test.rs

    // demonstrate performance advantages of geometric numbers

    // traditional approach would scale with dimensionality due to matrix operations
    // geonum angle operations remain O(1) regardless of dimensionality

    // create million-dimensional field space for testing
    let high_dim = Dimensions::new(1_000_000);
    let start_time = Instant::now();

    // create field vectors in high dimensions
    let field_vectors = high_dim.multivector(&[0, 1]);
    let e_high = field_vectors[0];
    let b_high = field_vectors[1];

    // perform curl operation (90° rotation) in million dimensions
    let curl_e_high = e_high.differentiate();

    // maxwell equations in million dimensions with O(1) complexity
    let elapsed = start_time.elapsed();

    // test must complete quickly despite extreme dimensionality
    assert!(
        elapsed.as_millis() < 100,
        "High-dimensional curl should be O(1)"
    );

    // prove maxwell equations still hold in million dimensions
    // b_high angle should be e_high angle rotated by PI/2
    let expected_b_angle = Geonum {
        length: 1.0,
        angle: e_high.angle + PI / 2.0,
    };
    assert!(b_high.angle_distance(&expected_b_angle) < EPSILON);

    // curl_e_high angle should be e_high angle rotated by PI/2
    assert!(curl_e_high.angle_distance(&expected_b_angle) < EPSILON);

    // compare with theoretical O(n²) scaling of traditional approaches
    // traditional curl computation would require matrix operations scaling with dimensions
    // geonum requires just 1 operation regardless of dimensions

GitHub

geonum/tests/electromagnetic_field_theory_test.rs at main · mxfactorial/geonum

geometric number library supporting unlimited dimensions with O(1) complexity - mxfactorial/geonum

[mxfactorial]

git clone https://github.com/mxfactorial/geonum && cd geonum && cargo test --test multivector_test it_operates_on_high_dimensional_multivectors

running 1 test
test it_operates_on_high_dimensional_multivectors ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 2 filtered out; finished in 0.00s

https://github.com/mxfactorial/geonum/blob/develop/tests/multivector_test.rs

use geonum::*;
use std::f64::consts::PI;
use std::f64::consts::TAU;

#[test]
fn it_operates_on_high_dimensional_multivectors() {
    let space = Dimensions::new(1_000);

    // basis vectors with distinct angles to avoid wedge collapse
    let e1 = Geonum {
        length: 1.0,
        angle: space.base_angle(0),
        blade: 1,
    }; // angle 0, grade 1
    let e2 = Geonum {
        length: 1.0,
        angle: space.base_angle(1),
        blade: 1,
    }; // angle π/2, grade 1
    let e3 = Geonum {
        length: 1.0,
        angle: space.base_angle(3),
        blade: 1,
    }; // angle 3π/2, grade 1

    // step 1: construct bivector B = e1 ∧ e2
    let b12 = e1.wedge(&e2);
    let b12_mv = Multivector(vec![b12]);

    // assert bivector lives in grade 2
    let g2 = b12_mv.grade_range([2, 2]);
    assert!(g2.0.iter().any(|g| g.length > 0.0));

    // step 2: trivector T = (e1 ∧ e2) ∧ e3
    // create e3 as multivector
    let e3_mv = Multivector(vec![e3]);

    // ensure e3 has a different angle from the bivector to prevent wedge collapse
    let e3_rotated = Geonum {
        length: 1.0,
        angle: PI / 4.0,
        blade: 1,
    };

    // create trivector directly using wedge product between b12 and e3_rotated
    let t123 = b12.wedge(&e3_rotated);
    let t123_mv = Multivector(vec![t123]);

    // assert trivector has a nonzero component in grade 3
    let g3 = t123_mv.grade_range([3, 3]);
    assert!(g3.0.iter().any(|g| g.length > 0.0));

    // step 3: reflect e3 across bivector plane
    let reflected = e3_mv.reflect(&b12_mv);
    assert!(!reflected.0.is_empty());

    // step 4: compute dual of trivector and test result
    let pseudo = Multivector(vec![Geonum {
        length: 1.0,
        angle: PI / 2.0,
        blade: 1000,
    }]); // dummy pseudoscalar with high dimension
    let dual = t123_mv.dual(&pseudo);
    assert!(dual.0.iter().any(|g| g.length > 0.0));

    // step 5: rotate a vector using bivector rotor
    let v = Geonum {
        length: 1.0,
        angle: PI / 4.0,
        blade: 1,
    };
    let v_mv = Multivector(vec![v]);
    let rotated = v_mv.rotate(&b12_mv);
    assert!(rotated.0.iter().any(|g| g.length > 0.0));

    // step 6: project and reject vector from e3
    let proj = v_mv.project(&e3_mv);
    let rej = v_mv.reject(&e3_mv);
    assert!(proj.0.len() > 0 || proj.0.is_empty()); // test execution
    assert!(rej.0.len() > 0 || rej.0.is_empty());

    // step 7: confirm mean angle is finite and within expected bounds
    let mean = t123_mv.weighted_circular_mean_angle();
    assert!(mean >= 0.0 && mean <= TAU);
}

GitHub

geonum/tests/multivector_test.rs at develop · mxfactorial/geonum

geometric number library supporting unlimited dimensions with O(1) complexity - mxfactorial/geonum