It's ugly but it works? The whole time I was coding this I couldn't shake the feeling that I was missing something that was going to requrie me to rewrite it almost from the ground up... but then, other than some reordering to match the expected order of things, it actually worked, so, uh, no rewrite needed, this ugly code I thought was doomed to be rewritten gets to be put on display!

damned if I know. Just popped back in after a year away from the site, spent tons of time polishing and refining my first kata, and almost as much time after that trying to get it approved. It's still beta, no clue why. Doesn't really matter, I suppose, since I'm not really active on the site anymore - but my frustration was a major reason for that tbh :/

ah, yeah, I forgot to come mark this resolved; thanks

I've forked the go translation to fix the issue here, if someone could approve it?

Don't think you can approve your own, will need to get the original kata creator or someone else with high enough honor to approve it for you.

The original creator hasn't been on since 2015, so probably no point holding your breat there; you can connect to the codewars gitter chat and ask someone there?

yeah, I did that while testing actually. Just a bit of a sanity check. Like I said, this fork is not meant to be accepted/merged - I only published it so you could see what I was tlaking about, and will unpublish it now

so what you're saying is I should add edge cases like that to the fixed tests? <_< :evil laugh:

ok, wow, I knew you guys' solutions were probably slower than mine because of the algorithm you used, but didn't realise just how much slower...

added to the random tests, and you're timing out pretty hard now.

For the record, my solution (which I didn't change) completes with the new set in <600ms, so... yeah.

sorry 'bout that, tweaked the tests a bit and broke your solution. Tested in a fork, and there's failure to meet precision requirements every now and then, plus a few odd "can't subscript nonetype" errors - since I can't see how the new tests could cause either, guessing you had to submit a few times to squeak through a pass, particularly on the precision thing?

just realized this could give false positives in some cases. Forking to fix, on general principles.

Made a fork trying to figure out why my test was consistently failing on the 6th test in the final, largest test group. Poked about and I still have no idea, really. I did find that replacing the source, actual, expected arguments from the call to cf_assert - which are there just to be substituted into the output message, since assert is just testing the boolean ok from comparing actual and expected - caused all tests to pass. Which... yeah. No idea why that would be, particularly since your reference solution passes regardless.

Anyway, the fork I made isn't really intended to be accepted as a replacement, certainly not in it's present form. Just a bit baffled about what could be going on there, and wanted to get your thoughts.

Oh, while poking it I also noticed that the "random" tests - at least 6th one in the last, largest group - don't seem to actually be random. It's always the same opening program that gets dumped to my log, starting with...

[[+,]>-[>-<>[<>++<,,.>>><-]<,[>->.[<.[--]]-<<<.<+-[[.-..-+<>[+>.]<>+.[<>[[--,<,<>+>[.[[.<+<...-<>[-[-[+[+]]-]>[--]+,,-..[.]<.-.[+][[-[.,,>[.,.<,-<>>[-]].<<].[.,,>-,[-[<>,,[<+]-,+....

I tried sticking a call to srand in there, but it seems to have done nothing, and I've no idea what that's about, either.

I'm looking at the C translation, pretty the test suited areto blame. Made a C solution myself, it was consistently crashing on one particular "random" test, after quite a bit of head-scratching and poking with a stick, I found what seems to be a fix - it's calling an assert method with an output format string and 3 strings to plug into it - the complete, 100000-byte bf program, plus both the actual and expected c programs. After dropping those inserted values, all tests pass.

Not sure if this is the cause of any or all the problems or not. Hopefully a fix will be coming soonish, though!

in cases like this, you can always add your own to the sample tests file - knowing they don't have to be meaningful brainfuck programs, it's not too hard to throw some together and work out what they ought to optimize/translate to.

Strange, but not removable in optimizations - one reads a character from input, throws it away, and then reads another. If you think of input as a byte stream, it makes more sense - you're deliberately skipping a byte to get to the one after it.

Sample tests may include that, but just tried forking the solution to be sure, and yah, it passes the actual tests, which is all that's actually required for it to be considered valid. So apparently the sample tests do include such a case, but the full tests don't?