Расчет Цены опциона если...
Atom Ответить
22.05.2013


Кто пробовал сделать такое :

Расчитать цену опциона елси цена базового актива изменится на 1000 пунктов или скажем будет равна определенному значению.

Например сейчас БА стоит 144000, как мне расчитать цену опциона при цене БА 141000 ?

Проблема в том как мне подвязать к опциону созданий мною виртуальный БА с ценой 141000 ?

Подкиньте идейку реализации такого.

Но нужно что б этот расчет никак не повлиял на другие расчеты по даному опциону.

Теги:


Спасибо:




4 Ответов
longtrades

Фотография
Дата: 22.05.2013
Ответить


Если я сделаю такое :
Код

 var bs = new BlackScholes(option);
 bs.UnderlyingAsset.LastTrade.Price = 141000;


не изменит ли это LastTrade.Price самого инструмента БА ?
Автор топика
Спасибо:

Дюшес

Фотография
Программист
Дата: 28.05.2013
Ответить


longtrades Перейти
Если я сделаю такое :
не изменит ли это LastTrade.Price самого инструмента БА ?

LastTrade.Price на каждом тике меняется, поэтому, наверное, толку от этого не будет.

Может быть так:
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 28.05.2013
Ответить


Коллеги, надо наверное сделать статически формулы. Я сам в свое время не допёр до этого, повелся на ООП. К сожалению, ООП и алготрейдиинг идут не в ногу (громко сказано, но реально это так). Уже и сам не раз натыкался на, скажем, ограниченность существующих классов. Подумаю, как лучше сделать.
Спасибо:

VassilSanych

Фотография
Дата: 29.05.2013
Ответить


Михаил Сухов Перейти
Коллеги, надо наверное сделать статически формулы. Я сам в свое время не допёр до этого, повелся на ООП. К сожалению, ООП и алготрейдиинг идут не в ногу (громко сказано, но реально это так). Уже и сам не раз натыкался на, скажем, ограниченность существующих классов. Подумаю, как лучше сделать.

ООП многогранен, особенно в C#, где он переплетается с событиями, функциональщиной и декларативностью.
(Кстати в StockSharp.Xaml вы смачно WPF изнасиловали. Но это не совсем ваша вина. Там всё очень жёстко. Без поллитры не разберёшься. )
Я продолжаю настаивать, что для алго ООП - это самое то, что доктор прописал.

Места, где ООП не рулит:
- принципиально функциональная логика
- хранение данных
- аспекты
- распределённые транзакции
- межпроцессное/межсерверное взаимодействие
Последние два случая немного (но не до конца) лечит WCF.
Косяки с непролезанием интерфейсов через коллекции уже замечательно вылечили.
Дженерики тоже очень хороши (Говорят, они были в движке изначально. Поэтому так всё и ускоряют.)

Ограниченность классов - это не проблема ООП, а проблема реализации.

Обращаю внимание на BLToolkit. Там довольно эффективно решаются вторая и третья проблемы, а также ещё лучше реализуется клонирование, мапинг объектов, работа с коллекциями и устраняются тормоза Reflection.

Статика вредна, потому что она к хренам ломает все принципы ООП (препятствует наследованию и т.п.)
Кстати о наследовании: было бы замечательно, если бы бОльшая часть private полей в той же Strategy и других основных классах была protected (хотя бы те, которые подразумевают какие-то сущности). Это бы на порядок облегчило жизнь.
Если боитесь излишнего их использования, сделайте класс-наследник-фасад (точнее, можно перенести основной функционал в какой-нибудь Base, а старый класс сделать фасадом, как было в старом добром Delphi)
Правда в C# с этим не заморачиваются, а просто используют в качестве ограниченных фасадов интерфейсы (к слову о статике, которая этого не позволяет).

Спасибо:


Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy