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

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 27 След.
Классы
 
s_mike@rambler.ru,Если доработка софта не несёт никакой функциональности и не исправляет имеющиеся ошибки, полезнее промолчать. У вас с этим проблемы. А я впервые слышу об этом именно потому, что для торговли вся эта таблица нафиг не нужна - тем более, её поле class_codes.
Классы
 
s_mike@rambler.ru, А зачем ещё и этим забивать голову разработчикам "лучшего в мире ПО"? Я вообще первый раз слышу про существование таблицы trade_accounts, и мне АБСОЛЮТНО по барабану, "что некоторых классов из class_codes нет в таблице classes". НА КОЙ они нужны? Мой скрипт заглатывает при старте из входного файла перечень тикеров, за которыми ему велено следить, и там у каждого указан и код тикера, и код класса, и всё остальное, что скрипту надобно знать. Да пусть эта таблица тыщу лет не работает - упаси, Господи, от новых версий!
Прием данных и стаканов в различных потоках
 
БорисД, Борь, у меня сегодня ночью всё легло в единую схему, абсолютно всё! И фондовый рынок, и срочный, и свечная торговля, и спредовая. Пока меня лучше не кантовать денёк-другой, я тебе подробно отпишу потом по мылу. Коротко по твоему сообщению:

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

2. Умный робот на Луа и в Квике возможен. Не этот долбаный ИИ, конечно, а просто очень качественный, который заткнёт за пояс любого трейдера, торгующего руками.

3. Нет, "имеем" не значит "предполагаем", это значит "удалось выяснить из прочитанных статей". :smile:

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

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

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

7. Да, "доят лохов, в основном, не на этом", но и на этом тоже. А "психология" скрипт мало волнует: нервы у него крепкие, да и внимательность на высоте.

8. Да, с твоими аппетитами стакан нужен, как и собственный сервер на бирже, но в Квике это бесполезно пытаться использовать. Забыли, как страшный сон! Как говорил незабвенный Владимир Ильич: "Мы пойдём другим путём". :smile:  
Прием данных и стаканов в различных потоках
 
nikolz,
Цитата
Относительно приема данных в различных потоках есть разница в получении данных по свечам и по стаканам.
Ни малейшей! И то, и другое реализовано в Квике настолько безобразно, что пользоваться ни тем, ни другим просто нельзя - это глюки и тормоза, тормоза и глюки. А приём данных в разных потоках - это готовые ошибки синхронизации. А умный робот не тратит время ни на приём стаканов, ни на анализ их содержимого: работа со стаканом в принципе дурость, а ещё и в Квике это дурость в квадрате.

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

1. Обнаружение айсберг-заявок. Обсуждалось когда-то здесь. Выяснилось, что они нафиг не нужны, а обнаружить их в стакане можно лишь тогда, когда их подаёт очень тупой инвестор. Или, наоборот, очень умный, который хочет, чтобы его заявки были обнаружены. А спрятать айсберг от доморощенных аналитиков при желании проще простого.

2. Ух ты! "Сейчас биржевые стаканы считаются довольно устаревшей моделью анализа рынка и поэтому все меньше трейдеров ими пользуются". Дык я про то и говорю! Лично я этим говном не пользовался никогда. Разве что при ручной торговле, ещё до появления своего первого скрипта. И не для анализа, разумеется, а для совершения сделок. Ну да, тут и говорят про то, что всякие кукловоды доят лохов на фиктивных заявках и других "стаканных" разводках.

3. Собссно, больше в этих статьях ничего и не написано - так, ликбез, что такое стакан, бид, аск и прочая лабуда. Ха-ха-ха! "Вникать в анализ биржевого стакана полезно скальперам. Трейдерам на более длинных дистанциях следует ориентироваться на уровни поддержки/сопротивления и различные индикаторы". Детский сад!

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

А так согласен: "Хоть тысячу отдельных потоков сделай, они все встанут в очередь при обращении к хранилищу".
Отладка QUIK 8.13
 
БорисД, Согласен: 100 тысяч сделок в сутки - это всё равно никакой не HFT, это примерно две сделки в секунду. А если в портфеле сотня тикеров, то в среднем у них и вообще получается одна сделка в три минуты. А если 1000 тикеров... :smile: Но для Квика это почти предельная скорость.
Отладка QUIK 8.13
 
nikolz,
Цитата
объясняю почему у меня сборщик не мешает.
Лапуль, да хрен бы с ним, со сборщиком! На кой Ваш сраный "сервер в датацентре", если торгуете через брокера? А у брокера сервер где? Прямая торговля на бирже? А за каким тогда нужен этот убогий Квик с не менее убогим Луа? И говорил уже: Ваш суходроч с ЗАЯВКАМИ не говорит вообще ни о чём. Вот когда Вы "примерно за 4 часа совершите 150 тысяч СДЕЛОК", тогда можете о чём-то говорить. Хотя слабо верится, что у Вас денег хватит хотя бы на одну минуту такой работы.
Прием данных и стаканов в различных потоках
 
nikolz, Лапуль, подсказываю:
1. Слово "подскажите" в данном случае нужно писать через "е".
2. Потоки - понятие алгоритмическое, они могут быть организованы в любом количестве, но, как правило, в этом нет никакой необходимости: они являются главным источником тормозов и глюков. Идиотизм нынешней реализации QUIK как раз в том, что юзерам (по определению малоквалифицированным) подсунули ДВА потока, да ещё и подали этот маразм как крутое решение. То же самое со стеками: в моих программах не раз встречалось несколько стеков (максимально 5 или 6 - уже не помню), но это только для ОЧЕНЬ специфических задач! Для такой же примитивной задачи, как организация торговли, у меня изначально не было НИ ОДНОГО стека. А сейчас их целых ТРИ, и все до единого созданы лишь с целью борьбы с последствиями работы банды полуграмотных придурков, сварганивших ТАКОЙ программный интерфейс. Лапуль, дружеский совет: перестаньте заниматься хернёй, забудьте, как страшный сон всякие вумные словечки, вроде "вектора", "потоки", "пакеты", "мьютексы" и прочую белиберду - пишите в ОДНОМ потоке. И будет Вам ЩАСТЬЕ! Вот слова "синхронизация", к сожалению, забыть не получается, поскольку у этих дебилов всё-таки ДВА потока. Впрочем, я давно понял, что Ваша задача не написать нормальный скрипт, а изображать из себя крутого программера. Плохо получается, лапуль. Позорно плохо!
Отладка QUIK 8.13
 
