in reply to Re^5: Problem with regex wildcard operator (.)...?
in thread Problem with regex wildcard operator (.)...?

Thanks for the explanation! I did not think that an escape '\' would work within TR. Even though that does indeed work, I prefer my tr/A-Z/a-z/ because it is easy for me to understand it at a glance. Of course, mileage varies.
  • Comment on Re^6: Problem with regex wildcard operator (.)...?

Replies are listed 'Best First'.
Re^7: Problem with regex wildcard operator (.)...?
by AnomalousMonk (Archbishop) on Sep 06, 2021 at 08:30 UTC
    I prefer ... tr/A-Z/a-z/ ...

    So do I - or better yet lc in this case. :)

    Give a man a fish:  <%-{-{-{-<

      Yes, lc() is rocket fast because this only involves fiddling with one bit within a byte. C and ASM can do this very, very quickly. This is just a minor point in the OP's code. This is in a "run once" initialization loop. No optimization here will make any difference at all in terms of user perceived performance.

      The OP does have a correct idea in that running a regex against all lines of the input dictionary will be so fast, that the complexity of that regex probably makes no difference at all. The idea of throwing away extraneous results that are either too long or too short in terms of number of characters also probably makes no difference.

      I think the problem here is that we do not have clearly defined textual description (meaning something that a human can understand) of what the code is supposed to do! Nobody here can "fix" code that doesn't do what it is supposed to do, if we don't know what it is supposed to do in the first place!

        lc() is rocket fast because this only involves fiddling with one bit within a byte.

        That's only true for ASCII. For Unicode, things are quite different and will probably need some kind of table lookup. Just an example for the german language:

        Upper Case CharacterCharacter CodeLower Case CharacterCharacter Code

        And unfortunately, that's not all. The LATIN CAPITAL LETTER SHARP S, as ẞ is called in Unicode, is very new. First proposals are about 140 years old, but it became part of the standard german orthography in 2017, after becoming part of Unicode in v5.1.0 (April 2008) and of ISO/IEC 10646 (June 2008).

        Before that (i.e. up to 2017), converting LATIN SMALL LETTER SHARP S to upper case resulted in converting it to SS or SZ. And to make things worse, the conversion depends on context. SZ is always ok, but considered harder to read. In general, SS was (and still is) used, except where it may cause misunderstandings. A common example for that problem is "Mae" (dimensions) vs. "Masse" (mass), both can be upper-cased to "MASSE". The meaning can often be derived from the context, to avoid misunderstandings, "Mae" would be upper-cased to "MASZE". Reversing that (i.e. implementing lc()) opens another can of worms, as other words may contain "ss" or "sz" that must not be converted to "". The LATIN CAPITAL LETTER SHARP S solves that problem nicely, lc("ẞ") is always "", no funny context rules needed.

        See also

        BTW, swiss standard german solved that problem differntly: was completely replaced by "ss" in the 20th century (mainly between the 1940s and 1970s). "Mae" vs. "Masse", both written as "Masse", has to be resolved by context.


        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)