Partition function P: Difference between revisions

m
m (→‎{{header|Raku}}: minor style tweaks, remove some unnecessary reification)
m (→‎{{header|Wren}}: Minor tidy)
 
(5 intermediate revisions by 2 users not shown)
Line 3:
 
 
The [https://mathworld.wolfram.com/PartitionFunctionP.html Partition Function P], oftenis the notatedfunction P(n), iswhere n∈ℤ, defined as the number of solutionsdistinct whereways n∈ℤin which n can be expressed as the sum of a set ofnon-increasing positive integers.
 
 
Line 15:
The successive numbers in the above equation have the differences:   1, 3, 2, 5, 3, 7, 4, 9, 5, 11, 6, 13, 7, 15, 8 ...
 
This task may be of popular interest because [https://www.youtube.com/channel/UC1_uAIS3r8Vu6JjXWvastJg Mathologer] made the video, [https://www.youtube.com/watch?v=iJ8pnCO0nTY The hardest "What comes next?" (Euler's pentagonal formula)], where he asks the programmers among his viewers to calculate P(666). The video has beenwas viewed more than 100,000 times in the first couple of weeks sinceafter its release.
 
In Wolfram Language, this function has been implemented as PartitionsP.
Line 906:
<pre>[1,2,3,5,7,11,15,22,30,42,56,77,101,135]</pre>
 
Using gojq 0.12.11, `partitions(6666)` yields (in about 12 minutes (u+s) on a 3GHz machine):
jq's built-in integer precision is insufficient for computing ``partitions(6666)``, but more as a test
 
of the BigInt.jq library for jq than anything else, here are the results of using it in conjunction
193655306161707661080005073394486091998480950338405932486880600467114423441282418165863
 
jq's built-inThe integer precision of the C implementation of jq is insufficient for computing ``partitions(6666)``, but more as a test
of the BigInt.jq library for jq than anything else, here are the results of using it in conjunction
with a trivially-modified version of the ''partitions'' implementation above. That is, after
modifying the lines that refer to "p" (or ".p"), we see that ''partitions(6666)'' yields:
Line 913 ⟶ 917:
"193655306161707661080005073394486091998480950338405932486880600467114423441282418165863"
 
TheCuriously, userthe u+syss time is 7m3s, which is significantly less than the above-mentioned gojq time, even asthough the BigInt.jq library is written in jq.
 
=== Recursive ===
{{trans|Julia}} with memoization
<syntaxhighlight lang="jq">def partDiffDiff($n):
Line 1,427 ⟶ 1,431:
In [4]: %timeit partitions(6666)
215 ms ± 1.84 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
</pre>
 
=={{header|Quackery}}==
 
<code>0 partitions</code> returns <code>1</code> as per [https://oeis.org/A000041 oeis.org/A000041 (Partitions of n)].
 
This is a naive recursive solution, so computing the partitions of 6666 would take a hideously long time.
 
<syntaxhighlight lang="Quackery"> [ 1 swap
dup 0 = iff drop done
[ 2dup = iff [ 2drop 1 ] done
2dup > iff [ 2drop 0 ] done
2dup dip 1+ recurse
unrot over - recurse + ] ] is partitions ( n --> n )
say "Partitions of 0 to 29" cr
30 times [ i^ partitions echo sp ]
</syntaxhighlight>
 
{{out}}
 
<pre>Partitions of 0 to 29
1 1 2 3 5 7 11 15 22 30 42 56 77 101 135 176 231 297 385 490 627 792 1002 1255 1575 1958 2436 3010 3718 4565
</pre>
 
Line 1,764 ⟶ 1,791:
{{libheader|Wren-big}}
Although it may not look like it, this is actually a decent time for Wren which is interpreted and the above module is written entirely in Wren itself.
<syntaxhighlight lang="ecmascriptwren">import "./big" for BigInt
 
var p = []
9,482

edits