The algorithm for general inversion seems to work OK, but the documentation
is seriously confusing, including http://clifford.readthedocs.io/en/latest/ .
From __init__() :

The inverses found are sometimes dependant [sic] on the order of multiplication.

etc. etc.

The only circumstance under which this situation might conceivably arise is
that both are unusably inaccurate, as a consequence of the argument being
approximately singular. Which could in principle be detected by inspecting
the size of the determinant relative to expected rounding error _eps ; a
simpler fix might just inspect __nonzero__( leftLaInv() - rightLaInv() ) .

Ideally I recommend completely expunging
leftInv() , rightInv() , normalInv() ;
and further removing from user documentation
leftLaInv() , rightLaInv() ,
leaving only inv() visible. A warning about potential ill-conditioning for
approximately singular arguments might also be attached.

A fuller discussion of the Clifford inverse has been posted at
https://github.com/FredLunnon/ClifFred/blob/master/inverse.txt

WFL

cd /Users/fred/fred/clifford-master; python

Instantiate algebra and unit vectors

from clifford import *;
p,q,r = 2,0,0; # r = 0 !
GAlayout, GAblades = Cl(p, q);
(e0, e1) = ( GAblades[GAlayout.names[k+1]] for k in range(0, p+q) );

Bug in add, subtract, multiply, divide by SymPy real: attribute error

from sympy import sqrt;
e1/e1.mag2(); # e1 OK!
e1/sqrt(e1.mag2()); # AttributeError: 'One' object has no attribute 'inv'
e1*sqrt(e1.mag2()); # ditto
sqrt(e1.mag2()) + e1; # ditto
e1 - sqrt(e1.mag2()); # ditto

minor organization questions for https://github.com/pygae.

@hugohadfield, @moble, @tingelst,

1. i had a hard time to come up with a name. is the name agreeable?
2. should i move the clifford repo to pygae, instead of fork it?
3. would it make sense to do the same for pyversor?

Dealing with arrays of geometric objects is very important for real world applications. This is an area in which I think we can make a lot of progress and would add a lot of value and ease of use to a person building applications with this library. The ConformalMultivectorArray class that I started creating shows some examples of the kind of operations that I find really useful. I don't know if anyone else has opinions on this but from my perspective this in conjunction with a complementary serialisation scheme for multivectors would really make my work easier

We should be automatically releasing to pypi when the travis builds succeed but as the builds have been broken for a while we have had a release. As there are quite a few improvements etc to the clifford package since the last release we should make sure to do this soon

Here is the project:
https://github.com/airspeed-velocity/asv
This, in conjunction with some example application benchmarks, would let us see what changes are worthwhile performancewise

Hi,
I am using clifford for mathematical computation of conformal geometric algebra. I want to get the angle between two planes, but the caculated output has only 5 number after decimal point. For example, we can use inner product to caculate the angle between plane one and plane two, if the angle is 30 degree,the answer caculated is 29.999473308300235-not acurate enough. So, how can I get more accurate caculation?
The code is below, as I am new to clifford, I am not sure the code below for the caculation whether true or not.The IDE is jupyter notebook.
Thank you

import numpy as np
from clifford import Cl, conformalize
G2,blades_g2=Cl(3)
G3c,blades_g3c,stuff=conformalize(G2)
locals().update(blades_g3c)
locals().update(stuff)
I = eo^e1^e2^e3^einf
plane0 = 1*e2+1*einf
p0 = up(eo)
p1=up(np.sqrt(3)/2*e1+0.5*e2)
p2=up(e3)
plane1=p0^p1^p2^einf
plane1.normal()
plane0_star = plane0*I.inv()
plane0_star|plane1/(abs(plane0)*abs(plane1))  #the answer is 0.86603,can this be more accurate?
np.arccos(0.86603) *180/pi  # the answer is 29.999473308300235

since blades are in layout, Cl() doesnt need to return a tuple of layout, blades, rather it could just return layout. this would make for mildly cleaner code. this will break things, so its worth considering. also i think we could consider changing Cl() to ga(), so we can write

