Чтобы можно было открывать и работать в роботе с разными таймфреймами, лучше передавать именно сделки и их в свечи превращать

Трафик большой. Можно передавать минутные свечи и на их основе строить уже другие тайм-фреймы.

Правда теряем подробную информацию по сделкам и возможность строить, например, секундные тайм-фреймы, если кому-то это нужно.

slkumax пишет:

В первую очередь "всех сделок" для построения графиков и создания свечей

Если сделки нужны только для построения свечей, то можно передавать не все сделки, а сразу готовые свечи.

Чтобы можно было открывать и работать в роботе с разными таймфреймами, лучше передавать именно сделки и их в свечи превращать

slkumax,

я, признаться, никак не пойму суть вопроса. В чем именно у вас затруднение?

Потому как, вы уж извините, но пока читаю ветку - постоянно хочется крикнуть по Станиславскому: "Наймите уже программиста!"
Ну вот правда. В чем конкретно сейчас у вас затруднение?

Написал Вам на почту неделю назад. Вы не ответили пока что.

В первую очередь "всех сделок" для построения графиков и создания свечей

Если сделки нужны только для построения свечей, то можно передавать не все сделки, а сразу готовые свечи.

я, признаться, никак не пойму суть вопроса. В чем именно у вас затруднение?

Потому как, вы уж извините, но пока читаю ветку - постоянно хочется крикнуть по Станиславскому: "Наймите уже программиста!"
Ну вот правда. В чем конкретно сейчас у вас затруднение?

slkumax,

вы говорите про получение "сделок" (своих) или "всех сделок" из QUIK ?

В первую очередь "всех сделок" для построения графиков и создания свечей

Во вторую очередь уже скорее для торговой части это "сделки, заявки, стоп заявки" но это как раз не срочно.

вы говорите про получение "сделок" (своих) или "всех сделок" из QUIK ?

А с терминалом все сложно- он привязан к одному конкретному компьютеру и ни на какой другой его просто так не поставить
Как следствие если писать сразу связку к нему, то процесс тестов усложняется и затягивается в разы.

Потому я пытаюсь сейчас откопать адекватную информацию или готовую связку qLUA и C++

Правильно ли я понимаю что на QLua графические возможности и возможности работать с создаваемыми объектами будут крайне ограничены, и потому проще именно эти функции уже выполнять на Си?

ну, в общем, понятно.
скажу со своей стороны - мне неинтересно развивать чужое направление - если я в силах создать собственное. поэтому, работа, как таковая - мне неинтересна. Но, если будут интересные вопросы по Вашему проекту - готов их обсуждать и что-то советовать, как впрочем, и многие находящиеся здесь другие.

Сейчас текущие вопросы следующие:
нужно выбрать язык (или смесь языков), который бы качественно работал с квиком и при этом в нём можно было достаточно адекватно работать с "объектами"
Поясню: в программу приходит только таблица сделок.
Эта таблица сделок превращается в свечи. (тут всё легко естественно)
Далее по определённому алгоритму, из набора свечей получаются движения. Причём у нас есть движения в прошлом, которые уже закончились и движение в настоящем, которое сейчас развивается. Еще при этом из этих движений по определённому алгоритму получаются движения более старших порядков.
Так вот каждое движение , это объёкт, у которого есть набор свойств, пример: продолжительность по времени, размер по проходу в пунктах, достижение целей и еще много разных. (но все эти свойства можно получить исключительно из изначальных данных)

Пример еще одного типа объектов обладающий своими свойствами это "поза". У неё тоже есть набор определённых свойств, такие как: размер, направление, цели итд. Таких поз может быть несколько. А может быть одна, но внутри которой заложено несколько частей с разными целями.

Еще один объект, это время. У него всего два свойства, реальное время и "состояние", ну т.е например "вечерка" или "первые 30 минут торгов". Эти состояния тоже фиксированы.

И таких типов объектов около 10.

А теперь главная идея. Чтобы качественно получать сигналы (даже для начала не торговые, а именно для алгоритма получения всего что требуется), нужно чтобы программа умела анализировать не только сами объекты, но и их взаимодействие.
Банальный пример взаимодействия перечисленных объектов:    Если движение больше стандартных размеров в N раз, и у нас по нему открыта плюсовая поза, при этом это движение не достигло целей, но уже наступила вечерка, то позу надо закрыть.

Мне сложно рассказать тут что-либо более подробно, так как у нас в работе уже давно используется собственная терминология и все объекты названы своими названиями и все их типы взаимодействий и влияний известны. И чтобы пояснить что-то подробнее, нужно пояснять термины и понятия тоже.

На данный момент мне кажется что оптимальным сочетанием будет:

1) основная программа, написанная на Си, которая состоит из модулей.
2) LUA скрипт, который будет из квика передавать все требуемые данные в нашу программу и от нашей программы принимать торговые сигналы, которые потом будет выполнять.

В последствии LUA скрипт можно будет заменить на что-то например для связи с PLAZA2

Аналогично как я понимаю работает QScalp (скальперский привод) и ещё некоторые программы.

Если кто-то пояснит с какой стороны подойти к этому вопросу, буду очень признателен.

Первым шагом как я понимаю должно быть написание LUA скрипта, который бы "отдавал" нам таблицу сделок в онлайне, и написание программы на Cи, которая эту таблицу бы понимала и превращала в свечи.