Search Ideas

I agree that HTV has to stand on its own. My argument isn't “Veritula has this problem too, therefore it's okay for HTV to have it.”

The reason I've been comparing the two is narrower: to show that outsourcing the parts requiring creativity and judgment to the user doesn't prevent us from having an executable decision procedure built on top of those inputs.

On revisability specifically, I agree that the result should be tentative and able to change when the user's judgments change. As I explained in #5559, this can technically already be done by rerunning the program with the updated inputs. The current CLI is only a minimal demonstration, so that's obviously not ideal UX. Letting the user add, edit, or delete variations and immediately recalculate the result would be straightforward and wouldn't change the decision procedure.

I think the program already gets this through human input.

The prompt isn't asking the user to enter arbitrary changes. It specifically asks:

“Enter variations of this explanation that would still work to explain the same thing.”

So by entering a variation, the user is making the judgment that it still accounts for what the original explanation was supposed to account for. That's intentionally a human judgment, just like the other judgments I've discussed in #5553.

If the user later changes their mind about one of those judgments, then yes, the current minimal CLI requires them to run it again with the corrected input. I agree that wouldn't be good UX for a full application, but that's not what I'm trying to build here. Adding the ability to add, edit, or delete variations and immediately recalculate the ranking is straightforward and doesn't change the decision procedure being demonstrated.

I don't think the program needs to choose one of the surviving variants if our current knowledge gives us no reason to choose.

If several variants of the better explanation still work and we currently have nothing that differentiates them, then I think it's fine for them to remain competing possibilities. In fact, my guess is that this is exactly how different research programs can get started: people can follow the different explanatory threads until further criticism, experiments, observations, or other new knowledge gives us a reason to distinguish them.

So I don't think the program should invent a preference between variants when our current problem situation and knowledge don't provide one. Sometimes the rational state really is that we don't yet know which variant is right. We can continue developing and testing them until we find something that differentiates them.

I agree that people can disagree about what counts as a variation versus a completely different explanation. I don't agree that the program itself needs to recognize the difference.

The program isn't intended to distinguish a variation from a completely different explanation. 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.

This is also part of the broader point I made in #5553: the program operates on the user's current understanding of the problem and explanations rather than independently understanding them for the user.

I think this is where the problem/question given to the program matters.

If the problem I'm trying to answer is “Why does Earth have seasons?”, then replacing Earth with Mars doesn't give me another working variation of the explanation of Earth's seasons. I've changed the phenomenon I'm trying to explain. Applying the same underlying theory to explain seasons on Mars seems to me like an example of its reach, not a variation of its explanation of Earth's seasons.

This is one reason the program asks for the question first. Whether a proposed variation still works can't be judged independently of what we're trying to explain.

As I explained in #5553, the program relies on the user's understanding of both the problem situation and the explanation. So I agree that reach and easy-to-vary shouldn't be confused, but I don't think the program requires us to confuse them. The user has to judge whether they've varied an explanation while preserving what it was supposed to explain, or instead applied the explanation to a different problem.

And of course people can disagree about that distinction, because they can understand the problem situation and explanatory argument differently. That's part of the human judgment the program deliberately leaves to the user.

As I argued in #5554, if the number of green hats is genuinely part of an explanation and can be changed arbitrarily without affecting anything, then I think that really does expose an easy-to-vary part of the explanation.

But I don't think adding “while I wear one green hat,” “while I wear two green hats,” etc. to the axial-tilt explanation necessarily varies the explanation at all.

If my explanation is that Earth's seasons result from its axial tilt and the resulting relationship between Earth and the Sun, whether I happen to be wearing one green hat or a thousand isn't part of that explanatory argument. Appending an unrelated fact to the English sentence doesn't change the explanation it expresses.

If, on the other hand, I genuinely claim that my hat is part of the explanation—say, that Earth's seasons occur because of axial tilt and because I'm wearing exactly one green hat—then changing the number of hats would be a genuine variation. But in that case I really have made the explanation worse by adding an arbitrary component that isn't constrained by what I'm trying to explain.

So I think there's a difference between varying an explanation and varying the string of English used to express it. The program relies on the user to understand that distinction, for the same reason I described in #5553: it operates on the user's understanding of the explanatory argument, not on arbitrary syntactic changes to its wording.

On that understanding, I don't think both explanations become equally easy to vary merely because infinitely many irrelevant statements can be appended to the sentences expressing them.

As I explained in #5553, the program operates on the user's current understanding of the explanation.

In this case, though, I think the green-hat example actually illustrates what it means for an explanation to be easy to vary.

Suppose my explanation really is “God causes the seasons while wearing one green hat,” and I genuinely think I can change that to two hats, three hats, a thousand hats, etc. without affecting the explanation at all. Then the number of hats is completely unconstrained by what I'm trying to explain. Nothing in the explanation tells me why it should be one rather than two or a thousand.

I would consider that a problem with the explanation, not with the HTV comparison. It's exactly the kind of arbitrariness that HTV is supposed to expose.

Of course, the program isn't going to enumerate infinitely many hats. It only works with the variations the user actually comes up with. But if I can keep producing arbitrary variations without affecting the explanatory argument, that seems like evidence that the explanation is easy to vary, not a reason to reject the method.

The program is operating on the user's current understanding of the explanation.
The seasons example in my submission is intentionally a toy example to demonstrate how the program works. In a proper use of the program, both the problem/question and the proposed explanations would include the relevant context needed to understand what is actually being explained and how the explanation works.
For example, “Earth's seasons are caused by axial tilt” is obviously not the full explanation. Someone who properly understands the explanation knows that Earth's tilt matters in relation to the Sun, Earth's orbit, the changing angle and duration of incoming sunlight, the resulting heating, and so on. These parts are connected and constrain each other.
So if the problem is to explain Earth's seasons, I wouldn't accept replacing Earth with Mars, Saturn, Neptune, etc. as working variations of that explanation. Once the relevant context is included, changing the planet changes other parts of the explanatory relationship and no longer explains the original phenomenon.
On the other hand, if a user genuinely understands “because of axial tilt” in such a shallow way that they think Earth can simply be replaced with any other planet while the explanation of Earth's seasons remains intact, then yes: according to their current understanding, the explanation really is easy to vary. The program is correctly reflecting the explanatory knowledge they've supplied to it.
This is why different users can get different results. Someone with a shallow understanding of an explanation may think many of its details can be changed independently. Someone who understands more of the explanatory structure may understand why those same changes break it. Conversely, an expert may also know genuine working variations that a novice would never think of.
So I don't expect the program to produce a context-independent ranking from a few isolated English sentences. The question and explanations are inputs supplied and understood by the user, and the HTV comparison is relative to that current understanding.

Thanks for clarifying! The updated #5546 does make it much clearer.