.net+mssql制造抽獎法式思緒及源碼。本站提示廣大學習愛好者：（.net+mssql制造抽獎法式思緒及源碼）文章只能為提供參考，不一定能成為您想要的結果。以下是.net+mssql制造抽獎法式思緒及源碼正文
在我碰到 SimPy 包的個中一名開創人 Klaus Miller 時，從他那邊曉得了這個包。Miller 博士浏覽過幾篇提出應用 Python 2.2+ 生成器完成半協同例程和“簡便”線程的技巧的 心愛的 Python專欄文章。特殊是（使我很愉快的是），他發明在用 Python 完成 Simula-67 款式模仿時，這些技巧很有效。
成果注解 Tony Vignaux 和 Chang Chui 之前曾創立了另外一個 Python 庫，它在概念上更接近於 Simscript，並且該庫應用了尺度線程技巧，而不是我的半協同例程技巧。該小組在一路研討時，以為基於生成器的款式更有用很多，而且比來在 SourceForge 上提議了應用 GPL 的項目，稱為 SimPy（請參閱 參考材料，取得 SimPy 主頁的鏈接），今朝處於 beta 測試版狀況。Vignaux 傳授願望他在惠靈頓維多利亞年夜學（University of Victoria）的未來年夜學教授教養中應用同一的 SimPy 包；我信任該庫也異常合適運用到各類適用成績中。
我認可在近期的通訊交換和查詢拜訪研討之前，我對編程范疇的模仿方面沒有任何基本常識。我料想本專欄文章的年夜部門讀者也和我一樣，對這方面的常識知之甚少。雖然有人會以為這類款式編程的方法有些別致，但在懂得資本無限的現實體系的行動時，模仿是很有效的。不論您感興致的是無限帶寬收集、汽車交通行動、市場和貿易性優化、生物／退化的交互感化照樣其它“隨機”體系，SimPy 對如許的建模都供給了簡略的 Python 對象。
隨機的界說
與“銜接”相相似，它是那些 最合適描述其功課的辭匯之一 - 再也找不到更合適的了：
隨機（stochastic），源自希臘語 stokhastikos（描述詞）
1）推想的、與推想相干的或許具有推想特色的；好推想的。
2）在統計學上：觸及或包括一個隨機變量或多個隨機變量，或觸及有時性或幾率。
起源：Dictionary.com
在本專欄文章中，我將一向應用食物雜貨店內具有多條通道的付款區域這個相當簡略的示例。經由過程應用所演示的模仿，我們可以依據對掃描器技巧、購物者習氣、人員裝備需求等停止的各類更改所發生的經濟上和期待時光上的寄義提出成績。這個建模的長處是在您對所做的更改發生的寄義有清楚的設法主意時，它讓您能提早制訂戰略。很顯著，年夜多半讀者不會專門運營一家食物雜貨店，但這些技巧可以普遍地運用於各類體系中。
模仿的概念
SimPy 庫只供給了三個籠統／父類，而且它們對應於模仿的三個根本概念。有很多其它慣例函數和常量用於掌握模仿的運轉，但主要的概念都與這些類聯合在一路。
模仿中的焦點概念是 過程。一個過程只是一個對象，它完成某些義務，隨後在它預備完成下一個義務之前有時會期待一會兒。在 SimPy 中，您還可以“鈍化”過程，這意味著在一個過程完成一個義務後，只要當其它過程請求該過程完成其它義務時，它才會去做。把過程看成測驗考試完成一個目的，經常是很有效的。在編寫過程時，平日把它編寫成可以在個中履行多個操作的輪回。在每一個操作之間，可以拔出 Python“yield”語句，它讓模仿調劑法式在前往掌握之前履行每一個期待過程的操作。
過程履行的很多操作取決於 資本的應用。資本只是在可用性方面遭到限制。在生物學模子中，資本能夠是食品供給；在收集模子中，資本可所以路由器或無限帶寬通道；在我們的市場模仿中，資本是付款通道。資本履行的獨一義務是在任何給定的時光內將它的應用限於一個特定的過程上。在 SimPy 編程模子下，過程零丁決議它要保存資本的時光有多長，資本自己是主動的。在現實體系中，SimPy 模子能夠合適概念性計劃，也能夠不合適；很輕易想象到資本在實質上會限制其應用率（例如，假如辦事器盤算機在必須的時光幀內沒有取得滿足的呼應，則它會中止銜接）。但作為編程成績，過程或資本能否是“自動”方就不是特殊主要（只需確保您懂得了您的意圖）。
最初一個 SimPy 類是 監控法式。現實上監控法式不是很主要，只不外它很便利。監控法式所做的全體義務就是記載向它申報的事宜，並保留有關這些事宜的統計信息（均勻值、計數、方差等）。該庫供給的 Monitor 類對記載模仿辦法是個有效的對象，但您也能夠經由過程您想應用的其它任何技巧來記載事宜。現實上，我的示例使 Monitor 子類化，以供給某些（略微）加強的才能。
設置市肆：對模仿編程
在我所撰寫的年夜部門文章中，我都邑立時給出樣本運用法式，但在本例中，我以為帶您閱歷食物雜貨店運用法式的每一個步調會更有效。假如您情願的話，可以把每一個部門剪貼在一路；SimPy 發明者們將在未來的刊行版中包括我的示例。
SimPy 模仿中的第一步是幾個慣例的導入（import）語句：
清單 1. 導入 SimPy 庫
#!/usr/bin/env python from __future__ import generators from SimPy import Simulation from SimPy.Simulation import hold, request, release, now from SimPy.Monitor import Monitor import random from math import sqrt
有些 SimPy 附帶的示例應用 import * 款式，但我更愛好使我填充的稱號空間更清楚。關於 Python 2.2（SimPy 所需的最低版本），將須要如指出的那樣，導入生成器特征。關於 Python 2.3 今後的版本，不須要如許做。
關於我的運用法式，我界說了幾個運轉經常量，它們描寫了在特定的模仿運轉時代我感興致的幾個計劃。在我更改計劃時，我必需在主劇本內編纂這些常量。如果這個運用法式的內容更充分，那末我便可能用敕令行選項、情況變量或設置裝備擺設文件來設置裝備擺設這些參數。但就今朝而言，這個款式曾經足夠了：
清單 2. 設置裝備擺設模仿參數
AISLES = 5 # Number of open aisles ITEMTIME = 0.1 # Time to ring up one item AVGITEMS = 20 # Average number of items purchased CLOSING = 60*12 # Minutes from store open to store close AVGCUST = 1500 # Average number of daily customers RUNS = 10 # Number of times to run the simulation
我們的模仿須要完成的重要義務是界說一個或多個過程。關於模仿食物雜貨店，我們感興致的過程是在通道處付款的顧客。
清單 3. 界說顧客的操作
class Customer(Simulation.Process):
def __init__(self):
Simulation.Process.__init__(self)
# Randomly pick how many items this customer is buying
self.items = 1 + int(random.expovariate(1.0/AVGITEMS))
def checkout(self):
start = now() # Customer decides to check out
yield request, self, checkout_aisle
at_checkout = now() # Customer gets to front of line
waittime.tally(at_checkout-start)
yield hold, self, self.items*ITEMTIME
leaving = now() # Customer completes purchase
checkouttime.tally(leaving-at_checkout)
yield release, self, checkout_aisle
每位顧客曾經決議推銷必定數目的商品。（我們的模仿不觸及從食物雜貨店通道上選擇商品；顧客只是推著他們的手推車達到付款處。）我不克不及肯定這裡的指數變量散布確切是一個准確的模子。在其低端處我感到是對的，但我覺得對現實購物者畢竟推銷了若干商品的最高極限有點掉實。在任何情形下，您可以看到假如可使用更好的模子信息，則調劑我們的模仿是何等簡略。
顧客采用的操作是我們所存眷的。顧客的“履行辦法”就是 .checkout() 。這個過程辦法平日被定名為 .run() 或 .execute() ，但在我的示例中， .checkout() 仿佛是最可描寫的。您可以對它起任何您願望的稱號。 Customer 對象所采用的現實 操作僅僅是檢討幾個點上的模仿時光，並將連續時光記載到 waittime 和 checkouttime 監控法式中。但在這些操作之間是相當主要的 yield 語句。在第一種情形中，顧客要求資本（付款通道）。只要當顧客取得了所需的資本以後，他們能力做其它操作。一旦離開付款通道，顧客現實上就在付款了 — 所花時光與所購商品的數目成比例。最初，經由付款處以後，顧客就釋放資本，以便其他顧客可使用它。
上述代碼界說了 Customer 類的操作，但我們須要在運轉模仿之前，創立一些現實的顧客對象。我們 可認為一天中將要購物的每位顧客生成顧客對象，並為每位顧客分派響應的付款時光。但更簡練的辦法是“在每位顧客到市肆時”，讓工場對象生成所需的顧客對象。現實上模仿其實不會同時對一天內將要購物的一切顧客感興致，而是只對那些要同時爭用付款通道的顧客感興致。留意： Customer_Factory 類自己是模仿的一部門 — 它是一個過程。雖然關於這個客戶工場，您能夠聯想到天然的機械工人（la Fritz Lang 的 Metropolis），但照樣應當只把它看做編程的方便對象；它其實不直接對應已建模域中的任何事物。
清單 4. 生成顧客流
class Customer_Factory(Simulation.Process):
def run(self):
while 1:
c = Customer()
Simulation.activate(c, c.checkout())
arrival = random.expovariate(float(AVGCUST)/CLOSING)
yield hold, self, arrival
正如我後面提到的，我想搜集一些以後 SimPy Monitor 類沒有處理的統計信息。也就是，我其實不僅僅對均勻付款時光感興致，並且還對給定計劃中最蹩腳情形感興致。所以我創立了一個加強的監控法式，它搜集最小和最年夜的計數值。
用監控法式監督模仿
class Monitor2(Monitor):
def __init__(self):
Monitor.__init__(self)
self.min, self.max = (int(2**31-1),0)
def tally(self, x):
Monitor.tally(self, x)
self.min = min(self.min, x)
self.max = max(self.max, x)
我們模仿的最初一步固然是 運轉它。在年夜多半尺度示例中，只運轉一次模仿。但關於我的食物雜貨店，我決議經由過程幾回模仿停止輪回，每次對應於某一天的營業。這看來是個好主張，由於有些統計信息會隨天天的情形而有相當年夜的分歧（由於達到的顧主人次和所購商品數采取隨機發生的分歧值）。
清單 6. 天天運轉模仿
for run in range(RUNS):
waittime = Monitor2()
checkouttime = Monitor2()
checkout_aisle = Simulation.Resource(AISLES)
Simulation.initialize()
cf = Customer_Factory()
Simulation.activate(cf, cf.run(), 0.0)
Simulation.simulate(until=CLOSING)
#print "Customers:", checkouttime.count()
print "Waiting time average: %.1f" % waittime.mean(), \
"(std dev %.1f, maximum %.1f)" % (sqrt(waittime.var()),waittime.max)
#print "Checkout time average: %1f" % checkouttime.mean(), \
# "(standard deviation %.1f)" % sqrt(checkouttime.var())
print 'AISLES:', AISLES, ' ITEM TIME:', ITEMTIME
三人不歡：一些成果（和它們意味著甚麼）
當我最後斟酌食物雜貨店模子時，我以為模仿可以解答幾個直接成績。例如，我想象雇主能夠會選擇購置改良的掃描儀（削減 ITEMTIME ），或許選擇雇傭更多人員（增長 AISLES ）。我想只需在每一個計劃下運轉這個模仿（假定雇員和技巧本錢給定的情形下），並肯定下面兩種選擇哪一種更能削減本錢。
只要運轉了模仿後，我才認識到能夠會湧現比預感的更風趣的工作。檢查搜集的一切數據，我認識到我不曉得要測驗考試優化的是甚麼。 甚麼。例如，削減 均勻付款時光和削減 最差情形的時光，哪一個更主要？哪些方面會進步整體顧客滿足度？別的，若何比擬顧客在付款之前所用的期待時光和掃描所購商品所花的時光？以我小我的經歷，我會在期待的隊列中覺得不耐心，但在掃描我的商品時，我不會覺得很費事（即便這會花一些時光）。
固然，我沒有運營食物雜貨店，所以我不曉得一切這些成績的謎底。但這個模仿確切讓我精確地決議甚麼是調和計劃；並且它很簡略，足以稍作調劑便可實用於很多行動（包含那些還未顯式地參數化的行動 — 例如，“一成天中顧客 真的會一向赓續地來嗎？”）。
我只需演示最初一個示例，便可以解釋該模子的價值。我在下面曾寫道龐雜體系的行動難以概念化。我以為這裡的示例可以證實這一現實。在可用的通道從 6 條削減到 5 條（其它參數不變）時，您以為會湧現甚麼情形？最後我想會 略微增長最蹩腳情形下的付款時光。而現實並不是如斯：
清單 7. 通道數變更前後運轉的兩個樣本
% python Market.py Waiting time average: 0.5 (std dev 0.9, maximum 4.5) Waiting time average: 0.3 (std dev 0.6, maximum 3.7) Waiting time average: 0.4 (std dev 0.8, maximum 5.6) Waiting time average: 0.4 (std dev 0.8, maximum 5.2) Waiting time average: 0.4 (std dev 0.8, maximum 5.8) Waiting time average: 0.3 (std dev 0.6, maximum 5.2) Waiting time average: 0.5 (std dev 1.1, maximum 5.2) Waiting time average: 0.5 (std dev 1.0, maximum 5.4) AISLES: 6 ITEM TIME: 0.1 % python Market.py Waiting time average: 2.1 (std dev 2.3, maximum 9.5) Waiting time average: 1.8 (std dev 2.3, maximum 10.9) Waiting time average: 1.3 (std dev 1.7, maximum 7.3) Waiting time average: 1.7 (std dev 2.1, maximum 9.5) Waiting time average: 4.2 (std dev 5.6, maximum 21.3) Waiting time average: 1.6 (std dev 2.6, maximum 12.0) Waiting time average: 1.3 (std dev 1.6, maximum 7.5) Waiting time average: 1.5 (std dev 2.1, maximum 11.2) AISLES: 5 ITEM TIME: 0.1
削減一條付款通道不是使均勻期待時光增長 1/5 或相似的情形，而是使它增長了年夜約 4 倍。並且，最不幸的顧客（在這些特定的運轉時代）的期待時光從 6 分鐘增長到了 21 分鐘。假如我是司理，我以為懂得這個極限情形對顧客滿足度而言是極端主要的。誰會早已曉得這一點呢？
