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

Quikos, Я когда-то спрашивал техподдержку, и ответ меня убил наповал: они считают свечи именно из ТОС, биржа транслирует только её. И уже на основании посчитанных ими свечей и работает вся эта глючная и тормознутая  лабуда типа SetUpdateCallback или CreateDataSource или что там у них есть.

Повторяю: я считаю все свечи сам, причём не эту японскую дрянь, а как среднее арифметическое значений курса за период, считаю, что это даёт куда более достоверную информацию. Считаю именно опросом ТТТ, для десятков и сотен тикеров, по десятку таймфреймов у каждого, начиная с 10-секундных и кончая часовыми. Просто, быстро, надёжно, информативно, работает как часы вот уже несколько лет, прямо с момента создания, и плевать мне сто раз на все реконнекты и пропущенные данные. Зачем искать на свою задницу приключений?

Quikos,
1. ЕСЛИ "скрипт получает каждые данные изменившейся цены и дату/время" ТО это таблица обезличенных сделок, т.е. один из самых тормознутых и глючных способов определения свечей.
2. ПОФИГ, произошёл ре-коннект или нет, имеем поступление новых данных, которые то ли уже приходили, то ли ещё нет, и определять нужно именно это.
3. На момент закрытия свечи НЕВОЗМОЖНО определить, все ли данные по ней уже поступили или часть их потерялась по дороге и, если так, имеем ещё одну проблему: являются ли пришедшие данные новыми или это дубль тех, которые уже были учтены при формировании свечи.
4. Скрипт по времени, полученным вместе с новыми данными, вполне способен определить, к какой именно свече они относятся, а потому нет никакой разницы между обработкой полученных после дисконнекта новых данных и "заполнением 5 минутного пропущенного промежутка".
5. Тыщу раз уж говорил, что особая точность в определении свечей не нужна, а потому на несколько порядков быстрее, надёжнее и, возможно, даже точнее считать их самостоятельно, периодическим опросом ТТТ, а не заниматься всеми этими глупостями. Ну, допустим, не было разрыва соединения, а там какой-нибудь клиринг идёт. И чего?

Рустем, Ну дык я всегда знаю, что у меня, где, сколько и почём - скрипт же САМ ведёт портфель. И все до единой заявки лимитные. А вот отлавливать бывшие OnTrade ОЧЕНЬ вредно. Я когда-то был в полном ахуе, когда запустил скрипт в субботу, а мне с полсотни пятничных сделок прилетело. Только по идентификатору транзакции, который, слава богу, я формирую сам.

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

Рустем, Да мне ваще насрать на onDisconnected. Проблемы со связью - это проблемы Квика, а не мои. Мой скрипт общается только с Квиком - он для него и брокер, и биржа. И разговариваю я с ним только на языке sendTransaction-OnTrade-getParamEx.

А какие проблемы "проинициализировать свои данные при запуске робота"? Они же свои! Мой скрипт вообще не использует ни onConnected, ни getInfoParam, ни локальное время компьютера, ни серверное время, ни... Вот getNumberOf - использую. Один раз на весь скрипт и раз десять в сутки во время его работы, и только для таблицы заявок (когда хочу снять несработавшую заявку). И у меня всегда актуальная инфа о позиции в портфеле после запуска скрипта!  

Рустем, Я говорил об ошибках в коде не в смысле потери соединения, а в том, что "QUIK подвисает примерно раз в 2 дня". А уж то, что он при потере связи самостоятельно восстанавливает соединение, я видел тыщу раз - хотя бы по его диагностике "соединение установлено" или "соединение установить не удалось". Любой браузер делает примерно то же самое.

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

Рустем, Ну, если "QUIK раз в 5-10 минут теряет соединение", то не только о скоростной торговле, но и вообще о торговле лучше забыть до появления нормального канала связи. То, что он ещё и "подвисает примерно раз в 2 дня", скорее всего, вызвано ошибками в Вашем коде. Автоматический перезапуск без выяснения причин предыдущего вылета лично я считаю глупостью. Наконец, QUIK в принципе непригоден для высокоскоростной торговли (да и слава богу, ибо такая торговля есть полное дерьмо) - здесь время измеряется секундами. Конечно, народ на этом форуме периодически впадает в маразм и занимается очередной ловлей микросекунд, но всё это чушь собачья.

Рустем, Так и в моём случае расхождения портфеля неприемлемы.   И торговля тоже не особо редкая - почти всегда более сотни сделок в сутки, бывает и по 5-6-7. Да, рассогласование - вещь весьма неприятная, но довольно редкая. А вот "альтернативные решения" как раз и дают во много раз больше ошибок - там ведь действительно бывают задержки в десятки минут и даже более. Для активной торговли это фактически смертный приговор.

Рустем, Мой ответ: ждать бесполезно. Я вообще отказался от программного контроля состояния портфеля со стороны брокера. Во-первых, потому, что утилита эта глючит со страшной силой. Во-вторых, потому, что она частенько врёт: мой скрипт самостоятельно ведёт учёт бумаг и денег, и при рассогласовании портфелей (а это довольно редкая ситуация, раз-другой в неделю по всем тикерам, а их у меня в портфеле болтается в районе полусотни) ошибки в данных бывают не только у меня (скажем, не пришло прерывание OnTrade или где-то задержалось на полчасика), но и у брокера (не успел обновить данные, и через некоторое время рассогласовании пропадает даже при полном отсутствии сделок по этой бумаге с моей стороны). Или вот убивающий пример на прошлой неделе: купил у меня скрипт фьюч Норникеля. Гляжу - и в таблице заявок, и в таблице сделок, и у меня в логе куплен один лот, а в состоянии портфеля их показано два. НУ НЕ ПОКУПАЛ Я ВТОРОЙ ЛОТ ПО ЭТОЙ БУМАГЕ! Через какое-то время скрипт этот фьюч продал, гляжу - в портфеле всё равно +1. Наконец, мне это надоело (прошло часов пять, не меньше), и я руками продал второй, в портфеле стало пусто. На следующий день запускаю скрипт, а у меня там... правильно, -1! Пришлось снова купить руками. И это важнейшие данные, содержимое портфеля! А уж связываться с этим говном ради каких-то сраных свечей... да в миллион раз дешевле, проще, надёжнее, быстрее посчитать их самому. Слава богу, я с самого начала поступил именно так.

БорисД, Борь, это не тот самый "следователь", у которого тыща алгоритмов, и все прибыльные?  

Kolossi, 99% всех веток практически любого форума, не говоря уже про этот, есть чистейший мусор. В частности, Ваша ветка. Несмотря на то, что здесь в достатке специализированных форумов ("Пожелания по развитию функциональных возможностей системы QUIK", "Вопросы по работе с графиками в системе QUIK", "Вопросы по эксплуатации системы QUIK, не выделенные в отдельные темы форума"), народ постоянно лезет в "Программирование на языке Lua" со своими дурацкими пожеланиями, которые "подлежит рассмотрению и исправлению в ближайших версиях квика", хотя софт уже настолько изуродован аналогичными пожеланиями их предшественников, что уже едва справляется со своими первоначальными задачами. Давайте не будем засорять форум.  

Kolossi, Кому как. Мне, например,  для торговли только Lua и нужен. А тема здесь направлена на потенциальное изменение софта Квика. НЕ НАДО ЭТОГО ДЕЛАТЬ!!!

Kolossi, Я, во всяком случае, считаю иначе: все эти графики с метками для торговли не нужны от слова совсем, и потому я категорически против любых изменений Квика, который и без того на ладан дышит.  

Kolossi, А нафига ВЫПАДАТЬ в дамп? Лично я сбрасываю дамп на диск раз в 5 минут... нет, вру - даже чаще: раз в 100 секунд, и потери данных здесь будут только если именно в момент сброса дампа Квик и сдохнет. Но вероятность этого прекрасного события вряд ли отличается от нуля, и все данные оказываются хорошо сохранившимися. Ну, разве что в эти 100 секунд что-то произойдёт.