nikolz, Один поток main для всех инструментов - это единственное устойчиво работающее решение при всех глюках системного софта.

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

Ах, Вы опять ловлей этих дурацких микросекунд занялись. Ну, флаг в руки. Когда коту делать нечего... :smile:

Лапуль, HFT предполагает высокую частоту СДЕЛОК, а не суходроч с заявками. А сделкам насрать на все Ваши микросекунды - они будут тогда, и только тогда, когда найдётся покупатель на продаваемую мной сделку и продавец на покупаемую.

Да, лапуль - со мной вообще говорить не серьёзно. Мой алгоритм работает и зарабатывает, а Ваш суходроч только на тесты мудацкие годится. Это в лучшем случае.

ЗА КАКИМ ХЕРОМ, лапуль, Вам "делать скрипты на луа многопоточные"? Что, зарабатывающие делать не получается, Данила-мастер?

О! Самообучающийся робот - это круто! Раз у разработчика мозгофф не хватает, так вдруг самообучающийся робот сам справится? Браво, лапуль! Бурные продолжительные аплодисменты, переходящие в овацию!

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

Лапуль, сколько можно повторять? У меня НЕТ никаких тормозов, мой скрипт спокойно работает с ТЫСЯЧАМИ тикеров, чего, как я полагаю, Ваше "микросекундное" говно делать не способно. Я прав? :wink:

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

TGB, Специальный сервер на бирже с прямыми каналами доступа к торгам тоже не поможет - Квик, батенька! Да ещё и Луа. А, ну да - ещё не дочитал до конца.

Предлагаю определение: HFT роботы не "манна небесная", а индикатор отсутствия у разработчика хоть одного мало-мальски пригодного алгоритма торговли. :smile:  
Отладка QUIK 8.13
 
nikolz, Ни секунды не было сомнений, что "робот с любым числом алгоритмов и любым числом инструментов должен работать  в одном скрипте QUIK"

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

Любой алгоритм для работы робота пишется в виде скрипта на чистом луа, без QLUA и выполняется в потоке main для всех инструментов.

Параметры по инструменту или портфелю хранятся в одной глобальной переменной (таблице Lua) и никуда не передаются.

И никаких индикаторов!

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

Ну очень нравится как оно работает в любой из версии Lua и QUIK.

Всё это работает вообще без каких-либо библиотек.

Очень быстро у меня исчезли любые пожелания по допиливанию QUIK. Я их просто боюсь - не все ещё глупости сделаны.

А насчёт HFT на QUIK согласен: это диагноз. :smile:  
# и table.getn, # и table.getn - косячно
 
nikolz, Стек-то LIFO, если брать только очерёдность обслуживания, но это не обязательно. Чистый стек, который однозначно LIFO у меня только стек прерываний. А стек сделок уже не стек в классическом понимании - там выбирается та сделка, которая сработала - и элемент с этой сделкой может располагаться где угодно. А на его место закидывается действительно последний на данный момент, чтобы дырок в массиве не было, а размер стека тоже уменьшается на единицу. Абсолютно та же техника и в стеке заявок, но там элементы вообще выбираются чуть ли не в порядке очереди. Но не совсем - некоторые элементы могут выбираться и вне очереди. А от стека во всех них то, что меняется всегда именно последний элемент - либо выбрасывается из стека, либо переносится в дырку. И что значит "максимальный размер"? ТЕКУЩИЙ размер! И он в большинстве случаев вообще нигде не хранится (для статических массивов), либо хранится в отдельной структуре данных, а нулевой элемент может использоваться и как обычный элемент массива, и для хранения метаданных о самом массиве. Например, нулевой элемент массива тикеров представляет собой сложное разветвлённое дерево на несколько десятков полей. Всё определяется удобством доступа к данным в каждом конкретном случае.

Как мне много лет назад ответил один программист, когда я ему тоже заявил, что стек это просто LIFO: "Просто LIFO - это магазин к АКМ". И он был прав!  :smile:  
# и table.getn, # и table.getn - косячно
 
Nikolay, Это если их инициализировать прямо в коде. У меня большинство массивов начинаются с нуля, а за дырками (в тех массивах, где они возможны) и размерами массивов слежу сам. Например, в стеках (заявок, сделок, прерываний) длина массива (она же ID последнего элемента) хранится как раз в его нулевом элементе. Очень удобно и очень надёжно, и плевать, что там "оператор #" по этому поводу думает - им я вообще не пользуюсь. Не говоря уже про "переопределенные метаметоды".
Количество активных заявок одной командой, Количество активных заявок одной командой
 
nikolz, Лапуль, Вы вообще читаете, что я пишу? Я говорил О СДЕЛКАХ, а не о заявках. У меня, например, более 90% заявок исполняются. Думаю, даже более 95%. Это во-первых. Во-вторых, если "скрипт по 36 акциям за час выставил и снял 64 тысячи заявок", то это ИДИОТИЗМ. Но тут ещё и вопрос: он просто ставил и снимал заявки или ещё и ОТСЛЕЖИВАЛ их? Ведь на каждую такую заявку приходит целая колода прерываний, и при тех цифрах их количество должно быть 30-50 в секунду, если не больше. Как дубли ловить будем? Или хрен бы с ними - главное послать, а там хоть трава не расти? А вот если Вы будете обслуживать свои заявки, то Квик СДОХНЕТ! АДНАЗНАЧНА!

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

