тот самый (Все сообщения пользователя)

Ответ на Ваш вопрос:
https://forum.quik.ru/messages/forum10/message5441/topic360/#message5441
https://forum.quik.ru/messages/forum10/message5500/topic565/#message5500

я думаю, не стоит однозначно закладываться на соответствие или НЕсоответствие тех или иных индикаторов. Индикаторы - эт лишь удобная математическая модель с помощью которой легко управлть толаой и её ожиданиями.
Вот у меня, к примеру есть СВОЙ индикатор - и что, тоже под него искать формулы и обоснования несоответствий? В разное время - те или иные индикаторы начинаются завидным постоянством то быть "техничными" - то значительно уходить от "техники", т.е. создавать дивергенции между ценой и показаниями индикатора. Сигнал дивергенции - это просто звоночек, что система начинает вести себя нестабильно - стало быть сигнал к снижению рисков - в данном случае - к изменению подхода.

Подытожив, данные всегда будут разными у всех, равно как и показания индикаторов - так стоит ли им так слепо доверять. Иногда - отстуствие результата (несоответствие показаний) - лучший результат. К тому же, тут не учитывается такой момент, что многие - элементарно "допиливают" "стандартные" индикаторы под изменяющиеся правила рынка, вместо изменения подхода к рынку коренным образом. Опять же, другими словами:
рынок - живой организм, индикатор - мат.модель. Некоторые пытаются подстроить мат.модель "создать клетку/на кинуть аркан" на рынок. В итоге: мат. модель у всех разная (хоть и порой с одинаковым названием бо как видение рынка - тоже разное), рынок всё-равно изменился и "поимел" "и тех и этих".

это надо запомнить на будущее..

В общем, как я понял, если речь идёт об индексах - то у всех будут разные данные, а значит и индикаторы будут показывать абсолютно разное.

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

п.1 полностью поддерживаю
п.2 - лично я - просто меняю в меню из списка набор (серию) опционов. Таким образом - все колонки (порядок параметров) - всё на своих местах. Раньше - тоже удалял доски после каждой экспирации.:)))

ну как обычно - е..ут через коллектив. мда уж...
дожились.


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

Сергей! Рад предложить Вам работу: https://forum.quik.ru/messages/forum10/message4838/topic113/#message4838
на хлеб с маслом - точно хватит:))))

а обо мне значит, НЕТ??? вот всегда - я так и знал... :(((

(шутка.)

это понятно:))))))
но ведь, а как же забота об остальных клиентах???))))))

похоже, те индикаторы, которые есть в квике - это предел для квика...

такое сейчас можно сделать самому, если потратить на это чуточку времени. А если покупать - то я б за него дал небольше 100руб.  :) ))

кстати, пока писал сообщение - уже нашёл для вас линк: http://mycreditcard.ru/robot/acceleration.html
правда, тут просят чуть ли не в 10 раз дороже:))) Но, думаю, для Вас это непроблема:)

Было бы интересно узнать о том, как бы ещё полезно можно классифицировать заявки, т.е. :

1. какой должна быть архитектура класса "Заявки"
2. Стоит ли вообще прикручивать к ним класс
3. надо ли прикрутить класс к её полям (вижу, что надо но, пока не могу понять, как это использовать). т.е. опять же - важна архитектура.
   

Для себя наметил на ближайшее будущее - создать класс для быстрого подсчёта арбитражного спреда и работы с ним. В последствии, после перевода в формат LUA-dll - буду думать, как синхронизировать "наклёвывающийся" торговый движок с графическим интерфейсом (GUI).


В общем, кому всё это действительно интересно и кто хочет поучаствовать - неотсиживайтесь - советы, идеи - принимаются с благодарностью (даже от "умников" троллей-роботорговцев :))) )

например, индикатор горизонтального объёма :)))

спасибо за информацию. буду знать.

за ссылку - спасибо. Займусь переводом))

скорей всего, SetUpdateCallback - это просто обёртка в виде метода CreateDataSource таких двух функций, как один из квиковских коллбеков (OnAllTrade, OnParam) + функция getParamEx. При том, что сравнения на старый-новый параметр в SetUpdateCallback похоже совсем не предусмотрено. Она просто полагается на то, что по коллбеку в так называемом "срезе" приходит целая линейка ТОЛЬКО изменённых параметров. Что, разумеется - в корне неверно бо как параметры - не меняются в одночасье (в силу тех или иных причин).

а вот и её результат:




За основу были взяты технологии создания компонентов в Delphi VCL, чуть-чуть JAVAscript и игровых движков.

