共被编辑 15 次
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，比较有意思的是像一种时间线流动一样，从最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，你也永远无法知道下一个数是什么。
这里满足四个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选4.总金额100分为10个人
m为总金额,n为人数，min选择下限，max为选择上限,用方程式
方程式为 min &= (m-x-z)/(n-y-1) &= max，配平就可以
下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
#encoding=utf8
from random import uniform
def flag(m, n, min, max):
for i in range(n):
bottom = 6
if not m-x-min*(n-y-1) &= 12:
top = m-x-min*(n-y-1)
if not m-x-max*(n-y-1) &= 6:
bottom = m-x-max*(n-y-1)
next = uniform(bottom, top)
L.append(next)
print flag(100, 10, 6, 12)
print sum(flag(100, 10, 6, 12))
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。这里在随机前进行判断来缩小区间，比随即后判断是否满足条件要好那是因为，选择出来的数符合逐渐变小的区间可能性会越来越低，结果在数据规模更大时，性能会下降严重。而先判断出上下区间则保证整个计算过程长度不变，都是常数级。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
=================
更新，有评论提到越后抽越多money的问题，是的：
这个是因为人均10元，下限6元比平均低4元，上限12元才高2元，不对称同时金额分10人最高只有12这个空间“拉得很紧”，所以前三个都是100%在6~12所以无问题，后面就出问题了。这样有一个问题，就是出现了明显的规律，越后面越可能大。
毕竟这里均值达到10，每抽到1个人抽到6就需要2个人抽到12来弥补，所以要么让它更为集中到10，要么分散到2端，同时后面那端要比前者的高很多，而均匀分布是不可能的。因为这里涉及到红包，红包分定额和随机两种。集中分布可以说是固定金额的近似值，所以一定要做两端分布，两端分布可以在区间随机前对区间进行权重选择再随机就能操控，另外，也可以每次随机都生成10次数据，然后再从中抽取一个出来，其他删掉，第二个人抽再根据第一个数据生成第二个数列一直到结束，就能做到“分布均匀”，但题目中的数据限制还是很多人会抽到很大的数，的确在所难免。
集中化只要为每个数据根据它的位置乘上相关系数解决。或者直接设为10，然后设定“随机抖动”= = 。
因为数学的好处所以这个性能完全是常数级的，执行步数每次都是一样的，不存在要把自己的算法的性能也连同一起和所需生成的数据一起来随机玩概率的问题。所以想要两端分布同时随机分布这里可以在最后生成的答案里加上随机选一个就能达到效果。但算法之外是这个抢红包的问题，到底是集中还是分散分布？或许很多人抢时最后的红包才大还是好事情，抢早了，红包小了，迟了，被抢光了，最后一个是最危险的也是概率上金额最大的那一个，有意思不？或者说，我喜欢平均一点，既要和某人玩随机金额才刺激，还要避免某人抽得太小而尴尬？所以最后还得看实际需求怎样才能决定。
PS：看到题主的评论，题主的思路有人提到是随机到6块这种的概率很低，假如真的如此（偷懒没试过），那算法直觉就是集中化趋势的过程了。没有好坏，只是看需求如何。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，比较有意思的是像一种时间线流动一样，从最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，你也永远无法知道下一个数是什么。
这里满足四个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选4.总金额100分为10个人
m为总金额,n为人数，min选择下限，max为选择上限,用方程式
方程式为 min &= (m-x-z)/(n-y-1) &= max，配平就可以
下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
#encoding=utf8
from random import uniform
def flag(m, n, min, max):
for i in range(n):
bottom = 6
if not m-x-min*(n-y-1) &= 12:
top = m-x-min*(n-y-1)
if not m-x-max*(n-y-1) &= 6:
bottom = m-x-max*(n-y-1)
next = uniform(bottom, top)
L.append(next)
print flag(100, 10, 6, 12)
print sum(flag(100, 10, 6, 12))
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。这里在随机前进行判断来缩小区间，比随即后判断是否满足条件要好那是因为，选择出来的数符合逐渐变小的区间可能性会越来越低，结果在数据规模更大时，性能会下降严重。而先判断出上下区间则保证整个计算过程长度不变，都是常数级。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
=================
更新，有评论提到越后抽越多money的问题，是的：
这个是因为人均10元，下限6元比平均低4元，上限12元才高2元，不对称同时金额分10人最高只有12这个空间“拉得很紧”，所以前三个都是100%在6~12所以无问题，后面就出问题了。这样有一个问题，就是出现了明显的规律，越后面越可能大。
毕竟这里均值达到10，每抽到1个人抽到6就需要2个人抽到12来弥补，所以要么让它更为集中到10，要么分散到2端，同时后面那端要比前者的高很多，而均匀分布是不可能的。因为这里涉及到红包，红包分定额和随机两种。集中分布可以说是固定金额的近似值，所以一定要做两端分布，两端分布可以在区间随机前对区间进行权重选择再随机就能操控，另外，也可以每次随机都生成10次数据，然后再从中抽取一个出来，其他删掉，第二个人抽再根据第一个数据生成第二个数列一直到结束，就能做到“分布均匀”，但题目中的数据限制还是很多人会抽到很大的数，的确在所难免。
集中化只要为每个数据根据它的位置乘上相关系数解决。或者直接设为10，然后设定“随机抖动”= = 。
因为数学的好处所以这个性能完全是常数级的，多少步能count，不存在“暴力”。所以想要两端分布同时随机分布这里可以在最后生成的答案里加上随机选一个就能达到效果。但算法之外是这个抢红包的问题，到底是集中还是分散分布？或许很多人抢时最后的红包才大还是好事情，抢早了，红包小了，迟了，被抢光了，最后一个是最危险的也是概率上金额最大的那一个，有意思不？或者说，我喜欢平均一点，既要和某人玩随机金额才刺激，还要避免某人抽得太小而尴尬？所以最后还得看实际需求怎样才能决定。
PS：看到题主的评论，题主的思路有人提到是随机到6块这种的概率很低，假如真的如此（偷懒没试过），那算法直觉就是集中化趋势的过程了。没有好坏，只是看需求如何。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，比较有意思的是像一种时间线流动一样，从最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，你也永远无法知道下一个数是什么。
这里满足四个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选4.总金额100分为10个人
m为总金额,n为人数，min选择下限，max为选择上限,用方程式
方程式为 min &= (m-x-z)/(n-y-1) &= max，配平就可以
下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
#encoding=utf8
from random import uniform
def flag(m, n, min, max):
for i in range(n):
bottom = 6
if not m-x-min*(n-y-1) &= 12:
top = m-x-min*(n-y-1)
if not m-x-max*(n-y-1) &= 6:
bottom = m-x-max*(n-y-1)
next = uniform(bottom, top)
L.append(next)
print flag(100, 10, 6, 12)
print sum(flag(100, 10, 6, 12))
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。这里在随机前进行判断来缩小区间，比随即后判断是否满足条件要好那是因为，选择出来的数符合逐渐变小的区间可能性会越来越低，结果在数据规模更大时，性能会下降严重。而先判断出上下区间则保证整个计算过程长度不变，都是常数级。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
=================
更新，有评论提到越后抽越多money的问题，是的：
这个是因为人均10元，下限6元比平均低4元，上限12元才高2元，不对称同时金额分10人最高只有12这个空间“拉得很紧”，所以前三个都是100%在6~12所以无问题，后面就出问题了。这样有一个问题，就是出现了明显的规律，越后面越可能大。
毕竟这里均值达到10，每抽到1个人抽到6就需要2个人抽到12来弥补，所以要么让它更为集中到10，要么分散到2端，同时后面那端要比前者的高很多，而均匀分布是不可能的。因为这里涉及到红包，红包分定额和随机两种。集中分布可以说是固定金额的近似值，所以一定要做两端分布，两端分布可以在区间随机前对区间进行权重选择再随机就能操控，另外，也可以每次随机都生成10次数据，然后再从中抽取一个出来，其他删掉，第二个人抽再根据第一个数据生成第二个数列一直到结束，就能做到“分布均匀”，但题目中的数据限制还是很多人会抽到很大的数，的确在所难免。
集中化只要为每个数据根据它的位置乘上相关系数解决。或者直接设为10，然后设定“随机抖动”= = 。
因为数学的好处所以这个性能完全是常数级的，多少步能count，不存在“暴力”。所以想要两端分布同时随机分布这里可以在最后生成的答案里加上随机选一个就能达到效果。但算法之外是这个抢红包的问题，到底是集中还是分散分布？或许很多人抢时最后的红包才大还是好事情，抢早了，红包小了，迟了，被抢光了，最后一个是最危险的也是概率上金额最大的那一个，有意思不？或者说，我喜欢平均一点，既要和某人玩随机金额才刺激，还要避免某人抽得太小而尴尬？所以最后还得看实际需求怎样才能决定。
PS：看到题主的评论，题主的思路有人提到是随机到6块这种的概率很低，假如真的如此（偷懒没试过），那就是集中化趋势的过程了。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，比较有意思的是像一种时间线流动一样，从最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，你也永远无法知道下一个数是什么。
这里满足四个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选4.总金额100分为10个人
m为总金额,n为人数，min选择下限，max为选择上限,用方程式
方程式为 min &= (m-x-z)/(n-y-1) &= max，配平就可以
下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
#encoding=utf8
from random import uniform
def flag(m, n, min, max):
for i in range(n):
bottom = 6
if not m-x-min*(n-y-1) &= 12:
top = m-x-min*(n-y-1)
if not m-x-max*(n-y-1) &= 6:
bottom = m-x-max*(n-y-1)
next = uniform(bottom, top)
L.append(next)
print flag(100, 10, 6, 12)
print sum(flag(100, 10, 6, 12))
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。这里在随机前进行判断来缩小区间，比随即后判断是否满足条件要好那是因为，选择出来的数符合逐渐变小的区间可能性会越来越低，结果在数据规模更大时，性能会下降严重。而先判断出上下区间则保证整个计算过程长度不变，都是常数级。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
=================
更新，有评论提到越后抽越多money的问题，是的：
这个是因为人均10元，下限6元比平均低4元，上限12元才高2元，不对称同时金额分10人最高只有12这个空间“拉得很紧”，所以前三个都是100%在6~12所以无问题，后面就出问题了。这样有一个问题，就是出现了明显的规律，越后面越可能大。
毕竟这里均值达到10，每抽到1个人抽到6就需要2个人抽到12来弥补，所以要么让它更为集中到10，要么分散到2端，同时后面那端要比前者的高很多，而均匀分布是不可能的。因为这里涉及到红包，红包分定额和随机两种。集中分布可以说是固定金额的近似值，所以一定要做两端分布，两端分布可以在区间随机前对区间进行权重选择再随机就能操控，另外，也可以每次随机都生成10次数据，然后再从中抽取一个出来，其他删掉，第二个人抽再根据第一个数据生成第二个数列一直到结束，就能做到“分布均匀”，但题目中的数据限制还是很多人会抽到很大的数，的确在所难免。
集中化只要为每个数据根据它的位置乘上相关系数解决。或者直接设为10，然后设定“随机抖动”= = 。
因为数学的好处所以这个性能完全是常数级的，多少步能count，不存在“暴力”。所以想要两端分布同时随机分布这里可以在最后生成的答案里加上随机选一个就能达到效果。但算法之外是这个抢红包的问题，到底是集中还是分散分布？或许很多人抢时最后的红包才大还是好事情，抢早了，红包小了，迟了，被抢光了，最后一个是最危险的也是概率上金额最大的那一个，有意思不？或者说，我喜欢平均一点，既要和某人玩随机金额猜刺激，还要避免某人抽得太小而尴尬？所以最后还得看实际需求怎样才能决定。
PS：看到题主的评论，题主的思路有人提到是随机到6块这种的概率很低，假如真的如此（偷懒没试过），那就是集中化趋势的过程了。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，比较有意思的是像一种时间线流动一样，从最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，你也永远无法知道下一个数是什么。
这里满足四个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选4.总金额100分为10个人
m为总金额,n为人数，min选择下限，max为选择上限,用方程式
方程式为 min &= (m-x-z)/(n-y-1) &= max，配平就可以
下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
#encoding=utf8
from random import uniform
def flag(m, n, min, max):
for i in range(n):
bottom = 6
if not m-x-min*(n-y-1) &= 12:
top = m-x-min*(n-y-1)
if not m-x-max*(n-y-1) &= 6:
bottom = m-x-max*(n-y-1)
next = uniform(bottom, top)
L.append(next)
print flag(100, 10, 6, 12)
print sum(flag(100, 10, 6, 12))
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。这里在随机前进行判断来缩小区间，比随即后判断是否满足条件要好那是因为，选择出来的数符合逐渐变小的区间可能性会越来越低，结果在数据规模更大时，性能会下降严重。而先判断出上下区间则保证整个计算过程长度不变，都是常数级。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
=================
更新，有评论提到越后抽越多money的问题，是的：
这个是因为人均10元，下限6元比平均低4元，上限12元才高2元，不对称同时金额分10人最高只有12这个空间“拉得很紧”，所以前三个都是100%在6~12所以无问题，后面就出问题了。这样有一个问题，就是出现了明显的规律，越后面越可能大。
毕竟这里均值达到10，每抽到1个人抽到6就需要2个人抽到12来弥补，所以要么让它更为集中到10，要么分散到2端，同时后面那端要比前者的高很多，而均匀分布是不可能的。因为这里涉及到红包，红包分定额和随机两种。集中分布可以说是固定金额的近似值，所以一定要做两端分布，两端分布可以在区间随机前对区间进行权重选择再随机就能操控，另外，也可以每次随机都生成10次数据，然后再从中抽取一个出来，其他删掉，第二个人抽再根据第一个数据生成第二个数列一直到结束，就能做到“分布均匀”，但题目中的数据限制还是很多人会抽到很大的数，的确在所难免。
集中化只要为每个数据根据它的位置乘上相关系数解决。或者直接设为10，然后设定“随机抖动”= = 。
因为数学的好处所以这个性能完全是常数级的，多少步能count，不存在“暴力”。所以想要两端分布同时随机分布这里可以在最后生成的答案里加上随机选一个就能达到效果。但算法之外是这个抢红包的问题，到底是集中还是分散分布？或许很多人抢时最后的红包才大还是好事情，抢早了，红包小了，迟了，被抢光了，最后一个也是最危险的也是可能最大的那一个。或者说，我喜欢平均一点？最后还得看实际需求怎样才能决定。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，比较有意思的是像一种时间线流动一样，从最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，你也永远无法知道下一个数是什么。
这里满足四个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选4.总金额100分为10个人
m为总金额,n为人数，min选择下限，max为选择上限,用方程式
方程式为 min &= (m-x-z)/(n-y-1) &= max，配平就可以
下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
#encoding=utf8
from random import uniform
def flag(m, n, min, max):
for i in range(n):
bottom = 6
if not m-x-min*(n-y-1) &= 12:
top = m-x-min*(n-y-1)
if not m-x-max*(n-y-1) &= 6:
bottom = m-x-max*(n-y-1)
next = uniform(bottom, top)
L.append(next)
print flag(100, 10, 6, 12)
print sum(flag(100, 10, 6, 12))
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。这里在随机前进行判断来缩小区间，比随即后判断是否满足条件要好那是因为，选择出来的数符合逐渐变小的区间可能性会越来越低，结果在数据规模更大时，性能会下降严重。而先判断出上下区间则保证整个计算过程长度不变，都是常数级。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
=================
更新，有评论提到越后抽越多money的问题，是的：
这个是因为人均10元，下限6元比平均低4元，上限12元才高2元，不对称同时金额分10人最高只有12这个空间“拉得很紧”，所以前三个都是100%在6~12所以无问题，后面就出问题了。这样有一个问题，就是出现了明显的规律，越后面越可能大。
毕竟这里均值达到10，每抽到1个人抽到6就需要2个人抽到12来弥补，所以要么让它更为集中到10，要么分散到2端，同时后面那端要比前者的高很多，而均匀分布是不可能的。因为这里涉及到红包，红包分定额和随机两种。集中分布可以说是固定金额的近似值，所以一定要做两端分布，两端分布可以在区间随机前对区间进行权重选择再随机就能操控，另外，也可以每次随机都生成10次数据，然后再从中抽取一个出来，其他删掉，第二个人抽再根据第一个数据生成第二个数列一直到结束，就能做到“分布均匀”，但题目中的数据限制还是很多人会抽到很大的数，的确在所难免。
集中化只要为每个数据根据它的位置乘上相关系数解决。或者直接设为10，然后设定“随机抖动”= = 。
因为数学的好处所以这个性能完全是常数级的，多少步能count，不存在“暴力”。所以想要两端分布同时随机分布这里可以在最后生成的答案里加上随机选一个就能达到效果。但算法之外是这个抢红包的问题，到底是集中还是分散分布？或许很多人抢时最后的红包才大还是好事情，抢早了，红包小了，迟了，被抢光了，最后一个也是最危险的也是可能最大的那一个。或者说，我喜欢平均一点？最后还得看实际需求怎样才能决定。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，比较有意思的是像一种时间线流动一样，从最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，你也永远无法知道下一个数是什么。
这里满足四个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选4.总金额100分为10个人
m为总金额,n为人数，min选择下限，max为选择上限,用方程式
方程式为 min &= (m-x-z)/(n-y-1) &= max，配平就可以
下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
#encoding=utf8
from random import uniform
def flag(m, n, min, max):
for i in range(n):
bottom = 6
if not m-x-min*(n-y-1) &= 12:
top = m-x-min*(n-y-1)
if not m-x-max*(n-y-1) &= 6:
bottom = m-x-max*(n-y-1)
next = uniform(bottom, top)
L.append(next)
print flag(100, 10, 6, 12)
print sum(flag(100, 10, 6, 12))
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。这里在随机前进行判断来缩小区间，比随即后判断是否满足条件要好那是因为，选择出来的数符合逐渐变小的区间可能性会越来越低，结果在数据规模更大时，性能会下降严重。而先判断出上下区间则保证整个计算过程长度不变，都是常数级。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，比较有意思的是像一种时间线流动一样，从最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，你也永远无法知道下一个数是什么。
这里满足四个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选4.总金额100分为10个人
以此建立方程式，x为已经抽取的数值,y为已经抽取的人数,z为下一个人抽取的金额数
方程式为 6 &= (100-x-z)/(10-y-1) &= 12，配平就可以
下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
from random import uniform
def random():
for i in range(10):
bottom = 6
if not (46-x+6*y) &= 12:
top = (46-x+6*y)
if not (-x+12*y-8) &= 6:
bottom = (-x+12*y-8)
next = uniform(bottom, top)
L.append(next)
print sum(L)
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，比较有意思的是像一种时间线流动一样，从最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，你也永远无法知道下一个数是什么。
这里满足四个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选4.总金额100分为10个人
以此建立方程式，x为已经抽取的数值,y为已经抽取的人数,z为下一个人抽取的金额数
方程式为 6 &= (100-x-z)/(10-y-1) &= 12，配平就可以
下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
from random import uniform
def random():
for i in range(10):
bottom = 6
if (46-x+6*y) &= 12:
top = (46-x+6*y)
if (-x+12*y-8) &= 6:
bottom = 6
bottom = (-x+12*y-8)
next = uniform(bottom, top)
L.append(next)
SUM += next
print sum(L)
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，比较有意思的是像一种时间线流动一样，从最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，你也永远无法知道下一个数是什么，但最后会不断缩短然后算出来最后一个值的上下限恰好相等。
这里满足四个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选4.总金额100分为10个人
以此建立方程式，根据最上面对x和y的描述建立。下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
from random import uniform
def random():
for i in range(10):
bottom = 6
if (46-x+6*y) &= 12:
top = (46-x+6*y)
if (-x+12*y-8) &= 6:
bottom = 6
bottom = (-x+12*y-8)
next = uniform(bottom, top)
L.append(next)
SUM += next
print sum(L)
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，比较有意思的是像一种时间线流动一样，从最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，你也永远无法知道下一个数是什么，但最后会不断缩短然后算出来最后一个值的上下限恰好相等。
这里满足三个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选
以此建立方程式，根据最上面对x和y的描述建立。下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
from random import uniform
def random():
for i in range(10):
bottom = 6
if (46-x+6*y) &= 12:
top = (46-x+6*y)
if (-x+12*y-8) &= 6:
bottom = 6
bottom = (-x+12*y-8)
next = uniform(bottom, top)
L.append(next)
SUM += next
print sum(L)
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到的金额接近总体平均值，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。所以用图来描述这个动态区间，最底三层都是6~12,6~12,6~12，然后后面会随着具体的数值发生变化，但最后会不断缩短然后算出来最后一个值的上下限恰好相等。
这里满足三个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选
以此建立方程式，根据最上面对x和y的描述建立。下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
from random import uniform
def random():
for i in range(10):
bottom = 6
if (46-x+6*y) &= 12:
top = (46-x+6*y)
if (-x+12*y-8) &= 6:
bottom = 6
bottom = (-x+12*y-8)
next = uniform(bottom, top)
L.append(next)
SUM += next
print sum(L)
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到中间树，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。
这里满足三个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选
以此建立方程式，根据最上面对x和y的描述建立。下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽，位数采用默认的很多位小数，根据实际情况再进行削减）
from random import uniform
def random():
for i in range(10):
bottom = 6
if (46-x+6*y) &= 12:
top = (46-x+6*y)
if (-x+12*y-8) &= 6:
bottom = 6
bottom = (-x+12*y-8)
next = uniform(bottom, top)
L.append(next)
SUM += next
print sum(L)
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到中间树，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。
这里满足三个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选
以此建立方程式，根据最上面对x和y的描述建立。下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：（我的代码写得很不pythonic请不要吐槽）
from random import uniform
def random():
for i in range(10):
bottom = 6
if (46-x+6*y) &= 12:
top = (46-x+6*y)
if (-x+12*y-8) &= 6:
bottom = 6
bottom = (-x+12*y-8)
next = uniform(bottom, top)
L.append(next)
SUM += next
print sum(L)
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。另外红包派不完的情况下，我无需去记录已经分配好的模式又在过期后对它进行删除的操作。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
X为已经抽取的数值Y为已经抽取的人数
思路：因为100块分10个人，可选范围是6到12。所以可以随机地在6~12分给全部人就可以了。但可能会出现派不完或者不够分的情况，所以实际上每个人的选择区间不一定是6~12，也取决于先抽到钱的人。假如他们都抽到中间树，那么这个区间就会保持在6~12，假如连续开头三个人都抽到6，那么第四个人的区间就会缩小，下限会提高。然而一旦她抽到了12，又会让下一位的选择区间变大了一点。但总体来看，越接近尾声，选择区间会缩小，直到最后一个人选择时，他的选择上限和下限是恰好相等的。
这里满足三个条件：1.剩余金额除以人数不能大于122.剩余金额除以人数不能小于63.每个人都只能在6~12里选
以此建立方程式，根据最上面对x和y的描述建立。下面是已经配平的式子，式子分别为上限和下限。上限可大于12时，配成12，否则保留。下限同理。
我不懂php，用python来代替：
from random import uniform
def random():
for i in range(10):
bottom = 6
if (46-x+6*y) &= 12:
top = (46-x+6*y)
if (-x+12*y-8) &= 6:
bottom = 6
bottom = (-x+12*y-8)
next = uniform(bottom, top)
L.append(next)
SUM += next
print sum(L)
优点是，我得出下一位数永远时即时运算的，它不是得出一个既定的组合，然后再分配给每一个人。而是根据前面的情况，即时产生下一个结果。在具体用户上，当然是没有区别，但我在思考红包这个玩意的时候，也很自然觉得要是提前分好一个模式给我，那其实下一个数是什么早有了定论，程序员log一下就能知道是什么，那样就不好玩了。
缺点是，如果不作另外的解释和运算，根本不知道上面这是在算什么，思路也不明了。
我要该，理由是：