財務工程會用到的程式語言 - 金融分析師

: : 我希望利用暑假時繼續去學程式語言
: : 我該繼續學C++下去嗎?? 還是學其他的比較好??
: 不管什麼語言
: 大致上邏輯都是一樣的
: 演算法才重要
: VB是微軟弄出來的
: 開始是為了讓沒有學過程式語言的人
: 能夠學習程式 所以平易近人(聽一個programmer說的)
: 不適於用在開發程式
: 不過 財務上對trader而言要用到多大型程式我倒是不知道
: 但我可以猜想 應該是不用的
: 只是trader為了求速度
: 用C++應該比較好
: 但要讓老闆看
: VB老闆比較喜歡 老闆看不懂C++
: C++夠強才能弄出不醜的介面

這年頭大概已經很少人 會要求你 從使用者介面 資料庫
到財務運算 都要從頭包到尾了

實務上 一個比較成熟的 dealing room
財工人員 與 資工人員的分工 大概不太會混淆
前面所說的介面到資料庫等跟財務演算法比較無關的部分
多數狀況下會由資工人員完成 (always 有例外, e.g. GS 的 swap desk)

至於 modeler 比較會被要求的成品
通常是一個封裝好 跑得動的 DLL (Dynamic Linking Library)
DLL 裡面不外就是一堆 function
function 的內容 可以是你的 LMM kernal
或者是被(可能是前人早就完成的) LMM 所驅動的特定 product的pricing module
甚至是你企圖要整合 cap/swaption vol.的 calibration algorithm

至於程式語言的選擇 比較完整的答案 應該說是:
端視你要評價的商品或任務目的而定
如果你是作 mechanical trading 手邊用的是 tradestation
那即使你用的是他們內建的 easy language 也無可厚非

但如果你作的是 fixed income modeling
以今天利率商品的複雜度
(舉例來說 隨便一個理專都能琅琅上口的
Daily fixing的Quanto CMS Spread Swap
光是要算出價格與幾個 Greeks
幾億次的運算就跑不掉)
難以想像用 VB 所包出來的 DLL
甚至更離譜的 赤裸裸的直接用 VBA/Excel
能夠 support 這種數以億計的運算要求
這種時候 C++ 就成了難以替代的選項

更細膩的分工下 還有不同的考量
同樣是作財務運算
front end 的所謂 Desk Quant
跟一般 middle office 的 quant
對同樣的產品 也會有不同的環境壓力與業務目的
相形之下 也會醞釀出不同的 coding 方式與文化
以及最適合的程式開發環境

另外強調一點
在學校上財務演算法時 唯一重要的 可能不外是 algorithm
每一個作業裡 大家都被假設成一個交易系統 或一個評價程式的原創者
同時 多數作業也不會要求你 在有限的時間內跑出避險參數
所以 程式語言的選擇 相形之下就顯得無關緊要
物件導向的觀念 就顯得可有可無
高速運算的意義 看起來也無關緊要

但現實世界的財務演算
十之八九 你必須在別人已經搭建的相當完整的函式庫上
繼續堆砌出新的物件(in DLL, of course)
在這種環境下 物件導向的觀念成熟與否
重要性絕對不下於財務演算法本身

同時 當身處一個 volatile 的市場環境下
能不能在 curve / price 跑掉前 "及時"給出"可靠的"避險參數
對所謂的 desk quant 也至關重要
簡單舉個例子
當 swap market 出現 convexity buying
半小時內 curve 震盪了十幾個 basis points
cap/swap vol 在 intra-day 一下跳了幾 percent
trader 急於作動態避險的時刻
一個能在一兩個鍾頭 甚至更短時間內 給出精確度夠高的 Greeks 的程式
與使用相同演算法 卻需要跑上幾個鐘頭甚至一整天 的程式之間
其價值相差何只十萬八千里


: 但介面又重要嗎 ?
: 哪一個好
: 學VB or C++?
: C++會 VB好上手 VB會 C++好上手
: 工作或研究 給自己求速度 或是給老闆觀賞
: C++夠不夠強
: 等等等等..
: 既然學了C++ 那就認真學摟
: 相信C++ 可以從中得到很多好處

--