It's a good solution, but it's hard to read. I think it's better when detailed names are used, and when conditions are complex, it's better to choose simpler constructions, not comprehensions.

ohhh haha. You should have seen some of the ones I unpublished. Just embarassing..

haha, nono, I meant because of all the down voting

lol! Yeah, not my jam. Your katas are waaay better.

I can see why you stopped authoring kata's

Your solution to this beta kata was invalidated because of recent requirement changes. Specifically, answers should now be returned as instances of class Fraction, not as floats.

I apologize for the inconvenience. Feel free to resubmit your solution to reflect this minor specification change.

This thing would require a very substantial effort

(Brain....) F***!!!! => Very nice kata (more than one month of long nights on this one...)!\

Will try to refactor and structure before submitting\

BTW I observed some weird differences between clang and msvc, along the journey...

After long (I mean... really long) investigations...
As amateur in C++ I wanted to use an std::variant structure that was to much (I mean... much too much) time consuming @ compile time.
Had to entirely rewrite, still trying...

This deserves a special 3rd button for Alien Code..

I don't know exactly what it could be, but I can tell you where my performance problem was. After I wrote a working solution I had a constant timeout on tests. The problem I had was that I chose the wrong algorithm for comparing > and <, he was too ineffective. I implemented one algorithm for this and then just swapped if I needed to take >:

    ...
    def lt(self, id1: int, id2: int) -> int:
        ...

    def gt(self, id1: int, id2: int) -> int:
        return self.lt(id2, id1)
    ...

And yes, if I have the < algorithm implemented now, that means I had > before. If anything, I was looking at the implementation from here. Try implementing < if you currently have > implemented.

My guess is that you have an intermittent infinite BF loop (e.g. due to some non-zeroed vars). Try out the online BF debugger to diagnose: https://esolangpark.vercel.app/ide/brainfuck

I too agree that implementing 'lset' / 'lget' was quite gnarly. I had to invent an algo mostly from whole cloth after getting some hints on Stack Overflow (I do see that @MikChan had a similar approach, so maybe it wasn't that original).