首先让我们为以后做一些导入：
import Control.Applicative
import Control.Monad
import System.Random
import Data.List hiding (partition)
代码修复
永远记住函数应用的优先级高于中缀运算符：return k1 ++ k2 表示 (return k1) ++ k2 和 round prop * n 表示 (round prop) * n。您可以使用$ 将函数与您应用它的表达式分开，因为f $ x = f x 但$ 的优先级非常低。例如，您可以使用return $ k1 ++ k2。
您的 Ints 和 Doubles 有点混淆了 (round prop * n) 在乘法之前对比例进行四舍五入，但您想先进行乘法运算，因此您需要将 fromIntegral 应用于 n。我为此做了一个单独的函数
(.*) :: Double -> Int -> Int
d .* i = floor $ d * fromIntegral i
所以现在你可以使用(prop .* n) 来代替(round prop * n)。它会稍微清理一下代码，这意味着如果它出错了，我们可以在一个函数中修复它，而不是到处修复。
我提供了一个类型签名以使错误消息更具信息性，并且还提供了第二种基本情况 - 它没有终止，因为有时舍入会导致它要求长度为 0 的列表。
partition1 :: Int -> Int -> IO [Int]
partition1 0 total = return []
partition1 1 total = return [total]
partition1 n total = do
prop <- randomRIO(0.0, 1.0)
k1 <- partition1 (prop .* n) (prop .* total)
k2 <- partition1 (n - (prop .* n)) (total - (prop .* total))
return $ k1 ++ k2
我还冒昧地给它起了一个更具描述性的名字。
获得正确的总数
不幸的是，这可以编译，但正如 Will Ness 在 cmets 中指出的那样，存在一个小故障：它通常会为您提供总计小于总计的数字。事实证明，这是因为您将调用 partition 0 n 以获得非零 n，要求一个长度为 0 且总和为非零的列表。哎呀。
您的算法背后的想法是随机拆分列表和总数，但保持两者的比例相同，以防止分布偏向一边，（原始问题中的问题）。
让我们使用这个想法，但要防止它要求长度为零 - 我们需要 prop 既不是 0 也不是 1。
partition2 :: Int -> Int -> IO [Int]
partition2 0 total = return []
partition2 1 total = return [total]
partition2 n total = do
new_n <- randomRIO(1,n-1)
let prop = fromIntegral new_n / fromIntegral n
k1 <- partition2 new_n (prop .* total)
k2 <- partition2 (n - new_n) (total - (prop .* total))
return $ k1 ++ k2
现在它永远不会给我们错误的总数。万岁！
随机不等于公平
但是哎呀：partition2 18 10000 给了我们
[555,555,555,555,556,556,555,556,556,556,555,555,556,556,555,556,556,556]
问题在于公平与随机不同。这个算法很公平，但不是很随机。让我们让它与长度分开选择比例：
partition3 :: Int -> Int -> IO [Int]
partition3 0 total = return []
partition3 1 total = return [total]
partition3 n total = do
new_n <- randomRIO(1,n-1)
new_total <- randomRIO(0,total) -- it's fine to have zeros.
k1 <- partition3 new_n new_total
k2 <- partition3 (n - new_n) (total - new_total)
return $ k1 ++ k2
看起来更好：partition3 15 20000 给了我
[1134,123,317,725,1031,3897,8089,2111,164,911,25,0,126,938,409]
随机不公平，但也没有偏见
这显然要好得多，但本质上我们所做的二进制分区会引入偏差。
你可以通过查看来测试很多运行
check :: (Int -> Int -> IO [Int]) -> Int -> Int -> Int -> IO ()
check f n total times = mapM_ print =<< map average.transpose.map (righttotal total) <$> replicateM times (f n total)
where average xs = fromIntegral (sum xs)/fromIntegral total
righttotal tot xs | sum xs == tot = xs
| otherwise = error $ "wrong total: " ++ show (sum xs)
check partition3 11 10000 1000 的一次运行给了我
180.7627
97.6642
79.7251
66.9267
64.5253
59.4046
56.9186
66.6599
70.6639
88.9945
167.7545
在不涉及大量测试数据和分析的情况下，尽管这很有趣，但当n 不是total 的一个因素时，不成比例的 0，并且分布不均匀，它是杯形 -该算法最终会在一端塞满数据。
出路
与其一点一点地选择子列表中有多少，让我们生成一个小计将同时结束的所有位置。当然其中一个必须是总数，我们最好在生成它们后对其进行排序。
stopgaps :: Int -> Int -> IO [Int]
stopgaps parts total = sort.(total:) <$> replicateM (parts-1) (randomRIO (0,total))
这里我使用replicateM :: Int -> m a -> m [a]生成正确范围内的parts-1随机数。
我想插入一个无名英雄：
mapAccumL :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y])
用于沿列表累加，生成新列表。
gapsToLengths :: [Int] -> (Int,[Int])
gapsToLengths = mapAccumL between 0
where between previous new = (new,new - previous)
partition4 :: Int -> Int -> IO [Int]
partition4 parts total = snd.gapsToLengths <$> stopgaps parts total
有效吗？
partition4 11 10000 的一些测试运行，打印得很漂亮：
[ 786, 20, 607, 677, 1244, 1137, 990, 50, 1716, 813, 1960]
[ 406, 110, 2556, 126, 1289, 567, 348, 1230, 171, 613, 2584]
[ 368, 1794, 136, 1266, 583, 93, 1514, 66, 1594, 1685, 901]
[ 657, 1296, 1754, 411, 691, 1865, 531, 270, 1941, 286, 298]
[2905, 313, 842, 796, 698, 1104, 82, 1475, 22, 619, 1144]
[1411, 966, 530, 129, 81, 561, 1779, 1179, 301, 607, 2456]
[1143, 409, 903, 27, 855, 354, 887, 1898, 1880, 301, 1343]
[ 260, 643, 96, 323, 142, 74, 401, 977, 3685, 2690, 709]
[1350, 979, 377, 765, 137, 1295, 615, 592, 2099, 1088, 703]
[2411, 958, 330, 1433, 1355, 680, 1075, 41, 988, 81, 648]
这看起来很随机。让我们检查一下没有偏见：
check partition4 11 10000 1000
92.6425
93.4513
92.3544
90.8508
88.0297
91.7731
88.7939
86.5268
86.3502
95.2499
93.9774
终于！