On 5 December 2016 at 11:46, Martin Baker <ax87...@martinb.com> wrote:
> My initial thoughts about group domains related to homotopy in FriCAS is
> that there is a need for at least 4 group domains shown at each corner of
> this square:
>
> PermutationGroup <-----equivalent-----> GroupPresentation
>       |                if finite               |
>       |                                        |
>   contains set of                        contains set of
>       |                                        |
>       V                                        V
> Permutation <-------------------------------> Word
>
> The domains at the bottom of the diagram are implementations of Group
> category. So in these cases % will contain something representing a single
> element of the group such as a single permutation or a single word.
> Functions will be from Group such as '*'.
>
> The domains at the top of the diagram have % which holds information about
> the whole group so it identifies it as say 'cyclic group 5' or 'dihedral
> group 3'. The functions will be functions on the whole group such as: sum,
> product, quotient, subgroup, order, orbit, etc.
>
> (I don't think Bill likes this way of describing it? I think the distinction
> is valid but can you think of a more mathematical way to describe the
> distinction? Perhaps in terms of initial and terminal algebras?)

No. My only objection was to the use of % to refer to a member of a
domain. % (in SPAD) refers to "this domain" or "self" in the context
of what ever domain one is actually compiling. In the interpreter % is
a shorthand for '%%(-1)', i.e. the previous result.

As I understand it you are talking about domains whose members
represent groups versus domains whose member are elements of some
group.

>
> So how does FinitelyPresentedGroup fit in this? It seems to me that
> FinitelyPresentedGroup is of type: Type

No. All domains are of type: Type, i.e. the following is True

  D has Type

for all domains D.  Type is the top of the category hierarchy.

>From the following definition:

)abbrev domain FPG FinitelyPresentedGroup
++ https://en.wikipedia.org/wiki/Presentation_of_a_group
FinitelyPresentedGroup(L,R) : Exports == Implementation where

  LS      ==> List Symbol
  OVAR    ==> OrderedVariableList
  FG(S)   ==> FreeGroup OVAR S
  LEQ(G)  ==> List Equation G

  L: LS
  R: LEQ FG(L)

  Exports == Join(Group, CoercibleTo OutputForm) with

    1 : () -> %
    generators : () -> List %
    relations : () -> LEQ %
    fpGroup : LEQ % -> Type
    rewriteFake : % -> %
    free? : () -> Boolean

    size : % -> NonNegativeInteger
    factors : % -> List(Record(gen: OVAR L,exp: Integer))

    coerce : % -> OutputForm

--

The "type" of FinitelyPresentedGroup is everything that appears in
Exports. So in particular it has Group in addition to several other
specific exported operations.

> whereas GroupPresentation is of a specific type:
>
> (1) -> F:=FPG([x,y,z],[])
>
>    (1)  FinitelyPresentedGroup([x,y,z],[])
>                                                   Type: Type
>
> (2) -> F2 := groupPresentation([1,2,3],[])
>
>    (2)  <a b c |  >
>                                       Type: GroupPresentation
>

GroupPresentation is a domain which as you have defined it:

GroupPresentation() : Exports == Impl where
  NNI ==> NonNegativeInteger
  PI ==> PositiveInteger
  x<<y ==> hconcat(x::OutputForm, y::OutputForm)
  GENMAP ==> List(Record(OldGen : NNI, NewGen : NNI))
  Exports ==> SetCategory() with
    groupPresentation : (v : List(NNI), rels1 : List(List(Integer))) -> %
      ++ construct from generators and relations
    groupPresentation : (v : List(NNI)) -> %
      ++ construct free group with generators but no relations
    groupPresentation : () -> %
      ++ construct trivial group with no generators or relations
    simplify : (s : %) -> %
      ++ There may not be a simplest form but it is possible to
      ++ do some simplifications as follows:
      ++ 1) Remove all zero terms in relations.
      ++ 2) If a relation consists of a single generator then remove
      ++    that generator.
      ++ 3) If a relation consists of a pair of generators then make the
      ++    second generator the inverse of the first.
      ++ 4) if a generator is adjacent to its inverse then cancel them out.
      ++ 5) Remove duplicate relations.
      ++ 6) Substitute one relation in another.
    simplify : (s : %, trace : Boolean) -> %
      ++ simplify with option to trace
    refactor : (a : %) -> %
      ++ actual value of generators is not important, it is only important that
      ++ they correspond to the appropriate entries in the relations.
      ++ Therefore we can refactor the generators without changing the
      ++ group represented.
    quotient : (a : %, remgen : List(NNI)) -> %
      ++ take quotient by removing generators specified by remgen
    quotient : (a : %, addrel : List(List(Integer))) -> %
      ++ take quotient by adding relations specified by addrel
    directProduct : (a : %, b : %) -> %
      ++ directProduct of two groups
    cyclicGroup : (n : PI) -> %
      ++ cyclicGroup(n) constructs the cyclic group of order n acting
      ++ on the integers 1, ..., n.
    dihedralGroup : (n : PI) -> %
      ++ dihedralGroup(n) constructs the dihedral group of order 2n
      ++ acting on integers 1, ..., N.
    toPermutationIfCan : (a : %) -> Union(PermutationGroup Integer, "failed")
      ++ convert to permutation group return "failed" for infinite groups.
    toPermutationIfCan : (a : %, trace : Boolean) ->
Union(PermutationGroup Integer, "failed")
      ++ convert to permutation group return "failed" for infinite groups.

--

does not satisfy Group. In order to satisfy Group it would have to
export * and 1 as operations.

> Given this, is it possible to construct functions like sum, product,
> quotient, subgroup, order, orbit, etc. on something of type: Type?
>

When you speak of Type as a "type" I am worried that you might be
confused by how FriCAS categories (such as Type) interact with
domains.  I think it is only approximately correct to think of
categories as "types" but in stricter terms only domains in FriCAS are
types in the now conventional use of the term is as much as only
domains have members, i.e. values of that type.

> If it is possible to do this, why is PermutationGroup not constructed this
> way?
>

The collection "subgroups of the symmetric group of S" do not form a
group, rather they ARE groups in-and-of themselves. To be a Group a
domain needs to export some multiplication operator * that acts on
members of the domain and an identity 1 for that operation. In this
case the members of the domain are groups they are not elements of
some group.

Bill.

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to