haven't made a final decision on what the syntax would be though. They'd need to have an atomic and molecular version I suppose, just like the other lookarounds

Lookintos would of course be a superset of lookbehinds in power (or identical in power), but usually not in golf-shortness.

I was just slightly annoyed that I couldn't test locally with ^(x(x+))(?<!^\3+(x+x))... I really like developing solutions by using ./regex

Yep, I hear ya. Maybe I'll start on implementing lookbehinds today.

I was just trying a slightly different approach for Guiga... Right now it's 4 chars longer: ^(x(x+))(?<!^\3+(x+x))(?!((x+)\5*(?=\5$))?\1(?=(\1*)\2+$)\1+$\6)\1*$

And it thinks that 1 is Guiga

((x+)\5*(?=\5$))? seems like a really ugly construction. I want to do tail /= n where n is a (possibly 1) divisor of tail

@H.PWiz Can get even shorter than that: ^(x(x+))(?<!^\3+(x+x))(?!(?=.*(?=\1*$)(\1\2+$))\4*$)\1*$

At that length, it's still better even when handling of zero and one is tacked on

I should have seen that optimization myself. It's obvious in retrospect: square \1 and then assert tail isn't divisible by that square. Much better than dividing it by \1 and then asserting it's not divisible by that quotient. What was I thinking

I never learnt about the square regexes... nice work. shorter yet is: ^(x(x+))(?<!^\3+(x+x))(?!(?=\1*(\1\2+$))\4*$)\1*$

@Deadcode The way the question is worded makes the approach we both originally took seem very natural

It would be nice if you weren't allowed to invert the outputs... That way handling 1 becomes much easier

It's one of the trends on code.golf that I came to really dislike. A rather hilarious example of this strange thinking is here

@H.PWiz Yep, that is the trap I fell into :-) good thinking to come up with the square idea

@H.PWiz Yep I agree

@H.PWiz Oh right, of course, because tail is already divisible by \1. Nice.

You realize it's tied with the .NET version now? :D

That's quite pleasing. I still feel uneasy with (?<!) for some reason. Even though it was introduced years ago

I haven't checked what changed, but it seems that you don't have to worry about 1 anymore, and can start with (x(x*))

So it beats .Net now!

Beats? No, not if it has to give a correct answer for 1.

It's a tie.

It only beats it by 4 bytes if we don't need to handle 1 correctly

^(x(x*))(?<!^\3+(x+x))(?!(?=\1*(\1\2+$))\4*$)\1*$

Yep just saw that

When I was playing earlier this didn't work... I can't remember what the difference is

Except I can maybe port the squaring idea to the .NET version and have it beat this

@H.PWiz There's a problem I'd really like you to try. Matching correct statements of 16-bit truncated binary addition. (with a robust solution, not just one that passes those test cases) I've done it in 67 bytes. I'm really curious if you can match that.

It can be tested for full robustness with RegexMathEngine, just do ./regex --test=binary-sum 'your regex'

@Grimmy Oh no, how did I totally miss this? Did Grimmy golf down a problem to 137 bytes that I'm still at 174 on, and then never post it?!

Or was 155 that problem but 137 the totient?

Either way that's much better than 174

@Deadcode My first attempt gets me to 121... I need to think some more about this

> Error: Unrecognized option "--test=binary-sum"

@H.PWiz That's a good start. Please keep each version, I'd like to see your path of progress

@H.PWiz Which version are you running? I added this in 2020-01-23

The test will generate no output iff the regex works perfectly

git pull syas I'm up to date...

nvm, I didn't recompile after pulling :)

;-)

> zsh: segmentation fault (core dumped) ./regex <<< '0000000000000000 + 000000000000000 = 0000000000000001'

@H.PWiz Does it work at all for other things now that you've recompiled it?

It fails for my cyclops regex on 3

Hmm, it crashes for me now when compiled on the latest gcc

so that means I can debug and fix that I guess

Geez, it crashes even when compiled with -O0. Weird.

Works fine compiled by MSVC

Fixed one crash, but it's not the only one it seems

actually that's unrelated. Only happens with --trace --trace I think

Tested with clang++ and it crashes too

@H.PWiz Would you like a temporary workaround or are you fine waiting for a proper fix?

Temporary workaround is just adding some padding bytes at the end of backtrack nodes

@H.PWiz Never mind, did the proper fix and pushed.

Oh yeah, and use ./regex --test=binary-sum --test-false+ 'your regex', not just --test=binary-sum alone