Hitting two targets: OO + group theory (pedagogy)

[Kirby Urner]

ullrich at math.okstate.edu (David C. Ullrich) wrote:

>Right. I didn't say it was inappropriate. Although in fact
>something about the bit about "If you've studied Genesis"
>or however you put it seems a little off-putting; if
>you were referring to Bugs Bunny or Zeus you'd
>just refer to them.

I understand.  Actually I was trying to sound international
and multi-ethnic -- not presuming my reader had ever heard
of Cain/Abel and suggesting a search engine might pull up
some of that Bible stuff -- just as I'd need to search re
characters in other storylines.  But I understand your 
sensitivity.

I do expect this OO thing eventually might inspire _other_ 
authors to write stuff like:

   class Man(God):

      self.lastwords = "To thee I commend my spirit..."

      def __init__(self):
          self.soul = God.lend(self)
          self.years_to_live = random.choice(range(113))

      def live_for_a_day(self):
          self.days_to_live -= 1
          if self.days_to_live == 0:
              self.die()

      def die(self):
          print "Last words: %s " % self.lastwords
          God.getback(self.soul)
            
but don't worry, I'm not planning to do _that_ website.

>Never mind - could be I've been in Okllahoma
>too long.
>

That's somewhere near Texas right? :-D

>>In my example, it's the elements of a group which
>>get instantiated as separate objects, with each 
>>element inheriting the same meaning for *, whatever
>>that might be. 
>
>Right. That's actually what I meant, a class Group
>instances of which would represent elements
>of a generic group - of course there's no such
>thing so you'd never create instances of Group.
>Then subclasses of Group represent actual
>groups; instances of the subclasses being
>elements of actual groups.
>
>Not important, just seems to me like what it
>"should" be.

After further consideration, I think you're right.  

However, a Group and a member of a Group are somewhat
distinct ideas, so an instance of a Group would not
be a member, but a kind of group, e.g. a group of 
coprimes.  Internal to each kind of group, you have 
your conception of a member -- meaning you endow your
paradigm member with knowledge of how to be fruitful
and multiply (*) in a closed universe :-D.

In Java we have what are called abstract classes, which,
as you say, are never implemented directly -- only 
their subclasses might be.  Another option is to define
an "interface", which is a list of names specifying the
methods you'd need to implement in order to legitimately 
advertise you support said interface (like a canned 
control panel -- these are the controls we'd expect 
of any foo (any so-called 'car' must have a way to 
'steer').

So a finite Group interface might include:

(C) List all members                    getall()
(A) multiply two members (associative)  mul(a,b)
(I) Supply the inverse of a member      a.inv()
(N) output the identity element         id()

Based on these ruminations, I went over my Python code 
to create a completely revamped version:

  http://www.inetarena.com/~pdx4d/ocn/python/groups_draft2.html

which is rather more advanced than before (might still 
have a bug or two though -- this is definitely beta).

The [finite] Group class now contains the code for spitting 
out a table of all possible products, but it will be 
looking to a subclass to define what this means.

The Coprimes class inherits from Group, and contains an
internal representation of a Member (another class), 
wherein __mul__, __pow__, and inv() are giving the 
relevant definitions for this particular kind of group 
(positive integers coprime to and less than a modulus).

A main advantage of coding in this way is I can get several 
Coprimes groups instantiated (as objects) and work with 
them all in memory simultaneously (example below).

A next challenge would be to define my Permutations subclass
as also inheriting from Group, with its own internal conception 
of a Member.  That'd give an even better idea of the super->sub
(in principle -> specialcase) hierarchy.

Thanks for prompting me to take a second and third look at 
this issue.

Kirby

===============================

Sample transcript:


 Python 2.1a2 (#10, Feb  2 2001, 16:01:03) [MSC 32 bit (Intel)] on win32
 Type "copyright", "credits" or "license" for more information.
 IDLE 0.6 -- press F1 for help

 >>> import primes2             # what I call the module on my end
 >>> g17 = primes2.Coprimes(17) # create group of 0<k<17 where gcd(k,17)=1
 >>> len(g17)                   # this method at the Group level
 16
 >>> g20 = primes2.Coprimes(20) # another group instance, coprimes of 20
 >>> len(g20)                   # invokes same Group-level method on self
 8
 >>> g20.getproducts()          # getproducts() is at the Group/top level
 
       1  3  7  9 11 13 17 19
    ----------------------------
  1|   1  3  7  9 11 13 17 19
  3|   3  9  1  7 13 19 11 17
  7|   7  1  9  3 17 11 19 13
  9|   9  7  3  1 19 17 13 11
 11|  11 13 17 19  1  3  7  9
 13|  13 19 11 17  3  9  1  7
 17|  17 11 19 13  7  1  9  3
 19|  19 17 13 11  9  7  3  1
 >>> g20.explist()              # exponent of each member, method in Coprimes
 [(1, 1), (3, 4), (7, 4), (9, 2), (11, 2), (13, 4), (17, 4), (19, 2)]
 >>> g17.explist()              # same method, but different self/instance
 [(1, 1), (2, 8), (3, 16), (4, 4), (5, 16), (6, 16), (7, 16), (8, 8), 
  (9, 8), (10, 16), (11, 16), (12, 16), (13, 4), (14, 16), (15, 8), (16, 2)]
 >>> a=g20[2]
 >>> a                          # indexing is from 0
 7
 >>> a*a                        # powering a member of g20 (2nd power)
 9
 >>> a*a*a                      # powering a member of g20 (3rd power)
 3
 >>> a*a*a*a                    # powering a member of g20 (4th power)
 1
 >>> a*a.inv()                  # a.inv() = a*a*a, since (a*a*a)*a = 1
 1