I’m trying to make a simple pattern to accept n*4 + 2 or 4n + 2 where n is any number. I wrote:
valid = p.sum(p.product(p.number,p.number.satisfies("x=4")),p.number.satisfies("x=2"))
but this is only accepting expressions where the other number comes before the 4, like 3(4) + 2 but not 4(3) + 2. I’m confused by this because shouldn’t product be valid regardless of the order?
It will accept 2+3(4), so sum is working like I expect. Not sure what is happening here?
I can’t work out what’s going on here either; this might be a bug.
Product (and sum for that matter) seems to have the option for .strictOrder, which would imply that without this tagged on, it should match product in any order. The fact that it behaves the same with or without that option suggests bug to me, but there may be something I’m missing.
Either way, something like p.anyOf(p.product(..., ...x=4), p.product(...x=4, ...)) inside the sum should allow it to capture either orientation.
I’m not sure if its oversight or limitation that is causing that pattern to break, but its not surprising.
Since the pattern is looking for any number first and then a specific number, both 3(4) and 4(3) satisfy the first argument. Then looking at the second argument, 3 fails but 4 does not. since the first argument does not fail in either case, attempting to match the second term to the first part of the expression never happens.
I’ll pass this on to engineering to see if there’s something that can be done, but you can avoid this yourself by listing the more specific terms first (so that it fails and attempts the reverse order).
p.product(p.number.satisfies(x=4),p.number)
Thanks for the explanation. Switching the order to put more restrictive first worked. I think I understand what you mean… if I enter 4(3), the 4 matches with the first argument and the 3 does not match with the second argument, so it fails, because it is not set up to then test in other orders.
But if the more restrictive argument were first, then if I type 3(4), the 3 fails the first check so it then will check it against the next argument, which passes, and then the 4 is checked with the only remaining argument which passes.
So if I am understanding correctly, it seems like it would be problematic to write a single pattern that matched 45n for example, if I wanted to specify that the integers had to satisfy 4 and 5.
Listing your arguments from most specific to least specific should be a pretty airtight strategy. Is the pattern you’re trying to match here 45n? Or is it something more specific like a number (4) times 5n?
Oh I had type 4 times 5 times n but somehow I triggered an italics tag. I’m not trying to build that per se, I was just wondering if there were two factors with restrictions would this still work. I guess I’ll play around with it more if/when it actually comes up in something I’m trying to do. But the most to least restrictive rule makes sense.