gmane.comp.python.sympy

Re: History and background on computer algebra software

Aaron Meurer — 2013-06-20T02:43:20

The foreword and preface of Bronstein's book detail some of the
history of symbolic integration, which historically was one of the
primary motivations for computer algebra.

Aaron Meurer

On Wed, Jun 19, 2013 at 12:07 PM, David Joyner <wdjoyner-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Diophantine Equation Module

Aaron Meurer — 2013-06-20T02:40:27

There's no need to use a name convention. I'm sure Thilina didn't know
about Dummy.

Aaron Meurer

On Wed, Jun 19, 2013 at 7:25 PM, Chris Smith <smichr-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Use of CSR representation

Saurabh Jha — 2013-06-20T01:47:05

Hi,

I(with the help of Chris) have recently merged in two functions that
convert Dictionary of Keys(DOK) representation to Compressed Row
Format(CSR) format and vice versa. [1].

Since I don't actually know much about the applications of  sparse
matrices in domains like Computer Science, Physics, Mathematics etc.,
I wanted to discuss following issues with people--

1. What are the applications of Sparse Matrices.
2. Where does CSR representation have advantage over DOK
representation. I now know that CSR takes less space than DOK. Can
others please tell me some other advantages?
4. Which operations can be optimised with the help of CSR
representation. By optimised, I mean making it's order of growth of
running time smaller.
3. Do we need another data representation for Vectors? Perhaps not,
but do other CAS have a vector data representation?

-Saurabh


[1] https://github.com/sympy/sympy/pull/2169

Re: Diophantine Equation Module

Chris Smith — 2013-06-20T00:25:12

Rather than use Parameters, I suggested that we just use a uniquely named
symbol. The problem with Dummy is that you can still get a visual clash on
symbols: Symbol("_t") looks like Dummy("t"). This (or the perhaps ugly
unique name), of course, could be replaced with user variables.

Re: Diophantine Equation Module

Chris Smith — 2013-06-20T00:19:01

This is the job of the docstring. Also, since subs doesn't check that the
new value matches the old assumption I don't think you have to bother with
returning assumptions on the symbols.

Re: Diophantine Equation Module

Stefan Krastanov — 2013-06-19T20:23:05

I guess that the solution is valid only for an integer t (if we are
talking about a Diophantine equation). This information should be
provided, through the new assumption module I guess.


I have an opinion, but it seems everybody has a different opinion
about it. I vote for something similar to

list of substitution dicts with an "assumptions" key and the use of
Parameter or IntegrationConstant subclass of Dummy:

example:

[{x:expr_of_t, y: other_expr_of_t, 'assumptions':
assumptions_object_with_info_about_t}]

It might be appropriate for assumptions to not be a key of the same
dict, but it is necessary to have it somewhere as data.

Parameters then can be gathered with atom(Parameter) if the user wants
to substitute them with something that prints better than Dummy.

Re: Lie algebra module

Mary Clark — 2013-06-19T20:18:03

Thanks, David!  I was scanning that document earlier, but I missed that 
part.  That should definitely help.

On Wednesday, 19 June 2013 21:14:03 UTC+1, David Joyner wrote:

Re: Lie algebra module

Matthew Rocklin — 2013-06-19T20:15:45

I'm unfortunately ignorant of the commutation relations of su(2) and su(3)
but I am generally interested in the clear expression of mathematics in
code.  Are you able to either point to simple and quick-to-read reference
or give a clear example of the problem and the importance (I prefer the
latter)?

If the problem isn't specific to lie algebras and if you're able to express
it clearly then you will be able to leverage a significantly larger
proportion of the community.


On Wed, Jun 19, 2013 at 2:31 PM, Mary Clark <mary.spriteling-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:

Re: Lie algebra module

David Joyner — 2013-06-19T20:14:03


I think I see what you mean now.
They definitely exist. I have my books on this stuff at work but
googling I found this:
http://phyweb.lbl.gov/~rncahn/www/liealgebras/texall.pdf
Are the relations you want on page 48?

Re: Lie algebra module

Alan Bromborsky — 2013-06-19T20:08:37

Would the attached reference help?

Re: Lie algebra module

Mary Clark — 2013-06-19T19:53:59




Sorry, but could you clarify what you mean?  For instance, what I'm saying 
is that su(2), for example, has a basis consisting of 3 elements, say u1, 
u2 and u3, and we know that [u1,u2] = 2(u3).  But, for su(n) which has a 
basis of n^2 - n elements, I can't find an algorithm or anything saying 
that [u_i, u_j ] = f u_k for some constant f.

Re: Lie algebra module

David Joyner — 2013-06-19T19:37:53


