@mmcdara You wrote:
- You write "This procedure does the same as my Answer above"
The "this" in my sentence that you've quoted is not referring to your procedure; it refers to my procedure that follows in the same Reply. Indeed, this (or its plural these) often refers to something following in the writing, whereas that (when used as a pronoun) (or its plural those) always refers to something preceding in the writing.
- Maple 2015 does not have a procedure equivalent to SumOfDivisors
The equivalent in Maple 2015 (as well as much older Maple) is numtheory:-sigma.
add(map(u -> mul(op(u)), %))*k
To conclude I do not pretend to have done something original.
Actually, that does seem original. However, it's totally infeasible when the number of divisors is large. As I said before, there's a simple formula to compute the sum of the divisors without needing to iterate through them:
#If the prime factorization is
n = Product(p[i]^e[i], i= 1..k);
| | e[i]
n = | | p[i]
i = 1
#then the sum of the divisors is
sigma(n) = Product((p[i]^(e[i]+1) - 1)/(p[i] - 1), i= 1..k);
| | (e[i] + 1)
| | p[i] - 1
sigma(n) = | | ------------------
| | p[i] - 1
i = 1
- I have already be surprised by the results CodeTools:-Usage and I generally use time() instead before and after a loop were the code to test is executed many times.
You are not achieving any benefit by doing that. In particular, you are not overcoming the inaccuracy in the timing that results from caching (a.k.a. memoisation), not to be confused with the processor-based hardware memory caches L1, L2, L3. You should stick with CodeTools.
- Maybe this is also due to this notion of "cache".
"Cache" is ambiguous (see the last paragraph). I am referring to option remember and option cache. If you read the code of ifactor by the following method, you'll see that it uses option remember. (And the difference between these two options is not very relevant to this measurement-of-time issue.)
Note: Reading the code the "normal way" with showstat will not reveal the options.
- Is this mentionned somewhere in the help pages?
I don't recall having seen it. And the help pages (and manuals) have extremely little information about accurately timing Maple code. Everything that I know about it has been learned through experimentation, which I've spent hundreds (perhaps thousands) of hours doing.
I think that these two statements taken together provide a convincing argument that timing a "dumb" repetition of some code is inaccurate in the presence of memoisation. The first of these statements is outright obvious. The second can be easily verified by experiment.
- If some code does not execute the steps needed to perform a computation because it's simply retrieving the results from the last time that it performed the computation, then it's not being accurately timed.
- If code has implemented memoisation, some generic timing procedure is not going to be able to turn that off.