http://www.perlmonks.org?node_id=213586


in reply to Multidimensional regular expressions

imagine you were going to do a pattern match against a multidimensional bitmap
Please comment on my Array::PatternMatcher... it seems somewhat up this alley.

thanks!

Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

  • Comment on Re: Multidimensional regular expressions

Replies are listed 'Best First'.
Re^2: Multidimensional regular expressions
by diotalevi (Canon) on Nov 18, 2002 at 04:52 UTC

    You're right it is. Where we differ is that your Array::PatternMatcher separates extractions from assertions and only borrows from the regex syntax. It's the sort of thing that we all know full well can be implemented by adding code. I'm looking at it sort of like exchanging m/^\d+$/ for sub is_numeric { for (split //) { return unless ord($_) >= ord('0') and ord($_) <= ord('9') } return 1 }. Or at least that's how it looks on the surface after reading your POD once.

    I'm just thinking it'd be a big win to be able to specify regular expressions in more than one dimension. Following on my original meditation I think perhaps I mislead myself. I think the proper multi-d regex is only going to have a new operator such that it tells the engine to go perpendicular and in which direction. A 2-d example would be an instruction to turn right at a certain point. 3-d might mean to start going up. I think the rest of the meaning makes the most sense when you think of multi-d as a tangled one-d space. A normal regex already goes one character/byte at a time, there's no reason to drop that (and that is what I originally proposed with the idea of skipping around). So maybe that means giving the \[{dimension,direction} sequence *just* a dimension and direction parameter.

    Initially I thought I'd need to rebind the regular expression at will to hop around to different array elements. I think instead... maybe when the engine isn't doing a normal 1-d regex that it'd need to run custom code that isn't regex at all to follow the data around. So this brings up the question - I've not seen a Regex tokenizer around (not that I've looked that hard either). Maybe with one of those an a controlling function you could jump around, test atoms and when possible use the normal regex engine.

    If this isn't clear then someone please let me know.

    __SIG__ use B; printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B::svref_2object(sub{})->OUTSIDE;
      Initially I thought I'd need to rebind the regular expression at will to hop around to different array elements. I think instead... maybe when the engine isn't doing a normal 1-d regex that it'd need to run custom code that isn't regex at all to follow the data around. So this brings up the question - I've not seen a Regex tokenizer around (not that I've looked that hard either). Maybe with one of those an a controlling function you could jump around, test atoms and when possible use the normal regex engine
      Do you need DFA or NFA regexes to do this? You know that Perl regexes are regex directed not string directed dont' you? In fact, I am just saying something. I still dont know what in the world you want to do. I'm just grabbing at straws and brainstorming.

      Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

        I'm thinking NFA since that'll be easier for me to get my head around. I prefer not to have to think about multi-d things accumulating in memory - and then there are local pockets of extra dimensions. Blech. No way.

        __SIG__ use B; printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B::svref_2object(sub{})->OUTSIDE;