On 03/05/2013 10:21 AM, tsc wrote:
Hi Alan,
Could you tell me what is the motivation for the base representation?
I had not seen that concept before. In Leo Dorst's book (Geometric
Algebra for Computer Science), multivectors are always represented as
linear combinations of blades. This works also in general metrics.
What do you think of this idea:
To simplify and possibly speed-up the code, we could assume for
internal computations that the metric is orthogonal. This would make
the base/blade distinction unnecessary, removing the need for
conversions and make the algorithms more straightforward. It would not
have to limit the functionality of the library since one can always
diagonalize a metric matrix (it is symmetric). In this way we can have
an internal representation on an orthogonal basis, while the user may
interact with the library using whatever basis is required (and that
basis is expressed as a linear combination of the orthogonal basis
vectors internally).
Your suggestion would depend on sympy's ability to diagonalize a general
symmetric matrix (I don't know how long it would take in general and you
might lose the advantage over my base/blade approach). Even if it can
do the diagonalization the result in many cases would be an algebraic
monstrosity (the elements of the transformation matrices would be very
complex). In my code if the metric is diagonal the base and blade
representations are identical and I only use the blade representation.
Likewise, if the metric is diagonal no multiplication tables are
calculated and all multiplicative operations (*,^,|,<, and >) are
calculated on the fly and every thing runs much faster. See test.py in
examples to see where general non-diagonal metrics are needed. What
would be of use would be to profile my code and see which routines are
hogging the execution time.
I would be interested to help out with the development of this
library. Is it hosted somewhere on a version control system
(git/svn/..)? Before you release this publically, I would suggest
making a clear distrinction between the public interface and the
private one. The public interface should express the mathematics while
the private interface may be concerned with a specific implementation.
If we don't do this, it will become very hard to make changes later
without breaking software that uses the library.
Best,
tsc
On Monday, March 4, 2013 10:09:40 PM UTC+1, brombo wrote:
On 03/04/2013 03:41 PM, tsc wrote:
Thank you very much for the quick reply and the code! I will
start to play around with the new code.
> Multivectors do not inherit from sympy symbols so solve does
not work.
How hard would it be to implement this? Is it only a (possibly
difficult, time consuming) programming exercise or is there a
fundamental reason why this is hard to do for GA equations? How
well do the solve routines deal with noncommutative symbols, for
instance?
I think there would be problems in solve due to the different
types of multivector multiplication. The documentation in GA.bip
goes into detail an to how the multivectors and operations are
implemented.
Regarding division, I suppose it wouldn't be too hard to
implement division for blades and simply check if the squared
norm is zero before dividing by it.
Regarding speed improvements for orthogonal bases: is there any
improvement for 'almost orthogonal' bases, such as the CGA
diag(1,1,1,1,-1) basis?
diag(1,1,1,1,-1) is an orthogonal basis (any metric tensor that is
diagonal gives an orthogonal basis).
How would you rate the new version of the software in terms of
stability and correctness?
The new version is simpler and uses sympy to do more of the heavy
lifting. I think it is much more reliable. Also I have been
working in collaboration with Alan Macdonald to provide the
software for his new book on geometric calculus so that we have
gone through many more examples. Two people can break code much
faster than one. Look at the examples in the example directory,
specifically test.py and test_latex.py. Note that the Latex doc
gives detailed instructions on how to install the module and get
it working with latex.
Best,
tsc
On Sunday, March 3, 2013 5:10:53 PM UTC+1, brombo wrote:
On 03/03/2013 08:07 AM, tsc wrote:
I've just found the sympy GA module, and I must say it looks
really neat! I'd like to use it for automatic
differentiation and equation solving in high-dimensional
conformal geometric algebra. While experimenting with the
module, I've run into a few problems though. I'm not
familiar with sympy internals, so before I dive into the
source of this module to fix things, I'd like to see if
anyone can tell me if these are really bugs or if I'm
misunderstanding something.
All examples below are run in isympy, just pulled from
github. I initialized with:
from sympy.galgebra.GA <http://sympy.galgebra.GA> import *
e1,e2,e3= MV.setup('e1 e2 e3', '1 0 0, 0 1 0, 0 0 1')
1. Division:
When I perform e1 / e1, I get an error: "TypeError:
unsupported operand type(s) for /: 'MV' and 'MV'". Is
this not implemented? For non-null vectors (i.e. x >> x
!= 0), the inverse is x / (x >> x). The inverse of a
product of invertible vectors is just the reverse
product of the inverses. For an invertible blade A, this
reduces to A / (A >> A).
2. Solving equations:
I tried to solve some basic equations, e.g.
>> solve( (x - e1) * e2, x)
_1*e1e2/e2
This is correct, but strangely it involves division
which doesn't appear to work when typed into the
terminal. Other examples that act strange:
>> solve( (x - e1) >> e2, x)
[]
>> solve( (x - e1) | e2, x)
[0]
Even though | and >> should both implement contraction.
3. Efficiency:
I tried MV.setup on some high-dimensional algebras, and
noticed that it takes very long to initialize beyond
n=8. The multivector basis is 2^n, so a slowdown is to
be expected, but 2^8 = 256, which seems a bit low. Would
it be possible to speed up the implementation, e.g.
using bitarray
<https://pypi.python.org/pypi/bitarray> to represent the
presence or absence of a multivector basis element, and
compute products using a combination of scalar
multiplication on numpy arrays and bitwise operations on
bitarrays?
4. Notation for outer product and powers:
I find the notation '**' for the wedge product
confusing. Consider typing this into a terminal:
>> e1*e1
e1**2
>> e1**2
2*e1
Why is the result of e1*e1 (e1 squared) written in the
usual python exponentiation notation e1**2, while at the
same time we cannot use that notation to perform
exponentiation? I think it would be best to use ** for
exponentiation, since that is the python standard. We
can use ^ for the wedge, which is visually most natural
anyway.
5. Contraction with scalar doesn't work.
When I compute e1 >> 2, or any other contraction with a
scalar, I get None. The correct results is 0 when a
(multi)vector is contracted onto a scalar. When a scalar
is contracted onto a multivector, the result should be
the same as scalar multiplication.
If I can make it all work I might be interested in
implementing a module for conformal GA, and one for linking
sympy to GAViewer. The latter would make it possible to
visualize results from symbolic computations in a 3D viewer.
Thanks in advance for any help!
--
You received this message because you are subscribed to the
Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at
http://groups.google.com/group/sympy?hl=en
<http://groups.google.com/group/sympy?hl=en>.
For more options, visit
https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
I forgot to mention that the attached file in the previous
response is named GA.bip but is really GA.zip. I was renamed
so that certain mail programs would not reject the attachment.
--
You received this message because you are subscribed to the
Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected] <javascript:>.
To post to this group, send email to [email protected]
<javascript:>.
Visit this group at http://groups.google.com/group/sympy?hl=en
<http://groups.google.com/group/sympy?hl=en>.
For more options, visit https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
You received this message because you are subscribed to the Google
Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