после смены сессии = все параметры в ТТП - сбрасываются. Остаются лишь итоговые значения отдельных параметров. В течении сессии - между апдейтами - просто показывают предыдущее значение (т.е. если не было изменений)

он только в дневную сессию расчитывается.

Ошибка была в том, что недопустимо сохранять ссылку на метод экземпляра не сохранив сам экземпляр. (как-то вот так)

Заработало. Вопрос - снимается.

исправленный код:

Скрытый текст

Код function AddOnParamListener(cls,sec,fn) return table.insert(OnParamEventListeners,{classcode = cls, seccode = sec, notifier = fn}) end local sim5ticker = Ticker.new("SPBFUT", "SiM5") AddOnParamListener("SPBFUT","SiM5",sim5ticker) function OnParam(a, b)    if OnParamEventListeners[1].classcode == a and OnParamEventListeners[1].seccode == b then       OnParamEventListeners[1].notifier:Update()    end     end

На случай, если кто-то не понял для чего я это всё:
https://forum.quik.ru/messages/forum10/message5441/topic360/#message5441
https://forum.quik.ru/forum10/topic565/

В общем, думаю, надо как-то создать ссылку на метод функции. Но пока не знаю как.

Есть:

Вопрос[ы]:

1. Как правильно сохранить метод экземпляра класса в совершенно постороннюю таблицу, чтоб потом его вызвать из неё.
2. Возможно ли и правильно ли хранить ссылку (или даже список ссылок) в конструкторе (new) на экземпляры класса и, если "Да" - то как?
   

Примечание: код черновой - пишу на ходу по ходу мысли.

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

сохранить не в UTF-8 w/o BOM, а просто в ANSI

куча топиков, и вроде и с разными темами, а об одном и том но с разных сторон)))

одна из идей уже частично озвучена: https://forum.quik.ru/messages/forum10/message5441/topic360/#message5441

если у кого есть, что сказать/дополнить - Welcome. :))

В качестве ответа на вопрос звучащий в названии темы:

пока, для себя, вижу лишь только одну альтернативу:

1. создать объект "тикер",
2. при его создании - получить всю линейку параметров по этому тикеру через getParamEx, сохранить её для последующего сравнения.
3. добавить в конструктор объекта вызов метода: AddParamListener, задачей, которого зарегистрироваться в таблице подписчиков на обновление данных, получаемых из OnParam и других квиковских коллбеков.
4. в OnParam - пробегаться по этой таблице подписчиков на обновление данных и вызывть метод ticker.update().
5. в методе ticker.update() - проверять ранее сохранённый "срез данных" со свежими (повторно вызывать getParamEx). Однако: такой номер - не для всех параметров прокатит - поэтому придётся настраивать под каждый определённое поведение алгоритмов сравнения по косвенным признакам (вот Вам и куча из "case и switch" (говоря в терминологии C++) [спасибо "Арке" за наше счастливое ...]). При этом, это ещё сильно ударит по масштабируемости такого объекта (ticker) - бо как праметров - тьма и все они разные для тех или иных инструмментов, равно как и алгоритмы сравнения (старый-новый параметр).
6. Если, каким-то чудом, всё же удасться изобрести "гига-велосипед" под названием п.5. то, дальше - дело за малым: можно смело создавать свои события и ботов на них реагирующих, причём в количестве - ограниченном лишь только быстродействием канала с брокером и скоростью работы компа. Если интересует конкретно, реализовать события в объекте ticker - то, - всё также как и с OnParam: пробегаем по таблице подписчиков и вызываем соответствующий коллбек (если он "assigned" так сказать)
   

вопрос к client support,

задача - сделать полноценный торговый движок на QLUA, с событиями и пр.
Чтобы её значительно упростить - хотелось бы (как это не раз уже предлагалось на старом и новом форумах) иметь в OnParam ещё одно поле - параметр, который непосредственно изменился. Глядишь и надобность в "куче CreateDataSource", как выше упомянуто - отпадёт. Если этого не сделать - то весь огород из "case и switch" (говоря в терминологии C++) перейдёт (а точнее, - уже перешёл) на плечи пользователей. Таким образом, почему бы изначально не отслеживать процесс изменения непосредственно в недрах квика, сравнивать все эти старые и новые значения? Ведь это всё у вас и так уже есть - надо просто довести "до ума", а не предлагать пользователям какие-то очередные функции-"заплатки". Ведь видно же, что такой функционал - это явная ваша недоработка. И это никак нельзя назвать каким-то особым или вынужденным программистским трюком. (если Вам мои слова показались излишне резкими - то, это Вам просто показалось...)