g3 = ga(3)

could even remove the a, so its g3 =g(3), since its a method. which brings up the point, why are we not just using the layout constructor? couldnt the stuff in Cl() be moved into Layout.__init__? and why isnt Layout called Ga or G or whatever,

One feature which might be of interest could be support for multiple computational backends.

here is a toy example to demo the idea that i made a while ago.

https://gist.github.com/arsenovic/125cb38cbfe3008e5f417b18267c845d

There's currently errors on https://clifford.readthedocs.io/en/latest/PerformanceCliffordTutorial.html

AttributeError: 'Layout' object has no attribute 'gmt'

Needs a fix?

Screenshot:

I have put in a load more improvements to the conformal tools since our last release and we have squashed a couple of significant bus since our last release:
835740b
#67
So maybe time to put out another?

In certain high-dimensional applications we only make use of a subspace of grades. For example the Cl(n) Clifford algebra grows in dimensionality by O(2^n) while using only blades of grade k = 1 and k = n - 1 grows linearly by O(2n).

I wrote a quick naive implementation just to test initiation times, the kr argument is used to specify a list of desired grades.

Stefan-Endres@81c78c3

>>> cf.Cl(4, kr=[1, 3])
(Layout([1, 1, 1, 1], [(), (1,), (2,), (3,), (4,), (1, 2, 3), (1, 2, 4), (1, 3, 4), (2, 3, 4)], 
firstIdx=1, 
names=['', 'e1', 'e2', 'e3', 'e4', 'e123', 'e124', 'e134', 'e234']), 
{'e1': (1^e1), 'e2': (1^e2), 'e3': (1^e3), 'e4': (1^e4), 
'e123': (1^e123), 'e124': (1^e124), 'e134': (1^e134), 'e234': 
(1^e234)})

>>> cf.Cl(4)
(Layout([1, 1, 1, 1], [(), (1,), (2,), (3,), (4,), (1, 2), (1, 3), (1, 4), (2, 3), (2, 4), (3, 4), (1, 2, 3), (1, 2, 4), (1, 3, 4), (2, 3, 4), (1, 2, 3, 4)], 
firstIdx=1, 
names=['', 'e1', 'e2', 'e3', 'e4', 'e12', 'e13', 'e14', 'e23', 'e24', 'e34', 'e123', 'e124', 'e134', 'e234', 'e1234']), 
{'e1': (1^e1), 'e2': (1^e2), 'e3': (1^e3), 'e4': (1^e4), 
'e12': (1^e12), 'e13': (1^e13), 'e14': (1^e14), 'e23': (1^e23), 'e24': (1^e24), 'e34': (1^e34),
'e123': (1^e123), 'e124': (1^e124), 'e134': (1^e134), 'e234': (1^e234), 'e1234':
(1^e1234)})

Some basic operations such as mutlivector addition, grade projection etc. are preserved nicely. Others such as dual (in cases where the result is an initiated grade) and reflection are not.

The initiation time growth isn't as promising as I'd hoped for either, but could possibly be drastically improved with a less naive implementation. In particular 99.1% of the initiation is spent in this loop in _getEvenOdd:

There is a comment in the code that states the loop runs for grade! permutations, however, at the moment it is unclear to me how the rest of the algebra and code will be affected when I change the range of these permutations or if it is even still looping for all the canonical grades at the moment. Especially when supplied with more arbitrary grade ranges.

Initiation times:

