Search Ideas

I gave you an opportunity to be eligible for the remaining funds if you just stopped arguing. Now you’re doubling down and arguing more. You’ve forfeited the remaining funds.

Veritula discussion trees can’t accurately reflect problematic vs unproblematic ideas when unreasonable people are involved.

I’m banning you from Veritula in perpetuity. Don’t contact me again. I wish you well and hope you find another forum more to your liking.

When thousands of dollars are at stake, I think it’s fair to ask people to play by the rules. Still, I’m allowing flexibility by giving Jad a chance to collect the remaining funds.

I’m always happy to reward good work; I’ve paid out bounties in the past. And before I found out about Jad’s use of AI, I gave him tips increasing his odds of beating the bounty. I also submitted criticisms of some of my own ideas, further increasing his odds.

But people need to earn the reward. At some point, I noticed Jad had submitted his replies very quickly, with unusually verbose text, and in fairly rapid succession. AI is notoriously verbose, so that would have been the second-best time for him to mention he was using AI. He did not. But some people do genuinely type fast, so I gave him the benefit of the doubt.

When I later asked him directly whether he was using AI, he admitted to it but claimed it was merely to “help edit some of [his] writings”.

Pangram, an AI detector, paints a different picture: it says 100% (!) of the code and 22% of the prose in his first idea are AI-generated. I’ve also sampled some of his replies since, which Pangram says are also 100% AI-generated.

To play devil’s advocate once again, I wanted to make sure Pangram wasn’t giving me false positives. So I ran several tests against some of my own prose and code, and compared the results with known AI-generated prose and code. Pangram was almost always right – the few times it did make mistakes, they were almost always false negatives, so if anything, Pangram is too permissive. It does have lower confidence for shorter texts, so I also made sure to use only texts that are long enough. I showed Jad these results privately and he didn’t have a good answer, so I’m surprised he now wants to continue the discussion publicly.

In terms of content, handwriting the code matters because of Deutsch’s yardstick for having understood a computational task: if you can’t program it, you haven’t understood it. Jad says he still understands the code regardless, so it shouldn’t matter. But why not raise that before agreeing to a rule he took issue with? Why accept the risk of disqualification instead?

In terms of fairness, as Jad knows, payout for a bounty depends on addressing all known criticisms inside a review deadline. When a participant uses AI to help with that, but the funders don’t know about it, it creates an unfair advantage. That’s a violation of not just the letter but also the spirit of the rules. It’d be like secretly using a chess computer for help in a chess competition. The amount of text Jad has submitted also creates an uphill battle for the remaining funders to review his submissions before the deadline. Jad says he knows how bounties work, so he knows payouts are automatic at the deadline. Still, the remaining funders are willing to accommodate him.

Before I made the decision to withdraw my funds, I reached out to Jad privately, as I said, to make sure there wasn’t anything I had missed and that there were no hard feelings. We discussed the issue thoroughly and I couldn’t find anything. I also discussed the matter with the co-funders for a second and third opinion, again to make sure I hadn’t left any stones unturned. (To be clear, the responsibility for the decision to withdraw my funds is mine alone.)

I understand Jad was hoping for a bigger payout, so this must be a disappointing outcome. I empathize with that. I’d be bummed too. But he could have easily avoided this outcome. One can’t agree to a rule, immediately break it, get an unfair advantage, hope I won’t notice, and then complain when I do. But with any luck, he’ll get the remaining funds, provided that the arguing ends now.

Okay, this is a great additional point that continues along the dealing-with-infinities path.

In #5598, I discussed the case where two explanations both have an infinite number of variants. I also said:

I don't think we need to get into comparing different sizes of infinity here.

In revision #5604, I explicitly added the ability to deal with infinite variations. Nevertheless, your point stands that the current program would treat A and B as equally hard to vary.

I think there's a pretty simple remediation. Rather than only comparing the number of variants, the program can also keep track of how many independently variable parameters have an infinite number of possible values.

So in your example, A has one infinitely variable parameter whereas B has two, so the program would rank A as harder to vary than B.

I think this is a good extension because it captures the improvement you're pointing out. I submitted a revision accordingly: #5609

In #5555, you say that adding an arbitrary component to an explanation makes it worse. Consider these two explanations of winter:

A: Winter happens because a god repeats a spell seven times.

B: Winter happens because a god repeats a spell seven times, and the spell only works if the god wears a red hat.

Suppose neither story explains why the number must be seven. We could substitute eight, nine, or any other positive whole number while the story still accounts for winter. In B, we could also change the required hat colour without affecting its ability to account for winter.

Both explanations therefore have infinitely many working variations. Your program declares them equally hard to vary.

But B has an additional arbitrary requirement: the hat colour. It is explicitly part of the supposed mechanism, not an unrelated detail added to the wording.

Removing that requirement removes an arbitrary part of the explanation. Yet your program cannot register the improvement, because the variation count remains infinite.

