Re^6: regex return true instead of false (precedence)

Replies are listed 'Best First'.
Re^7: regex return true instead of false (precedence) by Marshall (Canon) on Aug 27, 2019 at 02:33 UTC
Well part of the point that I'm trying to make is that condition should change to make the logical sense of this easier to understand. `unless ( (!($args =~ /\-rs(\s+)(\S+)/)) && (!($args =~ /\-p(\s+)(\S+)/)) && (!($args =~ /\-P(\s+)(\S+)/)) ) {..... # I figure this is easier to understand: if ( $args =~ /\-rs(\s+)(\S+)/ #update changed unless->if or $args =~ /\-p(\s+)(\S+)/ or $args =~ /\-P(\s+)(\S+)/ ) {....` [download] I was trained as a hardware engineer. DeMorgan's Theorem is an important part of hardware design. An AND or an OR gate is actually pretty rare. The most common gate is NAND, followed by NOR. The reason for that is that the fastest gates have a logical inversion - that is due to the way the hardware works. Inverting that output slows things down. Changing the formulation of condition can make things easier to understand. The compiler should generate similar code for the above examples. I just think that the second is easier for a human to understand.	[reply] [d/l]
Re^8: regex return true instead of false (precedence) by AnomalousMonk (Archbishop) on Aug 27, 2019 at 03:49 UTC
`unless ( (!($args =~ /\-rs(\s+)(\S+)/)) && (!($args =~ /\-p(\s+)(\S+)/)) && (!($args =~ /\-P(\s+)(\S+)/)) ) {..... # I figure this is easier to understand: unless ( $args =~ /\-rs(\s+)(\S+)/ or $args =~ /\-p(\s+)(\S+)/ or $args =~ /\-P(\s+)(\S+)/ ) {....` [download] I agree the second form is easier to understand, but it's also not equivalent to the first: `c:\@Work\Perl\monks>perl -wMstrict -le "for my $s (qw(p X)) { printf qq{for '$s' case }; unless ( (!($s =~ /p/)) && (!($s =~ /q/)) && (!($s =~ /r/)) ) { pri +nt 'A' } unless ( $s =~ /p/ or $s =~ /q/ or $s =~ /r/ ) { pri +nt 'B' } } " for 'p' case A for 'X' case B` [download] My understanding of haukex's point here is that the two `if/unless`-statement syntaxes that ovedpo15 was worried about are exactly equivalent, and so the condition expression doesn't have to change at all. If I had written the original code, I think I would have written something very much along the lines you and GrandFather suggest (or like this). But if the original condition expression was correct, convoluted as it was, and did not have to change, I would say it was the better part of wisdom to just leave it alone. I don't think we're really very far part on this one. :) Give a man a fish: `<%-{-{-{-<`	[reply] [d/l] [select]
Re^9: regex return true instead of false (precedence) by GrandFather (Saint) on Aug 27, 2019 at 07:18 UTC
When I first encountered `unless` in Perl I thought it was pretty cool. However in practise I'm much more used to plain ol' `if` and I find `unless` slows down comprehension of code so I hardly ever use `unless`. I never use negated expressions or expressions with more than one term with `unless` - that is just too mind bendy. I'd be strongly inclined to refactor the OP's condition to be like the version I used just to make the code easier to understand and maintain. In my view it is almost always worth taking the time to simplify convoluted code. And yes, putting the alternates in the regex is a completely acceptable solution. Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond	[reply] [d/l] [select]
Re^10: regex return true instead of false (precedence) by AnomalousMonk (Archbishop) on Aug 27, 2019 at 14:27 UTC
Re^9: regex return true instead of false (precedence) by Marshall (Canon) on Aug 27, 2019 at 23:27 UTC
but it's also not equivalent to the first: Quite correct...I forgot to change the unless() to a just if(). Updated my post. Don't do X if A,B,C are all false <- this is the original unless statement this the same: Do X if any of A,B,C are true (X doesn't happen if A,B,C are all false). I don't think there is anything truly controversial here. I would also agree if the code has been working and this is a modification, I'd leave it alone (as we see its easy to make a mistake with all these Not's!). If the code is still in initial development, then simplifying this convoluted loop condition is something I'd seriously consider.	[reply]