Anonymous user
Talk:N-smooth numbers: Difference between revisions
→Disagreement among implementations: added comments.
(→Disagreement among implementations: fixed the REXX problem.) |
(→Disagreement among implementations: added comments.) |
||
Line 9:
: The output of REXX for the optional sub-task is indeed incorrect, as some of the values are not really p-smooth. One such example is 38123 = 67 * 569. -- [[User:Trizen|Trizen]] ([[User talk:Trizen|talk]]) 09:34, 29 August 2019 (UTC)
:: I found the problem. Once the problem was found, it was so obvious. I don't want to go into the embarrassing details too much, but some of the simplest errors are so easy to overlook. What triggered the ''ah-ha!'' moment was the last line of the 1<sup>st</sup> batch of output, the 10<sup>th</sup> prime (and all others above that) were indexed incorrectly, the program has an internal table of the first nine primes, all higher primes are generated. Pesky little bug, ... the primes were being generated correctly, but their ''indices'' were incorrect, which manifested itself only when indices for primes > 23 were being used. But many thanks for noticing the problem in the output(s). I'm now glad that I put the (high) requirement in. Without those ginormous numbers, the error might not have been detected. Also, I had
|