: : 我希望利用暑假时继续去学程式语言 : : 我该继续学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++ 可以从中得到很多好处 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.228.220.9 ※ 编辑: zzboy 来自: 61.228.220.9 (05/03 23:11) ※ 编辑: zzboy 来自: 61.228.220.9 (05/03 23:14)