Ну, "различные стратегии торговли" я могу обсуждать разве что с Борисом - он профессионал в торговле. А Ваши жалкие "стратегии" меня не интересуют от слова "совсем". Не вижу никаких проблем с "обнаружением начала тренда", причём на нескольких таймфреймах сразу и для всех тикеров, которые обслуживаются скриптом. Информирую, что для этого НЕ НАДО "просматривать быстро эти тысячи". И уже говорил, что пару тысяч тикеров мой скрипт уж как-нибудь сумеет обслужить даже на самом дохлом процессоре. И уже говорил, что делать на Квике HFT робота - это ИДИОТИЗМ. И что толку "размещать его в дата центре", если там используется интерпретируемый язык?
Количество активных заявок одной командой, Количество активных заявок одной командой
 
Nikolay,
Цитата
Может быть так, что терминал упал вчера, а восстановился только сегодня.
Убей, не понимаю, зачем нужно искать на свою жопу приключений.  Посмотрим на постулаты (ну или гипотезы):
1. Скрипт непрерывно работает часами (или даже днями, неделями).
2. Всё время, пока он работает, он мониторит состояние рынка, портфеля, кошелька и т.п.
3. В любой момент своей работы он может послать заявку на совершение сделки - с тем тикером и по такой цене, которая его устраивает здесь и сейчас.
4. Количество сделок, которые скрипт совершает в сутки, может варьироваться от единиц (при такой частоте, собссно, скрипт вообще не нужен) до десятков тысяч (при сотнях Квик наверняка сдохнет, да и при десятках спорный вопрос), т.е. допустимый диапазон десятки-сотни-тысячи сделок в сутки.
5. Количество ошибок при сделках в сутки (по любым причинам) может исчисляться ну никак не больше, чем единицами (иначе такой софт нужно просто выбросить на помойку), а потому интервалы между процедурами выявления таких ошибок должны составлять минуты, десятки минут, часы, но никак не секунды.
6. Чем позже принимается решение о сделке, тем (потенциально) у скрипта больше информации для его принятия.
7. Чем позже исполняется принятое решение о сделке, тем больше вероятность, что ситуация изменилась, и это решение уже устарело, что оно не было бы принято в тот момент, когда заявка исполнилась.
Вопрос: ТАК ЗА КАКИМ ХЕРОМ заниматься всем этим онанизмом? Что, трудно сбросить к чертям собачьим все открытые заявки при остановке или включении скрипта? Или посылать заявки именно тогда, когда скрипт посчитает нужным их совершить? У меня 90% заявок исполняются в течение нескольких секунд, а не исполненные снимаются через 3 минуты активности - всё, поезд ушёл, решение устарело! Зачем искать на свою жопу приключений? НЕ ПОНИМАЮ!
Количество активных заявок одной командой, Количество активных заявок одной командой
 
just, Никак. В смысле, из таблицы orders - никак. Но можно отслеживать их количество самим скриптом. Например, мой скрипт ведёт свой собственный стек активных заявок (точнее, не активных в смысле торговли, а ещё не обслуженных самим скриптом), и его размер сразу говорит об их количестве.  
Запуск скрипта из примера подвешивает терминал Quik
 
Konstantin, Коллбек содержит sleep?! Это же самоубийство! :smile:  
Запуск скрипта из примера подвешивает терминал Quik
 
nikolz, А что тут обосновывать? Ещё во времена моей молодости было какое-то исследование, что задержка реакции на действия пользователя свыше 5 секунд вызывает раздражение, свыше 15 секунд - нервные расстройства. С тех пор темп жизни ускорился, процессоры стали круче в тысячи раз, и любая задержка просто недопустима. Полсекунды - та самая граница, до которой юзер задержки не замечает и считает реакцию на свои действия практически мгновенной.

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

Лапуль, кто Вам сказал, что я "на один инструмент Вы трачу не менее 0.5 секунды сна + время обработки"? Я опрашиваю инструменты раз в секунду, но всю 1000 инструментов сразу. И нет проблем! :wink: Кое-где в этот момент принимаются решения на покупку или продажу, но это обычно лишь несколько десятков или сотен действий в сутки.
Запуск скрипта из примера подвешивает терминал Quik
 
nikolz, Использование sleep - ЛУЧШЕЕ решение! Простое, отлаженное, работающее, эффективное. Не sleep (1), конечно, а sleep (500). Использовать меньшие задержки в скриптах для торговли не вижу ни малейшего смысла. А если нет диалога, то и вообще sleep (1000).
Сдвиг массива без цикла for или while, Возможно ли сдвинуть массив без цикла for или while, если количество строк массива может изменяться?
 
Nikolay, Нет, вопрос был про сдвиг без цикла. А это либо добавление в конец, либо цикл, но "написанный дядей Васей" внутри этих функций. И кольцевой массив здесь не поможет - это просто очередь (так, например, обрабатываются прерывания от клавиатуры).
Сдвиг массива без цикла for или while, Возможно ли сдвинуть массив без цикла for или while, если количество строк массива может изменяться?
 
Nikolay, Не помогут. :smile:  
Сдвиг массива без цикла for или while, Возможно ли сдвинуть массив без цикла for или while, если количество строк массива может изменяться?
 
Айдар, Чисто алгоритмически сдвинуть массив без цикла проще простого: это либо вставка элемента либо его удаление. Если массив не отсортирован по какому-либо признаку, то добавлять новый элемент нужно всегда в конец, а при удалении текущего ставить последний элемент на его место и уменьшать размер массива на единицу. Если же требуется поддерживать существующую сортировку, без цикла обойтись невозможно. Точнее, невозможно, если данные организованы именно в виде массива, а не списка - там достаточно поправить нужным образом указатели.