Unfortunately, Jad has admitted to using AI for his submissions, in violation of the bounty terms. As a result, he’s not eligible for a payout. After discussing the issue with him and separately with cofunders @dirk-meulenbelt and @davies, I’ve decided to withdraw my funds.

However, the co-funders say they don’t mind the use of AI. For that reason, and as a token of appreciation for Jad’s idea, I’m making an exception and he’ll remain eligible for their funds, pending further development of this bounty.

Link to exact code version used here: hard-to-vary/htv.py at ab8be8

Link to exact code version used here: hard-to-vary/htv.py at ab8be8

Link to exact code version used here: hard-to-vary/htv.py at ab8be8

Link to exact code version used in #5523, #5541, #5544, #5551:
hard-to-vary/htv.py at ab8be8

If the user already judges that both explanations have infinitely many working variations, do they really need the program to tell them that they're equally hard to vary? That seems unlikely—the result already follows from the inputs.

That said, if you think it's important for the program itself to represent this case explicitly, I can extend it to handle infinite families of variations as I suggested in #5598. I see that as a small extension to the implementation rather than a problem with the underlying HTV procedure.

Okay, so you're thinking of an edge case where two competing explanations genuinely both have infinitely many working variations.

For example, one explanation says some amount X of grass cures the disease, another says some amount Y of wheat cures it, and neither explanation constrains what X or Y should be. Both can just keep being varied indefinitely.

If that's the kind of case you have in mind, then yes, I agree it's an interesting edge case. If these were the only two competing explanations, my current program would have an awkward time representing the fact that both have infinitely many variations. But also, in this example they're genuinely both extremely easy to vary, so ranking them equally doesn't seem obviously wrong to me.

I don't think we need to get into comparing different sizes of infinity here. If a third explanation had only a finite number of working variations, it would clearly be harder to vary than either of the infinite ones.

As for the implementation, one simple extension would be to let the user indicate that a submitted variation represents an infinite family of working variations, rather than requiring them to enumerate individual examples. Something like a checkbox for "this can be varied indefinitely." That would let the program represent this edge case without changing the basic idea.

I'm not sure it's clear what you mean by this.

Are you saying the process I've outlined doesn't work for a factual matter like the Pop-Tarts question? If so, I've explained in #5586 and #5562 how facts and new knowledge change the problem situation and what explanations and variations we accept.

If, on the other hand, you're saying that this process does work, but that not all of it should be called HTV, then I think that's the same point you were making in #5585, which I'm fine with.

This is out of scope for the bounty. The bounty merely says the program must “Return a ranking indicating which explanation is better, worse, or equal.” It doesn’t say the program has to specify which variation.

The program can't accept my judgment that these are genuine variations and then independently override that judgment because it “knows” they're actually irrelevant. Doing that would require the program itself to understand what is doing explanatory work. That's precisely the part I'm outsourcing to the user.

Fair enough.

As of 2026-09-02, I’ve removed that part from the blog post.

It sounds like you’re agreeing, in which case this shouldn’t be marked as a criticism.

HTV could still be part of the process, but DD’s claim was that all rationality boils down to HTV.

I'm not defending DD's claim. My claim is that HTV can be implemented.

I think this is the same basic point as #5577.

How does this show that HTV is unrelated to finding truth?

You say:

But guess 1 and 2 are plausible and I see no reason to prefer one over the other.

That's exactly how I see it. Before looking up the historical evidence, both seem like good explanations given what we know. So HTV giving us no preference between them seems like the right result at that point.

Once we acquire new knowledge that distinguishes them, the problem situation changes, as I explained in #5562.

I don't see why HTV failing to distinguish two good explanations before we have the knowledge that distinguishes them means it's unrelated to truth.

I don't think test results need some separate formal mechanism for being “fed back” into HTV.

This is the same point I made in #5562. A test result is new knowledge, and new knowledge changes the problem situation and therefore what counts as a working explanation.

It does. Preference formation is the point of the program.

I don't think preference formation requires the program to always select exactly one variant.

If several variants are equally hard to vary given everything I currently know, then “equally hard to vary” is itself the result of the comparison. I don't currently have a rational reason from HTV to prefer one over the others.

I don't think the program should invent a preference when the current problem situation doesn't give us one. The variants can remain competing possibilities until we learn something that differentiates them.

Fair, I didn't mean to imply that #5531 says different people getting different results is itself a problem. I was explaining why I think disagreement about what counts as a variation is okay, even when that disagreement leads to different results.

The user can correct this by rerunning the program with the corrected inputs. I think the UX can be improved by adding add/edit/delete functionality, as discussed in #5559 and #5560, but the basic functionality of the MVP still holds.

Addressed that with #5577

@jadelmourad be sure to submit separate criticisms separately. You benefit because it means I need to address each criticism individually, not in ‘bulk’. (See #5546, keyword ‘bulk’.)