2013-04-26 285 views
6

我需要解決(很多時候,對於大量數據,以及其他一些事情),我認爲可以歸結爲second order cone program。它可以在CVX像這樣來簡潔地表示:R中的CVX-esque凸優化?

cvx_begin 
    variable X(2000); 
    expression MX(2000); 
    MX = M * X; 
    minimize(norm(A * X - b) + gamma * norm(MX, 1)) 
    subject to 
    X >= 0 
    MX((1:500) * 4 - 3) == MX((1:500) * 4 - 2) 
    MX((1:500) * 4 - 1) == MX((1:500) * 4) 
cvx_end 

的數據顯示長度和平等約束模式是從一​​些測試數據只是任意值,但一般形式將是大同小異,有兩個客觀條件 - - 一個最小化錯誤,另一個鼓勵稀疏性 - 以及對優化變量(本身被限制爲非負)變換版本元素的大量等式約束。

這似乎相當很好地工作,比我以前的做法,這囈語的約束腐朽好得多。問題在於R中的其他所有事情都發生在R中,並且將它移植到Matlab上將是相當麻煩的。那麼在R中是否可行?如果是這樣的話?

這實際上可以歸結爲兩個獨立的問題:

1)是否有這方面的任何好[R資源?據我可以從CRAN task page知道的,SOCP包選項CLSCOPDWD,其求解器包括SOCP作爲輔助其分類。兩者有相似,但相當不透明的接口,是有點薄上的文檔和例子,這給我們帶來:

2)什麼是代表由這些包所用的約束塊格式上述問題的最佳方式是什麼?上述CVX語法隱藏了大量繁瑣擺弄額外的變量和這樣的,而且我可以看到自己花費試圖得到這個權利,所以任何提示或指針,以輕推我在正確的方向將是非常歡迎的。 ..

+1

重新構造問題(引入鬆弛變量 以去除L^1範數並將L^2範數轉換爲錐約束) 相對容易: 替換「M%*%x」的L^1範數'yz' 並添加約束'y> = 0','z> = 0'; 用't' 代替'A%*%x - b'的L^2範數,並添加約束條件 '=> sqrt(t(u)%*%u)', 'u = A %*%x - b'。 大多數這些轉換甚至可能是 [自動](http://zoonek.free.fr/blosxom/R/2012-06-01_Optimization.html), 與CVX, 一樣,但對於這樣的簡單問題,這可能不值得麻煩。 – 2013-04-27 08:42:36

+1

但是,DWD :: sqlp或CLSOCP :: socp的輸入格式 沒有記錄: 您會被告知哪些參數包含約束,但不包括它們如何編碼... 您可以嘗試聯繫這些軟件包的作者 有更多關於約束編碼的信息。 你也可以看看'Rcsdp'包: 它解決了一大類問題(半定程序), 輸入被記錄, ,但將你的問題轉換成所需的形式不會那麼簡單... – 2013-04-27 08:43:49

+0

@Vincent謝謝,這很有幫助。 (這真是一篇博客文章!)'DWD :: sqlp'看起來仿照SDPT3,因此可以通過比較來澄清輸入。 – walkytalky 2013-04-27 11:11:24

回答

2

您可能會發現將R包CVXfromR有用。這可以讓您將優化問題從R傳遞到CVX並將解決方案返回給R.

1

好的,所以這個問題的簡短答案是:在R中沒有非常令人滿意的方式來處理這個問題。 Matlab中的相關部分在兩個系統之間進行了一些尷尬的混淆,最終可能會將所有內容都轉移到Matlab。 (我目前的做法早於用戶2439686發佈的答案,實際上我的問題同樣會使用CVXfromR,但它通常看起來像是一個有用的包,因此我會接受該答案)。因爲這在地面上很薄,但他在評論中提到的blog post by Vincent Zoonekynd絕對值得一讀。

包含在R包DWD中的SOCP解算器從Matlab解算器SDPT3(減去SDP部分)移植,因此編程接口基本相同。然而,至少在我的測試中,它運行速度慢得多,幾乎在幾千個變量+約束條件下出現問題,而SDPT3在幾秒鐘內解決了這些問題。 (我對此沒有做過完全公平的比較,因爲CVX在問題上做了一些漂亮的轉換,使其更加高效,而在R中我使用的是非常天真的定義,但仍然如此)。

另一種可能另外,特別是如果您有資格獲得學術許可,則使用商業Mosek解算器,該解算器具有R接口包Rmosek。我還沒有嘗試過,但可能會在某個時候發揮作用。(另外,與CVX捆綁在一起的另一個求解器,SeDuMi在同一個問題上完全失敗;當他們建議嘗試多個求解器時,CVX作者並不是在開玩笑,而且在一些重要的案例子集中,SDTP3有從Cholesky切換到LU分解,這使得處理階數的幅度更慢,與LU前階段相比,目標只有非常小的改進。我發現它值得降低要求的精度以避免這種情況,但是YMMV。 )