Код не смотрел, но глаз сразу зацепился за OnAllTrade. Насколько я помню, это прерывание, причём очень глючное и страшно тормознутое, так что внутри него ваапще ничего делать категорически нельзя (а лучше не использовать вообще).
не все то золото, что блестит
 
nikolz, Лапуль, сколько раз можно повторять, что Вы и есть самый натуральный, без подмесу, чайник? И что профессионалу почти всё равно, на каком языке писать - была бы обеспечена требуемая функциональность.

Как всегда, уже постановка задачи бездарная до невозможности:

Есть ГРУППА инструментов X и их параметров P, причём набор параметров для разных инструментов и/или их классов может различаться и в таблицу не влезать - только в ГРУППУ таблиц. А "искать параметры конкретного инструмента X в этой таблице" нужно только В ИСКЛЮЧИТЕЛЬНЫХ случаях - при нормальной организации должно быть и так известно, где они лежат.
Цитата
Вопрос:
Как  быстрее сделать поиск нужного элемента таблицы.
Ответ: обратиться к нему по имени (лучше по индексу). А всю остальную бредятину выбросить на помойку. И тогда значение любого параметра просто достаётся из этой таблицы: V=T[X][P][a][b][c]

Да, бывает и так, что используется НЕСКОЛЬКО индексных массивов, в которых под одинаковыми номерами j пишем некие данные. Например, у меня аж ВОСЕМЬ таких массивов по ДЕВЯТИ таймфреймам для каждого из пары-тройки сотен или тысяч обслуживаемых инструментов. Это свечи (накапливаемые, последние и предпоследние), ранги скоростей движения курса, количество сделанных ставок на каждом таймфрейме и ещё кое-что. И обращение к ним одинаковое, лапуль, тупее не придумаешь. Например, в ячейке a[i][1][4][j] лежит размер массива сделанных ставок по i-му тикеру на j-м таймфрейме. И искать ничего не надо, подходи и бери. А криворукие бездари пущай перебирают в цикле свои "вариант 1" и "вариант 2" - что с них взять, кроме анализа?
не все то золото, что блестит
 
nikolz, АХХХРЕНИТЕЛЬНЫЕ "числовые данные", лапуль! Предположим, что 800 000 клиентов, предположим, что 100 серверов, предположим, что все одновременно заявки послали. Что ни предположение, то БСК.

Вот именно: мало ли что на заборе пишут. В смысле, в ФЗ. :smile:

В любом случае "реальное время" у робота на клиенте нужно измерять В СЕКУНДАХ, а не в МИЛЛИсекундах и не в МИКРОсекундах.  Шурупен зи?
не все то золото, что блестит
 
nikolz, Чушь полная.

1. Вероятность того, что все клиенты одновременно выставляют заявки РАВНА нулю.

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

3. Заявка клиента будет стоять в очереди до тех пор, пока не будет исполнена или снята, а никакие не "8 секунд". Если же под "заявкой" подразумевается любая транзакция, то время её обработки наверняка будет зависеть от её вида.

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

5. В любом случае "реальное время" у робота на клиенте нужно измерять В СЕКУНДАХ, а не в МИЛЛИсекундах и не в МИКРОсекундах. Dixi.
Сохранение результатов работы скрипта в файл
 
TGB, Лапуль, Вам известно слово "сарказм"? Пишется "безумная сложность", а произносится "НУ ЧТО ТУТ ВАЩЕ МОЖЕТ БЫТЬ СЛОЖНОГО"?! Когда-то здесь какой-то придурок (николз, кажется) говорил, что торговый робот сложнее шахматной программы.

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

1. Капс всегда был и остался способом выделения фрагментов текста. Иногда единственным (например, в Фейсбуке). Так что "это похоже" именно на выделение фрагментов текста, чем мой капс и является в действительности.

2. А при чём тут "технологические сложности"?  Сам язык убог до неприличия - даже тип integer отсутствует. Я говорил про беспомощность Ваших функций, которые, как я предполагаю (в код я не заглядывал и не собираюсь) способна сохранять Lua-таблицы (которые ничего общего с таблицами не имеют) или дерево, которое эта структура может образовать. Уже в моём третьем сообщении на этом форуме... нет, вру - в четвёртом от 29.09.2020 10:31:16 я писал:
Ну вот, по Вашей ссылке, первым же предложением: "Tables in Lua are not a data structure; they are the data structure. All structures that other languages offer---arrays, records, lists, queues, sets---are represented with tables in Lua". Иными словами, никаких структур данных просто НЕТ! Печально... А уж "обоснование" и вообще курам на смех: "Хотя мы МОЖЕМ (!) реализовать массивы и списки, таблицы мощнее. Многие алгоритмы упрощаются до тривиальности с использованием таблиц". И дальше вообще издевательство: "Например, вы редко пишете поиск в Lua, потому что таблицы предлагают прямой (!!!) доступ к любому типу". Ребятки, доступ по ключу - это не прямой, а как раз КРИВОЙ доступ к данным! Даже если обозвать ключи "индексами". Уши бы надрать этому "Роберто Иерусалимскому!
В общем, с языком почти всё ясно: граф (точнее, дерево) объектов построить можно, а простейшую таблицу или даже массив - нельзя. Остаётся разобраться со строковыми переменными: способна ли эта loadstring интерпретировать строки как операторы языка (или, скажем, функции), то есть имеется ли здесь техническая возможность программирования данными.