в общем. как я понял - биржу можно сравнить с файлообменником с возможностью докачки. Врядли история ведётся по каждому брокеру. Логичней  было бы предположить, что есть некий общий биржевой кеш, в структуре биржевого потока - есть поля временных меток. Квиковский сервер мониторит пакеты с биржевого шлюза, и если есть изменение метки времени в структуре пакета - принимает данные. Брокеры - являются подписчиками на информацию теперь уже через квиковский сервер - тут уже - единый биржевой поток разбирается на части и к реально биржевым данным примешиваются чисто исторические - свечи и т. д. Теперь уже брокер является своего рода биржевым каналом (через выделенный квиковский сервер) и главным арбитром предоставления информации. Старина квик же - делает тоже самое, что и квиковский сервер с биржей: есть изменение метки времени в структуре пакета - есть и так называемы срезы в OnParam и другие коллбеки. серверное время стоит на месте - значит квик замирает. Если разница между изменениями превышает квантум - запрос на пропущенные данные. (что нетрудно понять/заметить потому как квик, как ошпаренный потом начинает "догонять" информацию на графиках и даже в стаканах котировок).

tech support - поправьте где я ошибся.

звучит, как будто я Вас - обидел своим предложением... :)))

если так - то искренне, извиняюсь...

выскажу своё личное мнение... )))))

я думаю, стоит задать вышеописанные вопросы непосредственно Михаилу Булычеву. А Сергею Горохову - зарегистрировать очередное несбыточное пожелание о том, чтоб в документации отразить детальную схему работы коллбеков и функции CreateDataSource. Но только детальную. Иначе, срач на форуме, равно как и число "бесполезных топиков" - нисколько не убавится :)))))

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

насчёт имени и фамилии - я не давал Вам своего согласия на сбор и обработку моих персональных данных, равно как их публикацию. Напоминаю Вам, что закон защищает мои персональные данные. Согласитесь, Вы б не хотели, чтоб достоянием общественности стали все Ваши e-mail, логины в соц. и других сетях? Я безусловно "рад", что Вы настолько прониклись интересом к моей персоне, что уже третий раз Вам приходится об этом напоминать. Очевидно - меня уже вся "Арка" знает:)))) Возможно Вы подумываете над тем, чтоб принять меня на работу??:)))))))))

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



С уважением, лично к Вам,

End-user of (м-м э-э так называемого Квика)

Спасибо за ценное наблюдение.

Сам часто замечал когда банальный запуск chckdisk и последующее обслуживание могут в разы увеличить скорость доступа к диску.

хотя Да, конечно. Вы правы.

это как это??? ))

из "хелпов" тупайла с описание полей ТТП. тип параметр - не имеет значения - главное, что он числовой (если говорить о QLUA)
Если дата последних торгов по инструменту не является датой последней сделки - то, что тогда является?

это уже совсем другое. К тому же, автор задавал вопрос, судя по контексту именно на открытие/закртие по одному тикеру.

TRADE_DATE_CODE DOUBLE Дата торгов

Также, если у кого есть примеры полноценных классов с использованием механизма событий - как говорится: "you are Welcome!!!"

Перерыл и старый и новый форум в поисках толковых примеров с использованием метатаблиц и closure но, ничего не нашёл, кроме вариаций стандартных примеров на основе QTable из "хелпов" квика.
Таким образом, в этой теме хотелось бы исправить столь досадное недоразумение.
Обращение ко всем кому не жалко и кто не считает, что "палит грааль" - поделиться информацией в теме.


Начну со своего маленького перевода одной интересной статьи по теме. -> http://quik2dde.ru/viewtopic.php?id=135

нет. Но в документации по Квику - есть все формулы по которым они (индикаторы) расчитываются. Этого более чем достаточно.

а откуда такая информация, что в ТТП они учитываются (если речь, конечно о количестве всех сделок "NUMTRADES")? Внесистемные сделки - на то и внесистемные и, скорей всего именно поэтому для них присутствует (а присутствует ли?) отдельный столбец: "кол-во внесист. сделок"

похоже без галок с квиком - никак. Теперь придётся хранить вместе с файлом скрипта ещё и "readme" по обязательной используемой комбинации галок. Маразм однако. Ну хоть так...

Заработало! )))

Появилась наконец сходимость между ТВС и ТТП. Больше нет пропущенных параметров. Для этого надо было всего лишь "удалить галочку":
В итоге, коллбек OnParam превратился в OnAllTrade и, даже утёр ему нос)))
Таким образом, концепция единого потока данных - всё же верна.
Также, раз OnParam настолько хорош - появилась вполне оправданная и доказанная возможность создавать на его основе "синтетические коллбеки" по интересующим бумагам и параметрам.

оставлю пока задумку до лучших времён - авось квик когда-нибудь позволит это реализовать.))

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

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