人工蜂群演算法應用
『壹』 智能優化演算法:人工蜂群演算法
@[toc]
摘要:人工蜂群演算法(artificial bee colony,ABC)是由土耳其學者Karaboga 於 2005 年提出,它是模擬蜜蜂的采蜜行為來解決生活中一些多維和多模的優化問題,它最初應用於數值優化問題,自提出以來受到了眾多學者極大的關注,並廣泛應用到神經網路、數據挖掘、工程應用、圖像識別等多個領域。
在 ABC 演算法里,用蜜源的位置來表示解,用蜜源的花粉數量表示解的適應值。所有的蜜蜂劃分為僱傭蜂、跟隨蜂、探索蜂三組。僱傭蜂和跟隨蜂各占蜂群總數的一半。僱傭蜂負責最初的尋找蜜源並采蜜分享信息,跟隨蜂負責呆在蜂巢里根據僱傭蜂提供的信息去采蜜,探索蜂在原有蜜源被拋棄後負責隨機尋找新的蜜源來替換原有的蜜源。與其他群智能演算法一樣,ABC 演算法是迭代的。對蜂群和蜜源的初始化後,反復執行三個過程,即僱傭蜂、跟隨蜂、探索蜂階段,來尋找問題的最優解。每個階段描述如下:
對 ABC 演算法的參數進行初始化,這些參數有蜜源數 、蜜源確定被拋棄的次數 、迭代終止次數。在標准 ABC 演算法里,蜜源的數目 與僱傭蜂數相等,也與跟隨蜂數相等。產生某個蜜源的公式為:
其中: 代表第 個蜜源 的第 維度值, 取值於 , 取值於 ; 和 分別代表第 維的最小值和最大值。初始化蜜源就是對每個蜜源的所有維度通過以上公式賦一個在取值范圍內的隨機值,從而隨機生成 個最初蜜源。
在僱傭蜂階段,僱傭蜂用以下公式來尋找新蜜源:
其中: 代表鄰域蜜源, 取值於 ,且 不等於 ; 是取值在[-1,1]的隨機數,通過式(2)得到新蜜源後,利用貪婪演算法,比較新舊蜜源適應值,選擇優者。
僱傭蜂階段結束,跟隨蜂階段開始。在該階段,僱傭蜂在舞蹈區分享蜜源信息。跟隨蜂分析這些信息,採用輪盤賭策略來選擇蜜源跟蹤開采,以保證適應值更高的蜜源開採的概率更大。跟隨蜂開采過程與僱傭蜂一樣,利用式(2)找尋新蜜源,並留下更優適應者。
蜜源擁有參數 ,當蜜源更新被保留時, 為 0;反之, 加 1。從而 能統計出一個蜜源沒有被更新的次數。
如果一個蜜源經過多次開采沒被更新,也就是 值過高,超過了預定閾值 ,那麼需拋棄這個蜜源,啟動探索蜂階段。這體現了 ABC 里自組織的負反饋和波動屬性 。在該階段里,探索蜂利用式(3)隨機尋找新的蜜源來代替被拋棄蜜源。
人工蜂群演算法流程
step1.初始化演算法參數,生成蜜蜂初始位置
step2.僱傭蜂計算適應度值,比較並保存最優值
step3.跟隨蜂選擇僱傭蜂更新蜜源位置,計算適應度值,保存最佳值
step4.若有偵察蜂出現,則重新生成初始位置並執行更新選優,否則繼續執行step5
step5.若迭代次數小於預設的迭代次數,則轉到step2;否則輸出最優解
[1]何堯,劉建華,楊榮華.人工蜂群演算法研究綜述[J].計算機應用研究,2018,35(05):1281-1286.
https://mianbaoo.com/o/bread/aJWVkps=
https://mianbaoo.com/o/bread/YZWalJxr
『貳』 土壤反演傳統優化方法
傳統的土壤反演優化方法主要由以下幾個:
(1)粒子群演算法——是無導數方法,它通過群體中個體之間的協作和信息共享來尋找最優解,是一種基於群體智能的優化計算方法。
(2)人工螢火蟲演算法——思想源於對螢火蟲發光求偶與覓食行為的研究:螢火蟲個體利用螢光素誘導其他螢火蟲個體發光來吸引伴侶,光強越強,熒光素的數值越高,各個螢火蟲個體向熒光素值高的位置移動。
(3)人工蜂群演算法——是由Karaboga於2005年提出的一種新穎的群智能優化演算法。演算法通過模擬蜂群的采蜜行為實現優化問題的求解:蜜蜂根據各自分工進行合作采蜜活動,並實現蜜源信息的共享和交流。
『叄』 java人工蜂群演算法求解TSP問題
一、人工蜂群演算法的介紹
人工蜂群演算法(Artificial Bee Colony, ABC)是由Karaboga於2005年提出的一種新穎的基於群智能的全局優化演算法,其直觀背景來源於蜂群的采蜜行為,蜜蜂根據各自的分工進行不同的活動,並實現蜂群信息的共享和交流,從而找到問題的最優解。人工蜂群演算法屬於群智能演算法的一種。
二、人工蜂群演算法的原理
1、原理
標準的ABC演算法通過模擬實際蜜蜂的采蜜機制將人工蜂群分為3類: 采蜜蜂、觀察蜂和偵察蜂。整個蜂群的目標是尋找花蜜量最大的蜜源。在標準的ABC演算法中,采蜜蜂利用先前的蜜源信息尋找新的蜜源並與觀察蜂分享蜜源信息;觀察蜂在蜂房中等待並依據采蜜蜂分享的信息尋找新的蜜源;偵查蜂的任務是尋找一個新的有價值的蜜源,它們在蜂房附近隨機地尋找蜜源。
假設問題的解空間是。
代碼:
[cpp]view plain
#include<iostream>
#include<time.h>
#include<stdlib.h>
#include<cmath>
#include<fstream>
#include<iomanip>
usingnamespacestd;
constintNP=40;//種群的規模,采蜜蜂+觀察蜂
constintFoodNumber=NP/2;//食物的數量,為采蜜蜂的數量
constintlimit=20;//限度,超過這個限度沒有更新采蜜蜂變成偵查蜂
constintmaxCycle=10000;//停止條件
/*****函數的特定參數*****/
constintD=2;//函數的參數個數
constdoublelb=-100;//函數的下界
constdoubleub=100;//函數的上界
doubleresult[maxCycle]={0};
/*****種群的定義****/
structBeeGroup
{
doublecode[D];//函數的維數
doubletrueFit;//記錄真實的最小值
doublefitness;
doublerfitness;//相對適應值比例
inttrail;//表示實驗的次數,用於與limit作比較
}Bee[FoodNumber];
BeeGroupNectarSource[FoodNumber];//蜜源,注意:一切的修改都是針對蜜源而言的
BeeGroupEmployedBee[FoodNumber];//采蜜蜂
BeeGroupOnLooker[FoodNumber];//觀察蜂
BeeGroupBestSource;//記錄最好蜜源
/*****函數的聲明*****/
doublerandom(double,double);//產生區間上的隨機數
voidinitilize();//初始化參數
doublecalculationTruefit(BeeGroup);//計算真實的函數值
doublecalculationFitness(double);//計算適應值
voidCalculateProbabilities();//計算輪盤賭的概率
voidevalueSource();//評價蜜源
voidsendEmployedBees();
voidsendOnlookerBees();
voidsendScoutBees();
voidMemorizeBestSource();
/*******主函數*******/
intmain()
{
ofstreamoutput;
output.open("dataABC.txt");
srand((unsigned)time(NULL));
initilize();//初始化
MemorizeBestSource();//保存最好的蜜源
//主要的循環
intgen=0;
while(gen<maxCycle)
{
sendEmployedBees();
CalculateProbabilities();
sendOnlookerBees();
MemorizeBestSource();
sendScoutBees();
MemorizeBestSource();
output<<setprecision(30)<<BestSource.trueFit<<endl;
gen++;
}
output.close();
cout<<"運行結束!!"<<endl;
return0;
}
/*****函數的實現****/
doublerandom(doublestart,doubleend)//隨機產生區間內的隨機數
{
returnstart+(end-start)*rand()/(RAND_MAX+1.0);
}
voidinitilize()//初始化參數
{
inti,j;
for(i=0;i<FoodNumber;i++)
{
for(j=0;j<D;j++)
{
NectarSource[i].code[j]=random(lb,ub);
EmployedBee[i].code[j]=NectarSource[i].code[j];
OnLooker[i].code[j]=NectarSource[i].code[j];
BestSource.code[j]=NectarSource[0].code[j];
}
/****蜜源的初始化*****/
NectarSource[i].trueFit=calculationTruefit(NectarSource[i]);
NectarSource[i].fitness=calculationFitness(NectarSource[i].trueFit);
NectarSource[i].rfitness=0;
NectarSource[i].trail=0;
/****采蜜蜂的初始化*****/
EmployedBee[i].trueFit=NectarSource[i].trueFit;
EmployedBee[i].fitness=NectarSource[i].fitness;
EmployedBee[i].rfitness=NectarSource[i].rfitness;
EmployedBee[i].trail=NectarSource[i].trail;
/****觀察蜂的初始化****/
OnLooker[i].trueFit=NectarSource[i].trueFit;
OnLooker[i].fitness=NectarSource[i].fitness;
OnLooker[i].rfitness=NectarSource[i].rfitness;
OnLooker[i].trail=NectarSource[i].trail;
}
/*****最優蜜源的初始化*****/
BestSource.trueFit=NectarSource[0].trueFit;
BestSource.fitness=NectarSource[0].fitness;
BestSource.rfitness=NectarSource[0].rfitness;
BestSource.trail=NectarSource[0].trail;
}
doublecalculationTruefit(BeeGroupbee)//計算真實的函數值
{
doubletruefit=0;
/******測試函數1******/
truefit=0.5+(sin(sqrt(bee.code[0]*bee.code[0]+bee.code[1]*bee.code[1]))*sin(sqrt(bee.code[0]*bee.code[0]+bee.code[1]*bee.code[1]))-0.5)
/((1+0.001*(bee.code[0]*bee.code[0]+bee.code[1]*bee.code[1]))*(1+0.001*(bee.code[0]*bee.code[0]+bee.code[1]*bee.code[1])));
returntruefit;
}
doublecalculationFitness(doubletruefit)//計算適應值
{
doublefitnessResult=0;
if(truefit>=0)
{
fitnessResult=1/(truefit+1);
}else
{
fitnessResult=1+abs(truefit);
}
returnfitnessResult;
}
voidsendEmployedBees()//修改采蜜蜂的函數
{
inti,j,k;
intparam2change;//需要改變的維數
doubleRij;//[-1,1]之間的隨機數
for(i=0;i<FoodNumber;i++)
{
param2change=(int)random(0,D);//隨機選取需要改變的維數
/******選取不等於i的k********/
while(1)
{
k=(int)random(0,FoodNumber);
if(k!=i)
{
break;
}
}
for(j=0;j<D;j++)
{
EmployedBee[i].code[j]=NectarSource[i].code[j];
}
/*******采蜜蜂去更新信息*******/
Rij=random(-1,1);
EmployedBee[i].code[param2change]=NectarSource[i].code[param2change]+Rij*(NectarSource[i].code[param2change]-NectarSource[k].code[param2change]);
/*******判斷是否越界********/
if(EmployedBee[i].code[param2change]>ub)
{
EmployedBee[i].code[param2change]=ub;
}
if(EmployedBee[i].code[param2change]<lb)
{
EmployedBee[i].code[param2change]=lb;
}
EmployedBee[i].trueFit=calculationTruefit(EmployedBee[i]);
EmployedBee[i].fitness=calculationFitness(EmployedBee[i].trueFit);
/******貪婪選擇策略*******/
if(EmployedBee[i].trueFit<NectarSource[i].trueFit)
{
for(j=0;j<D;j++)
{
NectarSource[i].code[j]=EmployedBee[i].code[j];
}
NectarSource[i].trail=0;
NectarSource[i].trueFit=EmployedBee[i].trueFit;
NectarSource[i].fitness=EmployedBee[i].fitness;
}else
{
NectarSource[i].trail++;
}
}
}
voidCalculateProbabilities()//計算輪盤賭的選擇概率
{
inti;
doublemaxfit;
maxfit=NectarSource[0].fitness;
for(i=1;i<FoodNumber;i++)
{
if(NectarSource[i].fitness>maxfit)
maxfit=NectarSource[i].fitness;
}
for(i=0;i<FoodNumber;i++)
{
NectarSource[i].rfitness=(0.9*(NectarSource[i].fitness/maxfit))+0.1;
}
}
voidsendOnlookerBees()//采蜜蜂與觀察蜂交流信息,觀察蜂更改信息
{
inti,j,t,k;
doubleR_choosed;//被選中的概率
intparam2change;//需要被改變的維數
doubleRij;//[-1,1]之間的隨機數
i=0;
t=0;
while(t<FoodNumber)
{
R_choosed=random(0,1);
if(R_choosed<NectarSource[i].rfitness)//根據被選擇的概率選擇
{
t++;
param2change=(int)random(0,D);
/******選取不等於i的k********/
while(1)
{
k=(int)random(0,FoodNumber);
if(k!=i)
{
break;
}
}
for(j=0;j<D;j++)
{
OnLooker[i].code[j]=NectarSource[i].code[j];
}
/****更新******/
Rij=random(-1,1);
OnLooker[i].code[param2change]=NectarSource[i].code[param2change]+Rij*(NectarSource[i].code[param2change]-NectarSource[k].code[param2change]);
/*******判斷是否越界*******/
if(OnLooker[i].code[param2change]<lb)
{
OnLooker[i].code[param2change]=lb;
}
if(OnLooker[i].code[param2change]>ub)
{
OnLooker[i].code[param2change]=ub;
}
OnLooker[i].trueFit=calculationTruefit(OnLooker[i]);
OnLooker[i].fitness=calculationFitness(OnLooker[i].trueFit);
/****貪婪選擇策略******/
if(OnLooker[i].trueFit<NectarSource[i].trueFit)
{
for(j=0;j<D;j++)
{
NectarSource[i].code[j]=OnLooker[i].code[j];
}
NectarSource[i].trail=0;
NectarSource[i].trueFit=OnLooker[i].trueFit;
NectarSource[i].fitness=OnLooker[i].fitness;
}else
{
NectarSource[i].trail++;
}
}
i++;
if(i==FoodNumber)
{
i=0;
}
}
}
『肆』 優化演算法筆記(八)人工蜂群演算法
(以下描述,均不是學術用語,僅供大家快樂的閱讀)
工蜂群演算法(Artificial Bee Colony Algorithm,ABC)是一種模仿蜜蜂采蜜機理而產生的群智能優化演算法。其原理相對復雜,但實現較為簡單,在許多領域中都有研究和應用。
人工蜂群演算法中,每一個蜜源的位置代表了待求問題的一個可行解。蜂群分為采蜜蜂、觀察蜂和偵查蜂。采蜜蜂與蜜源對應,一個采蜜蜂對應一個蜜源。觀察蜂則會根據采蜜蜂分享的蜜源相關信息選擇跟隨哪個采蜜蜂去相應的蜜源,同時該觀察蜂將轉變為偵查蜂。偵查蜂則自由的搜索新的蜜源。每一個蜜源都有開採的限制次數,當一個蜜源被采蜜多次而達到開采限制次數時,在寬檔該蜜源采蜜的采蜜蜂將轉變為偵查蜂。每個偵查蜂將隨機尋找一個新蜜源進行開采,並轉變成為采蜜蜂。
下面是我的實現方式(我的答案):
1. 三種蜜蜂之間可以相互轉化。
采蜜蜂->觀察蜂:有觀察蜂在采蜜過程中發現了比當前采蜜蜂更好的蜜源,則采蜜蜂放棄當前蜜源轉而變成觀察蜂跟隨優質蜜源,同時該觀察蜂轉變為采蜜蜂。
采蜜蜂->觀察蜂:當該采蜜蜂所發現的蜜源被開采完後,它會轉變為觀察蜂去跟隨其他采蜜蜂。
采蜜蜂->偵查蜂:當所有的采蜜蜂發現的蜜源都被開采完後,采蜜蜂將會變為偵查蜂,觀察蜂也會變成偵查蜂,因為大家都無蜜可采。
偵查蜂->采蜜蜂、觀察蜂:偵查蜂隨機搜索蜜源,選擇較好的數個蜜源位置的蜜蜂為采蜜蜂,其他蜜蜂為觀察蜂。
2.蜜源的數量上限
蜜源的數量上限等於采蜜蜂的數量上限。初始化時所有蜜蜂都是偵查蜂,在這些偵查蜂所搜索到的蜜源中選出數個較優的蜜源,發現這些蜜源的偵查蜂變為采蜜蜂,其他蜜蜂變為觀察蜂。直到所有的蜜源都被開采完之前,蜜源的數量不會增加,因為這個過程中沒有產生偵查蜂緩配。所有的蜜源都被開采完後,所有的蜜蜂再次全部轉化為偵查蜂,新的一輪蜜源搜索開始。也可以在一個蜜源開采完時馬上產生一個新的蜜源補充,保證在整個開采過程中蜜源數量恆定不變。
蜜源的開采實際上就是觀察蜂跟隨采蜜蜂飛向蜜源的過程。得到的下一代的位置公式如下:
表示第i只觀察蜂在第t代時隨機選擇第r只採蜜蜂飛行一段距離,其中R為(-1,1)的隨機數。
一隻觀察蜂在一次迭代過程中只能選擇一隻采蜜蜂跟隨,它需要從眾多的采蜜蜂中選擇一隻來進行跟隨。觀察蜂選擇的策略很簡單,隨機跟隨一隻采蜜蜂,該采蜜蜂發現的蜜源越優,則選擇它的概率越大。
是不是很像輪盤賭,對,這就是輪盤賭,同時我們也可以稍作修改,比如將勤勞的小蜜蜂改為懶惰的小蜜蜂,小蜜蜂會根據蜜源的優劣和距離以及開采程度等因素綜合來選擇跟隨哪只採蜜蜂(雖然影響不大,但聊勝於無)。
忘記了輪盤賭的小夥伴可以看一下 優化演算法筆記(六)遺傳演算法 。
下面是我的人工蜂群演算法流程圖
又到了實驗環節,參數實驗較多,慎哪亂全部給出將會佔用太多篇幅,僅將結果進行匯總展示。
實驗1:參數如下
上圖分別為采蜜蜂上限為10%總數和50%總數的情況,可以看出當采蜜蜂上限為10%總群數時,種群收斂的速度較快,但是到最後有一個點死活不動,這是因為該點作為一個蜜源,但由於適應度值太差,使用輪盤賭被選擇到的概率太小從而沒有得到更佳的蜜源位置,而因未開采完,采蜜蜂又不能放棄該蜜源。
看了看采蜜蜂上限為50%總群數時的圖,發現也有幾個點不動的狀態,可以看出,這時不動的點的數量明顯多於上限為10%總數的圖,原因很簡單,采蜜蜂太多,「先富」的人太多,而「後富」的人較少,沒有帶動「後富者」的「先富者」也得不到發展。
看看結果
嗯,感覺結果並沒有什麼差別,可能由於問題較簡單,迭代次數較少,無法體現出采蜜蜂數對於結果的影響,也可能由於蜜源的搜索次數為60較大,總群一共只能對最多20*50/60=16個蜜源進行搜索。我們將最大迭代次數調大至200代再看看結果
當最大迭代次數為200時,人工蜂群演算法的結果如上圖,我們可以明顯的看出,隨著采蜜蜂上限的上升,演算法結果的精度在不斷的下降,這也印證了之前的結果,由於蜜源搜索次數較大(即搜索深度較深)采蜜蜂數量越多(搜索廣度越多),結果的精度越低。不過影響也不算太大,下面我們再來看看蜜源最大開采次數對結果的影響。
實驗2:參數如下
上圖分別是蜜源開采限度為1,20和4000的實驗。
當蜜源開采上限為1時,即一個蜜源只能被開采一次,即此時的人工蜂群演算法只有偵查蜂隨機搜索的過程,沒有觀察蜂跟隨采蜜蜂的過程,可以看出圖中的蜜蜂一直在不斷的隨機出現在新位置不會向某個點收斂。
當蜜源開采上限為20時,我們可以看到此時種群中的蜜蜂都會向一個點飛行。在一段時間內,有數個點一動不動,這些點可能就是采蜜蜂發現的位置不怎麼好的蜜源,但是在幾次迭代之後,它們仍會被觀察蜂開采,從而更新位置,蜜源開采上限越高,它們停頓的代數也會越長。在所有蜜蜂都收斂於一個點之後,我們可以看到仍會不斷的出現其他的隨機點,這些點是偵查蜂進行隨機搜索產生的新的蜜源位置,這些是人工蜂群演算法跳出局部最優能力的體現。
當蜜源開采上限為4000時,即不會出現偵查蜂的搜索過程,觀察蜂只會開采初始化時出現的蜜源而不會采蜜蜂不會有新的蜜源產生,可以看出在蜂群收斂後沒有出現新的蜜源位置。
看看最終結果,我們發現,當蜜源開采上線大於1時的結果提升,但是好像開采上限為5時結果明顯好於開采次數上限為其他的結果,而且隨著開采次數不斷上升,結果在不斷的變差。為什麼會出現這樣的結果呢?原因可能還是因為問題較為簡單,在5次開採的限度內,觀察蜂已經能找到更好的蜜源進行開采,當問題較為復雜時,我們無法知曉開采發現新蜜源的難度,蜜源開采上限應該取一個相對較大的值。當蜜源開采限度為4000時,即一個蜜源不可能被開采完(開采次數為20(種群數)*200(迭代次數)),搜索的深度有了但是其結果反而不如開采限度為幾次幾十次來的好,而且這樣不會有偵查蜂隨機搜索的過程,失去了跳出局部最優的能力。
我們應該如何選擇蜜源的最大開采次數限制呢?其實,沒有最佳的開采次數限制,當適應度函數較為簡單時,開采次數較小時能得到比較好的結果,但是適應度函數較復雜時,經過試驗,得出的結果遠差於開采次數較大時。當然,前面就說過,適應度函數是一個黑盒模型,我們無法判斷問題的難易。那麼我們應該選擇一個適中的值,個人的選擇是種群數的0.5倍到總群數的2倍作為蜜源的最大開采次數,這樣可以保證極端情況下,1-2個迭代周期內小蜜蜂們能將一個蜜源開采完。
人工蜂群演算法算是一個困擾我比較長時間的演算法,幾年時間里,我根據文獻實現的人工蜂群演算法都有數十種,只能說人工蜂群演算法的描述太過模糊,或者說太過抽象,研究者怎麼實現都說的通。但是通過實現多次之後發現雖然實現細節大不相同,但效果相差不多,所以我們可以認為人工蜂群演算法的穩定性比較強,只要實現其主要思想即可,細節對於結果的影響不太大。
對於人工蜂群演算法影響最大的因素還是蜜源的開采次數限制,開采次數限制越大,對同一蜜源的開發力度越大,但是分配給其他蜜源的搜索力度會相對減少,也會降低蜂群演算法的跳出局部最優能力。可以動態修改蜜源的開采次數限制來實現對演算法的改進,不過效果不顯著。
其次對於人工蜂群演算法影響是三類蜜蜂的搜索行為,我們可以重新設計蜂群的搜索方式來對演算法進行改進,比如采蜜蜂在開采蜜源時是隨機飛向其他蜜源,而觀察蜂向所選的蜜源靠近。這樣改進有一定效果但是在高維問題上效果仍不明顯。
以下指標純屬個人yy,僅供參考
目錄
上一篇 優化演算法筆記(七)差分進化演算法
下一篇 優化演算法筆記(九)杜鵑搜索演算法
優化演算法matlab實現(八)人工蜂群演算法matlab實現
『伍』 (轉)物流優化演算法處理流程及演算法服務平台建設
轉自:吉勍Personal
http://www.jiqingip.com/page9001?article_id=94
演算法處理流程
物流方向的大多數業務演算法處理流程基本是按照模型建立、演算法開發、演算法測試流程進行,具體步驟如下:
模型建立
大多數優化問題都能構建成線性規劃、非線性規劃或混合整數規劃等數學模型。這些模型需要根據實際業務確定,模型主要包含以下因素:
1) 優化目標
2) 決策變數
3) 約束條件
演算法開發
模型的求解可根據實際的業務情況(問題復雜程度、數據規模、計算時效要求)等採用合適的精確演算法和近似的最優化演算法進行求解。
模型精確計算
模型精確求解有一些商業和開源的求解器,如下:Gurobi、Cplex、SCIP、OR-Tools、Glpk等,可以根據實際情況選擇合適的求解器。
最優化演算法計算
最優化演算法也有很多,比如變鄰域搜索演算法、自適應大鄰域搜索演算法、禁忌搜索演算法、模擬退火演算法、遺傳演算法、蟻群優化演算法、粒子群優化演算法、人工魚群演算法、人工蜂群演算法等,可以根據適用情況選擇。
業務相關開放項目計算
解物流領域的某些項目可以利用一些開放性的項目來求解,如求解車輛路徑問題的jsprit、求解排程類問題的optaplanner等,這類問題在模型建立好之後可以調用這些開放性項目來求解。
演算法測試
生產數據測試
物流方向的項目基本都是優化類型的項目,每個項目對應的業務環節一直在運行,涉及到的優化問題或者是業務系統簡單處理,或者人為計算,對於演算法有效性的檢測可以把這部分生產數據獨立抽離出來,經過優化演算法計算之後跟原有系統數據進行相關的對比,來評價演算法的優化效果。
模擬測試
物流的優化不像互聯網應用可以採用流量灰度的方式進行直接的驗證,並且物流系統的鏈路非常長,單點的改變可能引起上下游的變化。在決策優化的過程中需要同時使用優化求解及模擬技術來驗證或提供決策依據。模擬測試驗證大致需要以下過程:
1) 定義模擬模型確定績效指標體系
2) 輸入演算法結果數據到模擬模型進行模擬計算
3) 根據模擬模型的模擬結果計算績效指標,以反饋演算法的優化效果。
演算法服務平台建設
實際業務中的很多應用場景都可以抽象成同一類演算法問題。演算法在解決不同應用場景業務問題時,相關模型、處理流程及計算方法也都大致相同,因此可以對這類問題的演算法,按照其處理流程從業務中剝離出來,封裝好演算法的輸入、輸出及計算邏輯,構建統一的演算法服務平台。
VRP演算法服務
比較經典的VRP問題就會應用到很多業務場景,即時配、大件配送、冷鏈配送、門店補貨等。這些業務場景對於大型零售商來說是比較常見的,因此構建可靈活配置的VRP演算法服務平台,可達成一次構建,多場景應用的效果。
排班演算法服務
排班問題也是一樣,無論是生產線工人排班、司機排班、客服排班還是門店工作人員排班,這些都是排班問題應用的業務場景。通過構建可靈活配置的排班演算法服務平台,可解決多個業務場景的排班問題。
裝箱演算法服務
裝箱問題也有著豐富的應用場景,無論是商品配送的車輛裝箱、運輸網路的車型推薦及包裝作業的包材推薦都是裝箱問題的業務場景。構建靈活的裝箱演算法服務平台,可通過配置有效的解決各業務場景的裝箱問題。
運籌規劃演算法服務
無論是上面提到的一些演算法服務還是其他組合優化問題,都可以構建成運籌優化問題來解決。大家熟知的google or-tools就是組合優化問題的工具包。我們也可以根據自身的業務特點構建適合業務場景的運籌規劃演算法服務,底層可以調用不同的求解器,可以是商業求解器,如gurobi、cplex等,也可以是開源求解器,如scip、glpk等;也可以是一些最優化演算法,如鄰域搜索等。
『陸』 人工蜂群演算法的matlab的編程詳細代碼,最好有基於人工蜂群演算法的人工神經網路的編程代碼
蟻群演算法(ant colony optimization, ACO),又稱螞蟻演算法,是一種用來在圖中尋找優化路徑的機率型演算法。它由Marco Dorigo於1992年在他的博士論文中提出,其靈感來源於螞蟻在尋找食物過程中發現路徑的行為。蟻群演算法是一種模擬進化演算法,初步的研究表明該演算法具有許多優良的性質。針對PID控制器參數優化設計問題,將蟻群演算法設計的結果與遺傳演算法設計的結果進行了比較,數值模擬結果表明,蟻群演算法具有一種新的模擬進化優化方法的有效性和應用價值。
參考下蟻群訓練BP網路的代碼。