On 7/24/07, James Buddenhagen <jbuddenh@gmail.com> wrote:
I ran your maple code using Maple 7 (the only version I have) on an XP PC with Celeron 2.80 GHz, 504 MB Ram, and n = 173 took 0.21 seconds, and n = 2999 took 59 seconds.
Say 3x slower than on my Mac Powerbook ...
Probably I should have mentioned before (and you could have saved a couple of hours of search time) that (also with Maple 7) I searched up to n = 4000 using the built in Bell in the combinat package finding no Bell-pseudo-primes, and although I didn't time it, it took definitely less than 2 hours.
Now that's a bit strange --- under Maple 9, the library version is noticeably slower than mine, although not badly so. Under Maple 10, it is hopelessly outclassed. Your timings suggest that under Maple 7 it is actually 6x faster! What _is_ going on here, I wonder? Why should anybody have bothered to modify combinat[bell]() at all between versions, let alone substantially degrade it? Or is there some other explanation? By the way --- I am told that there are difficulties with implementations of CAS systems on the Mac G4 and G5 processors, involving the operating system failing fully to exploit the 64-bit hardware --- as well, I suspect, software companies' understandable reluctance to invest in development for a minority architecture. The Magma version of my bell() function --- slightly revised in order to improve efficiency for small n, and portability --- apparently runs 90x faster on a state-of-the-art PC than on my Mac. Sickening, isn't it! This prompts the thought that my cofactor search program (also in Maple) would probably run faster on a PC: currently it has eliminated all n = r q, where q is any prime, and r is any natural < 74. I shan't take up bandwidth with it here; but if anybody requests the code, I'm happy to email it personally. Fred Lunnon