And here I thought you wanted some input on your "New play methodology"... Well its not "New"... I have been using things similar to what you think is new for over 15 years... I guess I will just say that you may be on the right track...
Does GH software use custom made wheels based on sums as well? If not then it doesn't come even close to what I'm doing. I don't select any numbers, use wheels only based on sums. All wheels have all the numbers. And these wheels performance is the basis for playing selections, not any relationships between sums.
BTW, to answer my own question from the post above (I guess GH software did not have the answer) these 2 wheels were played:
S154-T15-wheel(16) & S160-T15-wheel(5). They come from different sums. Maybe GH software can find a relationship between these sums because I've got no clue. They were selected due to their ROIs and ROIs are not sum but generated cash, related.
Therefore, if GH software allows generating custom wheels (of any size) containing all the numbers for any sum, and computing their ROIs it could be of some use to me. But I suspect it cannot and thus is completely useless to me. Therefore, there is no connection between my methodology and GH software.
And, regarding things you've been using for over 15 years, any more details on that? I was quite explicit with details about my methodology. Just for comparison...
I use GH software to sanity check some basic algorithms I cooked up along the way...
I use ROI from actual play for this check. Percents displayed in the post above are such ROI checks.
BTY, I smalltalk with a lisp and carry a big class library, also prototype with R... Pythons got nothing on Lisp...
But as long as it helps to generate cash it's good enough for me. Lottery data processing does not require sophisticated processing. But, if it does, I would like to see statistical comparison.
P.S. Looks like your "I play sums from 135 to 165" is approximately the average between the GH middle two sums range...
Actually, this is not precisely how I arrived at the range of sums 135 to 165. Below is the list of most populous sums in 649. I took only those with 150 K or more members. Whatever other relationships betweens these sums were never of any concern.
150 - 165772
149 - 165732
151 - 165732
148 - 165490
152 - 165490
147 - 165176
153 - 165176
146 - 164654
154 - 164654
145 - 164062
155 - 164062
144 - 163273
156 - 163273
143 - 162410
157 - 162410
142 - 161354
158 - 161354
141 - 160236
159 - 160236
140 - 158923
160 - 158923
139 - 157554
161 - 157554
138 - 156004
162 - 156004
137 - 154397
163 - 154397
136 - 152617
164 - 152617
135 - 150794
165 - 150794
Because there are result similarities from independent (and trivial) computations this does not imply that one must come from the other.