3. Я вообще не говорил никогда про стратегию торгов - по крайней мере, про её сложность. Стратегии торгов достаточно простые - все до единой. По крайней мере, если для них сложность не самоцель, а задачей является эффективность стратегии. Да и откуда взяться сложности? Курс может либо расти, либо падать, либо стоять на месте, либо вообще торги по тикеру не ведутся - И ВСЁ! Больше даже вариантов никаких нет - просто безумная сложность!  :lol: Я говорил про сложность СТРУКТУРЫ данных, ЛОГИЧЕСКОЙ структуры, и предельная сложность такой структуры называется "граф общего вида" (если учесть, что узлами такого графа могут быть не только атомарные элементы, но и субграфы, а его рёбра также могут быть нагружены произвольной информацией, при этом количество рёбер по разным измерениям может быть переменным, в т.ч. нулевым.

4. Разумеется, "это не так". Единственно возможная структура на Lua представляет собой дерево, а обращение к её элементом конструкциями языка выглядит именно как обращение к ячейкам многомерного куба. Так что никакой "матрицы" нет и в помине. Более того, я терпеть не могу эти матрицы, и их нет вообще ни в одной из разработанных мною программ - я чуть ли не всю свою сознательную жизнь интересовался именно СЛОЖНЫМИ данными, а не этими погремушками.

5. Сложность данных не имеет ничего общего со сложностью типов данных - атомарные элементы (а никакие не "таблицы") могут быть любых типов, а в сохранённом виде это вообще одни только строки. Это ничуть не мешает построению из таких элементов конструкций ЛЮБОЙ сложности.

6. Вот именно: "надо стремиться к простоте". Не городить уродливую и беспомощную "универсальную" конструкцию, а делать простейшими способами то, что нужно. А нужно (мне) сохранить часть переменных (просто переменных или массивов, или деревьев) в файл - и не всех, которые там вообще есть, а те, которые мне НУЖНО сохранить. Сохраняются даже те данные, которых в структуре вообще нет - они рассчитываются "на лету" перед записью. И восстановить мне нужно не все данные, а те, которые мне НУЖНО восстановить, разбросав их по разным переменным, массивам, таблицам, деревьям. Вот и вся задача! И выполняется она в main (при запуске скрипта), в OnStop (по выходу), да раз в 5 минут (по таймеру) на всякий пожарный. Хоть сто лет думайте - ничего более простого не придумаете. :wink:

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

8. Господи, НУ ЗА КАКИМ ХЕРОМ нужно "сохранять и восстанавливать ВСЁ окружение"? Это же ИДИОТИЗМ! Нужно делать только то, что нужно, и ничего, кроме этого.
Сохранение результатов работы скрипта в файл
 
TGB, Пока?! Сколько можно повторять, что структура моих сохраняемых и восстанавливаемых данных НАМНОГО сложнее, и эта задача В ПРИНЦИПЕ не решаема такими функциями. Я не говорил, что эти функции не работают - я говорил, что они беспомощны в сколько-нибудь сложных случаях. Мне плевать, чужое это или своё - в любом случае такие функции практически бесполезны. И ещё больше плевать, какие там у Вас "возникают ощущения" - это Ваши комплексы, не мои. А про "мой непревзойденный скрипт" здесь знает разве что Борис, и никто более - я вообще про него практически ничего не говорил, кроме самых общих "технических" вопросов.

Да чего Вы ко мне прицепились? Не хочу я на Ваш код смотреть! Вообще не хочу, он алгоритмически убог, уже на стадии постановки задачи.
Сохранение результатов работы скрипта в файл
 
TGB, Я не вижу смысла в этих функциях - зачем же мне их тестировать? У меня для тестирования великое множество других, и даже связанных с торговлей, хотя алгоритмы торговли довольно просты, и проблемы там, в основном, связаны с глюками софта самого Квика - например, та самая синхронизация. Но есть и в тыщу раз более интересные задачи.
Сохранение результатов работы скрипта в файл
 
TGB, А у нас что, «батлз»? И я тыщу раз говорил, что я никогда не смотрю на то, КТО сказал - только на то, ЧТО сказано. Вы меня не интересуете, от слова "совсем", так что комментировать Вас я не собираюсь. Но если снова начнёте пороть чушь, ничего хорошего я Вам не гарантирую.
Сохранение результатов работы скрипта в файл
 
TGB, Да объяснял уже тыщу раз: "лапуля" - это термин такой, многократно доказавший за долгие годы применения свою высочайшую эффективность в вытравливании головожопых - они на него клюют, как на опарыша. И одновременно индикатор, что я уже не испытываю к собеседнику никаких чувств, кроме презрения. Вот именно, здесь форум по программированию, а не реклама маразматического софта как очередной вундервафли.

Лапуль, я уже затрахался торкать Вас носом, что сохраняется НЕ ВСЯ таблица, что сохраняемая структура в файле СОВЕРШЕННО ДРУГАЯ, нежели структура в ОЗУ, что восстанавливаются НЕ ВСЕ данные, что часть из них исполняется как операторы языка, что никакая универсальная утилита В ПРИНЦИПЕ не может этого сделать, что это не "таблица произвольной вложенности" и даже не дерево, а граф общего вида. Или, если Ваши мозги ничего кроме таблиц воспринимать не способны, это МНОЖЕСТВО таблиц, у которых ЧАСТЬ полей восстанавливается, а другая часть инициализируется значениями по умолчанию или читается из каких-то других источников. А "предложенные Вами коды можете засунуть себе в задницу - я вообще не могу представить, кому и за каким хреном это беспомощное дерьмо может понадобиться.

Господи, да насрать мне на Ваши грубые слова! Когда-то давно я воспринимал Вас как программиста, и даже примерно равного куда-то исчезнувшему Антону, с которым Вы когда-то пиписьками мерялись. Но это было давно. А сейчас я Воспринимаю Вас как надутого индюка - да, имеющего некоторые познания в программировании, но не более того. Много чести Вас в чём-то "затмить".
Сохранение результатов работы скрипта в файл
 
TGB, Лапуль, я и сам по себе хороший алгоритмист, и как таковой, знаю совершенно точно, что эту задачу никакая "универсальная" утилита В ПРИНЦИПЕ неспособна выполнить, какая бы хрень по этому поводу ни была где-либо написана кем бы то ни было. И я Вас уже торкал носом в этот Ваш коммент. Можем повторить(с):
НИКАКАЯ долбаная "сереализация" В ПРИНЦИПЕ неспособна это сделать! Хотя бы по той простой причине, что она не знает и не может знать, что и как сохранять, в каком виде, как и куда это всё восстанавливать. Она не будет работать НИКОГДА!
Сохранение результатов работы скрипта в файл
 
swerg, Блин, и первым же предложением "The table type implements associative arrays"! Лапуль, это не просто дебил, это КЛИНИЧЕСКИЙ дебил! Как и все, кто его читает. :smile:  
Сохранение результатов работы скрипта в файл
 
swerg, Лапуль, документацию, в которой таблица является типом данных, нужно относить на помойку, не читая.  :wink: Кто эту бредятину написал? Вы, что ли? Ах, Роберто Иерусалимский? Дык я чуть ли не в первом своём комменте на этом форуме говорил, что он дебил. Когаловский Михаил Рувимович - вот этого человека стоит читать, а не всяких придурков.
Сохранение результатов работы скрипта в файл
 
TGB, Да и я примирительно. Ну, сказали глупость - с кем не бывает?  :smile: И кто Вам сказал, что я злюсь? Я всего лишь сказал, что Ваше беспомощное дерьмо НИКОГДА оно не сделает из того, что требуется. И это просто медицинский факт.
Сохранение результатов работы скрипта в файл
 
Естественно, Вы нигде не писали, что сереализация знает что и как сохранять - я бы Вас высмеял беспощадно. НА КОЙ мне эти дурацкие функции tbl_to_string и string_to_tbl, если они по определению нихрена не умеют? Тем более, что весь код моего парсера и сохранения короче кода Ваших функций, которым вне зависимости от этого место только на помойке. НЕ МОГ БЫ я "заменить весь свой код по сохранению и при необходимости восстановлению моего графа двумя строками"! НЕ МОГ! Я же русским языком сказал, что при восстановлении подавляющее большинство всех этих данных теряют актуальность и НЕ ДОЛЖНЫ восстанавливаться! И что транспортный формат данных отличается от рабочего, И ДОЛЖЕН от него отличаться. И что часть данных предназначена для человека, и это не копия какого-то куска таблицы, а, в большинстве своём, РАСЧЁТНЫЕ данные, и что при восстановлении такие данные должны игнорироваться. Могу добавить, что есть ещё часть данных, которые записываются в синтаксисе языка Lua, и при восстановлении никуда не восстанавливаются, а просто исполняются как операторы языка (через loadstring). Так на кой мне (или кому бы то ни было) Ваше беспомощное дерьмо? НИКОГДА оно не сделает из того, что требуется. НИКОГДА! :wink:  
Сохранение результатов работы скрипта в файл
 
TGB, О, Господи!

КАКАЯ, блин, "таблица преобразовалась в КАКУЮ строку"?! Часть таблицы Lua (ЧАСТЬ, а не вся таблица!) преобразуется ВО МНОЖЕСТВО строк, файла, причём их структура РАЗНАЯ. Эти строки содержат информацию о рынке, о портфеле пользователя, о самом пользователе (код клиента, номер счёта и т.д.), о его сделках, текущей прибыли/убытку по тикерам, информацию по свечам, размер лота, ранги скоростей движения курса по таймфреймам, информацию о незакрытых заявках и прочая, и прочая, и прочая. Подавляющего большинства этих данных в файле дампа просто НЕТ, их НЕЛЬЗЯ сохранять и восстанавливать, ибо к моменту восстановления там будут ДРУГИЕ значения. Сохраняемых и восстанавливаемых данных там не более 10-20% от общего их количества, и они имеют СОВСЕМ ДРУГУЮ структуру. Мало того: туда записывается информация для самого пользователя, вроде отчёта о текущем состоянии портфеля по всем сделанным ставкам. НИКАКАЯ долбаная "сереализация" В ПРИНЦИПЕ неспособна это сделать! Хотя бы по той простой причине, что она не знает и не может знать, что и как сохранять, в каком виде, как и куда это всё восстанавливать. Она не будет работать НИКОГДА!
Сохранение результатов работы скрипта в файл
 
TGB, Это Вы "читайте внимательно" - не только ТОТ пост, который процитировали, но и самый первый в ветке. И там не "из контекста можно понять", а открытым текстом сказано, что и как. К тому же "таблица как ТИП ДАННЫХ" есть идиотизм. И кто Вам сказал, что "элементарный код я представляю как ваше открытие"? Это утверждение не соответствует действительности, а потому отвечать на вопрос "зачем" относительно лживого утверждения не имеет смысла. А Ваши "сильные подозрения" меня не интересуют.
Цитата
Справится. Попробуйте.  
Зачем мне "пробовать"? Любому дебилу понятно, что исходная и сохраняемая структура - это РАЗНЫЕ структуры. Или не любому?
Сохранение результатов работы скрипта в файл
 
TGB, Я так и сказал: "Зачем просто, когда можно сложно?"  :smile: Задача организации торговли элементарна, возможности языка ничтожны, глюков предостаточно, и лично я ещё до того, как написал свою первую строчку на Lua, знал, что буду использовать в качестве имён именно числовые индексы, и много раз здесь советовал поступать так же и писал, почему.

Здесь, кстати, вообще сказано, что нужно сохранять таблицу, созданную по AllocTable, т.е. таблицу Квика, а не таблицу Lua, и потому доступ к её данным должен осуществляться чем-то вроде getItem, так что никаких "таблиц произвольной вложенности, в которых индексами-ключами могут быть таблицы" там нет по определению.

Да, мой код не обработает ИДИОТСКУЮ таблицу: t = { [‘Тикер’] = 'SBER'}. А вот НОРМАЛЬНУЮ таблицу тот же код записи дампа прекрасно обрабатывает тем же способом, причём выводит не таблицу, а именно граф. Пара фрагментов РЕАЛЬНОГО кода записи этого всего в файл:

for i=1,N do -- цикл по тикерам
F:write(a[i][0][0].."\1"..a[i][0][1].."\2"..a[i][1][1].."\3"..d(a[i][1][2]).."\4"..d(a[i][1][3]).."\t");

Здесь выводится и код тикера, и код класса тикера, и код валюты тикера, и его качество (от "говна" до "отличного"), и его статус, где разные биты за что-то отвечают. Хранить эти данные в коде скрипта есть клинический маразм.

И далее (внутренний цикл):
while j<a[i][1][4] do -- выводим данные по сделкам
F:write(d(a[i][5][j])..":"..d(a[i][5][j+1]).."\t");
 j=j+2; -- переходим к следующей ставке

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

Парсер чуть сложнее. :smile:  
Сохранение результатов работы скрипта в файл
 
TGB, Зачем просто, когда можно сложно? :smile: На код просто смотреть страшно (и я не собираюсь этого делать). Программа пишется в 5 секунд, и она в 100500 раз проще, чем в этом "простом варианте". ЗА КАКИМ ХРЕНОМ нужна эта долбаная "конвертация таблицы в строку"? Заняться больше нечем?

Мой скрипт каждые 5 минут записывает дамп текущего состояния - так это целый граф, а не какая-то сраная таблица! Написать этот код ничуть не сложнее, чем этот пост. Вот, навскидку:
Код
for i=1,N do          -- цикл по строкам таблицы
 for j=1,M do          -- цикл по полям текущей строки таблицы
  F:write(Tab[i][j].."\t");     -- пишем значение поля с разделителем
 end;            -- конец цикла по полям
 F:write("\n");         -- разделитель строк
end;            -- конец цикла по строкам
Парсер чуть сложнее - пишется не в 5 секунд, а в 6. :smile:  
Сохранение результатов работы скрипта в файл
 
Дмитрий,
Цитата
Правильно тогда мой вопрос будет звучать как:
Результатом работы скрипта получается таблица как ТИП ДАННЫХ, которую нужно сохранить в файл.

О, Господи!.. Теперь уже и таблица стала "типом данных"? А граф тоже, или ещё нет? :smile:

В какой файл, в каком формате? CSV (как самое простое и разумное)? Тупейший двойной цикл: по строкам и (внутренний) по ячейкам текущей строки. Ну и разделители полей и кортежей нужно вставлять, разумеется.
Можно ли в квике настроить запрет запрет шортить или открывать позиции в лонг?
 
Евгений, Что значит "в квике нет"? Простейший if-then-else. Номера счетов скрипт знает? Заявки тоже он выставляет? Так какие проблемы?
Кривые шибки в QLua
 
TGB, Мои улучшения касаются именно алгоритмов торговли - о технических проблемах я давно хотел бы забыть, но вот не получается.

Практика показывает, что они и то, и другое только ухудшают. А само обилие версий говорит, что иначе и быть не может.
Кривые шибки в QLua
 
Я думаю, что описанные здесь ошибки (attempt to compare number with nil, tonumber вернул nil и т.п.) есть именно ошибки синхронизации (подобные вещи нередко встречаются и у меня). Места возникновения этих ошибок достаточно очевидны: коллбеки и обращения к таблицам QUIK, т.е. getParamEx, getDepoEx, GetCell и всё такое прочее, причём именно get, в не set - эти ошибки мало интересны. Любая из этих тварей может в любой момент вернуть nil - иногда так, что и сам скрипт вылетит. Надежды на то, что когда-либо хотя бы часть этих ошибок будет исправлена "на стороне Квика" лично у меня нет ни малейшей, так что бороться с ними придётся "подручными средствами". Такими средствами являются:

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

2. Как можно реже обращаться к таблицам Квика. У меня это только "orders", причём обращение к ней через getItem происходит лишь в некоторых экзотических случаях снятия несработавших заявок (вряд ли больше десятка-другого раз за сутки). Кроме того, я обращаюсь (через GetCell и тоже очень редко) к своим таблицам, созданным Квиком, но только к одному из столбцов таблицы по тикерам (невидимому), только для того, чтобы определить "настоящий" ID строки, который не меняется, скажем, при изменении порядка следования строк в таблице после сортировки и только для определения, по какому именно тикеру должно быть вызвано контекстное меню.

3. Проверять на nil во всех таких "опасных" ситуациях - это, по крайней мере, не приведёт к вылету скрипта.

4. Минимизировать время работы коллбеков. Например, мой OnTrade с течением времени оброс всякими проверками до неприличия из-за маразматической и годами не исправляемой ситуации с приходом нескольких прерываний на одно событие, да ещё и вразнобой, а также необходимости учёта "левых" сделок, совершённых в обход скрипта. Похоже, здесь тоже идут какие-то наводки из-за того, что во время обработки коллбека ещё что-то происходит. Планирую максимально облегчить сам OnTrade и перенести основную обработку в прерывание по таймеру, которое фактически находится в потоке main.

5. Очень аккуратно относиться к программированию диалога, средств для организации которого в Lua практически нет. Я толком не понимаю, что там происходит в обработчиках, устанавливаемых по SetTableNotificationCallback, но тут иногда даже не скрипт вылетает, а сам Квик отвисает.

Ну и не обращаться к техподдержке с пожеланиями что-либо исправить: в лучшем случае, останется всё как есть. :smile:  
Как обойти attempt to index a nil value ?, Как обойти attempt to index a nil value при отсутствии реальных значений в таблице
 
Дмитрий,Сюда посмотрите: https://forum.quik.ru/messages/forum10/message61995/topic6503/#message61995
Не могу заставить работать функцию Subscribe_Level_II_Quotes()
 
БорисД, Это не стакан, Борь, это ТТТ, т.е. на несколько порядков более быстрый способ. Стакан идеологически примерно та же хрень, как и со свечами: подписаться на него и Квик сам будет как-то менять там данные. И если даже со свечами работать практически невозможно (а свечи меня интересовали от 15 минут и выше!), то в стакане информация меняется тоже на несколько порядков быстрее. Так что по ТТТ за бид и аск следить можно и при паре тысяч тикеров, и при большем их количестве, а за стаканами или даже за свечами следить нельзя и при десятках, если не единицах - даже если не принимать во внимание бесконечные глюки Квика - только его тормоза. Тем более, что частота сделок у тебя намного выше, чем у меня, и я хочу её замедлить, чтобы сделки совершались не чаще, чем раз в секунду.
Не могу заставить работать функцию Subscribe_Level_II_Quotes()
 
Вася, Объясняю по пунктам:
1. И по Вашему собственному признанию, и по задаваемым здесь вопросам, Вы новичок в программировании, а здесь требуется уровень СУПЕРпрофессионала.
2. Мне совершенно наплевать на все эти '[Un]subscribe_Level_II_Quotes: во-первых, для принятия решение о сделках стакан практически бесполезен. Более того, он частенько используется именно в качестве разводки для лохов. Во-вторых, информация в стакане меняется очень быстро, и любыми своими "подписками и отписками" Вы безнадёжно теряете время. В-третьих, если "вопрос скорости обработки в этой задаче не критичен", то у меня просто фантазии не хватает, за каким хреном Вам понадобился стакан. И не 2000, а хотя бы один.
3. Если Ваша задача "выполнить функцию", а не "получить достоверные данные", то - извиняюсь - задача выполнима.  :smile:  
Не могу заставить работать функцию Subscribe_Level_II_Quotes()
 
Вася, Справиться с этой проблемой невозможно никак. Даже если у Вас будет десяток стаканов. А обслуживать 2000 тикеров не так просто даже моему скрипту, у которого ни одного стакана нет, не было, и не будет (Борис, слышишь меня? :smile: ). Ваша же задача просто безнадёжна, в принципе невыполнима.
Чудно считает CalcBuySell
 
TGB,  Я горячился очень давно и очень недолго - когда думал, что техподдержка заинтересована в качестве ПО QUIK. А у них задачи совсем другие: засрать софт любым говном, которое под руку попадётся, желательно глючным, и хорошенько это дело палкой перемешать. И я давно уже использую лишь АБСОЛЮТНО необходимые для торговли утилиты: OnTrade (тоже с дебильной, позорнейшей реализацией с колодой прерываний на одно событие), getParamEx, sendTransaction и ещё что-то. И я утверждаю, что пользоваться CalcBuySell и тому подобным говном может только полный идиот, ничего не понимающий в программировании. Приговор окончательный, обжалованию не подлежит. :smile:  
Чудно считает CalcBuySell
 
TGB, Мне АБСОЛЮТНО плевать, что там "его программа проверяет" - это ЕЁ проблемы. Мой же скрипт САМ проверяет свою состоятельность, и он при этом НЕ лезет в мой кошелёк - он имеет ту сумму в своём распоряжении, которую Я ей дал, и эта сумма может довольно заметно отличаться от содержимого моего кошелька, причём как в ту, так и в другую сторону (при маржинальной торговле). Мне НАСРАТЬ на "лимиты брокера" - в крайнем случае, он просто не пропустит мои заявки. Разумеется, "мои лимиты могут изменяться при выполнении заявок" - МОЙ скрипт это прекрасно учитывает при срабатывании OnTrade. И в гробу я видел эту идиотскую CalcBuySell, равно как и "обработку ситуации отказа выставления заявки" - просто OnTrade не сработает, И ВСЁ!
Чудно считает CalcBuySell
 
nikolz, Я сие могу объяснить.

1. Про функцию CalcBuySell первый раз слышу. Может, где и попадалась, но глаз проскальзывал мимо, ибо само название говорит, что это чистейший БСК.

2. Глянул в Гугл: "Функция предназначена для расчета максимально возможного количества лотов в заявке". ЧАВО???!!! Во-первых, за каким хреном мне нужно МАКСИМАЛЬНО возможное количество лотов в заявке? Во-вторых, откуда какая-то внешняя хреновина может знать, сколько МНЕ нужно лотов в МОЕЙ заявке?!

3. Смотрю формат вызова:  CalcBuySell(class_code, sec_code, client_code, account, price, is_buy, is_market). Что за бред?! А деньги-то где?! Да вы что, СОВСЕМ ОХРЕНЕЛИ?! Эта падла что, самостоятельно лезет в мой кошелёк, штоле? Да какое её собачье дело сколько чего там лежит?! И что, она думает, что я угроблю все свои деньги на одну-единственную сделку одного-единственного тикера?! Блин, да НАСРАТЬ, что и как она там считает, правильно или неправильно! Пользоваться этим дерьмом может только КЛИНИЧЕСКИЙ дебил!

Господа, вы ХОТЬ ЧТО-НИБУДЬ способны САМИ посчитать, СВОИМ СОБСТВЕННЫМ кодом, БЕЗ этих идиотских библиотек? Неужто не только программисты, но и быдлокодеры уже все повымерли?
Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 27 След.
Наверх