БорисД, Ладно, ладно, орлов собаки не трогают.  

TGB, ЗА КАКИМ ХЕРОМ "с битами работать", если нет целочисленных переменных ВААПЩЕ? Эта Ваша "local a" - она КАКОГО типа? Сам факт, что следом стоит "math.tointeger(a)" АДНАЗНАЧНА говорит, что какого угодно, только не целочисленного. Кстати, не нужно указывать, что "0x80 это 128 в десятичном исчислении" - язык, слава богу, прекрасно воспринимает и 16-ричные числа. И анализируемых битов в маске может быть более одного, и сама маска не обязана быть константой. Простейший пример из ассемблера: xor AX, AX - это то же самое, что и mov AX, 0, только работает быстрее и хранится компактнее.

Смешно, но именно тот долбодятел, который здесь утверждает, что целочисленный тип данных в языке имеется и делится потрясающими открытиями вроде "целое хранится иначе чем number" в 2020 году на мою фразу:
В 64-разрядный integer спокойно влезают даже 20-значные числа - более 18 квинтиллионов!
реагировал так:
Разрядность мантиссы в 64 битном вещественном числе составляет 52 бита, что  позволяет точно отобразить лишь 16 разрядное десятичное целое число, а не  18 квинтиллионов, как наивно полагает Владимир".

Наконец, эта долбаная динамическая типизация угробит любые типы, даже если бы они там и были. На заре своего появления здесь я описывал работу своего парсера: входные данные, которые все до единого были строками, он заносил в некую структуру, а в этой структуре более половины из них "волшебным образом" превратились в числа. А потому, чтобы не сильно зависеть от того, какая моча вдарит в головожопу интерпретатору в следующую секунду, приходится постоянно заворачивать эти переменные в tostring или tonumber. Тут не только типа integer - тут ваще никаких типов нет!

Quikos,
1) Это чистейший Lua.

2) А что делать прикажете? Язык - полное говно, и это единственная возможность программирования данными. В одном из самых первых своих постов я писал:
УХ ТЫ! А в описании языка (руководство пользователя) нет ни звука ни про unpack, ни про loadstring! А эти вещи, как я предполагаю, должны бы расширять функциональные возможности совершенно диким образом!

Quikos, Функция здешняя. Насколько я помню, недокументированная.
for l in F:lines() do
s=l:sub(1,1);
if s=="_" then load(l:sub(2))();end;
end;
Т.е. если строка в файле начинается с символа подчёркивания, скрипт выполняет её как если бы она была набита прямо в коде. Этим способом я сообщаю скрипту номер счёта, код клиента, количество денег, который ему разрешено использовать и т.д.

Nikolay, Да не надо мне ничего из коробки. Это ЕДИНСТВЕННЫЙ язык, который мне повстречался в жизни, у которого спи&дили целочисленный тип данных, и никакими костылями это не поправить.

Quikos, Я не знаю, что там за поле CreateDataSource - этим говном я никогда не пользовался и другим не советую. И пишу только на чистом луа - никаких API. Если Вам нужно вызвать строку - насрать, в какой таблице или переменной она лежит или является возвращаемым значением - попробуйте через load.

nikolz, Лапуль, уже не первый раз повторяю для особо одарённых: Нет в луа никакого  integer. Нет, не было и не будет. Я уже не молчу, что у этого говна по кличке "динамическая типизация" вообще никаких типов нет, и глюкам, с этим связанных, посвящена чуть не половина здешних веток. Я ещё в самом первом своём сообщении на этом форуме писал:
Я не нашёл тип данных integer ВООБЩЕ! И как же мне работать с битовыми масками? Как на Lua реализуется конструкция вида:
if (iData & 0x80) { blah-blah-blah }?

Quikos, Не понимаю, что Вы, собственно, хотите. to call a string value? Для программирования данными я лично использую функцию load, и только для того, чтобы держать некоторые куски кода во внешних файлах. Вызывать строку как функцию здесь, кажется, не пробовал, но в JS частенько этим пользовался, иногда даже сооружая код этой функции (в смысле, строки) на лету. Скорее всего, это должно работать и в Lua.

