combinat[numbpart](11269);

gives the same answer as Maple 11.

Also, it is interesting to compare timings. Here is the timing in SAGE:

sage: a=[ 11269, 11566, 12376, 12430, 12700, 12754, 15013, 17589, 17797, 18181, 18421, 18453, 18549, 18597, 18885, 18949, 18997, 101269, 501269 ]

sage: time b=[number_of_partitions(n) for n in a]
CPU times: user 0.15 s, sys: 0.00 s, total: 0.15 s
Wall time: 0.15
 

Here are the correct last 2 digits for those who is interested,

sage: for n in b: print n%100,
....:
50 48 86 95 91 45 81 90 83 54 77 59 0 15 35 0 12 65 25
 

The last 2 terms which are terms of the sequence, but not necessarily the next terms, were added by Robert Gerbicz.

One more timing:

sage: time c=number_of_partitions(10^9)
CPU times: user 35.38 s, sys: 0.00 s, total: 35.38 s
Wall time: 35.38
 

I wonder how long it would take Maple to calculate that.

Alec

It appears as though the newer code uses an approximation to Rademacher's series for the partition function. To "fix" it, I modified the exit condition:

numbpart := subs(0.1=0.03, eval(combinat[numbpart])):

With that change, the results for the given values agree with the expected values.

Such procedures, obviously, should be exhaustively tested for all values of n up to the values for which it is possible. And values in this sequence seems to be in the available range (unless the timing is even worse than I expected.)

The absence of such testing makes other similar functions suspicious, too.

Also, it seems as if the exit condition should be not constant, but depending on n, and values of it could be guessed using series of random values of n in various intervals, with exhaustive testing after that.

Another thing seems clear - either the procedure was not reviewed before including it in the released product, or the reviewers did not qualify to do the review.

I wouldn't blame the person who wrote the code - such things usually happen, but the procedure including testing and review should exist to prevent them.

Alec

And here are the SAGE calculations for the updated list of values:

sage: a=[11269, 11566, 12376, 12430, 12700, 12754, 15013, 17589, 17797, 18181, 18421, 18453, 18549, 18597, 18885, 18949, 18997, 20865, 21531, 21721, 21963, 22683, 23421, 23457, 23547, 23691, 23729, 23853, 24015, 24087, 24231, 24339, 24519, 24591, 24627, 24681, 24825, 24933, 25005, 25023, 25059, 25185, 25293, 27020]
sage: b=map(number_of_partitions,a)
sage: print map(lambda n: n%100, b)
[50, 48, 86, 95, 91, 45, 81, 90, 83, 54, 77, 59, 0, 15, 35, 0, 12, 88, 94, 79, 14, 63, 68, 44, 28, 33, 5, 61, 74, 69, 6, 45, 15, 55, 18, 7, 6, 34, 0, 1, 40, 80, 1, 13]
 

Alec

I didn't see the procedure's code. Could it be possible refined for using Compiler:-Compile? The C procedure should be much faster and allow testing for larger values of n. 

Using pentagonal recurrences (for calculating the partition function modulo some number, say 2^32 - in this case the modulus need not to be included - the usual addition would do that automatically in case of overflowing) can be written rather simple in the way that Compiler:-Compile can be used. I'm not sure how far it can go, but probably further than current numbpart, so that could be used for testing, too.

Alec