Jad Elmourad
@jadelmourad·Joined Sep 2026·Ideas
#5612·Dennis HackethalOP, 7 days agoWhen 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.
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.
I don't accept the characterization that I knowingly violated the rule and hoped you wouldn't notice. That wasn't my state of mind. More on this in #5622.
#5612·Dennis HackethalOP, 7 days agoWhen 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.
But why not raise that before agreeing to a rule he took issue with? Why accept the risk of disqualification instead?
This is a fair point, like I conceded in #5613: "We also agreed that in the future, discussions like this about the terms ought to be brought up at the beginning rather than after the fact."
And I definitely learned a lesson: to hash things out before if I see any potential conflict.
If you're curious for some more details about what happened here, I would say I got excited about getting my idea out as fast as possible and hearing criticisms. I had noticed the potential conflict about AI use, and I had marked it in my head as something we might have to discuss eventually, but I didn't see that point as arriving until at least the submission seemed to be surviving the criticisms. So when you brought it up and asked whether I was using AI, I immediately said yes.
#5612·Dennis HackethalOP, 7 days agoWhen 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.
But with any luck, he’ll get the remaining funds, provided that the arguing ends now.
I'm not sure what you mean by that. Are you saying that my eligibility for the remaining funders' funds depends on me not continuing this discussion?
If so, then this statement seems to block discussion and thus the growth of knowledge. Isn't the point of this platform to be able to hash out ideas and conflicts between them and thereby become more rational and knowledgeable?
I like the quote at the bottom of the website
[T]he growth of knowledge depends entirely upon disagreement.
— Karl Popper, The Myth of the Framework
I hope this is what we are doing here :)
#5612·Dennis HackethalOP, 7 days agoWhen 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.
I’m surprised he now wants to continue the discussion publicly
In fact, I had explicitly conveyed in the private discussion that I wanted to continue the discussion, but that I will also respect Dennis's boundaries if he wishes to stop the conversation. Dennis brought the conversation to an end by saying: "I think we've discussed all we have to discuss."
When he subsequently posted about the issue publicly in #5606, I replied publicly to confirm the AI use and explain my position.
#5612·Dennis HackethalOP, 7 days agoWhen 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.
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.
I don't see what creates an "unfair advantage". Maybe the next lines clarify.
It’d be like secretly using a chess computer for help in a chess competition.
I don't think this analogy is appropriate at all. In a chess competition, people are competing between themselves to prove who is better at chess. My understanding of this platform and the bounty is that it's to incentivize the growth of knowledge, not to prove who is better at writing ideas without AI.
The amount of text Jad has submitted also creates an uphill battle for the remaining funders to review his submissions before the deadline.
This reads to me as suggesting that the text I submitted was somehow excessive or perhaps even intentionally overwhelming, when instead my intention with all my writing was to communicate my ideas as clearly as possible. In fact, on the contrary, I felt that I had to excessively elaborate on some ideas that were clear to me just so that I could better get the idea across.
#5612·Dennis HackethalOP, 7 days agoWhen 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.
I showed Jad these results privately and he didn’t have a good answer
My actual reply to this was to bring up the questions from #5617 about what "AI-generated" signifies. Specifically, I asked "What does Pangram consider AI edits to be?", to which Dennis replied "I don't think they disclose that."
After that, I tried to make progress towards common ground by raising the deeper issue. I said:
Hmm, maybe we mean different things, so what do you think qualifies as an appropriate use of AI / using AI to edit vs an inappropriate use?
To which, Dennis replied by re-iterating that the bounty terms are clear that no AI must be used, but that didn't address the deeper issue I was trying to raise. I was trying to distinguish between different kinds of AI use in the context of what it means to have done the intellectual work necessary to earn the reward, see #5615.
#5612·Dennis HackethalOP, 7 days agoWhen 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.
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
I think this relates to #5615. I think there is a fundamental disagreement about what the term AI-generated means. If I write something and then pass it to an LLM for edits, then that gets marked as AI-generated. But is that really the deal-breaker here? Are we testing "ability to solve the bounty and write up the solution without AI"? Or are we testing that the submitter understands what they're submitting, which we already established?
#5612·Dennis HackethalOP, 7 days agoWhen 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.
At some point, I noticed Jad had submitted his replies very quickly, with unusually verbose text, and in fairly rapid succession.
For the record, I was working in blocks. I would read all the criticisms available at a time, then think about how to address them together. So I was sometimes writing out the response for each criticism, but holding off on submitting them so that I can properly cross-reference between them. Then I would submit them all at the same time. This is the explanation for the rapid succession and what might have appeared as unusually fast typing.
#5612·Dennis HackethalOP, 7 days agoWhen 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.
But people need to earn the reward.
This one sentence is really at the heart of this discussion. This is the point that bothers me the most because it confirms my interpretation that Dennis doesn't think I earned the reward because I used AI. Do I take it to mean that he thinks AI could have solved this puzzle if only anyone thought to plug it into an LLM? Do I take it to mean that he thinks that's how I used AI? I think that is dismissive of all the work and thought I put into this.
One question I would pose is: What do you think AI did that means I didn't earn the reward?
Marking as criticism
Just to confirm, and so you can hear it from me, yes I did use AI to help with my submission.
For posterity, here was my position during the discussion:
I think it's technically fair for Dennis to consider the submission ineligible because the bounty terms clearly say "Submissions must be handwritten. No AI-generated text or code; suspected AI use makes submissions ineligible."
On the other hand, I think this outcome is a shame because I don't think my use of AI changes any of the real work and thought that was put into it. If you zoom out, the motive of the bounty is to attract people to work on ideas and develop them, which is exactly what I did here, regardless of the tools used. As How Do Bounties Work? puts it, "Bounties let you invite criticism and reward high-quality contributions with real money."
And this is exactly what happened here. The idea had been posted on Veritula for about 10 months, and when I saw the bounty, I took it as a fun challenge to work on. So in that sense, the bounty incentive worked. And it seems to me that the reception of the idea has been good so far, which is why I find this outcome disappointing. On a symbolic level—and I acknowledge that this may be very different from how Dennis sees or intends the decision—his withdrawal of all his funds feels to me like this work is somehow not something he's willing to reward.
I did attempt to persuade Dennis to reinterpret the no-AI rule by discussing the underlying reasons for the rule. We agreed that handwriting can be a way to test the submitter's own understanding rather than relying on AI's understanding. While we agreed that this wasn't an issue for me, we disagreed about what should follow from that. My view was that the purpose of the rule should matter more than the literal wording, whereas Dennis seemed to think that the written terms should still govern.
Ultimately, we couldn't come to an agreement on whether my use of AI was appropriate in the context of this bounty. We also disagreed about whether I should have raised my use of AI proactively. In any case, I respect Dennis's decision since ultimately these were the terms of his bounty. We also agreed that in the future, discussions like this about the terms ought to be brought up at the beginning rather than after the fact.
Just to confirm, and so you can hear it from me, yes I did use AI to help with my submission.
For posterity, here was my position during the discussion:
I think it's technically fair for Dennis to consider the submission ineligible because the bounty terms clearly say "Submissions must be handwritten. No AI-generated text or code; suspected AI use makes submissions ineligible."
On the other hand, I think this outcome is a shame because I don't think my use of AI changes any of the real work and thought that was put into it. If you zoom out, the motive of the bounty is to attract people to work on ideas and develop them, which is exactly what I did here, regardless of the tools used. As How Do Bounties Work? puts it, "Bounties let you invite criticism and reward high-quality contributions with real money."
And this is exactly what happened here. The idea had been posted on Veritula for about 10 months, and when I saw the bounty, I took it as a fun challenge to work on. So in that sense, the bounty incentive worked. And it seems to me that the reception of the idea has been good so far, which is why I find this outcome disappointing. On a symbolic level—and I acknowledge that this may be very different from how Dennis sees or intends the decision—his withdrawal of all his funds feels to me like this work is somehow not something he's willing to reward.
I did attempt to persuade Dennis to reinterpret the no-AI rule by discussing the underlying reasons for the rule. We agreed that handwriting can be a way to test the submitter's own understanding rather than relying on AI's understanding. While we agreed that this wasn't an issue for me, we disagreed about what should follow from that. My view was that the purpose of the rule should matter more than the literal wording, whereas Dennis seemed to think that the written terms should still govern.
Ultimately, we couldn't come to an agreement on whether my use of AI was appropriate in the context of this bounty. We also disagreed about whether I should have raised my use of AI proactively. In any case, I respect Dennis's decision since ultimately these were the terms of his bounty. We also agreed that in the future, discussions like this about the terms ought to be brought up at the beginning rather than after the fact.
#5608·Benjamin Davies, 7 days agoIn #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.
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
Improve ranking of infinite variations
A simple implementation of hard-to-vary
This is my submission for Veritula's bounty for Idea #3069, which asks for an executable implementation that can compare arbitrary English explanations by how hard they are to vary.
Code: hard-to-vary/htv.py at cb2979b
I've implemented the approach as a small interactive program. It takes arbitrary explanations supplied by the user, collects working variations of each, and ranks the explanations by hardness to vary.
I think hard-to-vary can be implemented more simply than the approaches considered in Dennis's blog, Hard to Vary or Hardly Usable?. The basic idea I'm using is this: if an explanation is harder to vary, there should be fewer ways of changing it while still having it explain what it's supposed to explain.
The program starts by asking the user what question they're trying to answer and then asks for a list of proposed explanations. It goes through each explanation one at a time and asks the user to come up with variations of it that would still work as explanations. The user can enter as many as they can find, then move on to the next explanation.
Variations can either be entered individually or parameterized using notation like <X> and <Y>. For example, <X> kg of grass mixed with <Y> kg of wheat cures the disease can represent a whole family of variations. The user can either enter how many working values or combinations the parameters have, including an infinite number, or enumerate them and let the program count. This avoids requiring the user to manually enter every member of a family of variations.
The user can also review and revise their inputs before the final ranking by adding, editing, or deleting explanations and variations.
Finally, the program counts the working variations and ranks the explanations. Fewer working variations means harder to vary, while equal numbers mean equally hard to vary. So if explanation A has two working variations and explanation B has five, A is harder to vary than B.
An example
I'll use Deutsch's example from Chapter 1, “The Reach of Explanations,” of The Beginning of Infinity: Why do seasons occur?
One explanation is the story of Persephone. Hades, god of the underworld, kidnaps Persephone. Her mother Demeter eventually negotiates her release under an arrangement that requires Persephone to return to Hades once a year. Whenever Persephone is away, Demeter becomes sad and makes the world cold and bleak.
Deutsch's point is that we can change many of the details of this explanation while still accounting for the same observations. For example, I might try variations like:
- Persephone escapes instead of being released under an agreement.
- Something other than a magic seed compels her to return.
- Some other arrangement causes Persephone to return annually instead of a marriage contract.
The details have changed, but the story can still be made to explain the seasonal cycle. Suppose I find three such variations.
Now I try the explanation involving Earth's axial tilt. Here the details are much more constrained by what we're trying to explain. Changing the geometry substantially changes what the theory predicts about the seasons. Suppose I only find one working variation.
The program therefore ranks axial tilt as harder to vary: one working variation versus three. That's the entire comparison procedure.
How I understand Dennis's criticism
I don't understand Dennis as claiming that Deutsch simply gets the Persephone example wrong. The issue in the blog is how we get from examples like this, where we seem to have an intuition that one explanation is harder to vary, to a sufficiently specified procedure that could compare explanations in general.
Dennis initially explores numerical quality scores, but that immediately creates problems. Why should one explanation have a score of 500 rather than 550? Why choose that scale? How do criticisms affect the score? How do criticisms of criticisms affect it? I agree with Dennis that these choices look arbitrary.
He eventually gets rid of the quality scores entirely. Instead of trying to measure the quality of an idea, his program keeps track of pending criticisms. His proposed rule becomes: adopt ideas without pending criticisms and reject ideas that have them.
There's something important about how that system works, though. The program doesn't generate criticisms itself; people do. And that's intentional: Dennis says "I’m not looking to formalize or automate creativity as a whole". Creative input can come from users while the program handles the non-creative part of the process. I agree that you can have a rational decision-making process while outsourcing the creative part to the user.
I just don't see why we can't do the same thing with HTV. Let the user come up with variations and say which ones they think still work. The program doesn't need to understand the explanation or come up with the variations itself. It keeps track of the variations and compares the counts.
This doesn't seem fundamentally different from Dennis letting the user tell his program that something is a criticism. In fact, in the blog he explicitly avoids having the program figure out whether a comment is really a criticism: the user checks a box saying that it is. So in my program the user is supplying a working variation; in his, the user is supplying a criticism. In both cases the user is providing the part that requires understanding and judgment, and the program does something simple with that input.
It also means I don't need the quality scores Dennis runs into trouble with. I don't need to decide how many points axial tilt gets compared with Persephone. I'm just asking: how many ways have we actually found to change each explanation while still having it work?
But isn't this subjective?
One criticism Dennis quotes is:
“Also, isn’t the difficulty of changing an explanation at least partly a property not of the explanation itself but of whoever is trying to change it? If I’m having difficulty changing it, maybe that’s because I lack imagination. Or maybe I’m just new to that field and an expert could easily change it.”
I think this is true. I just don't think it's a problem specific to HTV.
Imagine I can't think of any working variations of an explanation, but an expert can immediately think of five. Then yes, our results will be different. But isn't that also what happens with criticism? I might look at an idea and fail to see anything wrong with it while someone who knows much more about the subject immediately sees a serious criticism.
The same goes for participation. An idea on Veritula might have zero pending criticisms simply because hardly anyone has tried to criticize it. That doesn't mean there are literally no criticisms of it. Someone could find one tomorrow. Dennis's answer in the blog is basically that if this bothers you, try to find a criticism yourself. If you can't find one, why not adopt the idea?
I think HTV can work the same way. Zero working variations doesn't mean that we've somehow proven there are no possible variations. It means we haven't found one. If you think the explanation is actually easy to vary, try to come up with a variation that still works.
So yes, the result depends on the knowledge and creativity of the person using the program. But I think rational decision-making is always going to depend on what criticisms, arguments, alternatives, etc. a person is actually aware of. I don't see how Veritula escapes that either.
What about human judgment?
There's another obvious question: who decides whether a variation actually works?
For this program, the user does. I don't think we can get rid of that kind of human judgment, at least until we get AGI. Two people can disagree about whether a variation still explains the thing we're trying to explain. They can also disagree about whether two variations are really different or are basically the same variation stated twice.
Again, I think Veritula has the same underlying issue. People still have to decide whether something really is a criticism, whether a countercriticism actually answers it, whether two criticisms are redundant, and so on. Dennis's program can keep track of the structure, but the structure only means something if those judgments make sense.
Take an extreme case. If a malicious moderator rejects every good criticism of an idea and accepts nonsense countercriticisms, the idea could end up showing 0 pending criticisms. I obviously shouldn't look at the 0 and conclude that the idea is rational to adopt. I'd want to read what happened and decide whether I agree with it.
I don't mean this as a criticism specific to Veritula. I think it's just a limit of this kind of approach. At some point people have to make judgments, and people can disagree about them. Ultimately everyone is their own moderator when it comes to their own decision-making. I have to decide which arguments I accept, which criticisms I think have been answered, and so on.
The same is true with my HTV program. If someone gives me a ranking based on ten supposed working variations, I don't have to accept the ranking blindly. I can look at the ten variations and decide that five don't really work and three others are basically duplicates. My result would then be different.
I'm fine with that. I don't think the goal of either program should be to somehow remove judgment from rational thinking. The program gives us a procedure for what to do with the judgments we've made.
What does the program actually contribute?
Dennis writes:
“We can’t just outsource everything to the user – the app has to do some things or it has no value.”
This was actually the part of the blog that made me think about Veritula itself. What is Veritula doing, and what is it outsourcing?
It outsources the interesting creative part to people. People come up with the ideas. People come up with the criticisms. The user can even tell the program whether something they've written is a criticism by checking a box. The program then keeps track of the structure and tells us how many criticisms are pending.
My program is doing something similar, except with variations. People come up with the explanations and the working variations. The program keeps track of them, counts them, and ranks the explanations.
So I don't think I'm outsourcing everything to the user any more than Veritula is. I'm outsourcing the part that requires creativity and judgment. The actual decision rule is implemented in the program.
For Veritula, that rule ultimately depends on whether there are pending criticisms. For my program, it depends on the number of working variations: fewer working variations means harder to vary.
Where I disagree with the blog
I agree with Dennis that the quality sliders in the blog don't work. I also agree with his decision to let users supply the creative input rather than expecting the program to generate it.
Where I disagree is that I think once we allow this same freedom for HTV, we can construct a similarly simple program for it. The user comes up with explanations and tries to vary them while keeping them working. The program counts the working variations and ranks the explanations.
There are still all the normal problems of human knowledge: maybe I missed a variation, maybe I accepted a bad one, maybe someone else would judge things differently. But those same problems exist when we come up with and judge criticisms.
I don't think either program solves those problems, and I don't think it needs to. That's the part people do.
A simple implementation of hard-to-vary
This is my submission for Veritula's bounty for Idea #3069, which asks for an executable implementation that can compare arbitrary English explanations by how hard they are to vary.
Code: hard-to-vary/htv.py at 9da0ddd
I've implemented the approach as a small interactive program. It takes arbitrary explanations supplied by the user, collects working variations of each, and ranks the explanations by hardness to vary.
I think hard-to-vary can be implemented more simply than the approaches considered in Dennis's blog, Hard to Vary or Hardly Usable?. The basic idea I'm using is this: if an explanation is harder to vary, there should be fewer ways of changing it while still having it explain what it's supposed to explain.
The program starts by asking the user what question they're trying to answer and then asks for a list of proposed explanations. It goes through each explanation one at a time and asks the user to come up with variations of it that would still work as explanations. The user can enter as many as they can find, then move on to the next explanation.
Variations can either be entered individually or parameterized using notation like <X> and <Y>. For example, <X> kg of grass mixed with <Y> kg of wheat cures the disease can represent a whole family of variations. The user can either enter how many working values or combinations the parameters have, including an infinite number, or enumerate them and let the program count. This avoids requiring the user to manually enter every member of a family of variations.
The user can also review and revise their inputs before the final ranking by adding, editing, or deleting explanations and variations.
Finally, the program counts the working variations and ranks the explanations. Fewer working variations means harder to vary, while equal numbers mean equally hard to vary. So if explanation A has two working variations and explanation B has five, A is harder to vary than B.
Infinite variations need a little more information. If two explanations both have infinitely many working variations, the program first compares how many independently variable parameters have infinitely many possible values. Fewer infinitely-variable parameters means harder to vary. If that's also equal, it compares the remaining finite parts of the variations. This lets the program distinguish, for example, between an explanation with one unconstrained infinite parameter and another with two.
An example
I'll use Deutsch's example from Chapter 1, “The Reach of Explanations,” of The Beginning of Infinity: Why do seasons occur?
One explanation is the story of Persephone. Hades, god of the underworld, kidnaps Persephone. Her mother Demeter eventually negotiates her release under an arrangement that requires Persephone to return to Hades once a year. Whenever Persephone is away, Demeter becomes sad and makes the world cold and bleak.
Deutsch's point is that we can change many of the details of this explanation while still accounting for the same observations. For example, I might try variations like:
- Persephone escapes instead of being released under an agreement.
- Something other than a magic seed compels her to return.
- Some other arrangement causes Persephone to return annually instead of a marriage contract.
The details have changed, but the story can still be made to explain the seasonal cycle. Suppose I find three such variations.
Now I try the explanation involving Earth's axial tilt. Here the details are much more constrained by what we're trying to explain. Changing the geometry substantially changes what the theory predicts about the seasons. Suppose I only find one working variation.
The program therefore ranks axial tilt as harder to vary: one working variation versus three. That's the entire comparison procedure.
How I understand Dennis's criticism
I don't understand Dennis as claiming that Deutsch simply gets the Persephone example wrong. The issue in the blog is how we get from examples like this, where we seem to have an intuition that one explanation is harder to vary, to a sufficiently specified procedure that could compare explanations in general.
Dennis initially explores numerical quality scores, but that immediately creates problems. Why should one explanation have a score of 500 rather than 550? Why choose that scale? How do criticisms affect the score? How do criticisms of criticisms affect it? I agree with Dennis that these choices look arbitrary.
He eventually gets rid of the quality scores entirely. Instead of trying to measure the quality of an idea, his program keeps track of pending criticisms. His proposed rule becomes: adopt ideas without pending criticisms and reject ideas that have them.
There's something important about how that system works, though. The program doesn't generate criticisms itself; people do. And that's intentional: Dennis says "I’m not looking to formalize or automate creativity as a whole". Creative input can come from users while the program handles the non-creative part of the process. I agree that you can have a rational decision-making process while outsourcing the creative part to the user.
I just don't see why we can't do the same thing with HTV. Let the user come up with variations and say which ones they think still work. The program doesn't need to understand the explanation or come up with the variations itself. It keeps track of the variations and compares the counts.
This doesn't seem fundamentally different from Dennis letting the user tell his program that something is a criticism. In fact, in the blog he explicitly avoids having the program figure out whether a comment is really a criticism: the user checks a box saying that it is. So in my program the user is supplying a working variation; in his, the user is supplying a criticism. In both cases the user is providing the part that requires understanding and judgment, and the program does something simple with that input.
It also means I don't need the quality scores Dennis runs into trouble with. I don't need to decide how many points axial tilt gets compared with Persephone. I'm just asking: how many ways have we actually found to change each explanation while still having it work?
But isn't this subjective?
One criticism Dennis quotes is:
“Also, isn’t the difficulty of changing an explanation at least partly a property not of the explanation itself but of whoever is trying to change it? If I’m having difficulty changing it, maybe that’s because I lack imagination. Or maybe I’m just new to that field and an expert could easily change it.”
I think this is true. I just don't think it's a problem specific to HTV.
Imagine I can't think of any working variations of an explanation, but an expert can immediately think of five. Then yes, our results will be different. But isn't that also what happens with criticism? I might look at an idea and fail to see anything wrong with it while someone who knows much more about the subject immediately sees a serious criticism.
The same goes for participation. An idea on Veritula might have zero pending criticisms simply because hardly anyone has tried to criticize it. That doesn't mean there are literally no criticisms of it. Someone could find one tomorrow. Dennis's answer in the blog is basically that if this bothers you, try to find a criticism yourself. If you can't find one, why not adopt the idea?
I think HTV can work the same way. Zero working variations doesn't mean that we've somehow proven there are no possible variations. It means we haven't found one. If you think the explanation is actually easy to vary, try to come up with a variation that still works.
So yes, the result depends on the knowledge and creativity of the person using the program. But I think rational decision-making is always going to depend on what criticisms, arguments, alternatives, etc. a person is actually aware of. I don't see how Veritula escapes that either.
What about human judgment?
There's another obvious question: who decides whether a variation actually works?
For this program, the user does. I don't think we can get rid of that kind of human judgment, at least until we get AGI. Two people can disagree about whether a variation still explains the thing we're trying to explain. They can also disagree about whether two variations are really different or are basically the same variation stated twice.
Again, I think Veritula has the same underlying issue. People still have to decide whether something really is a criticism, whether a countercriticism actually answers it, whether two criticisms are redundant, and so on. Dennis's program can keep track of the structure, but the structure only means something if those judgments make sense.
Take an extreme case. If a malicious moderator rejects every good criticism of an idea and accepts nonsense countercriticisms, the idea could end up showing 0 pending criticisms. I obviously shouldn't look at the 0 and conclude that the idea is rational to adopt. I'd want to read what happened and decide whether I agree with it.
I don't mean this as a criticism specific to Veritula. I think it's just a limit of this kind of approach. At some point people have to make judgments, and people can disagree about them. Ultimately everyone is their own moderator when it comes to their own decision-making. I have to decide which arguments I accept, which criticisms I think have been answered, and so on.
The same is true with my HTV program. If someone gives me a ranking based on ten supposed working variations, I don't have to accept the ranking blindly. I can look at the ten variations and decide that five don't really work and three others are basically duplicates. My result would then be different.
I'm fine with that. I don't think the goal of either program should be to somehow remove judgment from rational thinking. The program gives us a procedure for what to do with the judgments we've made.
What does the program actually contribute?
Dennis writes:
“We can’t just outsource everything to the user – the app has to do some things or it has no value.”
This was actually the part of the blog that made me think about Veritula itself. What is Veritula doing, and what is it outsourcing?
It outsources the interesting creative part to people. People come up with the ideas. People come up with the criticisms. The user can even tell the program whether something they've written is a criticism by checking a box. The program then keeps track of the structure and tells us how many criticisms are pending.
My program is doing something similar, except with variations. People come up with the explanations and the working variations. The program keeps track of them, counts them, and ranks the explanations.
So I don't think I'm outsourcing everything to the user any more than Veritula is. I'm outsourcing the part that requires creativity and judgment. The actual decision rule is implemented in the program.
For Veritula, that rule ultimately depends on whether there are pending criticisms. For my program, it depends on the number of working variations: fewer working variations means harder to vary.
Where I disagree with the blog
I agree with Dennis that the quality sliders in the blog don't work. I also agree with his decision to let users supply the creative input rather than expecting the program to generate it.
Where I disagree is that I think once we allow this same freedom for HTV, we can construct a similarly simple program for it. The user comes up with explanations and tries to vary them while keeping them working. The program counts the working variations and ranks the explanations.
There are still all the normal problems of human knowledge: maybe I missed a variation, maybe I accepted a bad one, maybe someone else would judge things differently. But those same problems exist when we come up with and judge criticisms.
I don't think either program solves those problems, and I don't think it needs to. That's the part people do.
#5606·Dennis HackethalOP, 8 days agoUnfortunately, 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.
Just to confirm, and so you can hear it from me, yes I did use AI to help with my submission.
For posterity, here was my position during the discussion:
I think it's technically fair for Dennis to consider the submission ineligible because the bounty terms clearly say "Submissions must be handwritten. No AI-generated text or code; suspected AI use makes submissions ineligible."
On the other hand, I think this outcome is a shame because I don't think my use of AI changes any of the real work and thought that was put into it. If you zoom out, the motive of the bounty is to attract people to work on ideas and develop them, which is exactly what I did here, regardless of the tools used. As How Do Bounties Work? puts it, "Bounties let you invite criticism and reward high-quality contributions with real money."
And this is exactly what happened here. The idea had been posted on Veritula for about 10 months, and when I saw the bounty, I took it as a fun challenge to work on. So in that sense, the bounty incentive worked. And it seems to me that the reception of the idea has been good so far, which is why I find this outcome disappointing. On a symbolic level—and I acknowledge that this may be very different from how Dennis sees or intends the decision—his withdrawal of all his funds feels to me like this work is somehow not something he's willing to reward.
I did attempt to persuade Dennis to reinterpret the no-AI rule by discussing the underlying reasons for the rule. We agreed that handwriting can be a way to test the submitter's own understanding rather than relying on AI's understanding. While we agreed that this wasn't an issue for me, we disagreed about what should follow from that. My view was that the purpose of the rule should matter more than the literal wording, whereas Dennis seemed to think that the written terms should still govern.
Ultimately, we couldn't come to an agreement on whether my use of AI was appropriate in the context of this bounty. We also disagreed about whether I should have raised my use of AI proactively. In any case, I respect Dennis's decision since ultimately these were the terms of his bounty. We also agreed that in the future, discussions like this about the terms ought to be brought up at the beginning rather than after the fact.
Updated the code to allow parameterized variations, revisability, and improved readability.
A simple implementation of hard-to-vary
This is my submission for Veritula's bounty for Idea #3069, which asks for an executable implementation that can compare arbitrary English explanations by how hard they are to vary.
Code: hard-to-vary
I've implemented the approach as a small interactive program. It takes arbitrary explanations supplied by the user, collects working variations of each, and ranks the explanations by hardness to vary.
I think hard-to-vary can be implemented more simply than the approaches considered in Dennis's blog, Hard to Vary or Hardly Usable?. The basic idea I'm using is this: if an explanation is harder to vary, there should be fewer ways of changing it while still having it explain what it's supposed to explain.
The program starts by asking the user what question they're trying to answer and then asks for a list of proposed explanations. It goes through each explanation one at a time and asks the user to come up with variations of it that would still work as explanations. The user can enter as many as they can find, then move on to the next explanation.
Finally, the program counts the working variations and ranks the explanations. Fewer working variations means harder to vary, while equal numbers mean equally hard to vary. So if explanation A has two working variations and explanation B has five, A is harder to vary than B.
An example
I'll use Deutsch's example from Chapter 1, “The Reach of Explanations,” of The Beginning of Infinity: Why do seasons occur?
One explanation is the story of Persephone. Hades, god of the underworld, kidnaps Persephone. Her mother Demeter eventually negotiates her release under an arrangement that requires Persephone to return to Hades once a year. Whenever Persephone is away, Demeter becomes sad and makes the world cold and bleak.
Deutsch's point is that we can change many of the details of this explanation while still accounting for the same observations. For example, I might try variations like:
- Persephone escapes instead of being released under an agreement.
- Something other than a magic seed compels her to return.
- Some other arrangement causes Persephone to return annually instead of a marriage contract.
The details have changed, but the story can still be made to explain the seasonal cycle. Suppose I find three such variations.
Now I try the explanation involving Earth's axial tilt. Here the details are much more constrained by what we're trying to explain. Changing the geometry substantially changes what the theory predicts about the seasons. Suppose I only find one working variation.
The program therefore ranks axial tilt as harder to vary: one working variation versus three. That's the entire comparison procedure.
How I understand Dennis's criticism
I don't understand Dennis as claiming that Deutsch simply gets the Persephone example wrong. The issue in the blog is how we get from examples like this, where we seem to have an intuition that one explanation is harder to vary, to a sufficiently specified procedure that could compare explanations in general.
Dennis initially explores numerical quality scores, but that immediately creates problems. Why should one explanation have a score of 500 rather than 550? Why choose that scale? How do criticisms affect the score? How do criticisms of criticisms affect it? I agree with Dennis that these choices look arbitrary.
He eventually gets rid of the quality scores entirely. Instead of trying to measure the quality of an idea, his program keeps track of pending criticisms. His proposed rule becomes: adopt ideas without pending criticisms and reject ideas that have them.
There's something important about how that system works, though. The program doesn't generate criticisms itself; people do. And that's intentional: Dennis says "I’m not looking to formalize or automate creativity as a whole". Creative input can come from users while the program handles the non-creative part of the process. I agree that you can have a rational decision-making process while outsourcing the creative part to the user.
I just don't see why we can't do the same thing with HTV. Let the user come up with variations and say which ones they think still work. The program doesn't need to understand the explanation or come up with the variations itself. It keeps track of the variations and compares the counts.
This doesn't seem fundamentally different from Dennis letting the user tell his program that something is a criticism. In fact, in the blog he explicitly avoids having the program figure out whether a comment is really a criticism: the user checks a box saying that it is. So in my program the user is supplying a working variation; in his, the user is supplying a criticism. In both cases the user is providing the part that requires understanding and judgment, and the program does something simple with that input.
It also means I don't need the quality scores Dennis runs into trouble with. I don't need to decide how many points axial tilt gets compared with Persephone. I'm just asking: how many ways have we actually found to change each explanation while still having it work?
But isn't this subjective?
One criticism Dennis quotes is:
“Also, isn’t the difficulty of changing an explanation at least partly a property not of the explanation itself but of whoever is trying to change it? If I’m having difficulty changing it, maybe that’s because I lack imagination. Or maybe I’m just new to that field and an expert could easily change it.”
I think this is true. I just don't think it's a problem specific to HTV.
Imagine I can't think of any working variations of an explanation, but an expert can immediately think of five. Then yes, our results will be different. But isn't that also what happens with criticism? I might look at an idea and fail to see anything wrong with it while someone who knows much more about the subject immediately sees a serious criticism.
The same goes for participation. An idea on Veritula might have zero pending criticisms simply because hardly anyone has tried to criticize it. That doesn't mean there are literally no criticisms of it. Someone could find one tomorrow. Dennis's answer in the blog is basically that if this bothers you, try to find a criticism yourself. If you can't find one, why not adopt the idea?
I think HTV can work the same way. Zero working variations doesn't mean that we've somehow proven there are no possible variations. It means we haven't found one. If you think the explanation is actually easy to vary, try to come up with a variation that still works.
So yes, the result depends on the knowledge and creativity of the person using the program. But I think rational decision-making is always going to depend on what criticisms, arguments, alternatives, etc. a person is actually aware of. I don't see how Veritula escapes that either.
What about human judgment?
There's another obvious question: who decides whether a variation actually works?
For this program, the user does. I don't think we can get rid of that kind of human judgment, at least until we get AGI. Two people can disagree about whether a variation still explains the thing we're trying to explain. They can also disagree about whether two variations are really different or are basically the same variation stated twice.
Again, I think Veritula has the same underlying issue. People still have to decide whether something really is a criticism, whether a countercriticism actually answers it, whether two criticisms are redundant, and so on. Dennis's program can keep track of the structure, but the structure only means something if those judgments make sense.
Take an extreme case. If a malicious moderator rejects every good criticism of an idea and accepts nonsense countercriticisms, the idea could end up showing 0 pending criticisms. I obviously shouldn't look at the 0 and conclude that the idea is rational to adopt. I'd want to read what happened and decide whether I agree with it.
I don't mean this as a criticism specific to Veritula. I think it's just a limit of this kind of approach. At some point people have to make judgments, and people can disagree about them. Ultimately everyone is their own moderator when it comes to their own decision-making. I have to decide which arguments I accept, which criticisms I think have been answered, and so on.
The same is true with my HTV program. If someone gives me a ranking based on ten supposed working variations, I don't have to accept the ranking blindly. I can look at the ten variations and decide that five don't really work and three others are basically duplicates. My result would then be different.
I'm fine with that. I don't think the goal of either program should be to somehow remove judgment from rational thinking. The program gives us a procedure for what to do with the judgments we've made.
What does the program actually contribute?
Dennis writes:
“We can’t just outsource everything to the user – the app has to do some things or it has no value.”
This was actually the part of the blog that made me think about Veritula itself. What is Veritula doing, and what is it outsourcing?
It outsources the interesting creative part to people. People come up with the ideas. People come up with the criticisms. The user can even tell the program whether something they've written is a criticism by checking a box. The program then keeps track of the structure and tells us how many criticisms are pending.
My program is doing something similar, except with variations. People come up with the explanations and the working variations. The program keeps track of them, counts them, and ranks the explanations.
So I don't think I'm outsourcing everything to the user any more than Veritula is. I'm outsourcing the part that requires creativity and judgment. The actual decision rule is implemented in the program.
For Veritula, that rule ultimately depends on whether there are pending criticisms. For my program, it depends on the number of working variations: fewer working variations means harder to vary.
Where I disagree with the blog
I agree with Dennis that the quality sliders in the blog don't work. I also agree with his decision to let users supply the creative input rather than expecting the program to generate it.
Where I disagree is that I think once we allow this same freedom for HTV, we can construct a similarly simple program for it. The user comes up with explanations and tries to vary them while keeping them working. The program counts the working variations and ranks the explanations.
There are still all the normal problems of human knowledge: maybe I missed a variation, maybe I accepted a bad one, maybe someone else would judge things differently. But those same problems exist when we come up with and judge criticisms.
I don't think either program solves those problems, and I don't think it needs to. That's the part people do.
A simple implementation of hard-to-vary
This is my submission for Veritula's bounty for Idea #3069, which asks for an executable implementation that can compare arbitrary English explanations by how hard they are to vary.
Code: hard-to-vary/htv.py at cb2979b
I've implemented the approach as a small interactive program. It takes arbitrary explanations supplied by the user, collects working variations of each, and ranks the explanations by hardness to vary.
I think hard-to-vary can be implemented more simply than the approaches considered in Dennis's blog, Hard to Vary or Hardly Usable?. The basic idea I'm using is this: if an explanation is harder to vary, there should be fewer ways of changing it while still having it explain what it's supposed to explain.
The program starts by asking the user what question they're trying to answer and then asks for a list of proposed explanations. It goes through each explanation one at a time and asks the user to come up with variations of it that would still work as explanations. The user can enter as many as they can find, then move on to the next explanation.
Variations can either be entered individually or parameterized using notation like <X> and <Y>. For example, <X> kg of grass mixed with <Y> kg of wheat cures the disease can represent a whole family of variations. The user can either enter how many working values or combinations the parameters have, including an infinite number, or enumerate them and let the program count. This avoids requiring the user to manually enter every member of a family of variations.
The user can also review and revise their inputs before the final ranking by adding, editing, or deleting explanations and variations.
Finally, the program counts the working variations and ranks the explanations. Fewer working variations means harder to vary, while equal numbers mean equally hard to vary. So if explanation A has two working variations and explanation B has five, A is harder to vary than B.
An example
I'll use Deutsch's example from Chapter 1, “The Reach of Explanations,” of The Beginning of Infinity: Why do seasons occur?
One explanation is the story of Persephone. Hades, god of the underworld, kidnaps Persephone. Her mother Demeter eventually negotiates her release under an arrangement that requires Persephone to return to Hades once a year. Whenever Persephone is away, Demeter becomes sad and makes the world cold and bleak.
Deutsch's point is that we can change many of the details of this explanation while still accounting for the same observations. For example, I might try variations like:
- Persephone escapes instead of being released under an agreement.
- Something other than a magic seed compels her to return.
- Some other arrangement causes Persephone to return annually instead of a marriage contract.
The details have changed, but the story can still be made to explain the seasonal cycle. Suppose I find three such variations.
Now I try the explanation involving Earth's axial tilt. Here the details are much more constrained by what we're trying to explain. Changing the geometry substantially changes what the theory predicts about the seasons. Suppose I only find one working variation.
The program therefore ranks axial tilt as harder to vary: one working variation versus three. That's the entire comparison procedure.
How I understand Dennis's criticism
I don't understand Dennis as claiming that Deutsch simply gets the Persephone example wrong. The issue in the blog is how we get from examples like this, where we seem to have an intuition that one explanation is harder to vary, to a sufficiently specified procedure that could compare explanations in general.
Dennis initially explores numerical quality scores, but that immediately creates problems. Why should one explanation have a score of 500 rather than 550? Why choose that scale? How do criticisms affect the score? How do criticisms of criticisms affect it? I agree with Dennis that these choices look arbitrary.
He eventually gets rid of the quality scores entirely. Instead of trying to measure the quality of an idea, his program keeps track of pending criticisms. His proposed rule becomes: adopt ideas without pending criticisms and reject ideas that have them.
There's something important about how that system works, though. The program doesn't generate criticisms itself; people do. And that's intentional: Dennis says "I’m not looking to formalize or automate creativity as a whole". Creative input can come from users while the program handles the non-creative part of the process. I agree that you can have a rational decision-making process while outsourcing the creative part to the user.
I just don't see why we can't do the same thing with HTV. Let the user come up with variations and say which ones they think still work. The program doesn't need to understand the explanation or come up with the variations itself. It keeps track of the variations and compares the counts.
This doesn't seem fundamentally different from Dennis letting the user tell his program that something is a criticism. In fact, in the blog he explicitly avoids having the program figure out whether a comment is really a criticism: the user checks a box saying that it is. So in my program the user is supplying a working variation; in his, the user is supplying a criticism. In both cases the user is providing the part that requires understanding and judgment, and the program does something simple with that input.
It also means I don't need the quality scores Dennis runs into trouble with. I don't need to decide how many points axial tilt gets compared with Persephone. I'm just asking: how many ways have we actually found to change each explanation while still having it work?
But isn't this subjective?
One criticism Dennis quotes is:
“Also, isn’t the difficulty of changing an explanation at least partly a property not of the explanation itself but of whoever is trying to change it? If I’m having difficulty changing it, maybe that’s because I lack imagination. Or maybe I’m just new to that field and an expert could easily change it.”
I think this is true. I just don't think it's a problem specific to HTV.
Imagine I can't think of any working variations of an explanation, but an expert can immediately think of five. Then yes, our results will be different. But isn't that also what happens with criticism? I might look at an idea and fail to see anything wrong with it while someone who knows much more about the subject immediately sees a serious criticism.
The same goes for participation. An idea on Veritula might have zero pending criticisms simply because hardly anyone has tried to criticize it. That doesn't mean there are literally no criticisms of it. Someone could find one tomorrow. Dennis's answer in the blog is basically that if this bothers you, try to find a criticism yourself. If you can't find one, why not adopt the idea?
I think HTV can work the same way. Zero working variations doesn't mean that we've somehow proven there are no possible variations. It means we haven't found one. If you think the explanation is actually easy to vary, try to come up with a variation that still works.
So yes, the result depends on the knowledge and creativity of the person using the program. But I think rational decision-making is always going to depend on what criticisms, arguments, alternatives, etc. a person is actually aware of. I don't see how Veritula escapes that either.
What about human judgment?
There's another obvious question: who decides whether a variation actually works?
For this program, the user does. I don't think we can get rid of that kind of human judgment, at least until we get AGI. Two people can disagree about whether a variation still explains the thing we're trying to explain. They can also disagree about whether two variations are really different or are basically the same variation stated twice.
Again, I think Veritula has the same underlying issue. People still have to decide whether something really is a criticism, whether a countercriticism actually answers it, whether two criticisms are redundant, and so on. Dennis's program can keep track of the structure, but the structure only means something if those judgments make sense.
Take an extreme case. If a malicious moderator rejects every good criticism of an idea and accepts nonsense countercriticisms, the idea could end up showing 0 pending criticisms. I obviously shouldn't look at the 0 and conclude that the idea is rational to adopt. I'd want to read what happened and decide whether I agree with it.
I don't mean this as a criticism specific to Veritula. I think it's just a limit of this kind of approach. At some point people have to make judgments, and people can disagree about them. Ultimately everyone is their own moderator when it comes to their own decision-making. I have to decide which arguments I accept, which criticisms I think have been answered, and so on.
The same is true with my HTV program. If someone gives me a ranking based on ten supposed working variations, I don't have to accept the ranking blindly. I can look at the ten variations and decide that five don't really work and three others are basically duplicates. My result would then be different.
I'm fine with that. I don't think the goal of either program should be to somehow remove judgment from rational thinking. The program gives us a procedure for what to do with the judgments we've made.
What does the program actually contribute?
Dennis writes:
“We can’t just outsource everything to the user – the app has to do some things or it has no value.”
This was actually the part of the blog that made me think about Veritula itself. What is Veritula doing, and what is it outsourcing?
It outsources the interesting creative part to people. People come up with the ideas. People come up with the criticisms. The user can even tell the program whether something they've written is a criticism by checking a box. The program then keeps track of the structure and tells us how many criticisms are pending.
My program is doing something similar, except with variations. People come up with the explanations and the working variations. The program keeps track of them, counts them, and ranks the explanations.
So I don't think I'm outsourcing everything to the user any more than Veritula is. I'm outsourcing the part that requires creativity and judgment. The actual decision rule is implemented in the program.
For Veritula, that rule ultimately depends on whether there are pending criticisms. For my program, it depends on the number of working variations: fewer working variations means harder to vary.
Where I disagree with the blog
I agree with Dennis that the quality sliders in the blog don't work. I also agree with his decision to let users supply the creative input rather than expecting the program to generate it.
Where I disagree is that I think once we allow this same freedom for HTV, we can construct a similarly simple program for it. The user comes up with explanations and tries to vary them while keeping them working. The program counts the working variations and ranks the explanations.
There are still all the normal problems of human knowledge: maybe I missed a variation, maybe I accepted a bad one, maybe someone else would judge things differently. But those same problems exist when we come up with and judge criticisms.
I don't think either program solves those problems, and I don't think it needs to. That's the part people do.
#5523·Jad Elmourad, 11 days agoA simple implementation of hard-to-vary
This is my submission for Veritula's bounty for Idea #3069, which asks for an executable implementation that can compare arbitrary English explanations by how hard they are to vary.
Code: hard-to-vary
I've implemented the approach as a small interactive program. It takes arbitrary explanations supplied by the user, collects working variations of each, and ranks the explanations by hardness to vary.
I think hard-to-vary can be implemented more simply than the approaches considered in Dennis's blog, Hard to Vary or Hardly Usable?. The basic idea I'm using is this: if an explanation is harder to vary, there should be fewer ways of changing it while still having it explain what it's supposed to explain.
The program starts by asking the user what question they're trying to answer and then asks for a list of proposed explanations. It goes through each explanation one at a time and asks the user to come up with variations of it that would still work as explanations. The user can enter as many as they can find, then move on to the next explanation.
Finally, the program counts the working variations and ranks the explanations. Fewer working variations means harder to vary, while equal numbers mean equally hard to vary. So if explanation A has two working variations and explanation B has five, A is harder to vary than B.
An example
Take the question: Why do seasons occur?
One explanation is the story of Persephone. She spends part of the year in Hades, Demeter grieves while she's gone, and this accounts for the seasonal cycle.
I might try changing the explanation in a few ways:
- Persephone spends five months in Hades instead of six.
- It's Demeter's son who is taken rather than her daughter.
- Zeus orders Persephone to return periodically rather than her return depending on the details involving the pomegranate.
The details have changed, but the basic explanatory story can still do the same job. Suppose I find three such variations.
Now I try the explanation involving Earth's axial tilt. I might be able to change the stated tilt from 23.4 degrees to 23.5 degrees without substantially affecting the explanation. But if I start making large changes to the geometry while trying to explain the same observations, the explanation stops working. Suppose I find one working variation.
The program therefore ranks axial tilt as harder to vary: one working variation versus three. That's the entire comparison procedure.
How I understand Dennis's criticism
I don't understand Dennis as claiming that Deutsch simply gets the Persephone example wrong. The issue in the blog is how we get from examples like this, where we seem to have an intuition that one explanation is harder to vary, to a sufficiently specified procedure that could compare explanations in general.
Dennis initially explores numerical quality scores, but that immediately creates problems. Why should one explanation have a score of 500 rather than 550? Why choose that scale? How do criticisms affect the score? How do criticisms of criticisms affect it? I agree with Dennis that these choices look arbitrary.
He eventually gets rid of the quality scores entirely. Instead of trying to measure the quality of an idea, his program keeps track of pending criticisms. His proposed rule becomes: adopt ideas without pending criticisms and reject ideas that have them.
There's something important about how that system works, though. The program doesn't generate criticisms itself; people do. And that's intentional: Dennis says "I’m not looking to formalize or automate creativity as a whole". Creative input can come from users while the program handles the non-creative part of the process. I agree that you can have a rational decision-making process while outsourcing the creative part to the user.
I just don't see why we can't do the same thing with HTV. Let the user come up with variations and say which ones they think still work. The program doesn't need to understand the explanation or come up with the variations itself. It keeps track of the variations and compares the counts.
This doesn't seem fundamentally different from Dennis letting the user tell his program that something is a criticism. In fact, in the blog he explicitly avoids having the program figure out whether a comment is really a criticism: the user checks a box saying that it is. So in my program the user is supplying a working variation; in his, the user is supplying a criticism. In both cases the user is providing the part that requires understanding and judgment, and the program does something simple with that input.
It also means I don't need the quality scores Dennis runs into trouble with. I don't need to decide how many points axial tilt gets compared with Persephone. I'm just asking: how many ways have we actually found to change each explanation while still having it work?
But isn't this subjective?
One criticism Dennis quotes is:
“Also, isn’t the difficulty of changing an explanation at least partly a property not of the explanation itself but of whoever is trying to change it? If I’m having difficulty changing it, maybe that’s because I lack imagination. Or maybe I’m just new to that field and an expert could easily change it.”
I think this is true. I just don't think it's a problem specific to HTV.
Imagine I can't think of any working variations of an explanation, but an expert can immediately think of five. Then yes, our results will be different. But isn't that also what happens with criticism? I might look at an idea and fail to see anything wrong with it while someone who knows much more about the subject immediately sees a serious criticism.
The same goes for participation. An idea on Veritula might have zero pending criticisms simply because hardly anyone has tried to criticize it. That doesn't mean there are literally no criticisms of it. Someone could find one tomorrow. Dennis's answer in the blog is basically that if this bothers you, try to find a criticism yourself. If you can't find one, why not adopt the idea?
I think HTV can work the same way. Zero working variations doesn't mean that we've somehow proven there are no possible variations. It means we haven't found one. If you think the explanation is actually easy to vary, try to come up with a variation that still works.
So yes, the result depends on the knowledge and creativity of the person using the program. But I think rational decision-making is always going to depend on what criticisms, arguments, alternatives, etc. a person is actually aware of. I don't see how Veritula escapes that either.
What about human judgment?
There's another obvious question: who decides whether a variation actually works?
For this program, the user does. I don't think we can get rid of that kind of human judgment, at least until we get AGI. Two people can disagree about whether a variation still explains the thing we're trying to explain. They can also disagree about whether two variations are really different or are basically the same variation stated twice.
Again, I think Veritula has the same underlying issue. People still have to decide whether something really is a criticism, whether a countercriticism actually answers it, whether two criticisms are redundant, and so on. Dennis's program can keep track of the structure, but the structure only means something if those judgments make sense.
Take an extreme case. If a malicious moderator rejects every good criticism of an idea and accepts nonsense countercriticisms, the idea could end up showing
0 pending criticisms. I obviously shouldn't look at the0and conclude that the idea is rational to adopt. I'd want to read what happened and decide whether I agree with it.I don't mean this as a criticism specific to Veritula. I think it's just a limit of this kind of approach. At some point people have to make judgments, and people can disagree about them. Ultimately everyone is their own moderator when it comes to their own decision-making. I have to decide which arguments I accept, which criticisms I think have been answered, and so on.
The same is true with my HTV program. If someone gives me a ranking based on ten supposed working variations, I don't have to accept the ranking blindly. I can look at the ten variations and decide that five don't really work and three others are basically duplicates. My result would then be different.
I'm fine with that. I don't think the goal of either program should be to somehow remove judgment from rational thinking. The program gives us a procedure for what to do with the judgments we've made.
What does the program actually contribute?
Dennis writes:
“We can’t just outsource everything to the user – the app has to do some things or it has no value.”
This was actually the part of the blog that made me think about Veritula itself. What is Veritula doing, and what is it outsourcing?
It outsources the interesting creative part to people. People come up with the ideas. People come up with the criticisms. The user can even tell the program whether something they've written is a criticism by checking a box. The program then keeps track of the structure and tells us how many criticisms are pending.
My program is doing something similar, except with variations. People come up with the explanations and the working variations. The program keeps track of them, counts them, and ranks the explanations.
So I don't think I'm outsourcing everything to the user any more than Veritula is. I'm outsourcing the part that requires creativity and judgment. The actual decision rule is implemented in the program.
For Veritula, that rule ultimately depends on whether there are pending criticisms. For my program, it depends on the number of working variations: fewer working variations means harder to vary.
Where I disagree with the blog
I agree with Dennis that the quality sliders in the blog don't work. I also agree with his decision to let users supply the creative input rather than expecting the program to generate it.
Where I disagree is that I think once we allow this same freedom for HTV, we can construct a similarly simple program for it. The user comes up with explanations and tries to vary them while keeping them working. The program counts the working variations and ranks the explanations.
There are still all the normal problems of human knowledge: maybe I missed a variation, maybe I accepted a bad one, maybe someone else would judge things differently. But those same problems exist when we come up with and judge criticisms.
I don't think either program solves those problems, and I don't think it needs to. That's the part people do.
Link to exact code version used here: hard-to-vary/htv.py at ab8be8
#5541·Jad Elmourad revised 10 days agoA simple implementation of hard-to-vary
This is my submission for Veritula's bounty for Idea #3069, which asks for an executable implementation that can compare arbitrary English explanations by how hard they are to vary.
Code: hard-to-vary
I've implemented the approach as a small interactive program. It takes arbitrary explanations supplied by the user, collects working variations of each, and ranks the explanations by hardness to vary.
I think hard-to-vary can be implemented more simply than the approaches considered in Dennis's blog, Hard to Vary or Hardly Usable?. The basic idea I'm using is this: if an explanation is harder to vary, there should be fewer ways of changing it while still having it explain what it's supposed to explain.
The program starts by asking the user what question they're trying to answer and then asks for a list of proposed explanations. It goes through each explanation one at a time and asks the user to come up with variations of it that would still work as explanations. The user can enter as many as they can find, then move on to the next explanation.
Finally, the program counts the working variations and ranks the explanations. Fewer working variations means harder to vary, while equal numbers mean equally hard to vary. So if explanation A has two working variations and explanation B has five, A is harder to vary than B.
An example
I'll use Deutsch's example from Chapter 1, “The Reach of Explanations,” of The Beginning of Infinity: Why do seasons occur?
One explanation is the story of Persephone. Hades, god of the underworld, kidnaps Persephone. Her mother Demeter eventually negotiates her release under an arrangement that requires Persephone to return to Hades once a year. Whenever Persephone is away, Demeter becomes sad and makes the world cold and bleak.
Deutsch's point is that we can change many of the details of this explanation while still accounting for the same observations. For example, I might try variations like:
- Persephone escapes instead of being released under an agreement.
- Something other than a magic seed compels her to return.
- Some other arrangement causes Persephone to return annually instead of a marriage contract.
The details have changed, but the story can still be made to explain the seasonal cycle. Suppose I find three such variations.
Now I try the explanation involving Earth's axial tilt. Here the details are much more constrained by what we're trying to explain. Changing the geometry substantially changes what the theory predicts about the seasons. Suppose I only find one working variation.
The program therefore ranks axial tilt as harder to vary: one working variation versus three. That's the entire comparison procedure.
How I understand Dennis's criticism
I don't understand Dennis as claiming that Deutsch simply gets the Persephone example wrong. The issue in the blog is how we get from examples like this, where we seem to have an intuition that one explanation is harder to vary, to a sufficiently specified procedure that could compare explanations in general.
Dennis initially explores numerical quality scores, but that immediately creates problems. Why should one explanation have a score of 500 rather than 550? Why choose that scale? How do criticisms affect the score? How do criticisms of criticisms affect it? I agree with Dennis that these choices look arbitrary.
He eventually gets rid of the quality scores entirely. Instead of trying to measure the quality of an idea, his program keeps track of pending criticisms. His proposed rule becomes: adopt ideas without pending criticisms and reject ideas that have them.
There's something important about how that system works, though. The program doesn't generate criticisms itself; people do. And that's intentional: Dennis says "I’m not looking to formalize or automate creativity as a whole". Creative input can come from users while the program handles the non-creative part of the process. I agree that you can have a rational decision-making process while outsourcing the creative part to the user.
I just don't see why we can't do the same thing with HTV. Let the user come up with variations and say which ones they think still work. The program doesn't need to understand the explanation or come up with the variations itself. It keeps track of the variations and compares the counts.
This doesn't seem fundamentally different from Dennis letting the user tell his program that something is a criticism. In fact, in the blog he explicitly avoids having the program figure out whether a comment is really a criticism: the user checks a box saying that it is. So in my program the user is supplying a working variation; in his, the user is supplying a criticism. In both cases the user is providing the part that requires understanding and judgment, and the program does something simple with that input.
It also means I don't need the quality scores Dennis runs into trouble with. I don't need to decide how many points axial tilt gets compared with Persephone. I'm just asking: how many ways have we actually found to change each explanation while still having it work?
But isn't this subjective?
One criticism Dennis quotes is:
“Also, isn’t the difficulty of changing an explanation at least partly a property not of the explanation itself but of whoever is trying to change it? If I’m having difficulty changing it, maybe that’s because I lack imagination. Or maybe I’m just new to that field and an expert could easily change it.”
I think this is true. I just don't think it's a problem specific to HTV.
Imagine I can't think of any working variations of an explanation, but an expert can immediately think of five. Then yes, our results will be different. But isn't that also what happens with criticism? I might look at an idea and fail to see anything wrong with it while someone who knows much more about the subject immediately sees a serious criticism.
The same goes for participation. An idea on Veritula might have zero pending criticisms simply because hardly anyone has tried to criticize it. That doesn't mean there are literally no criticisms of it. Someone could find one tomorrow. Dennis's answer in the blog is basically that if this bothers you, try to find a criticism yourself. If you can't find one, why not adopt the idea?
I think HTV can work the same way. Zero working variations doesn't mean that we've somehow proven there are no possible variations. It means we haven't found one. If you think the explanation is actually easy to vary, try to come up with a variation that still works.
So yes, the result depends on the knowledge and creativity of the person using the program. But I think rational decision-making is always going to depend on what criticisms, arguments, alternatives, etc. a person is actually aware of. I don't see how Veritula escapes that either.
What about human judgment?
There's another obvious question: who decides whether a variation actually works?
For this program, the user does. I don't think we can get rid of that kind of human judgment, at least until we get AGI. Two people can disagree about whether a variation still explains the thing we're trying to explain. They can also disagree about whether two variations are really different or are basically the same variation stated twice.
Again, I think Veritula has the same underlying issue. People still have to decide whether something really is a criticism, whether a countercriticism actually answers it, whether two criticisms are redundant, and so on. Dennis's program can keep track of the structure, but the structure only means something if those judgments make sense.
Take an extreme case. If a malicious moderator rejects every good criticism of an idea and accepts nonsense countercriticisms, the idea could end up showing
0 pending criticisms. I obviously shouldn't look at the0and conclude that the idea is rational to adopt. I'd want to read what happened and decide whether I agree with it.I don't mean this as a criticism specific to Veritula. I think it's just a limit of this kind of approach. At some point people have to make judgments, and people can disagree about them. Ultimately everyone is their own moderator when it comes to their own decision-making. I have to decide which arguments I accept, which criticisms I think have been answered, and so on.
The same is true with my HTV program. If someone gives me a ranking based on ten supposed working variations, I don't have to accept the ranking blindly. I can look at the ten variations and decide that five don't really work and three others are basically duplicates. My result would then be different.
I'm fine with that. I don't think the goal of either program should be to somehow remove judgment from rational thinking. The program gives us a procedure for what to do with the judgments we've made.
What does the program actually contribute?
Dennis writes:
“We can’t just outsource everything to the user – the app has to do some things or it has no value.”
This was actually the part of the blog that made me think about Veritula itself. What is Veritula doing, and what is it outsourcing?
It outsources the interesting creative part to people. People come up with the ideas. People come up with the criticisms. The user can even tell the program whether something they've written is a criticism by checking a box. The program then keeps track of the structure and tells us how many criticisms are pending.
My program is doing something similar, except with variations. People come up with the explanations and the working variations. The program keeps track of them, counts them, and ranks the explanations.
So I don't think I'm outsourcing everything to the user any more than Veritula is. I'm outsourcing the part that requires creativity and judgment. The actual decision rule is implemented in the program.
For Veritula, that rule ultimately depends on whether there are pending criticisms. For my program, it depends on the number of working variations: fewer working variations means harder to vary.
Where I disagree with the blog
I agree with Dennis that the quality sliders in the blog don't work. I also agree with his decision to let users supply the creative input rather than expecting the program to generate it.
Where I disagree is that I think once we allow this same freedom for HTV, we can construct a similarly simple program for it. The user comes up with explanations and tries to vary them while keeping them working. The program counts the working variations and ranks the explanations.
There are still all the normal problems of human knowledge: maybe I missed a variation, maybe I accepted a bad one, maybe someone else would judge things differently. But those same problems exist when we come up with and judge criticisms.
I don't think either program solves those problems, and I don't think it needs to. That's the part people do.
Update: responding to criticisms
After posting the first version, several criticisms came up that I initially thought about answering individually. After thinking about them, though, I realized that while they raise different issues, they can all be understood within the same framework. So rather than splitting the discussion across several different criticism threads, I'm adding this section and reposting the submission as version 2.
I don't think these criticisms require changing the program or the main argument above. But they do make one part of the argument worth clarifying: the program is operating on the user's current understanding of the explanation.
Dennis showed a case where the program gives the wrong ranking after more variations are entered for the axial-tilt explanation (#5526), and another where arbitrary details like an incrementing number of green hats can generate indefinitely many variations (#5528). This leads to the related problem that both explanations could have infinitely many variations and therefore appear equally hard to vary (#5529). Dennis also pointed out that some variations might represent the reach of a good explanation rather than make it worse (#5530), while Dirk raised the question of what counts as a variation rather than an entirely different explanation (#5531).
I think these concerns can all be looked at within the same framework: the program is operating on the user's current understanding of the explanation.
Take the example of replacing Earth's tilt with the tilt of Mars or another planet from #5526. If someone thinks they can replace Earth with Mars and the explanation still works as an explanation of Earth's seasons, then yes, according to their current understanding the explanation really is easy to vary.
But someone who properly understands the explanation of how axial tilt creates the seasons knows there's a lot more context. The tilt of Earth matters because of Earth's relationship with the Sun, how the amount and angle of incoming sunlight changes, how that affects heating, and so on. All these parts of the explanation are connected. You can't just replace Earth with Mars while keeping everything else the same and still claim to be explaining Earth's seasons.
My example in the program is obviously just a toy version of the explanation. A proper explanation includes all this context, and I think that's where the real hard-to-vary aspect starts to show. As you understand more of the explanation, you understand why certain details have to be the way they are and can't just be swapped out independently.
The same applies to the green-hat example in #5528. If wearing one hat, two hats, three hats, etc. is seriously part of my explanation, and I genuinely think all of those are valid variations that make no difference to what is being explained, then yeah, that's a bad explanation. It contains something completely arbitrary that I can vary however I want. That's exactly what I would expect an easy-to-vary explanation to look like.
This also addresses the infinity issue in #5529. If an explanation really contains something I can vary indefinitely without affecting its ability to explain the phenomenon, then having indefinitely many working variations isn't an accidental problem with the program. It's telling me something about the explanation: it contains an unconstrained part that I can keep changing without consequence.
This is also how I think about the concern in #5530 that some variations represent reach. If we're explaining Earth's seasons and I replace Earth with Mars, I don't think I've found another working variation of the explanation of Earth's seasons. I've applied the underlying explanation to a different problem. If someone understands those as the same explanation exhibiting reach, that's fine too; the important point is that the user has to understand what explanatory claim is being varied and what phenomenon it's supposed to explain.
The program isn't intended to distinguish a variation from a completely different explanation either, as raised in #5531. That's something the user has to decide. In fact, I don't see how a program could make that distinction in general without being a general intelligence that actually comprehends the problem situation and the explanations involved.
And people themselves can disagree about what counts as a variation. That's unavoidable because it depends on how they understand the underlying explanatory argument. What looks like a harmless change to me might look to someone with a deeper understanding like a change that completely breaks the explanation.
So I don't think different people getting different results is necessarily a problem. If I understand an explanation poorly, I may think lots of its details can be changed independently. Once I understand more of the connections between those details, I may realize that many of those variations don't actually work. On the other hand, an expert might also know valid ways of varying an explanation that I would never have thought of. The result reflects our current understanding, and that can change as our knowledge changes.
Dennis also points out that the current CLI doesn't let the user revise a variation after entering it (#5536) and contrasts this with Veritula, where further input can revise the tentative result (#5537). I agree that these judgments need to be revisable. The current program is just a minimal demonstration, so changing your judgment currently means rerunning it. Adding the ability to add, edit, or delete variations and recalculate the ranking is straightforward and doesn't change the decision procedure I'm proposing. If the user's understanding changes, their inputs can change, and the ranking can change with them.
Finally, Dennis asks in #5534 which variant of the better explanation the user should adopt if several variants still work. I think it's totally fine if we don't currently have an answer. If several variants all seem plausible and we have no way of choosing between them, my guess is that this is exactly the kind of situation where scientific research programs can diverge and follow different threads until we eventually find some differentiating factor between the explanations. The program doesn't need to invent a reason to choose between them when we don't currently have one.
Link to exact code version used here: hard-to-vary/htv.py at ab8be8
#5544·Dennis HackethalOP revised 10 days agoA simple implementation of hard-to-vary
This is my submission for Veritula's bounty for Idea #3069, which asks for an executable implementation that can compare arbitrary English explanations by how hard they are to vary.
Code: hard-to-vary
I've implemented the approach as a small interactive program. It takes arbitrary explanations supplied by the user, collects working variations of each, and ranks the explanations by hardness to vary.
I think hard-to-vary can be implemented more simply than the approaches considered in Dennis's blog, Hard to Vary or Hardly Usable?. The basic idea I'm using is this: if an explanation is harder to vary, there should be fewer ways of changing it while still having it explain what it's supposed to explain.
The program starts by asking the user what question they're trying to answer and then asks for a list of proposed explanations. It goes through each explanation one at a time and asks the user to come up with variations of it that would still work as explanations. The user can enter as many as they can find, then move on to the next explanation.
Finally, the program counts the working variations and ranks the explanations. Fewer working variations means harder to vary, while equal numbers mean equally hard to vary. So if explanation A has two working variations and explanation B has five, A is harder to vary than B.
An example
Take the question: Why do seasons occur?
One explanation is the story of Persephone. She spends part of the year in Hades, Demeter grieves while she's gone, and this accounts for the seasonal cycle.
I might try changing the explanation in a few ways:
- Persephone spends five months in Hades instead of six.
- It's Demeter's son who is taken rather than her daughter.
- Zeus orders Persephone to return periodically rather than her return depending on the details involving the pomegranate.
The details have changed, but the basic explanatory story can still do the same job. Suppose I find three such variations.
Now I try the explanation involving Earth's axial tilt. I might be able to change the stated tilt from 23.4 degrees to 23.5 degrees without substantially affecting the explanation. But if I start making large changes to the geometry while trying to explain the same observations, the explanation stops working. Suppose I find one working variation.
The program therefore ranks axial tilt as harder to vary: one working variation versus three. That's the entire comparison procedure.
How I understand Dennis's criticism
I don't understand Dennis as claiming that Deutsch simply gets the Persephone example wrong. The issue in the blog is how we get from examples like this, where we seem to have an intuition that one explanation is harder to vary, to a sufficiently specified procedure that could compare explanations in general.
Dennis initially explores numerical quality scores, but that immediately creates problems. Why should one explanation have a score of 500 rather than 550? Why choose that scale? How do criticisms affect the score? How do criticisms of criticisms affect it? I agree with Dennis that these choices look arbitrary.
He eventually gets rid of the quality scores entirely. Instead of trying to measure the quality of an idea, his program keeps track of pending criticisms. His proposed rule becomes: adopt ideas without pending criticisms and reject ideas that have them.
There's something important about how that system works, though. The program doesn't generate criticisms itself; people do. And that's intentional: Dennis says "I’m not looking to formalize or automate creativity as a whole". Creative input can come from users while the program handles the non-creative part of the process. I agree that you can have a rational decision-making process while outsourcing the creative part to the user.
I just don't see why we can't do the same thing with HTV. Let the user come up with variations and say which ones they think still work. The program doesn't need to understand the explanation or come up with the variations itself. It keeps track of the variations and compares the counts.
This doesn't seem fundamentally different from Dennis letting the user tell his program that something is a criticism. In fact, in the blog he explicitly avoids having the program figure out whether a comment is really a criticism: the user checks a box saying that it is. So in my program the user is supplying a working variation; in his, the user is supplying a criticism. In both cases the user is providing the part that requires understanding and judgment, and the program does something simple with that input.
It also means I don't need the quality scores Dennis runs into trouble with. I don't need to decide how many points axial tilt gets compared with Persephone. I'm just asking: how many ways have we actually found to change each explanation while still having it work?
But isn't this subjective?
One criticism Dennis quotes is:
“Also, isn’t the difficulty of changing an explanation at least partly a property not of the explanation itself but of whoever is trying to change it? If I’m having difficulty changing it, maybe that’s because I lack imagination. Or maybe I’m just new to that field and an expert could easily change it.”
I think this is true. I just don't think it's a problem specific to HTV.
Imagine I can't think of any working variations of an explanation, but an expert can immediately think of five. Then yes, our results will be different. But isn't that also what happens with criticism? I might look at an idea and fail to see anything wrong with it while someone who knows much more about the subject immediately sees a serious criticism.
The same goes for participation. An idea on Veritula might have zero pending criticisms simply because hardly anyone has tried to criticize it. That doesn't mean there are literally no criticisms of it. Someone could find one tomorrow. Dennis's answer in the blog is basically that if this bothers you, try to find a criticism yourself. If you can't find one, why not adopt the idea?
I think HTV can work the same way. Zero working variations doesn't mean that we've somehow proven there are no possible variations. It means we haven't found one. If you think the explanation is actually easy to vary, try to come up with a variation that still works.
So yes, the result depends on the knowledge and creativity of the person using the program. But I think rational decision-making is always going to depend on what criticisms, arguments, alternatives, etc. a person is actually aware of. I don't see how Veritula escapes that either.
What about human judgment?
There's another obvious question: who decides whether a variation actually works?
For this program, the user does. I don't think we can get rid of that kind of human judgment, at least until we get AGI. Two people can disagree about whether a variation still explains the thing we're trying to explain. They can also disagree about whether two variations are really different or are basically the same variation stated twice.
Again, I think Veritula has the same underlying issue. People still have to decide whether something really is a criticism, whether a countercriticism actually answers it, whether two criticisms are redundant, and so on. Dennis's program can keep track of the structure, but the structure only means something if those judgments make sense.
Take an extreme case. If a malicious moderator rejects every good criticism of an idea and accepts nonsense countercriticisms, the idea could end up showing
0 pending criticisms. I obviously shouldn't look at the0and conclude that the idea is rational to adopt. I'd want to read what happened and decide whether I agree with it.I don't mean this as a criticism specific to Veritula. I think it's just a limit of this kind of approach. At some point people have to make judgments, and people can disagree about them. Ultimately everyone is their own moderator when it comes to their own decision-making. I have to decide which arguments I accept, which criticisms I think have been answered, and so on.
The same is true with my HTV program. If someone gives me a ranking based on ten supposed working variations, I don't have to accept the ranking blindly. I can look at the ten variations and decide that five don't really work and three others are basically duplicates. My result would then be different.
I'm fine with that. I don't think the goal of either program should be to somehow remove judgment from rational thinking. The program gives us a procedure for what to do with the judgments we've made.
What does the program actually contribute?
Dennis writes:
“We can’t just outsource everything to the user – the app has to do some things or it has no value.”
This was actually the part of the blog that made me think about Veritula itself. What is Veritula doing, and what is it outsourcing?
It outsources the interesting creative part to people. People come up with the ideas. People come up with the criticisms. The user can even tell the program whether something they've written is a criticism by checking a box. The program then keeps track of the structure and tells us how many criticisms are pending.
My program is doing something similar, except with variations. People come up with the explanations and the working variations. The program keeps track of them, counts them, and ranks the explanations.
So I don't think I'm outsourcing everything to the user any more than Veritula is. I'm outsourcing the part that requires creativity and judgment. The actual decision rule is implemented in the program.
For Veritula, that rule ultimately depends on whether there are pending criticisms. For my program, it depends on the number of working variations: fewer working variations means harder to vary.
Where I disagree with the blog
I agree with Dennis that the quality sliders in the blog don't work. I also agree with his decision to let users supply the creative input rather than expecting the program to generate it.
Where I disagree is that I think once we allow this same freedom for HTV, we can construct a similarly simple program for it. The user comes up with explanations and tries to vary them while keeping them working. The program counts the working variations and ranks the explanations.
There are still all the normal problems of human knowledge: maybe I missed a variation, maybe I accepted a bad one, maybe someone else would judge things differently. But those same problems exist when we come up with and judge criticisms.
I don't think either program solves those problems, and I don't think it needs to. That's the part people do.
Link to exact code version used here: hard-to-vary/htv.py at ab8be8
#5551·Jad Elmourad revised 10 days agoA simple implementation of hard-to-vary
This is my submission for Veritula's bounty for Idea #3069, which asks for an executable implementation that can compare arbitrary English explanations by how hard they are to vary.
Code: hard-to-vary
I've implemented the approach as a small interactive program. It takes arbitrary explanations supplied by the user, collects working variations of each, and ranks the explanations by hardness to vary.
I think hard-to-vary can be implemented more simply than the approaches considered in Dennis's blog, Hard to Vary or Hardly Usable?. The basic idea I'm using is this: if an explanation is harder to vary, there should be fewer ways of changing it while still having it explain what it's supposed to explain.
The program starts by asking the user what question they're trying to answer and then asks for a list of proposed explanations. It goes through each explanation one at a time and asks the user to come up with variations of it that would still work as explanations. The user can enter as many as they can find, then move on to the next explanation.
Finally, the program counts the working variations and ranks the explanations. Fewer working variations means harder to vary, while equal numbers mean equally hard to vary. So if explanation A has two working variations and explanation B has five, A is harder to vary than B.
An example
I'll use Deutsch's example from Chapter 1, “The Reach of Explanations,” of The Beginning of Infinity: Why do seasons occur?
One explanation is the story of Persephone. Hades, god of the underworld, kidnaps Persephone. Her mother Demeter eventually negotiates her release under an arrangement that requires Persephone to return to Hades once a year. Whenever Persephone is away, Demeter becomes sad and makes the world cold and bleak.
Deutsch's point is that we can change many of the details of this explanation while still accounting for the same observations. For example, I might try variations like:
- Persephone escapes instead of being released under an agreement.
- Something other than a magic seed compels her to return.
- Some other arrangement causes Persephone to return annually instead of a marriage contract.
The details have changed, but the story can still be made to explain the seasonal cycle. Suppose I find three such variations.
Now I try the explanation involving Earth's axial tilt. Here the details are much more constrained by what we're trying to explain. Changing the geometry substantially changes what the theory predicts about the seasons. Suppose I only find one working variation.
The program therefore ranks axial tilt as harder to vary: one working variation versus three. That's the entire comparison procedure.
How I understand Dennis's criticism
I don't understand Dennis as claiming that Deutsch simply gets the Persephone example wrong. The issue in the blog is how we get from examples like this, where we seem to have an intuition that one explanation is harder to vary, to a sufficiently specified procedure that could compare explanations in general.
Dennis initially explores numerical quality scores, but that immediately creates problems. Why should one explanation have a score of 500 rather than 550? Why choose that scale? How do criticisms affect the score? How do criticisms of criticisms affect it? I agree with Dennis that these choices look arbitrary.
He eventually gets rid of the quality scores entirely. Instead of trying to measure the quality of an idea, his program keeps track of pending criticisms. His proposed rule becomes: adopt ideas without pending criticisms and reject ideas that have them.
There's something important about how that system works, though. The program doesn't generate criticisms itself; people do. And that's intentional: Dennis says "I’m not looking to formalize or automate creativity as a whole". Creative input can come from users while the program handles the non-creative part of the process. I agree that you can have a rational decision-making process while outsourcing the creative part to the user.
I just don't see why we can't do the same thing with HTV. Let the user come up with variations and say which ones they think still work. The program doesn't need to understand the explanation or come up with the variations itself. It keeps track of the variations and compares the counts.
This doesn't seem fundamentally different from Dennis letting the user tell his program that something is a criticism. In fact, in the blog he explicitly avoids having the program figure out whether a comment is really a criticism: the user checks a box saying that it is. So in my program the user is supplying a working variation; in his, the user is supplying a criticism. In both cases the user is providing the part that requires understanding and judgment, and the program does something simple with that input.
It also means I don't need the quality scores Dennis runs into trouble with. I don't need to decide how many points axial tilt gets compared with Persephone. I'm just asking: how many ways have we actually found to change each explanation while still having it work?
But isn't this subjective?
One criticism Dennis quotes is:
“Also, isn’t the difficulty of changing an explanation at least partly a property not of the explanation itself but of whoever is trying to change it? If I’m having difficulty changing it, maybe that’s because I lack imagination. Or maybe I’m just new to that field and an expert could easily change it.”
I think this is true. I just don't think it's a problem specific to HTV.
Imagine I can't think of any working variations of an explanation, but an expert can immediately think of five. Then yes, our results will be different. But isn't that also what happens with criticism? I might look at an idea and fail to see anything wrong with it while someone who knows much more about the subject immediately sees a serious criticism.
The same goes for participation. An idea on Veritula might have zero pending criticisms simply because hardly anyone has tried to criticize it. That doesn't mean there are literally no criticisms of it. Someone could find one tomorrow. Dennis's answer in the blog is basically that if this bothers you, try to find a criticism yourself. If you can't find one, why not adopt the idea?
I think HTV can work the same way. Zero working variations doesn't mean that we've somehow proven there are no possible variations. It means we haven't found one. If you think the explanation is actually easy to vary, try to come up with a variation that still works.
So yes, the result depends on the knowledge and creativity of the person using the program. But I think rational decision-making is always going to depend on what criticisms, arguments, alternatives, etc. a person is actually aware of. I don't see how Veritula escapes that either.
What about human judgment?
There's another obvious question: who decides whether a variation actually works?
For this program, the user does. I don't think we can get rid of that kind of human judgment, at least until we get AGI. Two people can disagree about whether a variation still explains the thing we're trying to explain. They can also disagree about whether two variations are really different or are basically the same variation stated twice.
Again, I think Veritula has the same underlying issue. People still have to decide whether something really is a criticism, whether a countercriticism actually answers it, whether two criticisms are redundant, and so on. Dennis's program can keep track of the structure, but the structure only means something if those judgments make sense.
Take an extreme case. If a malicious moderator rejects every good criticism of an idea and accepts nonsense countercriticisms, the idea could end up showing
0 pending criticisms. I obviously shouldn't look at the0and conclude that the idea is rational to adopt. I'd want to read what happened and decide whether I agree with it.I don't mean this as a criticism specific to Veritula. I think it's just a limit of this kind of approach. At some point people have to make judgments, and people can disagree about them. Ultimately everyone is their own moderator when it comes to their own decision-making. I have to decide which arguments I accept, which criticisms I think have been answered, and so on.
The same is true with my HTV program. If someone gives me a ranking based on ten supposed working variations, I don't have to accept the ranking blindly. I can look at the ten variations and decide that five don't really work and three others are basically duplicates. My result would then be different.
I'm fine with that. I don't think the goal of either program should be to somehow remove judgment from rational thinking. The program gives us a procedure for what to do with the judgments we've made.
What does the program actually contribute?
Dennis writes:
“We can’t just outsource everything to the user – the app has to do some things or it has no value.”
This was actually the part of the blog that made me think about Veritula itself. What is Veritula doing, and what is it outsourcing?
It outsources the interesting creative part to people. People come up with the ideas. People come up with the criticisms. The user can even tell the program whether something they've written is a criticism by checking a box. The program then keeps track of the structure and tells us how many criticisms are pending.
My program is doing something similar, except with variations. People come up with the explanations and the working variations. The program keeps track of them, counts them, and ranks the explanations.
So I don't think I'm outsourcing everything to the user any more than Veritula is. I'm outsourcing the part that requires creativity and judgment. The actual decision rule is implemented in the program.
For Veritula, that rule ultimately depends on whether there are pending criticisms. For my program, it depends on the number of working variations: fewer working variations means harder to vary.
Where I disagree with the blog
I agree with Dennis that the quality sliders in the blog don't work. I also agree with his decision to let users supply the creative input rather than expecting the program to generate it.
Where I disagree is that I think once we allow this same freedom for HTV, we can construct a similarly simple program for it. The user comes up with explanations and tries to vary them while keeping them working. The program counts the working variations and ranks the explanations.
There are still all the normal problems of human knowledge: maybe I missed a variation, maybe I accepted a bad one, maybe someone else would judge things differently. But those same problems exist when we come up with and judge criticisms.
I don't think either program solves those problems, and I don't think it needs to. That's the part people do.
Link to exact code version used in #5523, #5541, #5544, #5551:
hard-to-vary/htv.py at ab8be8
#5596·Dennis HackethalOP, 9 days agoOk so let’s put ourselves in the shoes of someone who genuinely thinks different decimal numbers lead to different variants for both competing explanations, and that, as a result, there are infinitely many variants for each. Walk me through how that person would use your program?
In short, the question is: how can we use the program when we genuinely think both explanations have infinitely many variants?
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.
#5596·Dennis HackethalOP, 9 days agoOk so let’s put ourselves in the shoes of someone who genuinely thinks different decimal numbers lead to different variants for both competing explanations, and that, as a result, there are infinitely many variants for each. Walk me through how that person would use your program?
In short, the question is: how can we use the program when we genuinely think both explanations have infinitely many variants?
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.
#5590·Dennis HackethalOP, 9 days agoI 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.
Because it doesn’t help us form a preference in a factual matter like the Pop-Tart question. HTV is not involved.
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.
#5585·Dennis HackethalOP, 10 days agoSo I don't see acquiring new knowledge as something that sits outside the process and simply overrides the HTV result.
One would reject some explanations for reasons unrelated to HTV. It’s not that one would override a specific HTV result – one wouldn’t even get to that result because one would first make other choices leading to different inputs.
If I gather new info and the problem situation changes to where I already know Pop-Tarts aren’t tart but sweet (eg because I taste test them), then I simply won’t include that guess in the inputs to the program, and I won’t bother varying that guess.
HTV could still be part of the process, but DD’s claim was that all rationality boils down to HTV.
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.
#5585·Dennis HackethalOP, 10 days agoSo I don't see acquiring new knowledge as something that sits outside the process and simply overrides the HTV result.
One would reject some explanations for reasons unrelated to HTV. It’s not that one would override a specific HTV result – one wouldn’t even get to that result because one would first make other choices leading to different inputs.
If I gather new info and the problem situation changes to where I already know Pop-Tarts aren’t tart but sweet (eg because I taste test them), then I simply won’t include that guess in the inputs to the program, and I won’t bother varying that guess.
HTV could still be part of the process, but DD’s claim was that all rationality boils down to HTV.
One would reject some explanations for reasons unrelated to HTV. It’s not that one would override a specific HTV result – one wouldn’t even get to that result because one would first make other choices leading to different inputs.
I think this is fair. You can treat new knowledge and criticism as changing the problem situation within which HTV operates, or more narrowly as filtering which explanations still work before applying HTV. I think those are functionally equivalent; if you want to call the latter preference formation outside HTV, I'm fine with that.
#5571·Dennis HackethalOP, 10 days agoBut suppose grass really did cure the disease and we actually understood how. Maybe a particular compound in the grass interacts with some biological mechanism, and a certain concentration is required for the effect. The explanation might allow a whole range of effective dosages rather than one exact number, but that range would itself be explained and constrained by the mechanism.
That assumes the cure works: then I agree there’s a reason for the specific range, and that range will be part of the one working variant. Your program would then accurately prefer it over a rival.
But the program also needs to account for cases where the cure doesn’t work. Then we can’t refer to a range anymore because there’s no reason to constrain the explanation to that range. And then we’re left with the situation described in #5549.
I think this is the same basic point as #5577.
#5580·Dennis HackethalOP, 10 days agoBeing hard to vary also doesn't guarantee that an explanation is true.
Agreed, but I’m not asking for a guarantee. I’m basically saying preference formation using HTV should help us find truth. The Pop-Tart example seems to be a case where HTV is unrelated to finding truth.
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.
