FFT failure makes sense if you think about what cooley-tukey actually needs. integer indexing into an array, log-N recursion depth with shared state across the butterfly. in pure lambda calc you're working with church numerals and church-encoded lists, where every index lookup is O(N) by itself. the algorithm goes from N log N to N^2 log N or worse depending on encoding. the bigger issue: most internet FFT implementations assume mutable arrays, so the model has nothing structurally similar to copy from. it has to derive the encoding-aware version itself. that's a different skill than reproducing C with let-bindings, which is what most coding evals actually measure.

fwiw, one of the FFT challenges is about the Scott encoding [1], while the other uses Church trees at least [2]. Both use a balanced ternary numeral system, which is a lot more efficient than plain Church/Scott and fairly well-known [3]. Either way, I would have assumed there to be a chance that at least one of the AIs had a look at [4] -- a tutorial about FFT in LC by the benchmark creator himself.

[1] task: https://github.com/VictorTaelin/lambench/blob/main/tsk/stre_... solution: https://github.com/VictorTaelin/lambench/blob/main/lam/stre_...

[2] task: https://github.com/VictorTaelin/lambench/blob/main/tsk/ctre_... solution: https://github.com/VictorTaelin/lambench/blob/main/lam/ctre_...

[3] https://link.springer.com/chapter/10.1007/3-540-45575-2_20

[4] https://gist.github.com/VictorTaelin/5776ede998d0039ad1cc9b1...