Services & ResourcesWolfram ForumsMathGroup Archive

[Date Index] [Thread Index] [Author Index]

Re: Re: Recognizing finite groups in Mathematica 7

• To: mathgroup at smc.vnet.net
• Subject: [mg102747] Re: [mg102567] Re: Recognizing finite groups in Mathematica 7
• From: Ron Monson <ron.monson at yahoo.com>
• Date: Wed, 26 Aug 2009 07:41:55 -0400 (EDT)
• References: <h46p4m$e5l$1@smc.vnet.net> <200908140959.FAA01447@smc.vnet.net>

..... However, the usefulness of such group recognition via multiplication tables will depend on the number of such tables in FiniteGroupData[]. Currently, as far as I can tell, there seems to be only ~10 different  multiplication tables that come with FiniteGroupData[] (several of the following are isomorphic) 

 Select[FiniteGroupData[],Head[FiniteGroupData[#,"MultiplicationTable"]]===List&]
->

 {C1,Pyritohedral,Quaternion,Td,Tetrahedral,Th,Trivial,Vierergruppe}


or

 Select[FiniteGroupData[All],Head[FiniteGroupData[#,"MultiplicationTable"]]===List&]

->

 {{AlternatingGroup,1},{CrystallographicPointGroup,1},{CrystallographicPointGroup,29},{CrystallographicPointGroup,31},{CyclicGroup,1},{CyclicGroupUnits,1}}

although I stand to be corrected if others have better/newer internet/paclet connections?) That the BabyMonster's multiplication table didn't get a guernsey is kind of understandable but much less so is that (for example) CyclicGroup 2 apparently didn't?

This raises the broader question of what level of functionality should be present when a new feature is introduced in Mathematica. I think it is fine, actually most welcome, when new (albeit less mature) frameworks get introduced early and also include certain functions/properties slated for future growth. I think however, it would be useful (perhaps even ethical) to at least include the current boundaries/limitations of such features (e.g. what is the coverage of all the other properties in FiniteGroupData? in GraphData? etc.)

Of course in the case of multiplication tables many of these can be generated from Combinatorica and this raises another broader question of the relationship between Combinatorica and FiniteGroupData[] (and indeed FiniteGraphData[]) Are these meant to eventually replace Combinatorica? What is the intended intersection between these packages? Are the developers on each interacting at all? Related to the future of Combinatorica is the broader question of the evolution of any third-party developed software whose ideas/functionality/documentation eventually gets integrated into Mathematica.

Finally, it would be interesting to know how the computable data in such functions as FiniteGroupData[] are being curated. The potential of such pre-computaton in experimental reasearch seems pretty profound but I wonder to what extent it will hinge on an accompanying accessibility of the algorithms used in the curation. While it may be true that access to an algorithms actual implementation is generally overated, I would argue that Combinatorica and perhaps any general implementations of combinatorial ideas, represents a prime example where this is definately *not* the case. I think that access to the source code of all Combinatorica  functions has been extremely valuable for not only learning combinatorical concepts and algorithms (and indeed in learning Mathematica) but also in algorithmic research by being able to assess its complexity or tweak the source (it is probably especially so since unfortunately there is no documentation for Combinatorica-
 surely an arrangement could have been done with the developers to include this within Mathematica?)

To take a small example. There seems to be a small bug in Combinatorica's implementation of the OrbitRepresentatives (ORS) function. This function finds representatives of the orbits induced by a group (ORS's first argument) acting on a given set (ORS's second argument). In typical usage (at least according to Combinatorica's manual) the group (say G) consists of n-permutations and acts on a set (say S) of length-n sequences. More generally however, a group action can involve a group acting on *any* set by specifying an explicit homomorphism f (f: SxG->S) which in ORS can be supplied as a third argument. In the typical usage case just mentioned therefore, the explicit homomorphism is the "Permute" function and this is added as the third argument by default when only two arguments are supplied. But this typical usage then requires the first two arguments to be of compatible dimensions (i.e. n-permutations acting on n-sequences) and this is checked
 (rudimentarily) via pattern matching. In a more general usage however, no such checks are required and in fact retaining such checks invariably *breaks* the general usage functionality (because the structure of the set and the group arguments will not pass the existing checks and therefore leave ORS unevaluated).

All this becomes clearer by looking at the source code e.g. by typing in

<<Combinatorica`

Begin["Combinatorica`Private`"]    (* to remove most of the context fluff) *)

??OrbitRepresentatives

to yield 

 OrbitRepresentatives[g_List,x_List,Combinatorica`Private`f_:Permute]:=Module[{y=Orbits[g,x,Combinatorica`Private`f]},Table[y[[i]][[1]],{i,Length[y]}]]/;(Length[g]>0&&Length[x]>0)&&Length[g[[1]]]==Length[x[[1]]]

The structural check that "ensures" ORS works in the typical case (with 2 arguments) but also prevents ORS working in the more general case (with 3 arguments) is the condition Length[g[[1]]=== Length[x[[1]]]. Hence, to use ORS for arbitrary group actions it is simply a matter of redefining ORS by removing this structural check (or perhaps adding && f=!=Permute) and everything works perfectly.

Without such access to the source code all of ORS's functionality and/or possible tweaking would be lost to any interested party.
 
Perhaps the scope for such benefits could be even more pronounced with a similar level of openness and accessibility in WRI's data-curation methods?

Cheers
Ron



________________________________
From: dh <dh at metrohm.com>
To: mathgroup at smc.vnet.net
Sent: Friday, August 14, 2009 7:59:36 PM
Subject: [mg102747] [mg102567] Re: Recognizing finite groups in Mathematica 7



jamievicary at NgOmSaPiAlM.com wrote:

> Hi all. Mathematica 7 has great finite group functionality, which

> includes knowledge of the common names of many group. I have an

> algorithm that produces multiplication tables for different groups ---

> how can I get Mathematica to recognize which group has been produced,

> and name it for me?

> 

> Thanks,

> Jamie.

> 

Hi Jamie,

FiniteGroupData[] gives the names of all groups known to Mathematica. We may now 

select the one that has the given multiplication table.

Assume that mt contains the multiplication table, e.g.:

mt = {{1, 2, 3, 4, 5, 6, 7, 8}, {2, 5, 4, 7, 6, 1, 8, 3}, {3, 8, 5, 2,

      7, 4, 1, 6}, {4, 3, 6, 5, 8, 7, 2, 1}, {5, 6, 7, 8, 1, 2, 3,

     4}, {6, 1, 8, 3, 2, 5, 4, 7}, {7, 4, 1, 6, 3, 8, 5, 2}, {8, 7, 2,

     1, 4, 3, 6, 5}};

the the following gives the name:

Select[FiniteGroupData[],

  FiniteGroupData[#, "MultiplicationTable"] === mt &]

Daniel

• References:
  • Re: Recognizing finite groups in Mathematica 7
    • From: dh <dh@metrohm.com>