Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extensions #5

Open
fingolfin opened this issue Mar 10, 2021 · 7 comments
Open

Extensions #5

fingolfin opened this issue Mar 10, 2021 · 7 comments

Comments

@fingolfin
Copy link
Collaborator

I am wondering in how far this should be left at the "core" API, or whether we should also start to define a few more things? E.g.

  • basic properties like isabelian, issolvable, isnilpotent, isperfect...
  • standard subgroups like derivedsubgroup(G), center(G), socle(G), ... or sylowsubgroup(G, p)
  • some subgroup related functionality like issubgroup(A,B), isnormalsubgroup(A,B), ...
  • standard operations like centralizer(G, H), normalizer(G, H), normalizer(G, H), ...
@albinahlback
Copy link
Contributor

I think this sounds very nice, great examples! Not familiar with everything, but I do think that general group-things would fit the package.

@fingolfin
Copy link
Collaborator Author

There are many more, of course, e.g.

  • trivial_subgroup
  • istrivial (default implementation could be istrivial(G) = isfinite(G) && order(G) == 1)
  • issupersolvable
  • iscyclic
  • issimple

Basically one can take a look at https://www.gap-system.org/Manuals/doc/ref/chap39.html and add things from there, including reusing some of the documentation. I am not sure whether it makes sense to do that here, though, as we wouldn't be providing implementations for most. I am happy to just have these all in Oscar.jl, and only move things to the "core" which others find interesting.

@fingolfin
Copy link
Collaborator Author

I think the two main piece of infrastructure still missing are handling of subgroups; and homomorphisms. All the other things are sugar on top; but subgroups are a central thing and not yet covered by GroupsCore at all, as far as I can tell.

@albinahlback
Copy link
Contributor

albinahlback commented Apr 19, 2021

Good thinking!

I think me and @kalmarek had a discussion that there is nothing stopping some extending package to implement subgroups on their own, since I tried to do something like

operation(g::GroupElement, h::GroupElement)

which I (after this discussion) think is too general.

Continuing along the lines with your comment, I think it would be natural to extend our current interface to something like

operation(g::GEl, h::GEl) where {GEl <: GroupElement}
operation(g::GEl, h::HEl) where {GEl <: GroupElement, HEl <: GroupElement}

where the parent of elements in HEl must either be a subgroup or supergroup of the parent of elements in GEl.

@fingolfin
Copy link
Collaborator Author

I don't understand your last comment, @albinahlback . What ist operation and what does it have to do with subgroups?

@albinahlback
Copy link
Contributor

Sorry for being unclear, don't mind what I said.

Do you think we should define an abstract type called Subgroup, or do you have a vision of something else, @fingolfin?

@kalmarek
Copy link
Owner

@fingolfin If you wish to discuss subgroups and homomorphisms, I'm all ears. ping me on slack

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants