分析设计高手进来

时间:2022-08-28 16:41:21
这两天有个问题把我搞得乱糟糟的,到现在还是思维杂乱中。忽然想到应该来这里问问高手们啊。

问题看起来容易,可是细想也会挺复杂的,请大家考虑全面点哦:

前提:
A,B,C,D四个对象。
A,B可以生产I,II,III三个产品,有公式f(a,b,c)可以计算其总耗。
C,D可以生产I,II两个产品,有公式f(a,b)可以计算其总耗。
每个对象有两种状态:正常,故障。
正常状态时若对象分摊到I或II或III的生产,则都有一个最小生产量IminA,IminB,IminC,IminD,IIminA,IIminB,IIminC,IIminD,IIIminA,IIIminB和最大生产量ImaxA,ImaxB,ImaxC,ImaxD,IImaxA,IImaxB,IImaxC,IImaxD,IIImaxA,IIImaxB,即其产值或是0或是介于最小生产量和最大生产量(包括端点)之间。

要求:
输入要生产的总的I、II、III,把所有可能的分配方案列出来,并计算出总耗。虽然是想求最优化的方案(即总耗最低的),但因为有时最优化的方案未必是用户根据实际诸多因素最想采取的方案,所以还是把所有组合按总耗排序列出来让用户选择的好,程序只起参考作用。
排序部分很容易实现,不需要大家分神考虑了,现在就需要一个高效而准确的所有可能方案的产生。

问题:
一般的想法是作个7层的简单循环嵌套,但是耗时巨长,所以要充分考虑一些潜在筛选条件才能争取较快地得到所有方案。如当Ia在未超出A所允许的I的最大生产量IMaxA,但已超过所想生产的总的I时就不必继续其他循环了。
为什么是7层而不是10层,因为略去了一层I一层II和一层III循环,大家知道循环嵌套一层就是加大一个几何级,300^10 是个什么概念? 所以能减则减,就用I-Ia-Ib-Ic得到Id省去Id的循环,同理省去IId和IIIb的循环。

增加复杂的因素1:嵌套顺序。
考虑:
当I=13,而Id最大值ImaxD=6,最小值IminD=1时
for Ia=0 to 5
   for Ib=0 to 3
      for Ic=0 to 2
          Id=I-Ia-Ib-Ic    ’实际到Id时的计算得值范围为13到3
          if Id>ImaxD then exit for  ’大于6的略去
          ....       '但是因为Id排在嵌套较里层,因此最终到3为止,而没能算到其真正的最小值,即丢失一部分区间。如果它排在外层自然不会这样,但另一个排在里层的也会如此。

增加复杂的因素2:是否故障状态
如果故障,则只取生产值0,而不必再从最小值到最大值(或反向)循环,还是因为循环嵌套的层数问题,即使是空循环体的七层循环也要20多分钟。但是也不能简单地跳出循环,对于最里层的循环体还可以跳出,但外层的不可以,因为因为它的故障一跳出就使其它正常的对象也无法执行到了。那么如何才能既很好地利用工作状态来减少不必要的循环数量,又使每个故障的对象不会影响到其它的对象参与组合呢??

大家先想,如果觉得还不明确,明天我把代码贴上一点,肯定是不理想的代码,大家修正补充一下,让它达到要求。

5 个解决方案

#1


早上忽然来了灵感,故障状态的因素已经解决了,可以不管它。

 排在里层的变量可能丢失一部分区间这个问题虽然可以如下解决:
  在大循环后面判断I-ImaxA-ImaxB-ImaxC是否大于0()
  若大于0,则把里层的Id提到外部从0到I-ImaxA-ImaxB-ImaxC循环,再按上面循环形式写一遍就能补全那部分区间了。
 这种方法我一直不满意,我不喜欢大片大片的代码,而最好是精简高效的形式。

 其实关于故障状态的解决算是一个关键点。现在感觉问题清晰很多。不过不知道还有没有更好的写法,希望各位大侠勇于出手。
 往往简单的问题可以有巨大的应用。

#2


我就喜欢搞算法的问题,不过对你的说明我没有搞明白,email联系吧:lindagroup@126.com,把你的代码附上,同时把本页的地址也说明一下,我记性不太好的。

#3


不太明确,代码贴上一点看看

#4


问题太长了,看不明白,帮你顶吧

#5


感觉遗传算法比较合适。遗传算法耗时很短,所得的结果很接近最理想的值,但是多次运行的结果通常不一样,一般情况下不会得到精确的最理想的值。

#1


早上忽然来了灵感,故障状态的因素已经解决了,可以不管它。

 排在里层的变量可能丢失一部分区间这个问题虽然可以如下解决:
  在大循环后面判断I-ImaxA-ImaxB-ImaxC是否大于0()
  若大于0,则把里层的Id提到外部从0到I-ImaxA-ImaxB-ImaxC循环,再按上面循环形式写一遍就能补全那部分区间了。
 这种方法我一直不满意,我不喜欢大片大片的代码,而最好是精简高效的形式。

 其实关于故障状态的解决算是一个关键点。现在感觉问题清晰很多。不过不知道还有没有更好的写法,希望各位大侠勇于出手。
 往往简单的问题可以有巨大的应用。

#2


我就喜欢搞算法的问题,不过对你的说明我没有搞明白,email联系吧:lindagroup@126.com,把你的代码附上,同时把本页的地址也说明一下,我记性不太好的。

#3


不太明确,代码贴上一点看看

#4


问题太长了,看不明白,帮你顶吧

#5


感觉遗传算法比较合适。遗传算法耗时很短,所得的结果很接近最理想的值,但是多次运行的结果通常不一样,一般情况下不会得到精确的最理想的值。