"Meino Christian Cramer" <Meino.Cramer / gmx.de> schrieb im Newsbeitrag
news:20040818.135303.74729997.Meino.Cramer / gmx.de...
> From: "Robert Klemme" <bob.news / gmx.net>
> Subject: Re: POT (partly offtopic) Re: Q: Shifting a hash anf and array
> Date: Wed, 18 Aug 2004 19:10:56 +0900
>
> >
> > >  I dont know, what I like most: Ruby or its mailing list people ! :O)
> >
> > :-))
>
>   I only can repeat what I said previously about my inabillity to
>   decide between both ! :O)

Take your time. :-)

> > >  I thought of implementing the wheels as such
> > >  not-integer-but-ordered-indexed "arrays". And my question about all
> > >  this rotating and shifting stuff was to figure out how to "rotate"
> > >  my wheel-arrays.
> >
> > IMHO rotating is much too inefficient.  I'd rather use a changing offset
> > like this:

<snip>code</snip>

>   Ok, this looks more like the Enigma++ or Enigma Pro or Enigma Deluxe
>   ;) (by the way...currently it seems that there were 17 different
>   models of the encyphering machine...)

Why Enigma++?  Personally I find it the easiest and most natural to create
those classes that abstract exactly the concepts of natural world that I
want to model.  So having a Wheel class would be most natural for me, even
if it had only one or two methods.

>   Unfortunately there is not only the one offset needed for rotating
>   the wheels -- there is also one offset to be take into account for
>   the outer ring or "tyre" of the wheels which was used to adjust the
>   alphabet against the internal wireing and an additional offset for
>   the start positions of the wheels.

Well, you can calculate all offsets in one step.

>   I think I will do first "rotate" the "wheels" into the initial
>   position takeing the outer ring position and the start position of the
>   wheels into account. This only happens once.
>
>   And then I will "robertize" the "wheels" according to your code
>   above, Robert. Since this happens for each letter to encypher it is
>   far more important for this part of the code to be fast. And the
>   code does not get too complex because of haveing three different
>   offsets to be calculated each time.

Sounds quite reasonable.  In that case maybe I'd change the encode method to
accept one offset argument (or a list of offsets) so you only have to do the
modulo once, i.e., you can sum them all up and then do "% @code.size".
Example with arbitrary many offsets:

    def encode(char, *offsets)
      @code[(normalize(char) + offsets.inject(@offset){|sum,x| sum + x} ) %
@code.size]
    end


>   What do you think, Robert?
>
>   Thank you very much for all the help I got from this list.

You're welcome!

>   Hopefully I will find the rest of informations I need about the
>   technical specs of the different Enigmas.

Good luck!  Some links that Google revealed:

http://www.mirrors.wiretapped.net/security/cryptography/algorithms/enigma/
http://www.javaworld.com/jw-08-1998/jw-08-indepth-p3.html

http://mathforum.org/library/topics/cryptography/


Kind regards

    robert