nikolz, Нет в луа никакого  integer. Нет, не было и не будет. Торкаешь носом торкаешь... умолкает, потом снова всплывает и снова начинает вонять.  

БорисД, Уверен? Я, конечно, не волк, но всё-таки собака по гороскопу.  

Alexander, Во-первых, никаких целых чисел тут вообще нет - эти идиоты отменили тип integer. Во-вторых, проблема обрезки концевых нулей здесь не раз обсуждалась, и только я несколько раз приводил код этой функции, так что в моих сообщениях это точно есть. Самому искать лень.

nikolz, А Чего тут зубоскалить, лапуль? Я ещё с прошлого тысячелетия гоняю ИИстов стихами Маршака.
Мой мальчик! Тебе эту песню дарю.
Рассчитывай силы свои.
И, если сказать не умеешь "хрю-хрю", -
Визжи, не стесняясь: "ИИ!"

БорисД, Ну да, робот должен нормально работать в любых, в т.ч. в экстремальных условиях. Сегодняшняя отработала нормально и по фьючам, и по акциям (в смысле, ещё работает, но после семи активность на бирже совсем дохленькая), но денёк-другой надо бы за ней ещё понаблюдать. Я, пожалуй, чуток подрежу ей агрессивности и, соответственно, понижу риски, а то на четырёх фьючерсах подушка себя ведёт хорошо, а до десятка расширять страшновато.

Звони, конечно.

БорисД, Про тебя я, конечно, вспоминал. Но к моменту нашего знакомства я уже знал про незакрытые свечи. Вот фрагмент моего сообщения от 26.05.2021 13:05:19:
ЧАВО???!!! Они что, НЕЗАКРЫТЫЕ свечи присылают?! Совсем шизанулись... Я, как уже говорил, считаю свечи сам, так у меня только три свечи на каждый таймфрейм: две рабочие и одна накапливаемая. И только когда она накопится, последняя свеча становится предпоследней, предпоследняя выбрасывается (меня не интересуют "преданья старины глубокой"), а накапливаемая обнуляется. И пока она снова не накопится и не станет последней, её данные не используются вообще никак. Чего и всем остальным желаю. Это ж ДОДУМАТЬСЯ надо! Я в ауте!
 
Боря, и с аналитикой по свечам, и с выбором опорного таймфрейма давным-давно нет никаких проблем, и все эти развороты ловятся в тыщу раз точнее, чем при использовании этого несчастного правила: "не покупать выше и не продавать ниже той самой линии". Анализ поведения рынка вылизан до идеального состояния, он меня вообще больше не интересует, но, как ты знаешь, на принятие решений оказывает влияние далеко не только поведение свечей.

Я тут позавчера вспомнил, что в скрипте существует и режим работы по историческим данным. Помнишь тот массив, который ты когда-то скачивал, который на 6 миллионов секундных свечей? У него курс вначале как-то болтается, потом резко падает почти в два раза, потом начинает расти. Так вот, я прогнал по нему последнюю версию скрипта. Сначала как будто это массив по акциям - отработал блестяще: и шортов немного, и прибыль неплохая. Но когда я сказал ему, что это фьючерс, я ржал часа три, внёс в код пяток изменений, и вот только что запустил новую версию в боевом режиме. Боря, НИ ОДНО из этих изменений не касалось анализа поведения рынка, я ржал над фантазией скрипта, который выкручивался из заданных рамок как глист на сковородке. Началось с того, что количество сделок на том же массиве выросло в 15 раз. В общем, это не то место, где это дело можно обсуждать. Скажу одно: я не вижу смысла совершенствовать свои стратегии, мне плевать, акции это или фьючерсы, ни с чем другим я работать не хочу (депозитарные расписки - те же акции, только вид сбоку), изучать основы биржевой торговли я никогда не собирался и не собираюсь, на психологию мне плевать, а с текущим поведенческим характером каждого из выбранных для торговли тикеров пущай скрипт разбирается: моя задача - включить и выключить. А ты так и вообще можешь не выключать - текущая версия вроде как это позволяет.  

