Hi pusha, I still believe the run factor is better. I have performed that test (temporal effectiveness vs run factor) and I concluded that the utilization of run factor will provide more hits in the long run. Both approaches can be used but the run factor is better at least in my tests.
But still i haven't found a good way to bypass that neighbour number issues...
The same issue to temporal effectiveness vs run factor; stick with the results given or try a variation? I firmly believe that one-off situation can be trapped at a higher GAT ID. However the problem here is the waiting time to reach that GAT ID. I think this partial hits situation will be further amended by the synthetic mode. I have to clarify here when a given GAT decides on some specific numbers, there is a very strict reason why it did pick those instead of the neighbor ones. The selection was decided on randomness evolution occurred at that point. A GAT later possibly can identify that one-off situation automatically and hit the exact numbers hopefully. I'll not work on code to trap one-off numbers, there is no way to identify when to pick a neighbor vs a predicted number. We'll end at a situation that we may skip a predicted number to favor a neighbor when the predicted number actually hit. Of course I want even better hits accuracy if possible but chasing one-offs lacks the definite criterion for that selection. I'll let the engine work as it is meant to work and I hope the synthetic will provide even better hits. The internal operation of randomness evolution is so complex that no mind can really understand the reason a given number was decided by a given GAT, so no tweaks are possible (and if it is possible, based on what? - only a new evaluator may offer some benefit but again, randomness evolution at some point will be able to provide what it should). So I trust a given number had a particular "reason" to be selected by that GAT, even if it is an one-off. At another case, it will be the correct one. Still, we mustn't forget that we deal will lotto draws! Nothing is definite and this makes the prediction task very hard.
Every suggestion comes down to the following: we MUST ensure that we do not make number selection decisions based on observations AFTER a prediction has been made. That means, the one-off is really an observation after we made a prediction. Making changes to that prediction, based on that observation makes a false approach. GAT is designed under that principle: do not use any information that shouldn't be used or known to make a decision, otherwise it can't be called a predictor, rather a nice looking program that does anything else but to predict. It is very easy to make this logical mistake which may provide a brilliant success of a test history but the outcome will be irrelevant to the forthcoming draw. On any program that claims it can predict, the only real question that must be asked is: does it use information that shouldn't be used at some stage during the prediction?
Getting a prediction and adding the one-off numbers does not violate this principle, it just makes a larger pool. However getting a prediction and picking the one-offs is wrong to do. I'm not sure I have described this properly but the is a subtle but very important issue here.
cheers
lottoarchitect