目前我只知道VB可以做到
TS不知道可不可以 (要查一下 TS function reference)
回復 30# 我愛紅茶
沒錯, Visual Studio 2010 就是 NET (NET Framework 4.0)
還有第一步是想寫
= ="策略下單功能
台灣券商軟體不是僅限一兩套有特殊功能
不然就是幾乎都沒
下單的策略~重點性不輸給盤面分析和技術分析
而盤面分析在台灣的軟體，則全都是土法煉鋼在看
技術分析就比較沒問題，很多軟體都有很多強大技術分析支援
重點是在盤面分析
因為那種東西是屬於在腦海中，虛無飄渺卻可用的東西(賓神操作法)
懂了和能用轉成程式~運作我知道~整合重點也知道~誰是主要觀察對象也知道
但就是不知道怎麼整合起來在程式中
最多的只有以前BLUE寫過的五大期指整合這樣
但是那個功能無法拿來操作，因為看法不是單純五大期指那樣看
還要參考時間點、量能等很多因素
不同時間就要調整策略
@@所以~為什麼我有興趣開發~也是在這裡
最後則是在於法人資訊的架構
這才是我以前慣用的方法籌碼面
籌碼面其實應該EXCEL就能架構出來
= ="偶連EXCEL都不太會了
台灣軟體過度偏重在價格分析了(技術分析)
對於重要的好比量這種東西幾乎沒人在注重
偏偏操作會看量，勝率可以大幅度提升
甚至還能預測盤的方向
這比單純只看價格要準確多
在股票是無庸置疑~卻難在期貨相關的軟體看到(台灣這方面根本是沙漠~只能偶而看到一朵花)
國外的量和價的開發
已經是兩者做到相輔相成~同步的地步了
台灣都還是停留在各管各的~沒個統一
所以真的很多東西要團體好辦事
單憑個人單打獨鬥~眼界和方法會大大侷限某個地方
甚至會先入為主就自我受限住了
其實台灣對於法人資訊的透露
是算不錯的了
甚至還影響到法人因為知道什麼資訊透露嚴重性
而不願意進入台灣市場佈大單
但是大單佈在哪裡，卻又有人搞錯方向去~甚至時間也搞錯(我知道業內自營商在搭配有時間性規劃)
這些好用資訊都是可以程式化拿來操盤的
小弟當初開發的,也連接到台指,大盤與3個參考指數做分析
發現太過複雜,相關係數變化有點亂,規則不宜固訂,又要做調整
複雜到一直簡化 @@
基本上,以你說的功能我都應該有了
紅茶兄說的籌碼面,不知是那方面的
搞不好這功課我已經做過了
發現太過複雜,相關係數變化有點亂,規則不宜固訂,又要做調整
說的籌碼面,不知是那方面的 ...
linchiyh 發表於 10-11-14 01:36 AM http://www.coco-in.net/images/common/back.gif
別叫我兄= ="偶是個少年ㄟ(噗哈哈)
沒錯~賓神操作法如果沒有用到一定程度
別說寫成軟體，光單純要理解到可以實際應用
就是一段長路了
人腦到後面可以解讀出來
可是程式可能就真的會變得很複雜，因為實際原因就是變數
但其實變數也有規律
只要什麼時間掌握什麼重點做出不同的下單策略就可以應用
只看分析~一定死
好比什麼狀況該用突破~什麼時候有賺就跑~什麼時候可以凹單~
這只是單純的下單策略喔~還沒搭配到市場分析中
至於籌碼面我想很可能你有研究過
回復 35# 我愛紅茶
的確,某些時段發生某些現象的機率偏高,就會有東西可以吃 {:4_82:}
問一下關於這點
如果用一個聯合開發平台~你們認為有無可能性?
但@@還是希望可以直接用到2010~或許有雲端強者看到~也可以加入整合{:4_163:}
聯合開發平台 ...
我愛紅茶 發表於 10-11-14 01:51 AM http://www.coco-in.net/images/common/back.gif
怎麼說~就像linux
初始沒什麼應用軟體和系統套件
但來到現在已經是千奇百怪的模組套件可用
多人共同開發，最後就可以自己挑出需要的模組去使用
每個人都有每個人的強項
開發成模組，甚至模組發布後還會被在更新開發
變得更強大
大家只需要各取所需要的模組來用
這樣結果可能就可以包山包海~形成一個很大的隊
只要模組數量一多
其實也不會有那種擔心一堆人都用同種東西的結果
造成市場都在擠一個點的現象發生
只是這真的要沒私心的人才做得出來的
在台灣有私心的人還是大過無私的人
所以台灣的一堆資訊都很落後、功能甚至簡直是原始時代
還要被強迫在某個券商才有什麼功能
這其實對大多數人甚至自己
都是很不利的
特別是關係到手續費價格
卻只能被綁住在哪個券商(幸好現在有API)
回復 32# powermm
裡面提到的東西~真的讓人很動心想去學呢{:4_199:}
.net 本身就是跨平台的一種設計
意味著學VB ,VC , c# 都可以加入同一個team開發同個project
所以選一個語言學就可以了
重點是.....
你的模組設計,要易於擴充
這可是一件累人的大工程 (思考與架構時間 > 程式編寫時間)
所以,要有一位熟知程式語言 與 交易需求的人
架構出這個模子 @@ (光想就覺得頭痛了)
如果沒有擴充性,單純把功能寫出來,可能會比較簡單
可是可能會累死軟體開發者吧 (如果要修改功能)
你的模組設計,要易於擴充
這可是一件累人的大工程 (思考與架構時間 > 程式編寫時間)
所以,要有一位熟知程式語言 與 交易需求的人
架構出這個模子 @@ (光想就覺得頭痛了)...
linchiyh 發表於 10-11-14 02:03 AM http://www.coco-in.net/images/common/back.gif
這點要怎樣做到呢?
以COCO的資源，交易需求的資訊非常多
很多方法都有人在用，大家大概也都能交流的都交流
至於熟知程式語言我就比較不清楚
你在說的中間者
就像是我以前做維修時，人家大樓要牽資訊設備
需要透過中間者去跟蓋大樓的人去溝通在怎樣布局
這個人本身也要有軟硬體設備概念，知道什麼可以達成
什麼是以後會用到的，什麼是當下必備的
但是也要懂工程建築，才知道建築人員的底線在哪裡
什麼是可以做到的，什麼又是做不做到的
只要一個環節錯
就會不是氣死資訊人員、就是氣死建築的人
要做到這方面整合
真的會有難度
像我就沒能力了，對於程式交易我是基本上講難聽，大概連概念也可能都錯很大=.=
http://wiki.mbalib.com/zh-tw/%E8%AE%BE%E8%AE%A1%E6%B2%9F%E9%80%9A