GSoC 2012 idea
Aleksandar Makelov
I'm currently a freshman at Harvard College, probably concentrating in
mathematics / mathematics and CS. I've done a lot of mathematics in
high school (math Olympiads) and university (honors linear and
abstract algebra, real and complex analysis) so far, and I'm
interested in bringing mathematics and CS together.
I've been dealing with sympy for a couple of weeks now and was
wondering whether it'd be a good idea for GSoC to implement some more
complicated combinatorial functionality (e.g. graph algorithms,
generating functions, recurrence relations, operations on sets,...) ?
Also, I'm currently working on several little functions for
computation of the Galois group of quadratic/cubic/quartic
polynomials; I'll probably send the code in a couple of days. Maybe
I'll be able to develop some GSoC-like ideas in this direction
(abstract algebra) as well.
David Joyner
<amak...@college.harvard.edu> wrote:
> Hi guys,
>
> I'm currently a freshman at Harvard College, probably concentrating in
> mathematics / mathematics and CS. I've done a lot of mathematics in
> high school (math Olympiads) and university (honors linear and
> abstract algebra, real and complex analysis) so far, and I'm
> interested in bringing mathematics and CS together.
>
> I've been dealing with sympy for a couple of weeks now and was
> wondering whether it'd be a good idea for GSoC to implement some more
> complicated combinatorial functionality (e.g. graph algorithms,
> generating functions, recurrence relations, operations on sets,...) ?
networkx implements in python a lot of graph theory. I don't think sympy has an
interface though.
sympy has rsolve for sequences defined by a linear recurrence relation
However, there isn't one for a vector-valued sequence (someone asked about that
the other day on the sage-support list).
>
> Also, I'm currently working on several little functions for
> computation of the Galois group of quadratic/cubic/quartic
> polynomials; I'll probably send the code in a couple of days. Maybe
> I'll be able to develop some GSoC-like ideas in this direction
> (abstract algebra) as well.
Sympy doesn't have much of that, although Sage does.
I think more abstract algebra in sympy would be very useful.
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
Sergiu Ivanov
On Fri, Mar 16, 2012 at 2:06 PM, Aleksandar Makelov
<amak...@college.harvard.edu> wrote:
>
> I've been dealing with sympy for a couple of weeks now and was
> wondering whether it'd be a good idea for GSoC to implement some more
> complicated combinatorial functionality (e.g. graph algorithms,
> generating functions, recurrence relations, operations on sets,...) ?
I'd recommend that you take a look at
https://github.com/sympy/sympy/wiki/GSoC-2012-Ideas . Some of your
suggestions seem to be related to what is listed on that page.
Note, though, that graph theory is out of scope of SymPy, mainly
because graphs are already implemented in a couple other Python
libraries (e.g. NetworkX: http://networkx.lanl.gov/). Sorry, I cannot
find the proper source to cite; but trust me, Aaron told me that about
a month ago :-)
> Also, I'm currently working on several little functions for
> computation of the Galois group of quadratic/cubic/quartic
> polynomials; I'll probably send the code in a couple of days. Maybe
> I'll be able to develop some GSoC-like ideas in this direction
> (abstract algebra) as well.
I suppose that your contributions will be welcome :-)
Sergiu
Aaron Meurer
networkx and similar libraries. Those other things would be fitting,
though. Take a look at what's already implemented in the
combinatorics module, the sets module, and elsewhere.
And it would be awesome to have a group theory module. We presently
only have a Permutation class in the combinatorics module, but other
than that, we don't really have a good way to represent a group.
Obviously, to compute the Galois group of a polynomial, you need a way
to represent it, so for this idea, you would really need to implement
a group theory framework that we can build upon.
What algorithm do you use to compute the Galois group?
Aaron Meurer
Aleksandar Makelov
for the Galois group I'm using a rather naive approach for equations
of degree 4 or less - it's based on the theory given in a standard
textbook (Artin's Algebra, 2nd edition) - looking at the discriminant
and in the quartic case at the resolvent cubic. It's a solid algorithm
except for one of the cases where there is ambiguity between C_4 and
D_4, but that's OK for most of the polynomials you'd encounter in the
exercises... But now that I looked around I saw there might be some
more general algorithms out there (http://mathoverflow.net/questions/
22923/computing-the-galois-group-of-a-polynomial/ for example), so
that's probably what I'm going to try next.
Respectively, representing groups will be just by name (not so many of
them in degrees less than 5...) but obviously in higher degrees it'd
be convenient to have a way of handling arbitrary groups. Galois
groups are naturally embedded in the symmetric groups S_n, so
permutations will probably pop up from the algorithms; as size gets
larger (approx. n!) it'd be better to have them in cycle notation, and
also try to extract a list of generators / generators with relations.
Other than that, I don't know... I'm currently doing representation
theory and it sounds tempting (eigenvals()? character tables?). But
that's just the mathematical side of it, and I'll have to think a lot
about implementation.
Aleksandar Makelov
Aaron Meurer
<amak...@college.harvard.edu> wrote:
> Hi,
>
> for the Galois group I'm using a rather naive approach for equations
> of degree 4 or less - it's based on the theory given in a standard
> textbook (Artin's Algebra, 2nd edition) - looking at the discriminant
> and in the quartic case at the resolvent cubic. It's a solid algorithm
> except for one of the cases where there is ambiguity between C_4 and
> D_4, but that's OK for most of the polynomials you'd encounter in the
> exercises... But now that I looked around I saw there might be some
> more general algorithms out there (http://mathoverflow.net/questions/
> 22923/computing-the-galois-group-of-a-polynomial/ for example), so
> that's probably what I'm going to try next.
http://www.maplesoft.com/support/help/Maple/view.aspx?path=galois may
also give you some inspiration.
>
> Respectively, representing groups will be just by name (not so many of
> them in degrees less than 5...) but obviously in higher degrees it'd
> be convenient to have a way of handling arbitrary groups. Galois
> groups are naturally embedded in the symmetric groups S_n, so
> permutations will probably pop up from the algorithms; as size gets
> larger (approx. n!) it'd be better to have them in cycle notation, and
> also try to extract a list of generators / generators with relations.
> Other than that, I don't know... I'm currently doing representation
> theory and it sounds tempting (eigenvals()? character tables?). But
> that's just the mathematical side of it, and I'll have to think a lot
> about implementation.
>
> Aleksandar Makelov
Well, we want to be able to do more with a group than just have its name.
How you represent the group, and its elements, depends on what the
group is (finite or infinite for one thing), and what you plan to do.
It will be useful to be able to represent them in many different ways.
If you're interested in working on group theory, you might also look
at the GAP project for some inspiration. They have the most powerful
group theory software (as far as I know).
Aaron Meurer
Aleksandar Makelov
Yup I'm looking at the GAP website now and it seems like a lot of fun;
I'm also looking for some kind of algorithm reference for
computational group theory like the ones listed at GAP. I'll have a
lot of work to do in the next couple of days (break's over) but will
try to implement at least one way of representing groups and find some
algorithms that might help build a potential group theory module.
Aleksandar Makelov
> On Fri, Mar 16, 2012 at 4:12 PM, Aleksandar Makelov
>
Alan Bromborsky
Seress - Cambridge Tracts in Mathemathics 152 published 2003.
Saptarshi Mandal
I worked as a student last year and may apply as mentor this year.
Please take a look at my branches in github. I was implementing the
Schreier Sims algorithm but I ran out of time unfortunately. You could
either help me merge my branches in or take off where I left.
Regards
Saptarshi
Saptarshi Mandal
> And it would be awesome to have a group theory module. We presently
> only have a Permutation class in the combinatorics module, but other
> than that, we don't really have a good way to represent a group.
anyway. Groups for specific structures can make use of functionality
implemented for them (matrix group -> sympy matrices, galois -> polys)
for basic operations and can implement the mapping to the perm group
module for group theoretic operations.
> Obviously, to compute the Galois group of a polynomial, you need a way
> to represent it, so for this idea, you would really need to implement
> a group theory framework that we can build upon.
groups only. I see that the book by Seress has already been
referenced.
I think a more fruitful venture would be to extend the perm groups
module and leverage that to implement matrix groups or galois groups
(but then again, I am probably biased ;)
Cheers
Sapta
krastano...@gmail.com
> Is this necessary? All groups are isomorphic to the permutation group
> anyway. Groups for specific structures can make use of functionality
> implemented for them (matrix group -> sympy matrices, galois -> polys)
> for basic operations and can implement the mapping to the perm group
> module for group theoretic operations.
>
This seems incorrect. Zn is abelian for example and it is not
isomorphic to any permutation group. Moreover, there are all the
continuous groups.
Besides, it will be nicer to have some abstract object that is not
tied to a concrete representation, even though it will probably just
be a wrapper for all the representations supported by sympy.
Aaron Meurer
<sapta....@gmail.com> wrote:
>>
>> And it would be awesome to have a group theory module. We presently
>> only have a Permutation class in the combinatorics module, but other
>> than that, we don't really have a good way to represent a group.
>
> Is this necessary? All groups are isomorphic to the permutation group
> anyway. Groups for specific structures can make use of functionality
> implemented for them (matrix group -> sympy matrices, galois -> polys)
> for basic operations and can implement the mapping to the perm group
> module for group theoretic operations.
As Stefan noted, this is only true for finite groups.
And anyway, the point I was trying to make was that a permutation
represents an element of a group, whereas I was talking about a way to
represent the whole group.
Aaron Meurer
>
>> Obviously, to compute the Galois group of a polynomial, you need a way
>> to represent it, so for this idea, you would really need to implement
>> a group theory framework that we can build upon.
>
> Again, most of the concrete algorithms for groups are for Permutation
> groups only. I see that the book by Seress has already been
> referenced.
>
> I think a more fruitful venture would be to extend the perm groups
> module and leverage that to implement matrix groups or galois groups
> (but then again, I am probably biased ;)
>
> Cheers
> Sapta
>
David Joyner
<krastano...@gmail.com> wrote:
>>
>> Is this necessary? All groups are isomorphic to the permutation group
>> anyway. Groups for specific structures can make use of functionality
>> implemented for them (matrix group -> sympy matrices, galois -> polys)
>> for basic operations and can implement the mapping to the perm group
>> module for group theoretic operations.
>>
>
> This seems incorrect. Zn is abelian for example and it is not
> isomorphic to any permutation group. Moreover, there are all the
> continuous groups.
It is not correct to say Zn (I assume you mean the ring of integers
mod n) is not isomorphic to a permutation group. (Consider the
cyclic group generated by the n-cycle (1,2,...,n) in disjoint
cycle notation.)
Implementing Lie groups would be a relatively difficult undertaking
I think...
>
> Besides, it will be nicer to have some abstract object that is not
> tied to a concrete representation, even though it will probably just
> be a wrapper for all the representations supported by sympy.
>
Sergiu Ivanov
> On Sat, Mar 17, 2012 at 3:55 PM, krastano...@gmail.com
> <krastano...@gmail.com> wrote:
>>>
>>> Is this necessary? All groups are isomorphic to the permutation group
>>> anyway. Groups for specific structures can make use of functionality
>>> implemented for them (matrix group -> sympy matrices, galois -> polys)
>>> for basic operations and can implement the mapping to the perm group
>>> module for group theoretic operations.
>>>
>>
>> This seems incorrect. Zn is abelian for example and it is not
>> isomorphic to any permutation group. Moreover, there are all the
>> continuous groups.
>
>
> It is not correct to say Zn (I assume you mean the ring of integers
> mod n) is not isomorphic to a permutation group. (Consider the
> cyclic group generated by the n-cycle (1,2,...,n) in disjoint
> cycle notation.)
I think difference should be made between
nZ = {n * k | k\in Z}
and
Z_n = {k mod n | k\in Z}.
Z_n is finite, while nZ is infinite. This might be the reason for the
misunderstanding.
Sergiu
Alan Bromborsky
Physicists" by Doran and Lasenby section 11.3 - Lie Groups and section
11.4 - Complex Structures and Unitary Groups.
krastano...@gmail.com
not consider subgroups). Thanks for the correction.
Aleksandar Makelov
> I think a main reference is "Permutation Group Algorithms" by Akos
> Seress - Cambridge Tracts in Mathemathics 152 published 2003.
serious business. Unfortunately, neither of these is a free resource;
I might end up buying one, I don't know.
> Is this necessary? All groups are isomorphic to the permutation group
> anyway. Groups for specific structures can make use of functionality
> implemented for them (matrix group -> sympy matrices, galois -> polys)
> for basic operations and can implement the mapping to the perm group
> module for group theoretic operations.
ish functions (like composing/inverting permutations, raising to
powers, conjugating permutations, getting the order (as an element of
the corresponding symmetric group) of a permutation, ...). These can
be incorporated in a representation of groups using permutation
groups; Galois groups would fit perfectly in this representation since
they naturally live inside the symmetric groups, and yes a lot of the
functions in the polys module will be helpful.
Also, there are generators for common groups like S_n, C_n, D_n, A_n
in the context of permutation representations. All this provides a
nice foundation for defining a Group class or something like that,
with one of the ways of representing it being the permutation
representation. Other ways (e.g., matrices, character tables, list of
generators and relations) could probably be added later, and
functionality to go from one to representation to another?
In other news, I found a bug inside the generators.py file in the
permutations module - the dihedral group D_2 of order 4 is given a
wrong permutation representation. I have a fix for this (well it's
quite straightforward, just manually considering the case n=2 and
outputting the right representation, because the general algorithm
fails there), what should I do about it?
Aleksandar Makelov
Aaron Meurer
Submit a pull request! This can be your patch for the patch requirement.
Aaron Meurer
>
> Aleksandar Makelov
Aaron Meurer
example, section 10).
Aaron Meurer
Aaron Meurer
paper is from 1998.
Aaron Meurer
Alan Bromborsky
http://www.4shared.com/office/LtxPTggL/Handbook_of_Computational_Grou.html
Attached is another way of implementing Lie groups
Aleksandar Makelov
yep I'll submit the pull request :)
Alex
On Mar 18, 9:16 am, Alan Bromborsky <abro...@verizon.net> wrote:
> On 03/18/2012 12:09 AM, Aaron Meurer wrote:
>
>
>
>
>
>
>
> > I wouldn't trust much from that section anyway, though, since the
> > paper is from 1998.
>
> > Aaron Meurer
>
> >> Is that a preprint? Some of the sections seem unfinished (for
> >> example, section 10).
>
> >> Aaron Meurer
>
> >>> On 03/17/2012 04:59 PM, Aaron Meurer wrote:
> >>>> On Sat, Mar 17, 2012 at 2:45 PM, Aleksandar Makelov
> Attached is another way of implementing Lie groups
>
> 299KViewDownload
Nathan Alison
On Saturday, March 17, 2012 2:57:57 PM UTC-5, Aaron Meurer wrote:
On Sat, Mar 17, 2012 at 1:42 PM, Saptarshi Mandal wrote:
>>
>> And it would be awesome to have a group theory module. We presently
>> only have a Permutation class in the combinatorics module, but other
>> than that, we don't really have a good way to represent a group.
>
> Is this necessary? All groups are isomorphic to the permutation group
> anyway. Groups for specific structures can make use of functionality
> implemented for them (matrix group -> sympy matrices, galois -> polys)
> for basic operations and can implement the mapping to the perm group
> module for group theoretic operations.As Stefan noted, this is only true for finite groups.
And anyway, the point I was trying to make was that a permutation
represents an element of a group, whereas I was talking about a way to
represent the whole group.Aaron Meurer
Alan Bromborsky
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/8BKF_m6cyR4J.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Aaron Meurer
so please edit it to add more kinds of things that you would like to
see in such a module.
Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sympy/-/8BKF_m6cyR4J.
>
Saptarshi Mandal
interesting. I referred to them for implementing some of the more
elementary algorithms.
http://www.math.colostate.edu/~hulpke/CGT/CGT.html
Aleksandar Makelov
I started reading the Handbook of Computational Group Theory and it
seems like a solid reference. So do you guys think it'd be a good idea
to build a group theory module for sympy for a possible GSoC? By that
I mean, do you find it interesting and in the scope of the project? If
so, I'm willing to try to come up with a proposal after going over the
book and the other references.
Also, how do you think groups should be implemented? I've been
thinking about making a group class that inherits Basic and has
properties like is_finite, is_abelian, is_cyclic, is_simple, and so
on... , and list the different possibilities for presenting a group as
properties as well - permutation_form, generators_form, ... and maybe
have methods for going from one to another; also have methods like
subgroup(), normal_subgroup(),... and so on. This is probably rather
naive at such an early point, but it seems abstract enough to allow
flexibility in the future. I guess it was inspired by the Permutation
class. Is this a good practice?
Also, the tiny little functionality covering Galois groups for
polynomials of degree less than 5 should come out soon, but for that I
first need some basic Group object to work with, hence my above
question.
David Joyner
<amak...@college.harvard.edu> wrote:
>
> On Mar 20, 12:32 am, Saptarshi Mandal <sapta.iit...@gmail.com> wrote:
>> The notes for a graduate course at Colorado State are also very
>> interesting. I referred to them for implementing some of the more
>> elementary algorithms.
>>
>> http://www.math.colostate.edu/~hulpke/CGT/CGT.html
>
> Thanks for the reference!
>
> I started reading the Handbook of Computational Group Theory and it
> seems like a solid reference. So do you guys think it'd be a good idea
> to build a group theory module for sympy for a possible GSoC? By that
> I mean, do you find it interesting and in the scope of the project? If
> so, I'm willing to try to come up with a proposal after going over the
> book and the other references.
>
> Also, how do you think groups should be implemented? I've been
> thinking about making a group class that inherits Basic and has
> properties like is_finite, is_abelian, is_cyclic, is_simple, and so
> on... , and list the different possibilities for presenting a group as
> properties as well - permutation_form, generators_form, ... and maybe
> have methods for going from one to another; also have methods like
> subgroup(), normal_subgroup(),... and so on. This is probably rather
> naive at such an early point, but it seems abstract enough to allow
> flexibility in the future. I guess it was inspired by the Permutation
> class. Is this a good practice?
This seems good. It sounds like you plan on implementing
permutation groups, and the methods you describe, which the
user defines using a list of (permutation) generators.
Is that your question?
>
> Also, the tiny little functionality covering Galois groups for
> polynomials of degree less than 5 should come out soon, but for that I
> first need some basic Group object to work with, hence my above
> question.
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
Aleksandar Makelov
> This seems good. It sounds like you plan on implementing
> permutation groups, and the methods you describe, which the
> user defines using a list of (permutation) generators.
> Is that your question?
generators and relations. For example, the cyclic group Cn is
generated by a single element {s} (set of generators) such that
{s^n=id} (set of relations); the dihedral group Dn is generated by
{r,s} such that {r^n=id, s^2=id, srs=r^{-1}} and so on to more
complicated stuff. The so-called "word problem" that determines
whether two words in the generators are in fact the same element of
the group is not solvable for finitely presented groups, but *is*
solvable for finite groups and some other classes of groups (http://
en.wikipedia.org/wiki/Word_problem_for_groups). The book ("Handbook of
computational group theory") provides algorithms for going from this
presentation to a permutation presentation.
My question was whether what I described would be an appropriate, good-
sympy-practice way to implement group objects - or at least start
implementing them :)
Alex
Nathan Alison
Saptarshi Mandal
group class is the best way to go. From an implementation perspective,
it would be very convenient if the abstract group class encapsulates
the permutation group class. Implementing any other concrete group
will then require one to a) inherit the abstract class, b) map the
group operation to an appropriate permutation group operation and c)
construct an isomorphism from the concrete group to the permutation
group. This way we can reuse all the algorithms that have been
implemented for permutation groups. This strategy is useful for
implementation because perm group algorithms are the simplest to
implement.
I have not looked at the source code of GAP but I think the abstract
groups that GAP allows you to create are really permutation groups
masquerading as abstract groups. I could be hopelessly wrong though.
Aaron Meurer
permutation when it's not necessary. This could be useful for groups
of very large order.
For example, the other day, I was trying to figure out a way to
generate a random permutation of order roughly 2**32 (what I was
trying to do was randomize some Python hashes). There is the function
random_permutation, but this generates the whole permutation, which
would take up way too much space. What I would rather have is some
lazy evaluation, where it generates unknown permutations "on the fly".
This could be easily implemented as a dictionary.
Aaron Meurer
Aleksandar Makelov
it seems that the finite groups - permutation groups, matrix groups,
polycyclic groups - are almost always realized as permutation groups
(for matrix groups there is a 'canonical' way to do this via a
faithful permutation representation on a set of vectors). But also
there are the finitely presented groups (i.e., a group of infinite
order which however can be described by a finite set of generators and
relations between them, as in my previous post) which also constitute
an important class, and there are a lot of algorithms that apply to
them.
Also, the way they implemented groups in GAP is, roughly speaking,
using a Domain - a set of elements together with operations on them
(which can have certain properties like associativity,
commutativity,...) under which it is closed; then they go on to define
a group as a domain with 1 associative operation that has inverses,
and with an identity. As you can see, quite a lot of things apart from
groups can inherit this domain structure - would it be possible to
have something like that in sympy as well or is it too late?
Then, finite groups are constructed by Group(... comma separated
generators ... ), where the generators can be permutations or matrices
(well if you put matrices that don't generate a finite group you get
yelled at); and finitely presented groups are constructed by first
constructing a free group of a certain number of generators and then
taking the "quotient" by a set of words in the generators that are
equal to the identity element (these are the relations).
So these are some ideas for a possible start on the groups module.
What do you guys think?
Aaron Meurer
<amak...@college.harvard.edu> wrote:
> Yep so I installed GAP and started reading through the manual. Indeed,
> it seems that the finite groups - permutation groups, matrix groups,
> polycyclic groups - are almost always realized as permutation groups
> (for matrix groups there is a 'canonical' way to do this via a
> faithful permutation representation on a set of vectors). But also
> there are the finitely presented groups (i.e., a group of infinite
> order which however can be described by a finite set of generators and
> relations between them, as in my previous post) which also constitute
> an important class, and there are a lot of algorithms that apply to
> them.
>
> Also, the way they implemented groups in GAP is, roughly speaking,
> using a Domain - a set of elements together with operations on them
> (which can have certain properties like associativity,
> commutativity,...) under which it is closed; then they go on to define
> a group as a domain with 1 associative operation that has inverses,
> and with an identity. As you can see, quite a lot of things apart from
> groups can inherit this domain structure - would it be possible to
> have something like that in sympy as well or is it too late?
How could it be too late?
>
> Then, finite groups are constructed by Group(... comma separated
> generators ... ), where the generators can be permutations or matrices
> (well if you put matrices that don't generate a finite group you get
> yelled at); and finitely presented groups are constructed by first
> constructing a free group of a certain number of generators and then
> taking the "quotient" by a set of words in the generators that are
> equal to the identity element (these are the relations).
>
> So these are some ideas for a possible start on the groups module.
> What do you guys think?
Well the GAP people have obviously thought about this problem a lot
more than we have, and they have quite a bit implemented, so it is a
good place to look for references. Obviously, we will want to modify
some things to make them more Pythonic, or to make them fit better
with other parts of SymPy. For example, GAP is written in C, which is
not object oriented, so depending on how they implemented their data
structures, we may want to do it different (not to mention that Python
has its own independent set of data structures from C with their own
advantages and disadvantages).
Aaron Meurer
>
> On Mar 21, 1:05 am, Saptarshi Mandal <sapta.iit...@gmail.com> wrote:
>> Sounds good. I am just not sure if *implementing* a pure abstract
>> group class is the best way to go. From an implementation perspective,
>> it would be very convenient if the abstract group class encapsulates
>> the permutation group class. Implementing any other concrete group
>> will then require one to a) inherit the abstract class, b) map the
>> group operation to an appropriate permutation group operation and c)
>> construct an isomorphism from the concrete group to the permutation
>> group. This way we can reuse all the algorithms that have been
>> implemented for permutation groups. This strategy is useful for
>> implementation because perm group algorithms are the simplest to
>> implement.
>>
>> I have not looked at the source code of GAP but I think the abstract
>> groups that GAP allows you to create are really permutation groups
>> masquerading as abstract groups. I could be hopelessly wrong though.
>
Aleksandar Makelov
take a massive amount of changes over different modules to put all
abstract algebraic structures on a common setting -- but I think
that's the right direction to treat this stuff (like, abstract algebra
is abstract so in order to implement it we need more abstractness :) )
>
>
> Well the GAP people have obviously thought about this problem a lot
> more than we have, and they have quite a bit implemented, so it is a
> good place to look for references. Obviously, we will want to modify
> some things to make them more Pythonic, or to make them fit better
> with other parts of SymPy. For example, GAP is written in C, which is
> not object oriented, so depending on how they implemented their data
> structures, we may want to do it different (not to mention that Python
> has its own independent set of data structures from C with their own
> advantages and disadvantages).
>
> Aaron Meurer
>
reference and also all the C-code is freely available. Apart from that
they have tables for a LOT of known finite groups. I think this is
going to help a lot - they are referred to in Chapter 11 of The
Handbook on Computational Group Theory and could speed up some of the
algorithms.
Aaron Meurer
<amak...@college.harvard.edu> wrote:
>
>
> On Mar 24, 10:39 pm, Aaron Meurer <asmeu...@gmail.com> wrote:
>
>> How could it be too late?
>>
>>
>
> Well yeah I hoped it's not :) I was wondering about that because it'd
> take a massive amount of changes over different modules to put all
> abstract algebraic structures on a common setting -- but I think
> that's the right direction to treat this stuff (like, abstract algebra
> is abstract so in order to implement it we need more abstractness :) )
I think you should start out implementing it separate from the core
(except where you use the core), and then later we can think about
merging the ideas. This is similar to how the polys work.
Aaron Meurer
David Joyner
sending it. Hope it still helps.
On Sat, Mar 24, 2012 at 10:53 PM, Aleksandar Makelov
<amak...@college.harvard.edu> wrote:
>
>
> On Mar 24, 10:39 pm, Aaron Meurer <asmeu...@gmail.com> wrote:
>
>> How could it be too late?
>>
>>
>
> Well yeah I hoped it's not :) I was wondering about that because it'd
> take a massive amount of changes over different modules to put all
> abstract algebraic structures on a common setting -- but I think
> that's the right direction to treat this stuff (like, abstract algebra
> is abstract so in order to implement it we need more abstractness :) )
>
>
>>
>
>>
>> Well the GAP people have obviously thought about this problem a lot
>> more than we have, and they have quite a bit implemented, so it is a
>> good place to look for references. Obviously, we will want to modify
>> some things to make them more Pythonic, or to make them fit better
>> with other parts of SymPy. For example, GAP is written in C, which is
>> not object oriented, so depending on how they implemented their data
>> structures, we may want to do it different (not to mention that Python
>> has its own independent set of data structures from C with their own
>> advantages and disadvantages).
>>
>> Aaron Meurer
>>
>
> Yep the GAP guys appear to be solid citizens. They have a 900 page
> reference and also all the C-code is freely available. Apart from that
Sage also has a lot - in python or cython. See for example
http://hg.sagemath.org/sage-main/file/c239be1054e0/sage/groups/perm_gps/permgroup.py#l1
However, their license is GPL, not BSD, so you can't use it directly.
Hopefully, it is another good reference for you to look at though.
You can see from the author field, it seems I wrote (many years ago) a
few of those
methods. Of course, I am more than happy to relicense any of my code as BSD,
in case that helps.
> they have tables for a LOT of known finite groups. I think this is
> going to help a lot - they are referred to in Chapter 11 of The
> Handbook on Computational Group Theory and could speed up some of the
> algorithms.
>
Aleksandar Makelov
Alex
On Mar 28, 3:03 pm, David Joyner <wdjoy...@gmail.com> wrote:
> I wrote this 3 days ago and somehow put it in drafts instead of
> sending it. Hope it still helps.
>
> On Sat, Mar 24, 2012 at 10:53 PM, Aleksandar Makelov
>
>
>
>
>
>
>
>
>
> <amake...@college.harvard.edu> wrote:
>
> > On Mar 24, 10:39 pm, Aaron Meurer <asmeu...@gmail.com> wrote:
>
> >> How could it be too late?
>
> > Well yeah I hoped it's not :) I was wondering about that because it'd
> > take a massive amount of changes over different modules to put all
> > abstract algebraic structures on a common setting -- but I think
> > that's the right direction to treat this stuff (like, abstract algebra
> > is abstract so in order to implement it we need more abstractness :) )
>
> >> Well the GAP people have obviously thought about this problem a lot
> >> more than we have, and they have quite a bit implemented, so it is a
> >> good place to look for references. Obviously, we will want to modify
> >> some things to make them more Pythonic, or to make them fit better
> >> with other parts of SymPy. For example, GAP is written in C, which is
> >> not object oriented, so depending on how they implemented their data
> >> structures, we may want to do it different (not to mention that Python
> >> has its own independent set of data structures from C with their own
> >> advantages and disadvantages).
>
> >> Aaron Meurer
>
> > Yep the GAP guys appear to be solid citizens. They have a 900 page
> > reference and also all the C-code is freely available. Apart from that
>