Open zhilvinas opened 2 years ago
@zhilvinas see #12
Thank you for the reply, the passing comment about 0s being quick to find eluded me. That was silly of me, given I read all previous feedback before posting this... From a curious bystander point of view this feels odd, even suspicious. Perhaps this disparity would be worth highlighting on the website?
It also confusing to me, in #12 is only part answer to your questions, about why it's not filtered before we get it to crunch on.
I have been running the code for a few days. There are periods where the result is returned very quickly, but there are also periods where it takes quite a long time to return even a negative result. My guess is that's just the natural effect the calculation has.
Hey all, just for you to know, we ported an algorithm that does no rigorous prefiltering of intervalls. So, there is a quite large chance that you get unlucky with the intervalls. I am currently redesigning the algorithm in order to be more "rewarding", but that is not an easy task at all. Please stay tuned! And thank you all for your participation.
General observation about which I am quite confused. Runs that successfully find single or multiple triplets take around few minutes to run. The runs that do not find triplets return instantly.
Why is it so? If there is some instant early-out condition that a range will not contain any solutions, why is it even being served as a job? Otherwise I would still expect some number crunching to, well, check the range for solutions?