nikolz, Лапуль, назначение свечи не сжатие, а как раз ИЗВЛЕЧЕНИЕ информации. Например, из того почти белого шума, который называется ТОС. Именно свечи и дают информацию для принятия решений, и, поскольку информация эта всегда вероятностная, то и особая точность в определении свечей не нужна и даже вредна. У меня, например, все свечи уже при получении округляются до шага цены, а при принятии решений и вообще используется не значение, а ранг этого значения (скорости или отклонения), у которого всего девять возможных состояний. А потому вся эта мышиная возня с ТОС и дурацкими колбеками есть абсолютно бесполезный для торговли онанизм - хотя бы потому, что он тормозной и глючный до безобразия. Кстати, мои свечи имеют лишь ОДНО значение на интервале тайма, так что "сжатие информации" у них в разы лучше, чем у этого "японского" говна.  

nikolz, Не говорите ерунды, лапуль. Во-первых, свечи для интервалов в секунды нафиг не нужны, а уж применение Си и вообще противопоказано. У меня минимальный интервал 10 секунд, но и это маловато, в качестве базового таймфрейма, в основном, используется 30-секундный. Всё на чистом Луа. А уж использовать OnAllTrade или ТОС могут только камикадзе. Ах, да - и пользоваться незакрытыми свечами тоже: у меня в своё время просто челюсть отвалилась, когда я об этом услышал.

Сколько раз уж говорил: считайте свечи сами опросом LAST из ТТТ и не занимайтесь фигнёй - это говно не будет работать НИКОГДА.

Vladimir Ivanov, То, что мне предложили, НЕ ЕСТЬ решение проблемы. Какова бы ни была связь, пакеты с запросом на аутентификацию ДОШЛИ до сервера, он ОПОЗНАЛ их содержимое, и вместо того, чтобы продолжить работу, с какого-то бодуна решил, что клиент уже работает в системе и РАЗОРВАЛ установленную связь. Даже если при этом НИ ОДНОГО пакета не было потеряно, результат был бы тот же самый. Это устойчиво повторяющееся действие - обычно в течение нескольких минут., после чего до этого придурка всё же доходит, что клиент больше не работает в системе, и он перестаёт рвать связь. Следовательно, предлагаемое мне "решение" не имеет ничего общего с проблемой - это на 146% глюк самого Квика.

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

Vladimir Ivanov, А где Вы увидели хоть намёк на конструктив? Я жаловался на диагностику  "вы уже работаете в системе". Режь меня, жги меня - я не понимаю, как это можно пришпилить к проблемам со связью. Эта диагностика В ПРИНЦИПЕ не может быть связана со сбоями связи, так что ТАКАЯ "помощь" мне нафиг не нужна. В любом случае, мне лучше знать, работаю я в системе или нет.

Vladimir Ivanov, А зачем, простите, "выполнять рекомендации, направленные мне выше"? Все эти "рекомендации" исходят из единственной гипотезы - наличие проблем со связью, а я ещё в первом своём сообщении показал, что гипотеза эта несостоятельна, что такое поведение НЕ МОЖЕТ быть вызвано никакими подобными проблемами.

А я разве просил Вас "объяснять мне что такое шифрованное соединение и как оно работает"? Я всего лишь сказал, что ЕСЛИ "шифрованное соединение ломается, когда пропадает один - три пакета, ТО такое соединение есть полное дерьмо. Поскольку соединение по защищённому каналу должно бы быть, как минимум, не менее надёжным, чем по незащищённому, иначе кому такое говно вообще нужно? Уж за полвека можно было бы и научиться передаче данных по каналам связи. Тем более, что передача зашифрованных данных НИЧЕМ не отличается от передачи любых других данных. Тем более, в Интернет, который и существует-то именно как сеть передачи данных - какие тут  ПРИНЦИПЕ могут быть "требования Quik к каналу"? Интернету соответствуют, а какому-то несчастному Квику не соответствуют? Тогда это просто фантастическое дерьмо, а не программное обеспечение!

