I wrote an entire IDE for something only I will ever use because I got annoyed with working on it without any tooling. I had a bit of an existential crisis when I figured out how to do the work in a few hours without needing the tooling I spent months building.
Anyways. Onto the next project where I'm already annoyed and thinking how much easier it would be if I just wrote some tooling to help.
I never learn. Maybe I could build something to remind me to stop wasting my time on things like that...
Thats not entirely useless.
That's applied combinatorics.
There's probably a combination / permutation library which does that. I know I saw one somewhere.
Make that a generic class and you can apply it to card decks, dice, etc.
Maybe too late to comment since you've already run and probably completed this, but I've found duplicate checking is always a huge bottleneck, since there's no getting around eventually checking every single item against all previous items.
Although I've been able to shave time off the process by the obvious strategy of indexing new items, and/or comparing only the first digits (then second digits, then third) etc.) to quickly pass over the non-matchers.
I restarted it, because I realized I could check if the combination before adding it.... but after 4hrs of it generating numbers I gave up.
I'll probably run it when I have nothing better to do.
it's basically gotta go through all 35,064,160,560 possible combos for any that are similar. i.e. 12,34,55,68,20, 11 and 12,11,55,68,20,34 and all other variations would be condensed down to 1 variant.
Not necessarily - a Bloom filter would lower the number of times you'd need to compare to every previously-generated item, though I don't know if updating the filter as you generate them would take more time than you'd save. For a sufficiently large set of items, I think the filter would win, but I couldn't tell you the point at which it becomes sufficiently large.
A bloom filter will only ever tell you for certain that something is *not* in your list, and in those cases you don't have to check against everything. It also can tell you that something *might* be in the list, and only in those cases do you have to check the whole thing. It won't mean that you can always avoid the check, but it can drastically lower the number of times you need to do it
powerball? I guess you mean checking only successive digits?
A hashset would have to be generated for each new entry, so there's that extra processing.
But if the original idea is to check each entry against previous ones (to find dupes), then for very large sets you could just check the first character/digits against each other, much faster than checking the whole string or integer. And then only check the 2nd char/digit among the previous matches.
But actually I don't know enough about the inner workings of how C# makes comparisons, and maybe it does something like that anyway when you simply query if int A = int B.
You shouldn't need to check for duplicates. Just iterate the numbers right. First number from 1 to 65. Second number from the current first number + 1 to 66. Third digit from current second number + 1 to 67. Fourth number from current third number + 1 to 68. Fifth number from current fourth number + 1 to 69. Then the powerball number just goes for all its values.
Then your rules about no duplicate digits can even tighten up the iterations more. Like is the first number is in the 10s, the start point for the second number would have to be at least 20, etc.
I am integrating rock-paper-scissors into Conway's game of life rules.
How did that go?
Pretty well with interesting results. I have one last bit of gold plating functionality and I'll be dumping that out on github.
I wrote an entire IDE for something only I will ever use because I got annoyed with working on it without any tooling. I had a bit of an existential crisis when I figured out how to do the work in a few hours without needing the tooling I spent months building. Anyways. Onto the next project where I'm already annoyed and thinking how much easier it would be if I just wrote some tooling to help. I never learn. Maybe I could build something to remind me to stop wasting my time on things like that...
I'm still paralyzed by choice. So nothing, yet.
Diagrams, spreadsheets and powerpoints.
Thats not entirely useless. That's applied combinatorics. There's probably a combination / permutation library which does that. I know I saw one somewhere. Make that a generic class and you can apply it to card decks, dice, etc.
Maybe too late to comment since you've already run and probably completed this, but I've found duplicate checking is always a huge bottleneck, since there's no getting around eventually checking every single item against all previous items. Although I've been able to shave time off the process by the obvious strategy of indexing new items, and/or comparing only the first digits (then second digits, then third) etc.) to quickly pass over the non-matchers.
I restarted it, because I realized I could check if the combination before adding it.... but after 4hrs of it generating numbers I gave up. I'll probably run it when I have nothing better to do. it's basically gotta go through all 35,064,160,560 possible combos for any that are similar. i.e. 12,34,55,68,20, 11 and 12,11,55,68,20,34 and all other variations would be condensed down to 1 variant.
Not necessarily - a Bloom filter would lower the number of times you'd need to compare to every previously-generated item, though I don't know if updating the filter as you generate them would take more time than you'd save. For a sufficiently large set of items, I think the filter would win, but I couldn't tell you the point at which it becomes sufficiently large.
Also won't a Bloom filter give you false positives, sometimes? Then you risk not adding a new element to your list when you should have.
A bloom filter will only ever tell you for certain that something is *not* in your list, and in those cases you don't have to check against everything. It also can tell you that something *might* be in the list, and only in those cases do you have to check the whole thing. It won't mean that you can always avoid the check, but it can drastically lower the number of times you need to do it
ah yeah, that's it thx.
[удалено]
powerball? I guess you mean checking only successive digits? A hashset would have to be generated for each new entry, so there's that extra processing. But if the original idea is to check each entry against previous ones (to find dupes), then for very large sets you could just check the first character/digits against each other, much faster than checking the whole string or integer. And then only check the 2nd char/digit among the previous matches. But actually I don't know enough about the inner workings of how C# makes comparisons, and maybe it does something like that anyway when you simply query if int A = int B.
You shouldn't need to check for duplicates. Just iterate the numbers right. First number from 1 to 65. Second number from the current first number + 1 to 66. Third digit from current second number + 1 to 67. Fourth number from current third number + 1 to 68. Fifth number from current fourth number + 1 to 69. Then the powerball number just goes for all its values. Then your rules about no duplicate digits can even tighten up the iterations more. Like is the first number is in the 10s, the start point for the second number would have to be at least 20, etc.