It sounds as though you are proposing using your approximate program predictor as a metric of how accurate a new candidate program predictor is. However, that is not going to result in any incentive to improve on the original approximate program predictor’s faults.
In fact, I’m “asking” the program predictor to find the program which generate the best program predictor. It should be noted that the program predictor do not necesserly “consider” itself perfect: if you ask it to predict how many of the programs of less than M bits it will predict correctly, it won’t necesserly say “all of them” (in fact it shouldn’t say that if it’s good enouygh to be improved on).
It sounds as though you are proposing using your approximate program predictor as a metric of how accurate a new candidate program predictor is. However, that is not going to result in any incentive to improve on the original approximate program predictor’s faults.
In fact, I’m “asking” the program predictor to find the program which generate the best program predictor. It should be noted that the program predictor do not necesserly “consider” itself perfect: if you ask it to predict how many of the programs of less than M bits it will predict correctly, it won’t necesserly say “all of them” (in fact it shouldn’t say that if it’s good enouygh to be improved on).
You are making this harder than it needs to be. General forecasting is equivalent to general stream compression. That insight offers a simple and effective quality-testing procedure—you compress the output of randomly-configured FSMs.
There’s a big existing literature about how to create compressors—it is a standard computer-science problem.
I’m not sure what you’re accusing me of making harder than it need to be.
Could you clarify?