Ха-ха-ха! Ну да, так и есть:
Требования к оборудованию и программному обеспечению
Для работы с системой QUIK необходим компьютер и доступ в интернет. Компьютер должен соответствовать следующим минимальным требованиям:
• компьютер с доступом в интернет;
• оперативная память не менее 2 Гб (рекомендуется 4 Гб);  
• не менее 2 Гб свободного пространства на жестком диске после установки дистрибутива;
• минимальное разрешение экрана – 1024×600 пикселей;
• операционная система Windows (×64) редакций Vista/Server 2008/7/Server 2012/8/10/Server 2016.
Требования к каналу связи
• протокол передачи данных ТСР/IP;
• пропускная способность канала связи не менее 14,4 Кбит/сек;

То есть вся эта лабуда построена ПОВЕРХ ТСР, который, к слову, является НАДЁЖНЫМ протоколом передачи данных, так что вся та лапша, которую Вы мне вчера вешали про "пропадание одного - трёх пакетов", мягко говоря, не соответствует действительности.  

Vladimir Ivanov, У меня уже много лет нет ни малейших претензий к каналам связи - да, они сильно изменились, но, надеюсь, в лучшую сторону? Связь у меня рвётся не каждый день, используется годами практически ежедневно, и проводить какое-либо её тестирование я не вижу смысла. Очевидно, проблемы в софте. Если "в шифрованном соединении пропадает один - три пакета, то соединение ломается", то софт просто никуда не годится. АДНАЗНАЧНА! Ведь софт тоже, надеюсь, должен меняться в лучшую сторону.

Я не понимаю, какие у Вас претензии к моему стилю - я почти всегда вежлив с собеседниками (что далеко не всегда можно сказать о некоторых из них), и я много лет знаю, что для качественной полемики эффективнее всего работает именно провокативная лексика. По крайней мере, при разговоре со специалистами. За все 30 лет моего пребывания в Инете я никогда не прятался, никогда не имел ника, по которому не было бы очевидно, что я - это я, и не вижу ни единой причины, по которой любые мои посты не должны быть видны участникам форума.

У меня здесь три компа, в один воткнут оптоволоконный кабель, а два других (в том числе тот, который используется для торговли) подключены через WiFi, но на торговом компе, кроме двух Квиков, вообще ничего нет - там просто смешной траффик, а на втором почти всегда идёт какое-то видео из Ютуба. Сейчас все три компа работают, никаких проблем со связью нет, на одном работают два Квика, на втором я пишу это сообщение и слушаю Пионтковского - он тоже подключен через WiFi. Более того, как я сказал ранее, такое поведение НЕ МОЖЕТ быть объяснено некачественной связью, связь разрывает сам сервер, и разрывает её потому, что думает, что происходит вторая попытка авторизации - типа, злоумышленник пытается войти.

Александр, Никак.

Даниил Волошин, Здравствуйте,

Я понимаю, что "can't get message size from net" означает, что в процессе подключения к северу возникли проблемы с передачей пакетов. Только что включал один из Квиков так трижды получал "can't get data from net", хотя у меня ещё с прошлого тысячелетия стоит оптика, второй Квик на том же компе прекрасно работает, а на другом компе, подключённом через тот же роутер, я сейчас это дело и пишу, а оба Квика в другой комнате работают. Эта ситуация неприятна, но понятна, здесь претензий нет - я говорил именно про "Вы уже работаете в системе", и эта диагностика НЕ МОЖЕТ "говорить о том, что в момент авторизации какие-то пакеты были отправлены, затем рабочее место  Quik отключилось не дождавшись ответа от сервера" - связь рвал именно сервер, причём немедленно после попытки авторизации, а тот факт, что после повторного входа после такой ситуации приходит сообщение о попытке авторизации с такой-то айпишки, говорит о том, что сервер НЕ посчитал, что авторизация произошла и разрывает соединение НЕ по причине проблем со связью.

