Search Ideas
31 ideas match your query.:
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
Link to exact code version used here: hard-to-vary/htv.py at ab8be8
Link to exact code version used here: hard-to-vary/htv.py at ab8be8
Link to exact code version used here: hard-to-vary/htv.py at ab8be8
Link to exact code version used in #5523, #5541, #5544, #5551:
hard-to-vary/htv.py at ab8be8
If the user already judges that both explanations have infinitely many working variations, do they really need the program to tell them that they're equally hard to vary? That seems unlikely—the result already follows from the inputs.
That said, if you think it's important for the program itself to represent this case explicitly, I can extend it to handle infinite families of variations as I suggested in #5598. I see that as a small extension to the implementation rather than a problem with the underlying HTV procedure.
Okay, so you're thinking of an edge case where two competing explanations genuinely both have infinitely many working variations.
For example, one explanation says some amount X of grass cures the disease, another says some amount Y of wheat cures it, and neither explanation constrains what X or Y should be. Both can just keep being varied indefinitely.
If that's the kind of case you have in mind, then yes, I agree it's an interesting edge case. If these were the only two competing explanations, my current program would have an awkward time representing the fact that both have infinitely many variations. But also, in this example they're genuinely both extremely easy to vary, so ranking them equally doesn't seem obviously wrong to me.
I don't think we need to get into comparing different sizes of infinity here. If a third explanation had only a finite number of working variations, it would clearly be harder to vary than either of the infinite ones.
As for the implementation, one simple extension would be to let the user indicate that a submitted variation represents an infinite family of working variations, rather than requiring them to enumerate individual examples. Something like a checkbox for "this can be varied indefinitely." That would let the program represent this edge case without changing the basic idea.
I'm not sure it's clear what you mean by this.
Are you saying the process I've outlined doesn't work for a factual matter like the Pop-Tarts question? If so, I've explained in #5586 and #5562 how facts and new knowledge change the problem situation and what explanations and variations we accept.
If, on the other hand, you're saying that this process does work, but that not all of it should be called HTV, then I think that's the same point you were making in #5585, which I'm fine with.
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.
How does this show that HTV is unrelated to finding truth?
You say:
But guess 1 and 2 are plausible and I see no reason to prefer one over the other.
That's exactly how I see it. Before looking up the historical evidence, both seem like good explanations given what we know. So HTV giving us no preference between them seems like the right result at that point.
Once we acquire new knowledge that distinguishes them, the problem situation changes, as I explained in #5562.
I don't see why HTV failing to distinguish two good explanations before we have the knowledge that distinguishes them means it's unrelated to truth.
I don't think test results need some separate formal mechanism for being “fed back” into HTV.
This is the same point I made in #5562. A test result is new knowledge, and new knowledge changes the problem situation and therefore what counts as a working explanation.
It does. Preference formation is the point of the program.
I don't think preference formation requires the program to always select exactly one variant.
If several variants are equally hard to vary given everything I currently know, then “equally hard to vary” is itself the result of the comparison. I don't currently have a rational reason from HTV to prefer one over the others.
I don't think the program should invent a preference when the current problem situation doesn't give us one. The variants can remain competing possibilities until we learn something that differentiates them.
Fair, I didn't mean to imply that #5531 says different people getting different results is itself a problem. I was explaining why I think disagreement about what counts as a variation is okay, even when that disagreement leads to different results.
The user can correct this by rerunning the program with the corrected inputs. I think the UX can be improved by adding add/edit/delete functionality, as discussed in #5559 and #5560, but the basic functionality of the MVP still holds.
I don't think those are genuine variations, so I wouldn't input them when running the program. But someone else might genuinely think they are.
The program can't decide which of us is right without itself understanding the explanation and the problem situation—in other words, without being a general intelligence. That's the point I just made in #5572, and more generally in #5553 and #5557.
At the current stage, without AGI, I think any work that requires that kind of understanding and creative judgment necessarily has to be outsourced to the user. The program then operates on the judgments the user supplies.
I think the program does expose it, given inputs that reflect the user's genuine understanding of the explanations.
If I genuinely regard “axial tilt while I wear one green hat,” “axial tilt while I wear two green hats,” etc. as distinct working variations of the axial-tilt explanation, then I've told the program that the hat count is part of the explanation and can be varied freely. In that case, I think it's completely fair for HTV to judge the explanation easier to vary.
If I instead understand the hat as an irrelevant fact that has nothing to do with the axial-tilt explanation, then I shouldn't submit changes in my hat count as variations of that explanation in the first place.
The program can't accept my judgment that these are genuine variations and then independently override that judgment because it “knows” they're actually irrelevant. Doing that would require the program itself to understand what is doing explanatory work. That's precisely the part I'm outsourcing to the user.
So I don't think this example shows that the program fails to expose easy-to-varyness. It shows that the result depends on which changes the user genuinely judges to be variations of the explanation—which is the same point I made in #5553 and #5555.
I think the Pop-Tarts example mixes together two different things: acquiring new knowledge and forming a preference between explanations. Looking up why Pop-Tarts were actually given their name gives us new knowledge; it doesn't by itself show that the preference formation between explanations isn't HTV.
As I argued in #5553, the program operates on the user's current understanding of the problem and explanations. The user is comparing explanations and variations they currently judge to work. So everything they already know, including criticisms they're aware of, is part of that judgment.
In the Pop-Tarts example, say the three explanations are equally hard to vary given what I currently know. That's fine. I currently have no reason to prefer one over another.
Now suppose I look it up and find historical evidence saying the name was chosen for reason X. I've gained new knowledge, and that changes the problem situation. I'm no longer just asking why they're called Pop-Tarts; I'm asking why they're called Pop-Tarts given that I also know this historical evidence says X.
I could still maintain that the real reason was something else. Maybe the company was lying or the historical source was wrong. But then I have to explain that too. If I just say “the real reason is that they pop out of the toaster, and for some unrelated reason the company says X,” I've added another arbitrary factor to preserve my explanation. That seems like exactly the kind of thing that would expose it as easy to vary.
So I don't see acquiring new knowledge as something that sits outside the process and simply overrides the HTV result. New knowledge changes the problem situation and therefore changes what a working explanation now has to account for. We can then compare the explanations again in light of that new problem situation.
Being hard to vary also doesn't guarantee that an explanation is true. Newton's theory of gravity was a good explanation and remains good enough for many engineering problem situations, even though we later learned that it isn't the full story. As new problems and observations came up that Newton couldn't adequately account for, the problem situation changed and we needed a better explanation.
So I don't think every act of acquiring knowledge or finding a criticism itself needs to take the form of thinking about variants. Those things change the problem situation and affect which explanations and variations we consider to still work.
But that's different from saying the preference formation itself isn't HTV. Once our current knowledge and criticisms are taken into account, HTV can still operate on the explanations that still work and give us a preference—or sometimes tell us that, given what we currently know, they're equally good.
I don't think it follows that a competing explanation would also have uncountably many working variants just because it involves continuous quantities.
The grass example is easy to vary precisely because there's no explanation for why the amount should be 1kg rather than 0.9kg, 0.95kg, etc. If 1kg doesn't work, I can just keep changing the number. Nothing in the explanatory argument constrains it.
But 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.
I wouldn't consider every possible dosage within that range a different variation of the explanation. They're different cases covered by the same explanation. Saying “this mechanism works within this dosage range” is one explanatory claim, even if there are infinitely many numerical values inside the range.
So I think there's a difference between an explanation containing a continuous variable and an explanation whose parameters can be changed arbitrarily without explanatory reason. The first can be perfectly constrained by the explanatory structure. The second is exactly what I understand easy-to-vary to mean.
This also comes back to the point I made in #5553: the program relies on the user's understanding of the explanatory argument. A knowledgeable user wouldn't enter 0.9kg, 0.9001kg, 0.90001kg, etc. as infinitely many distinct explanatory variations if they understand them as instances of one explained dosage range.
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 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.