PTT職涯區 / Option (期貨與選擇權)

Re: [轉錄][問題] 這有違反選擇權原理嗎？笑了

看板Option (期貨與選擇權)作者 (迷路的羔羊)時間15年前 (2011/01/25 12:36), 編輯推噓8(8推 0噓 35→)
留言43則, 14人參與, 最新討論串4/47 (看更多)
不好意思 圖借我改一下 ※ 引述《hhhhhhhh (....)》之銘言： : 不好意思圖應該是長這樣吧 : 借我改一下 今天苦主出現的狀況應該是這樣 ｜ / ｜ / +獲利 ｜ /------->此區為獲利理論上最大為無線 ｜ / ｜ / 0損益兩平｜==================================== ｜ / <---- ﹃此區是苦主原本的市價"3點"的虧損 ｜/.........』... ｜ / -虧損 /｜ / <----這區是造成滑價莫名其妙多出來的價位， / ｜ / 以630點成交價來說，如果大盤跌到7000點則有 / ｜ / 機會損益兩平，或是用630掛賣則不會出現虧損 / ｜ / 今天的虧損是怎麼來的? / ｜ / 是buy 630,sell 3，是平倉造成的虧損 ｜ / 跟你系統怎麼掛單無所謂，因為是已成交的部位! ｜ / 所以虧損是要把兩個部位合起來就會變成這樣.... ｜ / ｜ / ｜ / +獲利 ｜ / ｜ / ｜ / 0損益兩平｜==================================== ｜ / ｜ / ｜ / -虧損 ｜ / ｜ / <---- 30萬 = 1000萬 (?) ｜ / ｜ / ｜ / ｜ / 這張圖是苦主成交600多口後 當下所擁有的部位 因為都是BP的部位，所以合併起來變成這樣! 但是今天的問題是，30萬的保證金不可能造成將近千萬的虧損區域 那虧損哪來的呢? 一定不是微分微出來的~ (被毆 所以今天問題要探討的部位是這條線是怎麼成立的 小弟不才，不知道事實的真相，真相應該只有友驊知道 (再度被圍毆....) 系統當時的判斷應該是 if 保證金 > 委買口數 X 價格 then 掛單 end 當時的話，"也許"系統是這樣判定的 1000口 X 3 市價(=當時的成交價) X $50 = 15萬新台幣 條件成立，准許掛單 可是當滑價出現，系統沒有再檢驗一次條件 所以出現了BUG的漏洞 這是我目前唯一想到的可能性! 因此，那條國王的虧損線 應該是系統出現的判斷問題，就像很多新手學寫程式 都寫出無限回圈一樣 因此跟圖形沒有關係，是跟系統條件成立有關係，就是漏洞。 以上請鞭小力點........ : 兩邊都有錯吧!! : 期貨公司不該讓超出帳戶金額的部分成交， : 而苦主一次下1000口也很不合常理， : 苦主是新手嗎？？ : 因為最後也只成交600多口， : 也許真的有我們所不知的內幕。 : 斜線沒有對的很準請見諒 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.38.12.162
推
01/25 12:37, , 1F
再講一次..此例沒有保證金的問題
01/25 12:37, 1F
我沒說保證金有問題.....保證金是沒問題，有問題的是系統的判斷 方式造成的。
推
01/25 12:38, , 2F
友樺:不要一天到晚找我出來講話要車馬費
01/25 12:38, 2F
推
01/25 12:38, , 3F
苦主要解套 除非再來一次金融海嘯.911?
01/25 12:38, 3F
→
01/25 12:38, , 4F
都說不是保證金交易了 zzzzzZZZZZZZ
01/25 12:38, 4F
保證金沒有問題......文中說的是系統判斷+上市價單的定義 就出現了問題! ※ 編輯: rightX 來自: 114.38.12.162 (01/25 12:39)
推
01/25 12:40, , 5F
沒關係拉 有笑有推
01/25 12:40, 5F
推
01/25 12:41, , 6F
系統設計沒考慮到滑價時的保證金問題...誰的錯?
01/25 12:41, 6F
→
01/25 12:41, , 7F
系統程式的問題~苦主別傻傻的背這條!!
01/25 12:41, 7F
→
01/25 12:42, , 8F
系統設計沒考慮到......寫程式本來就要考慮所有可能的狀況
01/25 12:42, 8F
→
01/25 12:46, , 9F
哪位高手程式設計師可以設計一套交易系統考慮所有可能
01/25 12:46, 9F
→
01/25 12:47, , 10F
程式"不可能"考慮到所有的可能,當個系統開發設計人員這是
01/25 12:47, 10F
→
01/25 12:48, , 11F
程式設計是以雇主的需求為主。
01/25 12:48, 11F
→
01/25 12:48, , 12F
的確是不可能考慮到所有狀況，但是可以跑模擬
01/25 12:48, 12F
→
01/25 12:48, , 13F
必須要面對的事實.有問題的不是程式而是交易邏輯
01/25 12:48, 13F
→
01/25 12:49, , 14F
還有營業員當下也要把關......
01/25 12:49, 14F
→
01/25 12:49, , 15F
rightX如果你是KG的系統開發商在這個模擬下你只能得出
01/25 12:49, 15F
→
01/25 12:49, , 16F
交易邏輯也是有問題~所以問題都不再客戶....
01/25 12:49, 16F
→
01/25 12:49, , 17F
程式設計是以「試用者」的需求為主，所以才要防呆
01/25 12:49, 17F
→
01/25 12:50, , 18F
兩種結果1.不做市價委託 2.請KG另請高明
01/25 12:50, 18F
→
01/25 12:50, , 19F
這跟防呆無關,而是接單下單系統根本不知道市價會多少
01/25 12:50, 19F
→
01/25 12:51, , 20F
只能模擬一個市價然後比對帳戶金額是否足夠
01/25 12:51, 20F
推
01/25 12:51, , 21F
XD　營業員是要怎麼把關　ioc幾秒內成交光　營業員閃電俠嗎
01/25 12:51, 21F
→
01/25 12:51, , 22F
這是電子交易不是臨櫃交易
01/25 12:51, 22F
→
01/25 12:52, , 23F
不會有正妹打電話親切的告訴你剛剛虧了九百萬
01/25 12:52, 23F
→
01/25 12:54, , 24F
程式設計者可以加任何的條件去防止這個事件，但要不要這麼
01/25 12:54, 24F
→
01/25 12:55, , 25F
您所謂的任何條件.除非廢除市價交易.否則只要開著就沒得
01/25 12:55, 25F
→
01/25 12:55, , 26F
補.重點只有一個下單系統如何知道事先知道最後交易價
01/25 12:55, 26F
→
01/25 12:56, , 27F
做？這就是雇主的考量了，對程式設計師來說，user是指雇主
01/25 12:56, 27F
我指的是 他的程式每成交完一次就在重複一次 這樣當價格滑到40幾的時候，條件就不會成立，就會被擋下 ※ 編輯: rightX 來自: 114.38.12.162 (01/25 12:58)
→
01/25 12:57, , 28F
可雇主來說，或許他希望系統效率快，而市價單這種事對客戶
01/25 12:57, 28F
→
01/25 12:57, , 29F
做教育訓練就可以了。
01/25 12:57, 29F
→
01/25 12:58, , 30F
賣車的需要解釋車的特性,但是不負責教開車呀
01/25 12:58, 30F
→
01/25 12:59, , 31F
rightX大.當您一次喊兩百口出去要買的時候是一次出去搓合
01/25 12:59, 31F
→
01/25 12:59, , 32F
而不是一次喊個十張一次喊個十張,盤勢是不等人低....
01/25 12:59, 32F
→
01/25 13:00, , 33F
如果沒有一次成交完就可以再跑一次....
01/25 13:00, 33F
→
01/25 13:00, , 34F
這樣的做法是不符合交易特性的壓.不如就砍掉市價委託
01/25 13:00, 34F
→
01/25 13:06, , 35F
也就是完全不讓客戶做.或者是之前某個大大說的限制客戶
01/25 13:06, 35F
→
01/25 13:06, , 36F
某些特性的客戶可以做某些不能
01/25 13:06, 36F
推
01/25 13:14, , 37F
有沒可能凱x的主機功能不夠強?!因為在成交的瞬間一定有一個
01/25 13:14, 37F
→
01/25 13:14, , 38F
界點 就是保證金不足 可是程式沒能夠檔下來
01/25 13:14, 38F
→
01/25 13:15, , 39F
成交與否不是凱基的主機判斷的呀
01/25 13:15, 39F
→
01/25 13:16, , 40F
可是應該能判斷裡面金額夠不夠阿
01/25 13:16, 40F
推
01/28 18:13, , 41F
苦主是權利金不是保證金啦
01/28 18:13, 41F
→
08/12 23:24, , 42F
補.重點只有一個下單系 https://noxiv.com
08/12 23:24, 42F
→
09/15 06:35, , 43F
苦主要解套 除非再 https://daxiv.com
09/15 06:35, 43F
‣ 更多 rightX 的文章
文章代碼(AID): #1DFbDhTN (Option)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 4 之 47 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共47篇)
Option 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 rightX 的文章
文章代碼(AID): #1DFbDhTN (Option)