Я когда-то сам был сисадмином Инет-провайдера, когда ещё клиенты дозванивались через пул телефонов со скоростью порядка 30-50К, но даже тогда проблемы были именно у клиентов, а у меня, сидящего на радиоканале, никаких проблем со связью не было. А уж сейчас... именно на этом "низкого качества канале связи" я качал несколько дней почти терабайтную базу данных - и ничего, прекрасно скачалась.

А чем мой тон диалога недружелюбный? Это же я с Квиком разговаривал.  

Александр, Проблема не только в том, что getDepoEx возвращает nil, она иногда возвращает валидные, но неверные данные. Я когда-то и спрашивал, и полный код своей функции сверки портфелей выкладывал, и пытался не колодой тикеров к ней обращаться, а с задержкой в секунду после каждого вызова. Короче, отключил нафиг всю сверку - глазами сравниваю периодически, как и раньше, до знакомства с getDepoEx.

Alexander, Ха-ха-ха! Нет, я допускаю, что nikolz настолько тупой, чтобы пытаться изображать из себя кукловода, но вот в то, что ЕГО робот специально ставит в стакан заявки, чтобы сбить с толку других роботов, верить категорически отказываюсь - по той же причине. Нормальным скриптам (моему, например) весь этот суходроч глубоко по барабану - он вообще не знает, что такое стакан. И по рынку я, кстати, тоже никогда не торговал.

TGB, А что за зверь "модель случайных процессов"? И уж совершенно точно, что никакая "модель толпы" нафиг не нужна - как известно, "любая толпа - это толпа баранов". Да, "единственным критерием качества торговой стратегии является реальная прибыль автора стратегии", так что я давно перестал путаться под ногами у своего скрипта: в 9 случаях из 10 его решения лучше, чем мои.

Мазохисты..

У Владимира не CreateDataSource или там SetUpdateCallbackcallback, в первую очередь, потому, что он даже не пытался эту хрень использовать, ибо ему нужны, как минимум, сотни тикеров и, соответственно, тысячи свечей. И я даже не спрашиваю, работает ли что там у кого бы то ни было - я и так прекрасно знаю: сколько-нибудь удовлетворительно это дерьмо работать НЕ МОЖЕТ.

nikolz, Согласен, лапуль - засрать мозги Quikos я, возможно, и могу, а вот Вам - никогда. По причине полного их отсутствия. А учебники я давно уже не читаю - я их пишу.

Лапуль, я же тыщу раз здесь говорил, что эти дурацкие "японские" свечи есть полное дерьмо, придуманное неучами, слабо знакомыми с математикой. Свеча есть среднее значение курса за интервал. Точка. Именно так я это дело понимаю, именно так мой скрипт это использует при торговле. А свои бредни про "нормальный закон распределения" вместе со всей этой японской гадостью можете смело засунуть себе в задницу.  

nikolz, Лапуль, Вы бы хоть Вики полистали, что ли...

По оценкам на 2009 год, высокочастотная торговля составляла 60-73 % от всего объема сделок на рынках США, в 2012 году эта доля упала примерно до 50 %.
...
Обычно HFT-трейдеры конкурируют лишь друг с другом, но не с долгосрочными инвесторами.
...
По мере широкого внедрения стратегий высокочастотной торговли, становится все сложнее получать с их помощью прибыль. По оценке Frederi Viens (Purdue University) прибыли от всех HFT торговли в США упали с 5 миллиардов долларов в 2009 до 1,25 миллиардов в 2012.

Лично мне АБСОЛЮТНО насрать на этот лихорадочный суходроч стада баранов с крутым железом и полным отсутствием мозгофф - у меня ВСЕ заявки лимитированные, и как бы это стадо ни усиралось, оно НИКАК не может мне помешать. Это чистосердечное признание, что они вообще не умеют торговать и шакалят возле кассы, срубая свои несчастные копейки. Брокеру и бирже они, конечно, деньги приносят, а вот самим себе... и вся эта мышиная возня ради нескольких сраных миллиардов долларов? Ха-ха-ха!

