я вернулся
Алексей Неботов
С одной стороны, я сейчас не имею даже законченной нулевой версии
продукта, отталкиваясь от которой можно было бы продолжить развивать
продукт.
С другой стороны виден интерес к продукту, даже если каждый десятый
подписчик рассылки и написавший мне лично станет пользователем, это
будет много.
Разработка у меня получается дольше, чем я ожидал, т.к. свой
первоначальный подход приходится пересматривать. Оказалась, что
написание для себя, и написание кода для сообщества, это очень разные
процессы. В любом случае я продвигаюсь вперед, и однажды (сроки
называть уже боюсь) опубликую результат.
Итак, я предлагаю следующие варианты:
1) ждем, пока я разражусь с архитектурой и выложу первую версию, и уже
после её публикации начнем дорабатывать
2) пытаемся как то коммуницировать, и делаем в том числе архитектуру
совместно
Правда в данный момент я не представляю в каком формате, и по каким
технологиям возможно взаимодействие на данном этапе. "Код - svn;
общение - данная рассылка" кажется мне несколько не эффективным, т.к.
мне придется очень много времени тратить на общение, и меньше времени
писать код. Но надеюсь, что меньше времени на написание кода
компенсируется, если будут приниматься правильные решения с самого
начала, и к разработке присоединятся разработчики кроме меня. Ещё из
технологий которые нравятся мне и могут помочь в общении: wiki, skype
(мой логин alexeynebotov) и docs.google.com.
Итак, те кто за первый подход, молча ждут готовой версии продукта,
которую останется только дорабатывать.
Те, кто хочет начать РАЗРАБАТЫВАТЬ продукт, пишут как они себе это
представляют. Считайте, что сейчас нет не чего, и для начала требуется
выработать технологии общения. После того как договоримся о том, как
будем взаимодействовать, я выложу код, который у меня готов.
Про личные сообщения: если есть выбор написать личное сообщение мне
или сообщение в группу, выбирайте группу!
Константин
Мог бы поучаствовать в разработке.
Сперва нужно подробно расписать, что мы хотим от программы, хотя бы в
первом приближении, и как это должно быть реализовано.
Какие библиотеку будут использоваться. Это немаловажно ( я пытался
использовать StockSharp, мне не понравилось. к тому же код закрытый)
После этого нужно составить диаграмму классов, расписать внутренние
интерфейсы. Разделить программу на модули.
Алексей Неботов
http://code.google.com/p/open-wealth-project/wiki/Modules
теперь буду детализировать описание и состав каждого модуля
любому желающему, без проблем, дам доступ на редактирование wiki.
Mikhail Sukhov
Предлагаю процесс общения не прерывать. Тоесть я за пункт 2.
Архитектура очень вкусная часть проекта, и бывает только один раз.
Допиливать напильником функционал - уже не то.
По пунктам из Вики все примерно понятно, что и как будет
функционировать. Не понятно, будут ли эти части как-то пересекаться
друг с другом по функционалу. Например, скачиватся с Финама будет
закачивать их сначала в БД, или сразу в Велс через исторический
адаптер? Или пункт Боевой запуск робота без WL. Как это предполагается
реализовать?
Алексей Неботов
"Интерфейс"
Добавил более подробное описание для модулей
Преобразование таймфрейма решил сделать функцией модуля "Данные"
итак, документ на вики обновился http://code.google.com/p/open-wealth-project/wiki/Modules
Кроме того я выложил архив, с наработками, которые я имею в данный
момент.
мне самому данные наработки не нравятся!!!
но, возможно, если Вы бегло ознакомившись с ними, то станете меня
лучше понимать.
http://code.google.com/p/open-wealth-project/downloads/detail?name=v0.zip
Елисей Саватеев
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком
группы "Open Wealth Project" в Группах Google.
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
open-weal...@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу:
open-wealth-pro...@googlegroups.com
Чтобы выполнить другие действия, посетите страницу группы
http://groups.google.ru/group/open-wealth-project?hl=ru
или проекта
http://code.google.com/p/open-wealth-project/
Внимательно почитал - достаточно продуманная архитектура. Только не обнаружил в явном виде модуля, хранящего информацию о текущих позициях и заявках, или для этих целей будет использоваться модуль "ордера?". Так же будет необходим модуль, хранящий статистику по работе текущей стратегии: прибыль, убыток, и д. т. (основные параметры , необходимые для оценки эффективности робота). Или это берет на себя WL? Я просто не имел с этой программой дела вообще и не совсем представляю как она взаимодействует с QUIK. Алексей - разделяешь ли ты понятия заявка и ордер? Правильно ли я понял, что говоря об ордере ты имеешь в виду транзакцию QUIK, а заявка это уже собственно заявка, порожденная транзакцией? Вопрос возник еще в связи с тем, что у тебя в модуле DDE указано "обновление информации о заявках в модуле Ордера". На мой взгляд удобнее, правильнее и быстрее получать информацию о статусе транзакций и заявок через API, вместо того, чтобы парсить таблицу из DDE.
--
С уважением,
Елисей Саватеев.
au100
Сожалел, что не мог подойти к проекту летом, но оказалось, что и жизнь
здесь замерла по тем же причинам, что и у меня. Пора приступать к
делу.
Естественно, я за пункт 2 всеми конечностями. не разработав
архитектуру - не сделаем нормальную вещь, а преджелка (как изветсно)
занимает больше времени и сил. Так что бумать надо на этом этапе
сообща, Вопросов пока нет, только-только сел и посмотрел все новости,
но расчитывать на меня можно и нужно. Вопоросы возникнуть через пару
дней, когда разгребу все, что накопилось за долгое отсутсвие.
С уважением всем участникам.
Алексей Неботов
> о текущих позициях
> и заявках, или для этих целей будет использоваться модуль "ордера?".
Для меня слова Заявка и Ордер - это синонимы. Как и в Quik, то что они
называют
по русски заявкой, в API у них является ORDER'ом.
Да, информация о заявках хранится в модуле Ордер
> Так же будет необходим модуль, хранящий статистику по работе текущей стратегии:
> прибыль, убыток, и д. т. (основные параметры , необходимые для оценки
> эффективности робота). Или это берет на себя WL?
Часть статистики отображает WL, но думаю захочется считать и свои
показатели,
например отношение транзакций к сделкам на FORTS.
Модуль Статистика в wiki добавил.
> Алексей - разделяешь ли ты понятия заявка и ордер? Правильно ли я
> понял, что говоря об ордере ты имеешь в виду транзакцию QUIK, а заявка это
> уже собственно заявка, порожденная транзакцией?
Повторюсь, заявка=ордер
ВСПЛЫЛ СЛОЖНЫЙ ВОПРОС !!!
транзакция это штука, которая нужна только для того, чтобы создать/
отменить заявку
к томуже они отличаются от системы к системы, от биржи к бирже.
Я выступаю за то, чтобы термин транзакция, не выходил дальше
функционала "Отправка транзакция (API)"
Хотя часть интересной статистики должна использовать информацию из
транзакций.
Но думаю эта статистика будет зависить от реализвации модуля "Отправка
транзакция (API)"
Других мест системы, знающих специфику транзакции, на мой взгляд, быть
не должно.
Ещё минус: усложнился процесс отправки транзакций MoveOrder на Фортс,
т.к. роботы не знают,
что транзакции с двумя заявками возможны.
Но т.к. данные транзакции возможны не везде, ради унификаци, этим
можно пожертвовать.
Ещё один минус знаний о транзакциях: перезагрузили систему, инфа о
заявках с биржи пришла,
а вот какие там были транзакции хз.
> Вопрос возник еще в связи с тем, что у тебя в модуле DDE указано "обновление
> информации о заявках в модуле Ордера". На мой взгляд удобнее, правильнее и
> быстрее получать информацию о статусе транзакций и заявок через API, вместо
> того, чтобы парсить таблицу из DDE.
Да, пусть обновление информации о заявках будет в "Отправка транзакция
(API)".
Просто я не имею опыта работы с API 1.1, а ранее получить данную инфу
из API было нельзя.
Т.е. по DDE мы получаем только информацию о всех сделках(дата/время-
инструмент-цена-кво)?
(до свеч агрегируем самостоятельно)
Какая инфа ещё Вам нужна?
Вообще, я считаю, что в ядре должно быть прописано минимум информации
+ стандарт для описания дополнительной инфы. И модуль считается
работающим, если обеспечивает этот минимум, а дополнительная инфа -
это на усмотрение пишущего модуль интеграции.
О стаканах:
И хочется и колется.
На самом деле сделать их не проблема, но нагрузку на систему они дают
существенную, а пользы от них с каждым годом становится всё меньше.
О позициях:
в своё время я наткнулся на грабли с получением информации об остатках
из квика (асинхронность,
запаздование и т.п.), и сейчас я рассчитываю остатки самостоятельно из
заявок (т.е. даже не из сделок).
Таким образом мне удалось синхронизирывать информацию о заявках и
остатках, и, что тоже очень важно,
разнести остатки по нескольким роботам. Думаю данный опыт можно
применить и здесь.
Минусы: Информация о сделках остается несинхронизированной. Т.е.,
например, видно, что произошло изменение
баланса заявки на 5 штук, но одной сделкой данное изменение было
осуществлено или пятью, и по какой цене не
видно. Я всегда умудрялся обходится без этой информации, но возможна
она сильно нужна Вам.
Госпада, НУЖНА ЛИ ВАМ СИНХРОНИЗИРОВАННАЯ ИНФОРМАЦИЯ О СДЕЛКАХ?
отвечая, учтите, что синхронизация
добавит в систему задержку!
О транзакциях/заявках:
я сделал так, что заявка внутри системы создается одновременно с
коммитом транзакции, т.е. даже
до того, как транзакция ушла на биржу. Просто добавил дополнительные
статусы для подобных
заявок. Это позволило роботу не знать о транзакциях, и сильно
упростило логику самого робота.
Дополнительные статусы заявок, которых нет на бирже (точнее они нам не
отображаются):
Ожидает выставления
Ожидает отмены
Ожидает перестановки
Может Вам будет интересно почитать о заявках
http://www.onixs.biz/tools/fixdictionary/4.4/msgType_8_8.html
или http://ftp.rts.ru/pub/support/FIX/old/fixgate-protocol.pdf
Кстати, для посмотревших http://code.google.com/p/open-wealth-project/downloads/detail?name=v0.zip
как Вам проект Core?
Как Вам подобная структура проекта?
Вообще, пришло время выкладывать код на svn. И надо решить какова
будет его структура.
Каюсь, я никогда не делал больших совместных проектов на c#, то как
формирует структуру папок
MSVS2010, если просто добавлять в солюшен проекты, мне не нравится. К
тому же MSVS2010 кидает
файлы в корень, если создаются UnitTest'ы.
Но для начала вопросы такие:
Есть возражения против MS Visual Studio 2010?
Есть возражения против использования встроенных в MSVS средств юнит
тестирования?
Есть возражения против зависимости от log4net?
Елисей Саватеев
Я выступаю за то, чтобы термин транзакция, не выходил дальше
функционала "Отправка транзакция (API)"
Полностью с тобой согласен и в своих наработках реализовал то же самое. Плюс не рекомендую связываться с асинхронными транзакциями, т. к. геммора много, а польза - сомнительна, по крайней мере на обычных бытовых каналах связи.
Ещё минус: усложнился процесс отправки транзакций MoveOrder на Фортс,
т.к. роботы не знают,
что транзакции с двумя заявками возможны.
Но т.к. данные транзакции возможны не везде, ради унификаци, этим
можно пожертвовать.
Не совсем понял, что ты хочешь сказать про MoveOrder. Предлагаешь вообще отказаться от нее или отказаться от перемещения двух заявок? Я в свое время хлебнул на серваках БКС с MoveOrder и косяки до сих по вылезают - то начинает неправильно отображаться поле "Активная покупка (продажа)", то они формат ответа торговой системы поменяют, то вообще транзакция переставала работать. Плюс есть еще ограничение - если используется едина денежная позиция, то двигать заявку можно только без изменения количества.
Да, пусть обновление информации о заявках будет в "Отправка транзакция
(API)".
Просто я не имею опыта работы с API 1.1, а ранее получить данную инфу
из API было нельзя.
Т.е. по DDE мы получаем только информацию о всех сделках(дата/время-
инструмент-цена-кво)?
(до свеч агрегируем самостоятельно)
Какая инфа ещё Вам нужна?
Вообще, я считаю, что в ядре должно быть прописано минимум информации
+ стандарт для описания дополнительной инфы. И модуль считается
работающим, если обеспечивает этот минимум, а дополнительная инфа -
это на усмотрение пишущего модуль интеграции.
Я в своих наработках по DDE вообще получаю только текущие котировки и лучшие бид и аск по инструменту. Все. Вся необходимая информация о сделках приходит через API. Другое дело, из какой таблицы брать котировки, особенно это касается тиковых данных. На практике я пришел к тому, что информацию эту беру из ТТП (таблицы текущих параметров), а не из таблицы всех сделок. Дело в том, что инфа в таблице всех сделок обновляется как я понял пакетно и поступает в итоге "рывками". Правда я теряю информацию об объемах в сделках и об их направлении, но лично для моих стратегий нужна только рыночная котировка и тиковый объем (количество изменений цены за промежуток времени).
О стаканах:
И хочется и колется.
На самом деле сделать их не проблема, но нагрузку на систему они дают
существенную, а пользы от них с каждым годом становится всё меньше.
Считаю не стоит тратить на это время. Ты же не скальперский привод разрабатываешь.
О позициях:
в своё время я наткнулся на грабли с получением информации об остатках
из квика (асинхронность,
запаздование и т.п.), и сейчас я рассчитываю остатки самостоятельно из
заявок (т.е. даже не из сделок).
Таким образом мне удалось синхронизирывать информацию о заявках и
остатках, и, что тоже очень важно,
разнести остатки по нескольким роботам. Думаю данный опыт можно
применить и здесь.
Минусы: Информация о сделках остается несинхронизированной. Т.е.,
например, видно, что произошло изменение
баланса заявки на 5 штук, но одной сделкой данное изменение было
осуществлено или пятью, и по какой цене не
видно. Я всегда умудрялся обходится без этой информации, но возможна
она сильно нужна Вам.
Грабли такие есть и они очень неприятные. Я с ними тоже столкнулся, но все же преодолел, по крайней мере настолько, чтобы можно было реализовывать задуманные стратегии. Синхронизация информации о позициях (сделках) с реальным положением дел в квике на мой взгляд все таки очень важна, особенно если разрабатывается робот, реализующий высокочастотную торговлю и не одним лотом. Опять же если не синхронизировать сразу информацию о сделках, как рассчитать реальную итоговую стоимость позиции (проскальзывания)? Или я чего то не так понял?
О транзакциях/заявках:
я сделал так, что заявка внутри системы создается одновременно с
коммитом транзакции, т.е. даже
до того, как транзакция ушла на биржу. Просто добавил дополнительные
статусы для подобных
заявок. Это позволило роботу не знать о транзакциях, и сильно
упростило логику самого робота.
Дополнительные статусы заявок, которых нет на бирже (точнее они нам не
отображаются):
Ожидает выставления
Ожидает отмены
Ожидает перестановки
Это верное решение, поступил аналогичным образом.
Алексей Неботов
> > функционала "Отправка транзакция (API)"
>
> Полностью с тобой согласен и в своих наработках реализовал то же самое. Плюс
> не рекомендую связываться с асинхронными транзакциями, т. к. геммора много,
> а польза - сомнительна, по крайней мере на обычных бытовых каналах связи.
асинхронные или нет, на данном этапе это не принципиально, это дело
конкретного модуля.
у меня с асинхронными всё хорошо.
Вообще, если люди подтянутся, то существование нескольких модулей
интеграции, реализующих разные алгоритмы к различным терминалам,
вполне возможно.
> > Ещё минус: усложнился процесс отправки транзакций MoveOrder на Фортс,
> > т.к. роботы не знают,
> > что транзакции с двумя заявками возможны.
> > Но т.к. данные транзакции возможны не везде, ради унификаци, этим
> > можно пожертвовать.
>
> Не совсем понял, что ты хочешь сказать про MoveOrder. Предлагаешь вообще
> отказаться от нее или отказаться от перемещения двух заявок? Я в свое время
> хлебнул на серваках БКС с MoveOrder и косяки до сих по вылезают - то
> начинает неправильно отображаться поле "Активная покупка (продажа)", то они
> формат ответа торговой системы поменяют, то вообще транзакция переставала
> работать. Плюс есть еще ограничение - если используется едина денежная
> позиция, то двигать заявку можно только без изменения количества.
Метод Изменить у заявки должен быть, это упростит роботов.
Как он будет реализован, это дело модуля интеграция.
> Я в своих наработках по DDE вообще получаю только текущие котировки и лучшие
> бид и аск по инструменту. Все. Вся необходимая информация о сделках приходит
> через API. Другое дело, из какой таблицы брать котировки, особенно это
> касается тиковых данных. На практике я пришел к тому, что информацию эту
> беру из ТТП (таблицы текущих параметров), а не из таблицы всех сделок. Дело
> в том, что инфа в таблице всех сделок обновляется как я понял пакетно и
> поступает в итоге "рывками". Правда я теряю информацию об объемах в сделках
> и об их направлении, но лично для моих стратегий нужна только рыночная
> котировка и тиковый объем (количество изменений цены за промежуток
> времени).
в WL надо давать правильные свечи, иначе весь смысл работы с WL
пропадает.
т.е. получение таблицы всех сделок на мой взгляд обязательное условие
проекта.
Итак, появились ещё данные: лучший Бид/Аск. Вспомнил, что эти данные
тоже часто использую. ЧТО ЕЩЁ?
> > О стаканах:
> > И хочется и колется.
> > На самом деле сделать их не проблема, но нагрузку на систему они дают
> > существенную, а пользы от них с каждым годом становится всё меньше.
>
> Считаю не стоит тратить на это время. Ты же не скальперский привод
> разрабатываешь.
просто, когда речь заходит о стаканах, обычно начинаются вопли, что
без них никак :)
кстати, лучший Бид/Аск - это уже почти стакан :)
> > О позициях:
> Грабли такие есть и они очень неприятные. Я с ними тоже столкнулся, но все
> же преодолел, по крайней мере настолько, чтобы можно было реализовывать
> задуманные стратегии. Синхронизация информации о позициях (сделках) с
> реальным положением дел в квике на мой взгляд все таки очень важна, особенно
> если разрабатывается робот, реализующий высокочастотную торговлю и не одним
> лотом. Опять же если не синхронизировать сразу информацию о сделках, как
> рассчитать реальную итоговую стоимость позиции (проскальзывания)? Или я чего
> то не так понял?
понял, похоже, всё так.
Что делать когда изменение баланса заявки уже произошло, а сделки ещё
нет?
И наоборот, когда сделка пришла, а заявка ещё не изменилась?
Я вижу только один выход: рассчитывать баланс заявки и её статус
самостоятельно, на основании инфы о сделках.
Т.е. закладываем в архитектуру, что информация о заявках/сделках/
остатках передается в систему из интеграции синхронизированной? Кстати
о синхронизации, без многопоточности, думаю, мы не обойдемся.
Елисей Саватеев
в WL надо давать правильные свечи, иначе весь смысл работы с WL
пропадает.
т.е. получение таблицы всех сделок на мой взгляд обязательное условие
проекта.
А какая свеча для WL является правильной? Ему нужны еще какие то данные кроме OHLC?
Что делать когда изменение баланса заявки уже произошло, а сделки ещё
нет?
И наоборот, когда сделка пришла, а заявка ещё не изменилась?
Это извечный вопрос всех роботостроителей под QUIK :)
Я вижу только один выход: рассчитывать баланс заявки и её статус
самостоятельно, на основании инфы о сделках.
На мой взгляд верное решение. Поступаю так же.
Mikhail Sukhov
> бид и аск по инструменту. Все. Вся необходимая информация о сделках приходит
> через API.
Это точно не айс. Потому как в таких программах как OWP нужна вся
информация (возможно, опционально, для оптимизации). Заранее
неизвестно, кому что понадобится. Хуже что-то не додать, чем передать.
On 2 сен, 13:03, Елисей Саватеев <elisey.savat...@gmail.com> wrote:
> 2 сентября 2010 г. 14:35 пользователь Алексей Неботов
> <anebo...@gmail.com>написал:
Mikhail Sukhov
Имеет ли смысл делать ядро с таким ограниченным функционалом? В каком
сценарии ядро будет использоваться без, скажем, модуля заявки?
On 1 сен, 18:30, Алексей Неботов <anebo...@gmail.com> wrote:
> Заметил, что упустил из несколько модулей "Данные", "Ордера" и
> "Интерфейс"
> Добавил более подробное описание для модулей
> Преобразование таймфрейма решил сделать функцией модуля "Данные"
>
> итак, документ на вики обновилсяhttp://code.google.com/p/open-wealth-project/wiki/Modules
>
> Кроме того я выложил архив, с наработками, которые я имею в данный
> момент.
> мне самому данные наработки не нравятся!!!
> но, возможно, если Вы бегло ознакомившись с ними, то станете меня
> лучше понимать.http://code.google.com/p/open-wealth-project/downloads/detail?name=v0...
Максим Кожуров
2 сентября 2010 г. 15:56 пользователь Алексей Неботов <aneb...@gmail.com> написал:в WL надо давать правильные свечи, иначе весь смысл работы с WL
пропадает.
т.е. получение таблицы всех сделок на мой взгляд обязательное условие
проекта.
А какая свеча для WL является правильной? Ему нужны еще какие то данные кроме OHLC?
Алексей Неботов
> кроме OHLC?
объем
> Это точно не айс. Потому как в таких программах как OWP нужна вся
> информация (возможно, опционально, для оптимизации). Заранее
> неизвестно, кому что понадобится. Хуже что-то не додать, чем передать.
надо определить минимум (пусть он будет даже большим), остальное
опционально,
например создать для каждой бумаги/таймфрейма
Dictionary<key,DataSeries>, где key
open
close
high
low
value
BestAsk
BestBid
мы гарантируем, остальные key (например, направление сделки)
опциональны.
меня больше беспокоет то, что DataSeries оперирует Double.
Как лучше хранить номера сделок и направление сделки?
> Понял, что теряю нить разговора... Но зачем вообще нужна модульность?
> Имеет ли смысл делать ядро с таким ограниченным функционалом? В каком
> сценарии ядро будет использоваться без, скажем, модуля заявки?
ядро описывает правила взаимодействия других модулей.
без модуля заявки система может использоваться для оптимизации
стратегии в WL.
но основная фишка не в этом, а в том, что разбитие на небольшие части:
1) позволяет точно определить, что разрабатывается и куда вносятся
изменения
2) возможно кто то сделает данный модуль лучше меня, или например,
сделает модуль
хранящий данные не в файлах, а в MSSQL, при этом просто замняем
модуль
и наслождаемся.
> зачем использовать свечи? OHLC - очень неправильные числа. Даже если
> добавить V.
> Ведь при сдвиге (вправо-влево) времени дискретизации на долю от свечного -
> вся картина меняется. И весь теханализ потому - полная чушь.
> Брать OHLC - это всё равно что из всего многообразия животного мира Земли
> взять Жирафа и Слона и сказать - Землю населяют только высокие и толстые
> животные.
> И кто говорит, что нужно дискретизировать по времени? можно сделать то же
> самое по объему например, или по другим параметрам.
> Ведь получая и используя полный объем инфы (тики с временем, объемом и,
> возможно, направлением сделки) мы явно выиграем. Свечки можно и самому
> нарисовать если нужно. Свечки - производная информация.
я отталкиваюсь от WL, он оперирует свечами.
размер свечи может быть равен тику, или, например 100 тикам, или
постоянный объем
недостаток WL при работе с тиками: нет понятия номер сделки, и чтобы
его
хранить в DataSeries приходится представлять в виде Double
Mikhail Sukhov
> самое по объему например, или по другим параметрам.
В точку. Тоже не понимаю, почему нужно сделать все, как в Велсе. Надо
давать возможность пользователю резать самому по тиковой базе так, как
нужно... Более того, для точного тех анализа надо дать возможность
хранить и стаканы (произвольной глубины). Велс явно не лидет в ТА по
возможностям. Он самый популярный, и только.
On 2 сен, 17:36, Максим Кожуров <mak...@kozhurov.ru> wrote:
> 2 сентября 2010 г. 14:09 пользователь Елисей Саватеев <
> elisey.savat...@gmail.com> написал:
>
>
>
> > 2 сентября 2010 г. 15:56 пользователь Алексей Неботов <anebo...@gmail.com>написал:
Mikhail Sukhov
написанное про ТА данные.
Максим Кожуров
Подумал лучше. Велс даже не самый популярный... Но это не отменяет
написанное про ТА данные.
Алексей Неботов
> давать возможность пользователю резать самому по тиковой базе так, как
> нужно... Более того, для точного тех анализа надо дать возможность
> хранить и стаканы (произвольной глубины). Велс явно не лидет в ТА по
> возможностям. Он самый популярный, и только.
Велс позволяет работать и с тиками и со свечами, агрегированными не по
времени.
Стаканы добавляются в Велс на два счета, проблема в том, что со
стаканами в итоге делать.
Велс не самый популярный
http://www.google.com/insights/search/?hl=ru#q=Wealth%20lab%2CAmi%20Broker%2CMetaStock%2CTradestation%2CNinja%20Trader&date=1%2F2008%2012m&cmpt=q
> Я прогнозировал движение фьюча РТС по методу Гусеница (SSA), (http://www.gistatgroup.com/gus/index.html- например здесь можно
> ознакомиться) - результат меня очень порадовал. Единственная возникшая
> проблема - с технической реализацией и автоматизацией.
Какие торговые данные кроме тиковых или свечей нужны в данном методе?
To > Mikhail Sukhov
думаю мы не поняли друг друга в том "что такое модуль". Добавил в вики
раздел "Описание взаимодействия" http://code.google.com/p/open-wealth-project/wiki/Modules
Господа, давайте не обсуждать то, чего нет в Wiki, т.к. это потом всё
равно забудется.
Т.е. предложения и вопросы должны быть такими:
Думаю в wiki не хватает тогото ...
Думаю в wiki тото написано не правильно ...
Кроме того, по желанию, могу дать права на редактирование wiki.
Добавил в wiki страницу http://code.google.com/p/open-wealth-project/wiki/Environment
Кто нибудь работал с функционалом http://www.google.com/moderator/ ?
Чувствую, что он был бы нам полезен, но пока не смог понять как.
Максим Кожуров
Велс позволяет работать и с тиками и со свечами, агрегированными не по
времени.
Стаканы добавляются в Велс на два счета, проблема в том, что со
стаканами в итоге делать.
> Я прогнозировал движение фьюча РТС по методу Гусеница (SSA), (http://www.gistatgroup.com/gus/index.html- например здесь можноКакие торговые данные кроме тиковых или свечей нужны в данном методе?
> ознакомиться) - результат меня очень порадовал. Единственная возникшая
> проблема - с технической реализацией и автоматизацией.
Mikhail Sukhov
> стаканами в итоге делать.
Тогда я не понял функционал Велса. В него можно добавлять стаканы для
тестирования на истории, или просто для отображения реальных стаканов,
что есть в самом Квике?
On 3 сен, 11:31, Алексей Неботов <anebo...@gmail.com> wrote:
> > В точку. Тоже не понимаю, почему нужно сделать все, как в Велсе. Надо
> > давать возможность пользователю резать самому по тиковой базе так, как
> > нужно... Более того, для точного тех анализа надо дать возможность
> > хранить и стаканы (произвольной глубины). Велс явно не лидет в ТА по
> > возможностям. Он самый популярный, и только.
>
> Велс позволяет работать и с тиками и со свечами, агрегированными не по
> времени.
> Стаканы добавляются в Велс на два счета, проблема в том, что со
> стаканами в итоге делать.
> Велс не самый популярныйhttp://www.google.com/insights/search/?hl=ru#q=Wealth%20lab%2CAmi%20B...
>
> > Я прогнозировал движение фьюча РТС по методу Гусеница (SSA), (http://www.gistatgroup.com/gus/index.html-например здесь можно
> > ознакомиться) - результат меня очень порадовал. Единственная возникшая
> > проблема - с технической реализацией и автоматизацией.
>
> Какие торговые данные кроме тиковых или свечей нужны в данном методе?
>
> To > Mikhail Sukhov
> думаю мы не поняли друг друга в том "что такое модуль". Добавил в вики
> раздел "Описание взаимодействия"http://code.google.com/p/open-wealth-project/wiki/Modules
>
> Господа, давайте не обсуждать то, чего нет в Wiki, т.к. это потом всё
> равно забудется.
> Т.е. предложения и вопросы должны быть такими:
> Думаю в wiki не хватает тогото ...
> Думаю в wiki тото написано не правильно ...
>
> Кроме того, по желанию, могу дать права на редактирование wiki.
>
> Добавил в wiki страницуhttp://code.google.com/p/open-wealth-project/wiki/Environment
Алексей Неботов
> тестирования на истории, или просто для отображения реальных стаканов,
> что есть в самом Квике?
Стаканы вынес в отдельную тему, и обсуждать предлагаю отдельно.
На мой взгляд, это явно не первый приоритет. Хотя помнить о них нужно,
т.к. потом всё равно делать придется, и надо чтобы в архитектуру легли
они нормально.