@Adám why does it require suboptimal solutions? 6 is clearly pairwise reduce, but it doesn't accept that, so i switched to using the described approach and wrote a fork (1∘↓=¯1∘↓) and it also doesn't accept that, so in the end i had to repeat 'bookkeeper' twice in the code, which is so ugly
similarly for problem 5, where it doesn't accept a solution with ⍨
I understand not explaining all these features to the beginners the competition is aimed towards, but why not at least accept them for us more experienced apl developers?
unrelated, but i'm considering dropping last-axis versions of all, or at least most (, might get saved), functions to tinyapl. would this be too radical a choice? At Rank makes them useless anyways, right?
though i don't know what classifies as tiny in the apl implementation world – 2500 lines is still tiny, right?
it will quickly grow in size once i start adding complex functions, though
I just learned about complex floor, is it important to have or is my current implementation of ⌊a⊕b ↔ a⊕⍥⌊b fine? it doesn't look that hard to implement so maybe i could just add that and not worry about it
@RubenVerg I'd say better error than using that simplified definition, since it isn't mathematically correct (i.e. it should not be possible that 1<|x-⌊x)
@RubenVerg It fails #3 only. I think the justification for that requirement is very weak. It's true that if the magnitude of a remainder is less than that of the denominator then the Euclidean algorithm can easily be proven to halt on rational inputs. It doesn't follow that this is the only way to get the Euclidean algorithm to work. Erik Wallace told me it still converges fine with component-wise floor. I don't know a proof of that but I haven't come up with any contrary examples at least.