nikolz, А на кой с ними соревноваться? HFT есть расписка в отсутствии нормальных алгоритмов торговли, суходроч по схеме "сила есть - ума не надо". Да и прибыль от них копеечная, если вообще есть.

Quikos, Да я тыщу раз говорил, что классические мат. ожидание и дисперсия в миллион раз информативнее этой японской гадости. Но при желании можно посчитать и их: первый замер после отсечки очередной свечи - начало, последний - конец, минимум и максимум считаем обычным образом. Но лично меня интересует только ОДНО значение - то самое среднее арифметическое. Дисперсию когда-то собирался посчитать, но оказалось, что она тоже нафиг не нужна.

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

Quikos, А зачем? Мне на это событие совершенно наплевать, как и на время сделки. Зачем вообще нужны свечи? Это основа для принятия решений - правильно? А все решения по определению вероятностные. Следовательно, особая точность при их определении не нужна. А раз так - я раз в секунду опрашиваю LAST из ТТТ и считаю свечу как среднее арифметическое за период (кстати, я даже округляю это значение с точностью до шага). В этом случае, если сделок не было, то свеча и будет тем самым LAST. То же самое будет, если между измерениями цена изменилась, но потом вернулась на место (не поймали этих сделок - да и хрен бы с ними). Раньше я опрашивал раз в полсекунды, но результат был почти идентичен, так что зачем попусту грузить процессор? Не говоря уже про то, чтобы считать свечи по таблице обезличенных сделок или по прерываниям. Эта же информация используется для определения текущей ликвидности тикера (по количеству пойманных сделок), а также для того, чтобы узнать, что тикер в данный момент не торгуется (например, в перерывах между сессиями все тикеры не торгуются, и программа это прекрасно видит). Загрузка процессора при этом никакая - до тысячи тикеров держит без проблем, надёжность очень высокая - вообще не припомню, чтобы какие-то глюки проявлялись, так нафига нам эта дурацкая CreateDataSource, глючная и тормознутая, которая в принципе не способна отслеживать хоть сколько-нибудь заметное количество тикеров?  

Quikos, Я сам считаю свечи. От десятисекундных до часовых.

Sergey Denegin, Скорость перерисовки таблицы действительно довольно высока: мне доводилось рисовать скриптом таблицу на 20К тикеров, т.е. примерно на 400К полей, при этом на моём дохленьком процессоре тормоза были заметны, но вполне терпимы. Скорость поступления данных тоже вполне терпима. Но есть ведь ещё и третья скорость: способность юзера кликать мышкой и давить на клавиши, и держать будет именно она. Кроме того, на эту таблицу придётся вешать и свой обработчик событий, а это уже чревато разными приятными неожиданностями, вплоть до отвисания Квика. Наконец, как бы быстро ни мельтешил стакан, соответствие его данных тому, что в данный момент творится на сервере, не гарантируется. А потому это совершенно бесполезная конструкция, даже если бы её вдруг удалось реализовать и без глюков. Попробуйте попасть в нужную строчку обычного встроенного стакана при бурных событиях на рынке - вряд ли получится. А с этим стаканом будет, как минимум, не лучше. Кроме того, данные часто меняются в непосредственной близости от рынка, а чуть подальше от него стакан уже статичен, почти неподвижен и, соответственно, юзеру почти не нужен. Скрипту тем более. А цены на границе рынка быстрее всего, проще всего и надёжнее всего ловить из ТТТ как BID и OFFER. Мой скрипт поступает именно так.

Quikos, Да плюньте Вы на этот CreateDataSource, это источник глюков и ничего более. Какая разница, что там происходит, если пользоваться этим всё равно невозможно?

nikolz, Лапуль, во-первых, связь не каждый день рвётся. Вернее, во-первых, каким боком здесь вообще провайдер и что ему здесь можно "показать"? А ну, шайбу!