in reply to (Golf) Cryptographer's Tool #2

Maybe this will help. I took the approach that it doesn't matter what the "cypher pattern" is as long as it's the same for both, but I'm probably missing something.
sub e{$a=$_;eval"\$a=~y/\Q$_\E/\0-~/";$a}

sub c{
  ($_,$m,$n,$a,$d)=@_;

  map{$x=e;

      $_,[grep{e eq$x}@$d]

     }/\b[^ ]{$m,$n}\b/g
}

[download]
107 chars w/o the linebreaks and indentation.
update: changed \S to [^ ] (as per chipmunk) to match tabs and newlines in encoded strings: 109 chars.
(but note that using $_[0..4] would get back a couple of chars.)
Actually, the really correct way to do it seems to be something along the lines of:
map{$x=e;$_,[grep{e eq$x}@{$_[4]}]}

" $_[0] "=~/ ([^ ]{$_[1],$_[2]})(?= )/g

[download]
which makes it 115 chars.

update2: Same length but more straightforward:
map{$x=e;$_,[grep{e eq$x}@{$_[4]}]}

grep{/^.{$_[2],$_[3]}$/s}$_[0]=~/[^ ]+/g

[download]
Well it would be the same length:  `grep/.../,' parses, but    `grep/.../s,' doesn't seem to.
Oh, and this last has the args ordered right. As to how I got it "working with the parameter errors"; simple, I was calling it with the args in the wrong order.

  p

Replies are listed 'Best First'.
Re^2: (Golf) Cryptographer's Tool #2
by tadman (Prior) on Jun 27, 2001 at 03:27 UTC
    I tried a few different approaches, but to no avail. So instead, I'm going to post a variation on petral's that has the added advantage of actually working. I'm just being funny because I don't have anything better. 
    sub e{$a=$_;eval"\$a=~y/\Q$_\E/\0-¦/";$a}

sub c{
  ($_,$m,$n,$a,*d)=@_;
  map{$x=e;$_,[grep{e eq$x}@d]}
  /\b[^ ]{$n,$a}\b/g
}

    [download]
    Two quick fixes. Instead of using @$d, just use @d, but declare a glob in the parameter extraction phase, *d. A silly trick, I know, but I've got to use it while I can before Perl 6 comes and takes away all my toys. Second, for whatever reason, petral wanted to use the second parameter $m (the "alphabet") as the minimum, instead of $n. Thus, the range should be {$n,$a}, not {$m,$n}.

    A change for the detail oriented required using '¦' (ASCII 127) instead of '~' (ASCII 126) in the pattern. It looks like the vertical pipe character, but isn't. The input specification said 7 bit (0-127), so this was a pseudo-off-by-one error.

    Not sure how petral managed to get that thing working without noticing the parameter errors. Good show!

    I'll just go on to post a few observations.

    1. The tr// operator can be fed "garbage" input and still make sense of it. This allows you to do duplicate characters in the first part, such as "tr/froggy/abcdef" which when run on "froggy" will give you "abcddf" even though 'g' has two possibilities. The first is taken, subsequent ones are ignored.
    2. You can always "overshoot" the second part of a tr by as much as you want. The extra stuff is ignored.
    3. The \b characters do not match newlines or tabs when the [^ ] (not space) element is there to pick up the slack (greedy).
[reply]
[d/l]
[select]
      Two quick comments... :)

      Remember that one 7-bit character, the space, is being used as puncuation, so there really are at most 126 characters in the alphabet.

      The use of word-boundaries (\b) to match the words is rather strange here, because we're using words that don't necessarily consist of "word characters". For example, if $n and $a were 2 and 4, that regex would match ('this', '-is!', 'one+', word') in 'this-is!one+word?'.

      Negative look-ahead/-behind assertions are necessary for this approach: /(?<! )[^ ]{$n,$a}(?! )/g

[reply]
[d/l]

In Section Meditations