cf.Cl(4)
Initiation time: 0.22497177124023438
cf.Cl(4, kr=[1, 3]) 
Initiation time: 0.0009617805480957031
cf.Cl(5)
Initiation time: 0.009763717651367188
cf.Cl(5, kr=[1, 4]) 
Initiation time: 0.0020651817321777344
cf.Cl(6)
Initiation time: 0.0555272102355957
cf.Cl(6, kr=[1, 5]) 
Initiation time: 0.010433673858642578
cf.Cl(7)
Initiation time: 0.41026782989501953
cf.Cl(7, kr=[1, 6]) 
Initiation time: 0.08707642555236816
cf.Cl(8)
Initiation time: 4.242865324020386
cf.Cl(8, kr=[1, 7]) 
Initiation time: 1.0086712837219238
cf.Cl(9)
Initiation time: 61.97481608390808
cf.Cl(9, kr=[1, 8]) 
Initiation time: 15.875498056411743
# cf.Cl(10) did not initiate after several minutes 
f.Cl(10, kr=[1, 9]) 
Initiation time: 329.20880341529846

cProfile for cf.Cl(9, kr=[1, 8]:

I would be happy to contribute as much as possible under the direction of the developers.

Regards,
Stefan Endres

this blows up for euclidean e12

theta = linspace(0,20*pi,101)
[e**(t*e12) for t in theta]

We should build and upload wheel files with our releases, would allow us to be hosted on pyiodide
https://alpha.iodide.io/notebooks/2805/

@rkern or @moble, do either of you know why this happens?

import numpy as np
from clifford import Cl 
layout,blades = Cl(2) # note i changed firstIdx=1 by default in Cl
locals().update(blades)

np.array([e1,e2],dtype=np.object) 

yields

array([[0, 1, 0, 0],
       [0, 0, 1, 0]], dtype=object)

perhaps there are some special array-like methods that Multivector implements? is there a way to have an array of multivectors, instead of an array of their values?

I just installed the package (v 0.8) using pip, loaded some example code:
from numpy import e, pi from clifford.g3 import * # import GA for 3D space

and got an error:
../python3.6/site-packages/clifford/__init__.py", line 306
raise ValueError, "names list of length %i needs to be of length %i"% (len(names), self.gaDims)
^
SyntaxError: invalid syntax

Unable for format it right but the error points to the comma after raise ValueError
Seems the package might be a bit outdated?

Thanks for the heads up @enkimute

Currently we only really have tests implemented for (4,1) and (3,0). The library however should support a range of algebras, it would be fantastic to create some super basic tests for space time algebra and any other useful algebras that people care about. Unfortunately I know very little about STA etc so cannot really do much here...
Maybe @arsenovic or @moble you guys might be able to suggest some STA tests?

i am working on changing the operators (on this branch) to match those in galgebra: ie &->* and from *->|

however, i am getting some strange behavior which i dont undertand, which seems to be related to some operator overloads with numpy dtypes. it appears as though the float64.__add__ is taking precedence over cliffords MultiVector.__radd__. not sure why the operator changes created this problem.

@moble, @rkern perhaps you all have some ideas on how to solve this?

here is demo of error,
https://gist.github.com/13b0ee10dde76817c79aab567b682efa

Docs still aren't building on rtd, maybe we should move to github pages?

https://travis-ci.org/pygae/clifford/jobs/598229672#L1943

Error is

RemoveError: 'setuptools' is a dependency of conda and cannot be removed from
conda's operating environment.

I am working on some reports/papers that will need to cite this package, we should come up with some strategy for this... my current plan:

@Misc{clifford_python,
author =   "{The Pygae Team}",
title =    {clifford: Numerical geometric algebra module for python},
howpublished = {\url{https://github.com/pygae/clifford}}
}

Any opinions?

Comparison in MultiVector._checkOther compares ids of layout objects rather than contents of the layout instead. This is a problem when operating with instances of the algebra created with copy.deepcopy() applied to the MultiVector as the contents of the layouts will be the same but the ids of the objects will be different. A quick hack fix is to implement an eq and ne method for the layout class:

def __eq__(self, other):
  return self.__str__() == other.__str__()
def __ne__(self, other):
  return not self.__eq__(other)

and change MultiVector._checkOther to use != rather than 'is not'.

Obviously getting the layout as a string and comparing these values is not the best serialisation and comparison scheme. Any detailed comparison of the full contents of the class is likely to affect performance somewhat but I think some kind of comparison of core pieces of information from the layout would be worthwhile instead of the id comparison currently used.

While numba is still giving us problems we should check in import whether it works and disable it if not
This issue contains a pretty minimal reproducer: numba/numba#3671

I have just bumped the version number to v0.83 to test how the latest tools work with GAOnline etc and to check they work on Azure/other online notebooks.... It would be good to do a better release for AGACSE (I'm gonna start writing doc strings now :)), not really sure how versioning numbers should work but looking at this: https://semver.org/ we might want to make it v0.90 or maybe we bump to v1.0...

Either way it would be good to release by the end of the week!

I am currently seeing a test failure in the numba-integration-testing framework:

======================================================================
FAIL: test_general_logarithm_rotation (test_g3c_tools.TestGeneralLogarithm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/circleci/repo/clifford/test/test_g3c_tools.py", line 95, in test_general_logarithm_rotation
    np.testing.assert_almost_equal(biv_2.value, biv_3.value, 3)
  File "/home/circleci/repo/miniconda3/envs/clifford/lib/python3.7/site-packages/numpy/testing/_private/utils.py", line 572, in assert_almost_equal
    return assert_array_almost_equal(actual, desired, decimal, err_msg)
  File "/home/circleci/repo/miniconda3/envs/clifford/lib/python3.7/site-packages/numpy/testing/_private/utils.py", line 1007, in assert_array_almost_equal
    precision=decimal)
  File "/home/circleci/repo/miniconda3/envs/clifford/lib/python3.7/site-packages/numpy/testing/_private/utils.py", line 819, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 3 decimals

Mismatch: 9.38%
Max absolute difference: 1.38089358
Max relative difference: nan
 x: array([-0.000e+00, -0.000e+00, -0.000e+00, -0.000e+00, -0.000e+00,
       -0.000e+00,  1.535e-05, -6.327e-06, -0.000e+00, -0.000e+00,
        5.405e-06, -0.000e+00, -0.000e+00, -0.000e+00, -0.000e+00,...
 y: array([ 0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  1.381, -0.569,
        0.   ,  0.   ,  0.486,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,
        0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,
        0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ])

----------------------------------------------------------------------

The build log can be seen here: https://circleci.com/gh/numba/numba-integration-testing/323

because rtd is not working i setup the gh-pages. a preview,

https://arsenovic.github.io/docs/v0.82/

i also went ahead and re-structured the docs, to make the API more usable. take a look and let me know what you think. the source for this is in the branch

https://github.com/arsenovic/clifford/tree/oo_cga

this branch also contains the object oriented cga stuff. ( sorry to mix topics on a single PR.)

i think we should refactor hugo's stuff into the OO format, but its up to him. perhaps we can keep it out of OO and have it in OO simultaneously.

i will write a little how-to for the doc building, when this branch is done.

currently the version info is independently stored in

• a git tag
• clifford/init.py
• setup.py
• docs/conf.py

a conda-forge teamate suggested rever, https://regro.github.io/rever-docs/, i will look into it.

also using github released tar/zips doesnt seem to be working with conda-forge for every release. looks like deleting branches changes the checksum or something, regro/cf-scripts#327 (comment) ... bummer.

The current implementations are fairly slow and could do with an optimisation pass, probably implementing some of Leo Dorsts algorithms. They also need some more tests to make sure they don't get broken in the process.

Is there any interest in adding null bases to the metric? This enables GA to implement euclidean spaces in projective geometry. By limiting the metric to positive and negative bases as it is now, only spherical and hyperbolic spaces are implemented. Projective geometry has many benefits such as calculating distances between points, lines, and higher dimensional objects. The downside is that the pseudoscalar cannot be used to generate the dual space.

I spoke to Brombo about this issue several years ago, but he was not interested in adding null bases because it made generating the dual space more difficult.

For performance reasons is might be nice to have a set of cached algebras available to the user. These could be generated at install or manually after install, depending on the users needs.

https://gist.github.com/arsenovic/4639ab4144d91376edf07a4842fa910c

@moble @hugohadfield thoughts?

Excerpt from these lines:

======================================================================
FAIL: test_motor_between_rounds (clifford.test.transplant_class.<locals>.C)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/pygae/clifford/clifford/test/test_g3c_tools.py", line 635, in test_motor_between_rounds
    np.testing.assert_almost_equal(C2.value, C3.value, 3)
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/numpy/testing/_private/utils.py", line 568, in assert_almost_equal
    return assert_array_almost_equal(actual, desired, decimal, err_msg)
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/numpy/testing/_private/utils.py", line 973, in assert_array_almost_equal
    precision=decimal)
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/numpy/testing/_private/utils.py", line 789, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 3 decimals
(mismatch 6.25%)
 x: array([-0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,
       -0.   , -0.   ,  0.   , -0.   , -0.   , -0.   , -0.   , -0.   ,
        0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,
        0.   ,  0.   , 20.374, 20.374,  0.862, -0.47 ,  0.19 ,  0.   ])
 y: array([ 0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   , -0.   ,  0.   ,
        0.   ,  0.   ,  0.   , -0.   , -0.   , -0.   , -0.   ,  0.   ,
        0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,  0.   ,
        0.   ,  0.   , 20.542, 20.542,  0.862, -0.47 ,  0.19 ,  0.   ])
-------------------- >> begin captured stdout << ---------------------
random_point_pair 2
random_circle 3
random_sphere 4
(20.37353^e1234) + (20.37354^e1235) + (0.86168^e1245) - (0.47045^e1345) + (0.1897^e2345)
(20.54226^e1234) + (20.54227^e1235) + (0.86168^e1245) - (0.47045^e1345) + (0.1897^e2345)
--------------------- >> end captured stdout << ----------------------

it will likely be useful to be have the ability to serialize and perhaps eventually transfer objects to other GA computational systems. the __repr__() methods of Layout and Multivector provide an outline of how to do this.

for non-orthogonormal bases, a the layout's signature should be a tensor.

currently, signature only supports a list of signs {+1, -1}.

Using the numba extension interface
https://numba.pydata.org/numba-doc/latest/extending/interval-example.html
We should be able to create a multivector type that numba understands and can work with directly. This would vastly improve the readability and quality of the jitted library code.

We should implement at least the operators:

• a + b (gh-332)
• a - b (gh-332)
• a * b (gh-332)
• a ^ b (gh-332)
• a | b (gh-332)
• a / b
  • b scalar (gh-333)
  • b multivector, general inverse
• a << b
• ~a (gh-333)
• -a (gh-333)
• +a (gh-333)
• a(b) (for integer b) (gh-336)

i think the up and down methods of conformalize() should take/return vectors in the different algebras:

• up should operate on vectors in ga, and
• down should operate on vectors in cga

we could overload each method to work on vectors in either algebra. here is a quick way to do it,

from numpy import zeros
from clifford import Cl

ga,blades = Cl(2)
cga,blades,stuff = conformalize(ga)
def up(x):
    old_val = x.value
    new_val = zeros(cga.layout.gaDims)
    new_val[:len(old_val)] = old_val
    x_in_cga =  cga.MultiVector(value=new_val)
    #do normal up method on x_in_cga

and similar for down .what do you think? also, we need a consistent name for the algebra that is conformalized, like original, lower, whatever.

Following https://clifford.readthedocs.io/en/latest/Installation.html, I tried the following in a Conda Python 3 environment:

pip install clifford

It fails with the following error(only the relevant part ):

Building wheels for collected packages: future, llvmlite
(omitted)
-- Detecting CXX compile features - done
  CMake Error at CMakeLists.txt:9 (find_package):
    Could not find a package configuration file provided by "LLVM" with any of
    the following names:

      LLVMConfig.cmake
      llvm-config.cmake

    Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
    "LLVM_DIR" to a directory containing one of the above files.  If "LLVM"
    provides a separate development package or SDK, be sure it has been
    installed.


  -- Configuring incomplete, errors occurred!
  See also "E:/Temp/pip-install-zgckej4r/llvmlite/ffi/build/CMakeFiles/CMakeOutput.log".
  Trying generator 'Visual Studio 14 2015 Win64'
  Traceback (most recent call last):
    File "E:\Temp\pip-install-zgckej4r\llvmlite\ffi\build.py", line 167, in <module>
      main()
    File "E:\Temp\pip-install-zgckej4r\llvmlite\ffi\build.py", line 155, in main
      main_win32()
    File "E:\Temp\pip-install-zgckej4r\llvmlite\ffi\build.py", line 93, in main_win32
      try_cmake(here_dir, build_dir, generator)
    File "E:\Temp\pip-install-zgckej4r\llvmlite\ffi\build.py", line 28, in try_cmake
      subprocess.check_call(['cmake', '-G', generator, cmake_dir])
    File "E:\Miniconda3\envs\py3\lib\subprocess.py", line 311, in check_call
      raise CalledProcessError(retcode, cmd)
  subprocess.CalledProcessError: Command '['cmake', '-G', 'Visual Studio 14 2015 Win64', 'E:\\Temp\\pip-install-zgckej4r\\llvmlite\\ffi']' returned non-zero exit status 1.
  error: command 'E:\\Miniconda3\\envs\\py3\\python.exe' failed with exit status 1

  ----------------------------------------
  Failed building wheel for llvmlite
  Running setup.py clean for llvmlite
Successfully built future
Failed to build llvmlite

I believe this dependencies and possible trouble shooting should be addressed in doc. But anyway, as long as it's a native building problem, we can alway see if conda can help:

conda install clifford

Then there's PackagesNotFoundError.

So I take a look at https://github.com/pygae/clifford/blob/master/azure-pipelines.yml and tried the following:

conda install -y future h5py nose pytest setuptools scipy numpy
conda install -y numba=0.40.1
pip install clifford

Everything went smoothly, time to use clifford! Unfortunately:

>python
Python 3.6.8 |Anaconda, Inc.| (default, Feb 21 2019, 18:30:04) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from clifford.tools.g3c import random_line
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "E:\Miniconda3\envs\py3\lib\site-packages\clifford\tools\g3c\__init__.py", line 133, in <module>
    from clifford.tools.g3 import quaternion_to_rotor, random_euc_mv, \
  File "E:\Miniconda3\envs\py3\lib\site-packages\clifford\tools\g3\__init__.py", line 49, in <module>
    from clifford.g3c import *
  File "E:\Miniconda3\envs\py3\lib\site-packages\clifford\g3c.py", line 3, in <module>
    layout_orig, blades_orig = Cl(3)
  File "E:\Miniconda3\envs\py3\lib\site-packages\clifford\__init__.py", line 2286, in Cl
    layout = Layout(sig, bladeTupList, firstIdx=firstIdx, names=names)
  File "E:\Miniconda3\envs\py3\lib\site-packages\clifford\__init__.py", line 620, in __init__
    self._genTables()
  File "E:\Miniconda3\envs\py3\lib\site-packages\clifford\__init__.py", line 719, in _genTables
    np.array(self.sig))
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\dispatcher.py", line 367, in _compile_for_args
    raise e
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\dispatcher.py", line 324, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\dispatcher.py", line 655, in compile
    cres = self._compiler.compile(args, return_type)
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\dispatcher.py", line 82, in compile
    pipeline_class=self.pipeline_class)
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\compiler.py", line 904, in compile_extra
    return pipeline.compile_extra(func)
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\compiler.py", line 367, in compile_extra
    return self._compile_bytecode()
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\compiler.py", line 835, in _compile_bytecode
    return self._compile_core()
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\compiler.py", line 822, in _compile_core
    res = pm.run(self.status)
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\compiler.py", line 253, in run
    raise patched_exception
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\compiler.py", line 244, in run
    stage()
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\compiler.py", line 539, in stage_parfor_pass
    parfor_pass.run()
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\parfor.py", line 682, in run
    self.array_analysis.run(self.func_ir.blocks)
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\array_analysis.py", line 906, in run
    equiv_set = equiv_set.intersect(from_set)
  File "E:\Miniconda3\envs\py3\lib\site-packages\numba\array_analysis.py", line 537, in intersect
    assert(len(varlist) > 0)
AssertionError: Failed in nopython mode pipeline (step: convert to parfors)

I haven't figured out what these mean yet, just searched that there's no similar issue and opened this one.

After installing the package from conda-forge, is it possible to run the test-suite?

From the docs for nose:

Nose has been in maintenance mode for the past several years and will likely cease without a new person/team to take over maintainership. New projects should consider using Nose2, py.test, or just plain unittest/unittest2.

Pytest seems to be the standard in the scientific python ecosystem

Hi Alex,

Having seen your issues raised with pyversor (tingelst/pyversor#7) I agree entirely that something should be done to improve the python GA tooling.
@ereide and I work extensively with this library at Cambridge. From our perspective the key advantages that it offers are:

1. Syntax -> Close to the math (minus the operator precedence issues)
2. Distribution -> All the requirements of the package are part of the standard python scientific ecosystem. It does not require a complex build process and is available with pip. This massively reduces the barriers to getting started.

The disadvantage of this library:

1. Performance. As you have previously mentioned the matrix multiplication basis of the library is very inefficient and prevents it from being realistically useful in large applications.

What do you see as the future of this project? Do you intend to continue developing it performance-wise?
If so, what do you think needs to be done? and how can I help?

does anyone see a benefit to consolidate the modern GA projects under a single github group or something similar?

pygae -> gae?

we could retain individual ownership of each repo, and i suppose it would be largely symbolic, but with hopes to,

• keep us up-to-date with other project's features, publications,etc
• allow us to share resources/knowledge/users
• force a justification of why we are developing separate packages
• make it easier for users to choose a project

my thought is that we could have a group page pointing people to the project that suits their needs. current list of projects i am aware of

• clifford
• versor @wolftype
  • pyversor
  • versor.js @weshoke
• ganja @enkimute
• quaternion

thoughts? is timing with regard to AGACSE important ?

Pardon me asking this here in the form of an issue. I am not sure what a more relevant place would be. Whack me with a clue-stick if there is a better place.

I recently started climbing the learning curve on GA. Read MacDonald, am working through Dorst's GA for CS (not very far yet), watched Mathoma's Youtube vids (excellent BTW) and also Alex's (810labs) Smith Chart Youtube, which I found highly motivating. And now I try to apply GA, and crash and burn. For context: my ultimate interest is robot arm inverse kinematics, perhaps computer vision.

So a couple questions:

1. Is there a better place for GA discussion and general questions, like a forum or such?

2. For starters, I thought I would try to do some simple things with a plane geometry model. Simple E(2) constructions in conformal G(3,1) or homogeneous G(3). I have not been able to make the leap. Any pointers to good resources?

3. I think it would be helpful to noobs like me to add some really basic examples for some of these practical things I am trying to learn. So... since it would be good motivation and keep me from taking shortcuts... I would make some PR's to add them if that is of any interest. Assuming I can learn enough to actually make them work.

As part of my research I have to work with large arrays of multivectors, often they are blades and thus very sparse. Currently I have no really good solution to storage and transmission of these arrays.

Ideally we would have some kind of file format that encodes the sparse multivectors and contains header information about what algebra they come from etc.

Before I put too much thought into this in isolation I thought I might consult the wider community and see if we can come up with something/adopt some existing format that others might know better than me!

So @arsenovic @moble @enkimute @tingelst @utensil @chrisjldoran @darkshikamo @penguian anyone got any smart ideas for a good numerical multivector file format that we might aim to make a standard?

Initialisation timings Cl(6) 0.195 sec, Cl(7) 3.7 sec, Cl(8) 2.5 mins :
building multiplication table as n -> n+1 costs 20x, 40x longer,
instead of expected ~5.3x .
Why is it necessary to search an (evidently very large) table at all?

python

import timeit; 
from clifford import *;  

secs = timeit.default_timer(); 
Cl(6); 
secs = timeit.default_timer() - secs; 
"Elapsed time in secs ", secs;  # 0.195 sec 
secs = timeit.default_timer(); 
Cl(7); 
secs = timeit.default_timer() - secs; 
"Elapsed time in secs ", secs;  # 3.7 sec 
secs = timeit.default_timer(); 
Cl(8); 
secs = timeit.default_timer() - secs; 
"Elapsed time in secs ", secs;  # 148 sec 

Cl(8); 
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "clifford/**init**.py", line 1653, in Cl
    layout = Layout(sig, bladeList, firstIdx=firstIdx, names=names)
  File "clifford/**init**.py", line 302, in **init**
    self._genTables()
  File "clifford/__init__.py", line 476, in _genTables
    list(self.bladeList[j]))
  File "clifford/__init__.py", line 448, in _gmtElement
    elif newBlade in self.even.keys():
KeyboardInterrupt
# Interrupted after minutes: always at same line!

Could we bump the version in pypi to the latest in master?

There is still quite a bit of low hanging fruit performance-wise around the algebra generation setup. Currently we swap between tuples of grades, bitmaps and indices into the mv value array pretty liberally, eliminating this and jitting the remaining functions would allow us to speed up the generation quite a lot as well as allowing us to lean on the automatic parallelisation capabilities in numba and potentially even adding a cuda generation option.

Additionally @enkimute has suggested a nice loop free bitcount method that could add additional performance:
enkimute/ganja.js#17 (comment)

TODO

I want to write a load of tests for this library as I have a lot of code depending on it and have a range of core implementation related changes I want to add.
I am struggling to think of some good tests that are applicable across multiple algebras as my main experience is with Cl(3) and Cl(4,1).

In an ideal world what tests would people like to see implemented?
Shall I just write some (3) and (4,1) specific tests?

My system is throwing errors for the following basic code

Solver.py

from numpy import e,pi
import clifford as cf

layout, blades = cf.Cl(2)

I tried installation via pip and setup.py. But both failed.
Tried on both WSL (ubuntu 16.04) and Windows 10.
Python on both systems was 3.5
The error is consistent across all formats.

Thanks

Error

(venv) akash@DESKTOP-6S41RA1:/mnt/c/Users/Akash/Documents/project/webapp/solver/Solver$ python Solver.py
Traceback (most recent call last):
File "Solver.py", line 4, in
layout, blades = cf.Cl(2)
File "/home/akash/venv/lib/python3.5/site-packages/clifford-1.0.2-py3.5.egg/clifford/init.py", line 2260, in Cl
File "/home/akash/venv/lib/python3.5/site-packages/clifford-1.0.2-py3.5.egg/clifford/init.py", line 594, in init
File "/home/akash/venv/lib/python3.5/site-packages/clifford-1.0.2-py3.5.egg/clifford/init.py", line 693, in _genTables
File "/home/akash/venv/lib/python3.5/site-packages/numba/dispatcher.py", line 348, in _compile_for_args
error_rewrite(e, 'typing')
File "/home/akash/venv/lib/python3.5/site-packages/numba/dispatcher.py", line 315, in error_rewrite
reraise(type(e), e, None)
File "/home/akash/venv/lib/python3.5/site-packages/numba/six.py", line 658, in reraise
raise value.with_traceback(tb)
numba.errors.TypingError: Failed in nopython mode pipeline (step: convert to parfors)
Invalid use of Function() with argument(s) of type(s): (int64, int64)

• parameterized
  In definition 0:
  All templates rejected with literals.
  In definition 1:
  All templates rejected without literals.
  This error is usually caused by passing an argument of a type that is unsupported by the named function.
  This is not usually a problem with Numba itself but instead often caused by
  the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/dev/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/dev/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new