Just a question on terminology:
Are you talking about general commutation relations or just those for the
standard lie algebra generators?

Lie algebra module

Mary Clark — 2013-06-19T19:31:36

Hello all,

As we all know, this is the first week of GSOC and I'm working on a Lie 
algebra module.  My blog is http://meclark256.wordpress.com/ 

Specifically I'd like to generate some discussion on the issue that I just 
wrote about in this week's blog entry, on actual physical commutation 
relations for specific Lie algebras.  Quoted from my blog:

What I am, however, running into difficulties about is generating the 
commutation relations for su(n) in general.  With the somewhat cursory look 
I did into this specific issue when I was writing my application, I rather 
thought that there was a well-defined relation or algorithm to generate the 
commutation relations which I would then just implement.   However, upon 
really researching this, I’ve realised that there is no such algorithm.  
So, while I could have my code dispense the commutation relations for su(2) 
and su(3) (which are probably the only cases when you would /really/ want 
the actual, physical commuation relations between the basis eleme

Re: Diophantine Equation Module

Stefan Krastanov — 2013-06-19T17:44:47

sorry for  the dupe, problem with my drafts

On 19 June 2013 19:14, Stefan Krastanov <krastanov.stefan-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Diophantine Equation Module

Stefan Krastanov — 2013-06-19T17:14:39

Inputting the parameter as a keyword to the solver seems like a
fragile solutions. What if we need two parameters? What if we do not
need any? How we add appropriate assumptions to the parameter (integer
or whatever)?

Moreover, this would create two divergent styles for the different
solvers: why should the additional symbols needed to represent
solutions to differential equations (the integration constants) follow
a different api from the Diophantine

On 19 June 2013 17:13, Ondřej Čertík <ondrej.certik-Re5JQEeQqe8< at >public.gmane.orgm> wrote:

Re: History and background on computer algebra software

David Joyner — 2013-06-19T17:07:10

Do you mean online? There is
http://orms.mfo.de/
http://www.symbolicnet.org/toc.html
and the "rosetta stone"
http://www.axiom-developer.org/axiom-website/rosetta.html

As far as books go, I like "Modern Computer Algebra" by Joachim von
zur Gathen, Jürgen Gerhard,
but it is 10 years old and fairly expensive. Wester's book is even
older (and more expensive) but you
can find several examples of Wester's test suite applied to different
systems, eg
homepages.math.uic.edu/~jan/mcs507/testing_software.pdf

Re: Diophantine Equation Module

Thilina Rathnayake — 2013-06-19T17:05:33

Ondrej: That's exactly what I am doing right now.

I am just implementing the low level functionalities which just solves
the equation and for the time being I am returning solutions as a set of
tuples.

I think the only assumption on the parameters would be that they
are Integers. Sometimes they may require to be positive or negative
but still I haven't come across that kind of a situation.

On the other hand, Stefan has a point in saying that we can't expect
user to be aware of the number of parameters to be used in the solution.
User may be unaware of how many parameters linear diophantine
equations or perhaps more unheard Pell's equation needs in the solution.

Can't we use the method or a slightly modified version of what Chris
proposed?
We use a set of fixed parameters internally, If we find them to be in the
equation
we add a '_' before that and use that as a parameter? Only problem here is
that
user can't know of the assumptions on the parameter. Besides being integers
I
didn't found any special assu

Re: Domains in Matrices

Saurabh Jha — 2013-06-19T16:58:41

I was thinking about adding what you said in above levels. In bottom
levels, I thought of passing domains explicitly to functions after
they are determined from above levels. The lower level functions will
form the basis of functions/methods at upper levels. I am still not
sure if this is the right way to look at this problem.

-Saurabh

On Jun 19, 9:50 pm, David Joyner <wdjoy...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Domains in Matrices

David Joyner — 2013-06-19T16:50:34


Why do you need a third argument? Can't you determine the domain
from the type of the matrix entries?

History and background on computer algebra software

Matthew Rocklin — 2013-06-19T16:41:08

Can anyone recommend a good review of computer algebra software other than
wikipedia?

Re: Diophantine Equation Module

Ondřej Čertík — 2013-06-19T16:40:09

On Wed, Jun 19, 2013 at 9:39 AM, Stefan Krastanov
<krastanov.stefan-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

I think for linear equations it is clear from the equation how many
parameters you need.


I am not sure what you mean here.


We should follow the same API everywhere. Do you have some suggestions
what the "correct" API should be?

Thilina, so until this gets settled, just implement the low level API,
and simply try to make all arguments explicit for each solver. Then it
will be quite easy to hook this up with our high level solve()
function.

Ondrej