Чтобы можно было открывать и работать в роботе с разными таймфреймами, лучше передавать именно сделки и их в свечи превращать
Трафик большой. Можно передавать минутные свечи и на их основе строить уже другие тайм-фреймы.
Правда теряем подробную информацию по сделкам и возможность строить, например, секундные тайм-фреймы, если кому-то это нужно.
]]>slkumax пишет:В первую очередь "всех сделок" для построения графиков и создания свечей
Если сделки нужны только для построения свечей, то можно передавать не все сделки, а сразу готовые свечи.
Чтобы можно было открывать и работать в роботе с разными таймфреймами, лучше передавать именно сделки и их в свечи превращать
]]>slkumax,
я, признаться, никак не пойму суть вопроса. В чем именно у вас затруднение?
Потому как, вы уж извините, но пока читаю ветку - постоянно хочется крикнуть по Станиславскому: "Наймите уже программиста!"
Ну вот правда. В чем конкретно сейчас у вас затруднение?
Написал Вам на почту неделю назад. Вы не ответили пока что.
]]>В первую очередь "всех сделок" для построения графиков и создания свечей
Если сделки нужны только для построения свечей, то можно передавать не все сделки, а сразу готовые свечи.
]]>я, признаться, никак не пойму суть вопроса. В чем именно у вас затруднение?
Потому как, вы уж извините, но пока читаю ветку - постоянно хочется крикнуть по Станиславскому: "Наймите уже программиста!"
Ну вот правда. В чем конкретно сейчас у вас затруднение?
slkumax,
вы говорите про получение "сделок" (своих) или "всех сделок" из QUIK ?
В первую очередь "всех сделок" для построения графиков и создания свечей
Во вторую очередь уже скорее для торговой части это "сделки, заявки, стоп заявки" но это как раз не срочно.
]]>вы говорите про получение "сделок" (своих) или "всех сделок" из QUIK ?
]]>А с терминалом все сложно- он привязан к одному конкретному компьютеру и ни на какой другой его просто так не поставить
Как следствие если писать сразу связку к нему, то процесс тестов усложняется и затягивается в разы.
Потому я пытаюсь сейчас откопать адекватную информацию или готовую связку qLUA и C++
]]>Правильно ли я понимаю что на QLua графические возможности и возможности работать с создаваемыми объектами будут крайне ограничены, и потому проще именно эти функции уже выполнять на Си?
]]>ну, в общем, понятно.
скажу со своей стороны - мне неинтересно развивать чужое направление - если я в силах создать собственное. поэтому, работа, как таковая - мне неинтересна. Но, если будут интересные вопросы по Вашему проекту - готов их обсуждать и что-то советовать, как впрочем, и многие находящиеся здесь другие.
Сейчас текущие вопросы следующие:
нужно выбрать язык (или смесь языков), который бы качественно работал с квиком и при этом в нём можно было достаточно адекватно работать с "объектами"
Поясню: в программу приходит только таблица сделок.
Эта таблица сделок превращается в свечи. (тут всё легко естественно)
Далее по определённому алгоритму, из набора свечей получаются движения. Причём у нас есть движения в прошлом, которые уже закончились и движение в настоящем, которое сейчас развивается. Еще при этом из этих движений по определённому алгоритму получаются движения более старших порядков.
Так вот каждое движение , это объёкт, у которого есть набор свойств, пример: продолжительность по времени, размер по проходу в пунктах, достижение целей и еще много разных. (но все эти свойства можно получить исключительно из изначальных данных)
Пример еще одного типа объектов обладающий своими свойствами это "поза". У неё тоже есть набор определённых свойств, такие как: размер, направление, цели итд. Таких поз может быть несколько. А может быть одна, но внутри которой заложено несколько частей с разными целями.
Еще один объект, это время. У него всего два свойства, реальное время и "состояние", ну т.е например "вечерка" или "первые 30 минут торгов". Эти состояния тоже фиксированы.
И таких типов объектов около 10.
А теперь главная идея. Чтобы качественно получать сигналы (даже для начала не торговые, а именно для алгоритма получения всего что требуется), нужно чтобы программа умела анализировать не только сами объекты, но и их взаимодействие.
Банальный пример взаимодействия перечисленных объектов: Если движение больше стандартных размеров в N раз, и у нас по нему открыта плюсовая поза, при этом это движение не достигло целей, но уже наступила вечерка, то позу надо закрыть.
Мне сложно рассказать тут что-либо более подробно, так как у нас в работе уже давно используется собственная терминология и все объекты названы своими названиями и все их типы взаимодействий и влияний известны. И чтобы пояснить что-то подробнее, нужно пояснять термины и понятия тоже.
На данный момент мне кажется что оптимальным сочетанием будет:
1) основная программа, написанная на Си, которая состоит из модулей.
2) LUA скрипт, который будет из квика передавать все требуемые данные в нашу программу и от нашей программы принимать торговые сигналы, которые потом будет выполнять.
В последствии LUA скрипт можно будет заменить на что-то например для связи с PLAZA2
Аналогично как я понимаю работает QScalp (скальперский привод) и ещё некоторые программы.
Если кто-то пояснит с какой стороны подойти к этому вопросу, буду очень признателен.
Первым шагом как я понимаю должно быть написание LUA скрипта, который бы "отдавал" нам таблицу сделок в онлайне, и написание программы на Cи, которая эту таблицу бы понимала и превращала в свечи.
]]>