On Mar 5, 2013, at 8:21 AM, tsc <taco.co...@gmail.com> 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).
I would be interested to help out with the development of this library. Is
it hosted somewhere on a version control system (git/svn/..)?
Alan, I would recommend creating a pull request with the work you have so
far. That way, people can easily follow the changes, and furthermore,
easily send you pull requests. And if the new module is in a working state,
we can just merge it in (don't worry if the API isn't smoothed out yet. I
don't foresee a release any time soon).
Let us know if you need help with the git.
Aaron Meurer
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 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 sympy+un...@googlegroups.com.
>> To post to this group, send email to sy...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/sympy?hl=en.
>> For more options, visit 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 sympy+un...@googlegroups.com <javascript:>.
> To post to this group, send email to sy...@googlegroups.com <javascript:>.
> 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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
