On Tue, Mar 5, 2013 at 8:57 AM, Alan Bromborsky <abro...@verizon.net> wrote:
> On 03/05/2013 10:32 AM, Aaron Meurer wrote:
>
> 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')
>>>
>>> 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).
>>> 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.
>>> 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 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?
>>> 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.
>>> 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.
>> 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.
>>
>>
>>
>>
> --
> 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.
>
>
>
> The way I have been developing the new module is to have a GA directory
> completely separate from the sympy directory and use a pth file to access
> the GA modules from anywhere on my file system. Is there a reasonable way
> to implement this way of doing things on github. I find this simple in that
> I can always get the latest sympy from github and not interfere with my
> current source code. The only thing that someone who wishes to use or
> modify my code has to do is put the pth file containing the path of the GA
> directory in the proper location of their python distribution.
So you want GA to be a separate module from SymPy? What you are
describing is essentially that.
If not, then you should just update it in the library. You will only
be working against whatever git version you started with. If there is
some change in the git master that you need, you can always do a "git
merge master" on your branch to get the most up-to-date stuff. But
usually this doesn't happen, and so most of the time, you just work
against where you started.
Ideally, you would submit your work whenever there is enough finished
to be merged in. This generally just means that the code is tested and
the tests pass. Then, your work will be merged in, and it will
automatically be *part* of the git master, so of course any update to
some other part of SymPy will be updated concurrently.
In the past, we've had people (myself included) develop large branches
with big code changes for a long time without submitting them to be
merged, but it has always lead to a very difficult review process,
both for the people trying to review the code and for the person who
wrote the code. What happens is that the changes get quite large,
making it very hard to review. Also, changes in master go on, so you
end up getting people changing the same code you changed, leading to
very nasty merge conflicts, and changes in master that break your code
(because your tests were never run against it), meaning you now have
to go fix those bugs. On the other hand, if your code is merged
early, all further changes are tested against it, and furthermore,
other people will make fixes against your code, instead of just you.
A common idiom for git is "commit early, and commit often". I would
say, "submit early, and submit often" (as in, "submit a pull
request").
Aaron Meurer
>
> --
> 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.
