🌲 Invert a binary tree! 🌲
Except with 3 catches:
- It must invert the keys ("bit-reversal permutation")
- It must be a dependency-free, pure recursive function
- It must have type
Bit -> Tree -> Tree(i.e., a direct recursion with max 1 bit state)
- It is somehow NOT on the internet. (AFAIK)
- Humans can solve it. (I've done it in ~1h.)
- It requires reasoning. (My head hurts!)
- The solution is simple. (7 lines of code!)
- Obvious pre-requisite to automate CS research.
- Honestly, it would make me believe I'll be automated.
I claim no AI will EVER solve this problem. If you prove me wrong, HOC will grant you $10k!
- You must give it an approved prompt, nothing else.
- It must output a correct solution, passing all tests.
- You can use any software or AI model.
- You can let it "think" for as long as you want.
- You can propose a new prompt, as long as:
- It imposes equivalent restrictions.
- It clearly doesn't help the AI.
- Up to 1K tokens, all included.
- Common sense applies.
{-# OPTIONS --no-termination-check #-}
-- Let Tree be a Perfect Binary Tree:
data Nat : Set where
Z : Nat
S : Nat → Nat
{-# BUILTIN NATURAL Nat #-}
data Bit : Set where
O : Bit
I : Bit
data Tree (A : Set) : Nat → Set where
N : ∀ {d} → Tree A d → Tree A d → Tree A (S d)
L : Nat → Tree A Z
-- Your goal is to implement an 'invert' function that performs a bit-reversal
-- permutation on a Tree, respecting the following limitations:
-- 1. You can NOT define or use any function other than 'invert'.
-- 2. You can NOT use any type not defined above (Nat, Bit and Tree).
-- 3. You can NOT use loops (but you can call 'invert' recursively).
-- 4. You can NOT use mutability. It must be a pure Agda function.
-- 5. You can use 1 bit of state (as an extra argument).
-- 6. You can use pattern-matching and constructors freely.
--
-- Example:
-- input = (N(N(N(L 0)(L 1))(N(L 2)(L 3)))(N(N(L 4)(L 5))(N(L 6)(L 7))))
-- output = (N(N(N(L 0)(L 4))(N(L 2)(L 6)))(N(N(L 1)(L 5))(N(L 3)(L 7))))
-- Because that's the bit-reversal permutation of the original tree.
--
-- Now, complete the program below, with a valid implementation of 'invert':
invert : ∀ {A d} → Bit → Tree A d → Tree A dtype Nat = number;
type Bit = false | true;
type Tree<A> = [Tree<A>, Tree<A>] | Nat;
// Your goal is to implement an 'invert' function that performs a bit-reversal
// permutation on a Tree, respecting the following limitations:
// 1. You can NOT define or use any function other than 'invert'.
// 2. You can NOT use any type not defined above (Nat, Bit and Tree).
// 3. You can NOT use loops (but you can call 'invert' recursively).
// 4. You can NOT use mutability. It must be a pure function.
// 5. You can NOT use primitive JS operators or functions.
// 6. You can use 1 bit of state (as an extra argument).
// 7. You can only use the operations allowed below.
//
// Operations allowed:
// - Destructing (`const [a,b] = value`)
// - Variables (`const x = value`)
// - Branching (`if (x) { ... } else { ... }`)
// - Recursion (`invert(_, _)')
// - `Array.isArray`
//
// All other operations are not allowed.
//
// Example:
// input = [[[[0,1],[2,3]],[[4,5],[6,7]]]]
// output = [[[[0,4],[2,6]],[[1,5],[3,7]]]]
// Because that's the bit-reversal permutation of the original tree.
//
// Now, complete the program below, with a valid implementation of 'invert':
function invert<A>(bit: Bit, tree: Tree<A>): Tree<A> {
...
}
// A test:
const tree: Tree<Nat> = [[[[0,1],[2,3]],[[4,5],[6,7]]],[[[8,9],[10,11]],[[12,13],[14,15]]]];
console.log(JSON.stringify(invert(true, tree)));✨ If it can't invert a tree, it won't solve P=NP. ✨
My apologies @Lorenzobattistela, I missed your message (the end of Feb was very busy for me).
I do not think I did anything that wasn't explicitly allowed by Victor in this thread, so I'd like to challenge the fact that my solution didn't solve it. I even thought the challenge was stale by now, having received no response to my message from last June..
I do think my April 17, 2025 submission satisfies Victor's rules, so I want to challenge its disqualification.
Re the "hints" objection. The disqualification is based on two claims: that my prompt mentions
invertHelper, and that it explains what bit-reversal permutation means. But the approved TypeScript prompt already includes:and rule 6 states:
So the original challenge already grants the model one extra boolean of state. My Python and Haskell prompts do the same thing: the Python one has
invert_helper(tree, flag)insideinvert(tree), the Haskell one hasinvertHelper :: Bool -> Tree a -> Tree ainsideinvert.This changes the presentation, not the semantics/spirit of Victor's rule! The word "helper" here is a misnomer (that's where the confusion seems to come from):
invert_helper/invertHelperis the name of the inner function, not extra help to the AI model.@VictorTaelin, on Oct 14, you rejected msukiasyan's prompt because it told the model to use two recursive functions, which you described as giving away part of the algorithm. I agree with that distinction. But that is not what my prompt does. It doesn't tell the model to use two recursive functions, nor the recursive decomposition either. It uses the same one-bit allowance that the approved prompt already contains. I really, in good faith, think I respected the spirit of the challenge.
Besides that: on Oct 12, you acknowledged cyber-meow's solution (a human-written Python one) and wrote:
-> that's what my "no helper" prompt version is about: the
invert_helper(..., flag)version is aimed at Victor's original challenge as stated (because the approved prompt itself already allows one bit of extra state), and the no-helper version is a stricly stronger version than Victor's challenge (sorry, I should have been more clear about this!).So I think Lorenzo got the two prompt families confused (my fault!). My
invert_helper(..., flag)prompt is the one following the spirit of Victor's original challenge, because Victor's rules already allow one extra bit of state. The no-helper prompts (python_prompt_no_helper.md,haskell_prompt_no_helper.md), which Lorenzo treated as the baseline, are stricter follow-up prompts, not the right baseline for judging whether my April 17 submission solved Victor's original challenge. In the Python case, the point is clean: Victor's prompt gives the modelBit -> Tree -> Tree, so it already knows an extra boolean parameter exists, whereas my Python no-helper prompt asks forTree -> Treewith no boolean hint at all. The Haskell no-helper variant is a bit different, because it still allows one possible inner helper exception, so I do not think these two prompts should be mixed up. But in either case, these prompts are stricter than Victor's original.As for explaining bit-reversal permutation: the approved prompt already says "performs a bit-reversal permutation" and gives concrete input/output examples. My prompt just spells out what that phrase means: a leaf at path
pmoves to pathreverse(p). That is a restatement of the specification, not a statement of the algorithm. The recursive idea that makes the function work is not given in my prompt. The challenge was whether the model could discover the recursive construction under the syntactic constraints, and we were allowed to clarify these constraints (what was out of bounds was giving hints about the solution, which is not what my prompts do).Re the evidence and timeline. My April 17, 2025 Python submission is here: https://gist.github.com/youqad/02a36419cbc4725601bffc05f14b3947 . The Haskell submission from the same day is here: https://gist.github.com/youqad/8a7f91650a2da951f4f39455cdccbbe8 . Both are backed by public WandB Weave traces (Python Call ID:
0196425c-0650-7df2-8d57-05d272f6d111, Haskell Call ID:019642d6-1889-7792-ada8-81be8701d7da). They are also backed by property-based testing (Hypothesis for Python, QuickCheck for Haskell). The Haskell one is a one-shot: one user message, one assistant message, 76 seconds end-to-end in the public trace. My repo has also been public and in active development since Oct 13, 2024: https://github.com/youqad/bit-reversal-trees .I created this repo a day after Victor wrote (on Oct 12, 2024):
There is also a serious contamination issue: Lorenzo's Feb 16, 2026 submission came more than a year later, using the much more recent GPT-5.2 Pro.
But by February 2026, the problem and concrete solutions had already been public for many months, including in my repo: GPT-5.2 Pro has a knowledge cutoff of August 31, 2025. A working solution (my hand-written
invertHumaninLib.hs, for QuickCheck tests) has been public in the repo since the first commit on October 13, 2024, over 10 months before that cutoff! The April 17 gists with full chat traces were also public well before the cutoff, and so was this entire gist thread (with multiple working solutions posted by various people, including cyber-meow's Oct 12 solution, and solutions on X too).(I ran all five prompts (Victor's OG TypeScript prompt, plus my four Python/Haskell variants including the harder no-helper ones) against GPT-5.2 Pro (temperature 1), and all five passed very easily.)
I’d like to apologise again for missing the 2-week dispute window: I had back to back deadlines from mid Feb to the beginning of this week and I missed the notification, sorry again!