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

Артем, Это чушь свинячья, а не "прерывание по таймеру". Прерывание прерывает работающую программу, а не возвращает управление в приостановленную.

TGB, Это не диалог - это два монолога - Вы же не отвечаете на вопросы. Так что мне НИЧЕГО не известно о Ваших вариантах представления графов. А соревноваться мне с Вами не в чем.

TGB, Я очень редко читаю невнимательно - Вы НЕ ответили на мой вопрос, Вы всего лишь сказали, что Вы ДУМАЕТЕ. А вопрос этот принципиальный: либо Вы ЗНАЕТЕ другой способ представления графа, либо Вы его НЕ знаете (вариант "знаете, но используете этот" я отбрасываю, как абсолютно нереальный).

Это не "свое (особое) мнение" - это ТЕХНОЛОГИЯ! Причём не только представления графа, но и его МОДИФИКАЦИИ - а это "две большие разницы"!

Я почему схему транспорта Москвы упомянул? Однажды мой друг попросил её сделать на базе схем движения пассажирского транспорта, представленных на каком-то сайте администрации Москвы (там было десятка два мелких баз, доступных для скачивания). Я всё это дело объединил, определил "станции пересадок" (по координатной близости остановок) трёх видов: до 10 метров (фактически та же остановка, где можно пересесть на другой автобус или трамвай), до 50 метров (чуть отнесённая) и до 200 метров (это обычно выходы из метро). навесил на это дело территориальные деревья (улицы, районы, округа) и тематические (по названиям остановок) - школы, больницы, университеты, кафе, рестораны, магазины (продовольственные, винные, мебельные и прочие), парки, бассейны, музеи, кинотеатры, и прочая, и прочая, и прочая Не сделал только схему движения автомобилей или пешеходов (перекрёстки ведь тоже "станции пересадок" с улицы на улицу!) - исходных данных в тех базах было маловато, тут уже нужна карта вроде OpenStreetMap, Сделал, и говорю: "В каком формате тебе всю эту кухню выдать? JSON? Какой, нафиг, JSON? У меня нет никаких таблиц, у меня многомерный граф! Формат давай!" А вот формата он так и не сумел придумать - и это только для чтения и представления ПОДГОТОВЛЕННОЙ базы, а не для её модификации! А что может Ваша несчастная "сереализованная таблица Lua"? ДА НИЧЕГО!

TGB, Что "это" Вы "делали не один раз"? Вы можете это сделать - нет, не для схемы транспорта Москвы, а хотя бы вот для этой, достаточно примитивной задачи торговли? Хотя бы в усечённом виде, хотя бы в том, который я описал: счета-валюты-тикеры-заявки-сделки-свечи? Как доступ к элементам получать будете? Как будете, скажем, определять текущее состояние рынка в евровой зоне? Какая вообще будет структура данных - та самая, которую Вы собрались упаковывать-распаковывать?

Это я сказал (профессионализм - это шоры) много лет назад. Цитата точная.

Меня не интересует, что Вы думаете, и я не собираюсь гадать на кофейной гуще. Я задал вопрос: "Насчёт таблицы смежности я прав"? Вы способны на него ответить [Y/N]?

TGB, Опыт.    ОГРОМНЫЙ опыт! Насчёт таблицы смежности я прав?

TGB, А Вы это пробовали когда-нибудь РЕАЛЬНО это сделать? Я практически всю жизнь занимался сложными базами данных, у меня есть две утилитки, которые так и называются: RelToTree и TreeToRel, и я прекрасно знаю, что такое "упаковывать в строку (распаковывать) таблицу (!!!) Lua произвольной структуры" - в частности, на терабайтных базах и, в особенности, на сильно перевязанных базах (иногда с миллионами рёбер на узел графа, да ещё и разных измерений). То, что у Вас "граф" и "таблица" чуть ли не синонимы, говорит о том, что рёбра Вы представляете в виде примитивной таблицы смежности, с которой работать практически невозможно. Я уже не говорю про ошибки, которые имеют пакостную тенденцию накапливаться и плодить ошибки наведённые. Но даже без этого Ваша схема не будет работать НИКОГДА!

TGB, Во-первых, дерево-то можно, а вот граф произвольного вида - уже нельзя. У меня там на уровне хранения дерево, но на логическом уровне уже граф. Во-вторых, ЗАЧЕМ? НА КОЙ мне эта "серализованная таблица Lua", что я с ней делать-то буду? Мои данные сложнее, они в таблицу просто не лезут.

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

TGB, Каких ещё "строк"? У меня же там деревья!

Имеем N тикеров... нет, даже не так: имеем N валют, M тикеров по каждой валюте, К сделок по каждому тикеру с указанием цены и объёма каждой из них, текущий выигрыш (проигрыш) по каждой валюте и каждому тикеру, заявки на покупку (продажу), стоп-лоссы, свечи по 9 таймфреймам  (надо бы по 16), таймер когда снимать неисполненные заявки, код тикера/код класса/размер лота, код качества тикера (плохой/нормальный/хороший/отличный), код его статуса (можно/нельзя его роботу покупать/продавать), цена последней сделки/спроса/предложения, количество наличной валюты (на которую скрипту разрешено торговать), количество заблокированной валюты, статус кошелька по валютам (избыток/нехватка наличности) плюс всякая мелочь (код клиента, торговый счёт, обработчики событий от юзера и прочая хрень). Кроме того, данные там меняются со страшной силой - даже головное меню раз в 15 секунд может серьёзно поменять количество своих элементов! И вот это всё Вы предлагаете запихивать В СТРОКУ? Побойтесь Бога!  

Dr Wed, Но ведь "день" тоже понятие плавающее! К тому же, у ВТБ "концов сессии" минимум три.

Разные брокеры и должны выдавать разные данные. А что такое "кривые" и "нормальные"?.

Айдар, Толк от неё совсем в другом: это эмулятор прерывания по таймеру.

TGB, Именно описывать! Не "пакет IUP", конечно, а возможности прикладника при программировании в событиях.

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

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

Честно говоря, мне жаль выбрасывать средства организации диалога в SINT – за долгие годы там накопилось немало интересных решений: горизонтальные, вертикальные, двумерные, трёхмерные, виртуальные (невидимые), неоднородные, редактируемые меню, управление курсором, горячие клавиши, виртуальные клавиши, клавиши «внутрь» и «наружу» для каскадных (Z-меню), трёхмерных или двумерных меню специального вида (XZ или YZ), организация контекстной помощи и диагностики на ошибки, автоопределение координат или палитры, работа мыши в активных и неактивных координатах меню, локальные меню блоков, синхронизация изменения данных в параллельных окнах, плавающий размер паспорта меню, возможность задания собственного «бланка» меню с указанием на нём координат элементов, переопределение объектов до прорисовки меню, до цикла ожидания события, во время ожидания, после обработки события, перед выходом из меню (одно это расширяет возможности программиста со страшной силой – можно, например, организовать меню из элементов базы данных с их подкачкой и редактированием), разгон при листании некоторых видов меню… да разве всё перечислишь! Я даже немного баловался с «очеловечиванием» диалога: выдавал диагностики системы не статическими строками, а генератором фраз (техника вариантных списков) – склейкой фразы из компонентов-синонимов случайным образом. Получалось довольно эффектно: компьютер уже казался не тупой железякой, а живым собеседником. Или, по крайней мере, полуживым. Но больше всего жалко, конечно, применяемую в SINT технологию программирования диалога в объектах и событиях, которую при использовании веб-браузера практически невозможно сохранить. Частично её удаётся эмулировать путём использования фреймовой структуры, чудом сохранившейся функции eval «и какой-то матери», хотя это просто слёзы по сравнению с организацией диалога в SINT. Тем более, что каждый браузер (а нередко даже и разные версии одного и того же браузера!) работают, мягко говоря, по-разному. Этот раздел и посвящён браузеру как клиентской части СУБД. Второе его название – «Хождение по мукам». Или даже «Mein Kampf».

TGB, Да очень просто: таблица по тикерам и есть меню. А дочерние уже содержат информацию по выбранному тикеру. Но, поскольку она бывает довольно объёмная, неплохо было бы иметь и дочерние уже от него (например, по сделкам, по свечам. И редактировать в них кое-что не мешало бы.

TGB, Ну, я "рискнул использовать таблицу QUIK для создания диалога", и при этом именно "искал лёгких путей".

Я свято убеждён: "нормальные средства создания диалога" предполагают возможность программирования в событиях - все остальные способы ненормальные. А здесь даже и слова такого нет.

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

Структура меню также не выдерживает критики: у меня это «дерево» меню содержит несколько сотен веток от корня (думаю, вскоре дойдёт до пары тысяч) и время от времени хочется нарастить его до 3-го уровня, причём с редактируемыми элементами. Но потом вспомнишь, как Квик отвисает от команд, пришедших даже из первого уровня иерархии - и всё проходит.  

Anton, Какой, блин, "наброс"? Какой "дзен"? Арифметика, школьный курс! Я предлагаю отделить свечи от графиков, дать удобный сервис для их получения, и считать сами свечи по-нормальному, как сумму всех сделок за период, делённая на количество лотов в них. Без этого "японского" идиотизма. Оно, к тому же, и короче будет: одно значение вместо четырёх.

Господа, я написал как считается среднее арифметическое! Это известно тыщу лет назад, и именно так я считаю свои свечи (попроще, без объёмов, по которым у меня нет данных - да и фиг с ними). А если это кто-то назвал "SMA индикатором" (или там LWMA), то не следует эту глупость бездумно повторять.

BlaZed, Серьёзно? Оказывается, я всю жизнь разговаривал прозой? Тогда я тоже не перестаю с меня удивляться.

Какой это, в задницу, "индикатор"? Я эту формулу знаю со школьных лет, а школу я закончил в 1975 году, когда никаких индикаторов и в помине не было!

Сирануш, Одуреть! Кто лучше знает состояние Вашего портфеля: брокер или Вы сами?    

BlaZed, Ссылочку? Ну разве что на какой-нить учебник по арифметике.   Тупое мат. ожидание, то бишь среднее арифметическое. Ну, можно ещё и дисперсию дать - есть там какая-то мышиная возня вокруг него или нет. Заодно и гонки курса малыми объёмами будут затруднены. Короче, примерно так:
M=(n1*p1+n2*p2+n3*p3+...)/(n1+n2+n3+...)

BlaZed, Лучше бы она выкладывала нормальные свечки и простой доступ к ним. И не надо никаких индикаторов! Кстати, и свечки желательно без этих дурацких "японских" штучек, а нормальные, куда более информативные.

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

Я-то понимаю, что если на каком-либо инструменте вдруг видим цену 0, то это либо торгов нет, либо косяк какой с данными. А вот скрипт мой НЕ понимает, и я не очень понимаю, как ему это втолковать. Я также понимаю, что если там не 0, это всё равно ещё ничего не значит. Я когда-то поймал (писал здесь об этом) хороший индикатор: если не цена, а BID/OFFER в нуле, но оказалось, что и это не всегда так.

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

BlaZed,  Прям уж "такого значения быть не может". У меня "вот прям ща" у одного брокера два таких значения и у другого ещё одно. А перед началом торгов на Мосбирже там и ваще одни нули. А в СПб все данные с виду нормальные, но торгов-то всё равно нет.  

BlaZed, Именно "степени двоек"! Там просто НЕМЕРЯНОЕ количество информации для принятия решений! Представьте: имеем по две свечи, зато сразу по 16 таймфреймам (к меня сейчас по 9). Из них: две месячные, две недельные и далее со всеми остановками. То есть мы видим движение курса сразу на всех уровнях, да ещё и имеем возможность оценить, как каждый таймфрейм ведёт себя относительно родительского (стоит, растёт или падает) и как ведёт себя по отношению к нему дочерний таймфрейм! Ну разве может какой-то сраный график, да ещё и по заранее выбранному таймфрейму, дать столько информации? Да ни в жисть!

Да, я как раз считаю из ТТТ по LAST.

BlaZed, Вот и плохо, что "не при созревании". Надо бы дать пожелание разработчикам на доработку софта.

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

Да я уже когда-то заводил ветку с предложениями. Потом осмотрелся немного и перестал.  

BlaZed, А как я ещё должен писать? Мне и в голову не приходило, что они могут давать незакрытые свечи! А так всё просто: свеча созрела, пришла - прерывание.

Нет, мы и говорим о разном: у меня незакрытая (накапливаемая) свеча существует лишь потому, что я сам её считаю, как сервер. А вот отдаю её "клиенту" лишь тогда, когда она будет закрыта. Фактически в прерывании и отдаю (15-секундном). А накапливается она в полуторасекундном, то есть обработчик свечей и знать не знает о её существовании: раз он вообще получил управления, значит, пришла новая свеча.

А зачем тогда этот форум, если "разработчики менять все равно ничего не будут"?   Это же бесплатный набор тестирующих их софт, причём крайне заинтересованных в его качестве!

Dr Wed, В ТТТ затолкать ничего нельзя - она только для чтения.

BlaZed, А какие же ещё могут поступать новые данные в источник, если не свечи?

Ещё как не пофиг! Мне и в страшном сне не могло присниться искать свечи в функциях для графиков! Тем более, что понятия "скрипт" и "индикатор" здесь с какого-то бодуна разные - тоже не понимаю, какая разница: и то, и другое есть программируемый код, интерпретируемый исполнительным механизмом. И свечи нужны именно моему скрипту - индикаторов у меня нет и не будет.

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

Не понимаю, как такое решение может не подходить другим. если сделок нет - объём нулевой, а все эти H/L/O/C равны цене последней реальной сделки. Абсолютна вся информация здесь имеется для любой стратегии.

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

BlaZed, Ну и замечательно! Квик загружает исторические данные, скрипт их читает, если хочет по прерыванию - заказывает коллбек на событие "пришла новая свеча". В любом случае, данные с сервера получает Квик,а не юзер - в том виде, в каком удобнее именно ему.

График-то построить можно, но это РАЗНЫЕ процессы - зачем же их смешивать? Мне вот графики нафиг не нужны, а свечи на что-то и пригодились бы.

Да, конечно, можно и сразу получить часы - я имел в виду, что даже для минутных свечей при нынешних каналах связи объёмы никакие. И потом: откуда Квику знать, что нужно Вам? Он вполне может отдавать Вам то, что нужно Вам, а получать от сервера то, что нужно ему. Может, ему выгоднее получить один массив на все таймфреймы и формировать данные для юзера "на лету"? А нам какое дело, как именно он готовит для нас данные? Это проблемы Квика, а не наши. Кстати, и на низколиквидных инструментах свечи могут идти обычным порядком - мои так и считаются: вот включил я комп в 7 часов, так у меня все рублёвые и евровые активы и большинство долларовых не торгуются, а свечки тикают - просто у них цена не меняется. Я именно по ним и определяю, торгуется данный инструмент в данный момент или нет.

Так ведь актуальные данные это ТОЖЕ исторические данные! Прилетать новые свечки могут, изменяться - нет.

Никогда раньше не интересовался этим вопросом, поскольку свечи считаю сам, но тема популярная - решил посмотреть и опупел. Всё как-то жутко сложно и непонятно. Во-первых, почему CreateDataSource? Ведь алгоритмически задача проста до безобразия: получить с сервера некий массив данных, причём исторических данных! Что здесь вообще можно "Create"? Во-вторых, какого хрена она в разделе "Функции для работы с графиками"? При чём тут вообще графики? У меня никаких графиков нет, не было и не будет, а со свечами я активно работаю. В-третьих, данные нужно получать фактически по одному интервалу (минутному), поскольку все остальные интервалы (даже полюбившиеся кому-то нестандартные) при необходимости прекрасно считаются из него прямо на клиенте (тики здесь явно инородное тело и должны быть выброшены нафиг). В-четвёртых, объём этих данных для одного тикера даже при круглосуточной работе: 60 минут * 24 часа * 30 дней * 12 месяцев * sizeof одной свечи = курам на смех даже за год, при этом более-менее востребованным является интервал размером в сутки, а время можно даже не указывать: порядковый номер свечи в массиве однозначно его идентифицирует. В-пятых, какого хрена здесь делает SetUpdateCallback?! Какая может быть "обработка изменившихся свечек"?! Повторяю: это ИСТОРИЧЕСКИЕ данные! Всё, поезд ушёл, ничего уже не меняется! Какой-то тихий ужас, господа! Неужели вся эта кухня вообще хоть как-то работает?  

Dr Wed, Все?! У меня не все, но их больше, даже если отбросить евровые. Похоже, глючит этот GetClassSecurities.

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

Dr Wed, Рассказывал уже создаёте таблицу, кидаете туда хоть все возможные инструменты, добавляете столбцы "код инструмента" и "код класса", забираете оттуда копипастом всё содержимое и делаете с ним всё, что душе угодно. Работы на пару минут.

Сирануш, Во дела!   А я как раз наоборот, почти мгновенно ушёл от Excel, как только заработал мой самый первый скрипт (который даже не умел ещё торговать). По актуальности данных и наглядности представления Excel и близко не стоял рядом со скриптом!

Сирануш,  А я что, не торгую роботами?   Но меня, например, абсолютно не интересуют фьючерсы, а для других это может быть основной (или даже единственный) класс, с которым они работают. В любом случае, зачем заставлять Квик гонять данные от брокера, если они Вам не нужны? Только плодить тормоза или потенциальные глюки. Поэтому МОИ "Текущие торги" содержат данные только о тех инструментах, которые В ПРИНЦИПЕ могут появиться В МОЁМ портфеле, а "Состояние счета" - что и сколько там УЖЕ лежит в данный момент. А что они там "входят и выходят" - да, состояние "Торгов" иногда корректируется. Например, меня "разочаровали" акции AAXN, ACIA, BEAT, BMCH, CBPO, CHA, CHL, CXO, EV, GSH, GTX, HDS, IMMU, IPHI, LVGO, MNK, MTSC, MYL, MYOK, PRSC, PS, RP, SINA, TIF, VAR, VIE, VRTU, WYND - их я выкинул не только из портфеля, но и из ТТТ. А вместо них залил туда несколько десятков новых тикеров. Скрипту-то какое дело? Он работает с теми инструментами, которые я ему укажу - я ведь главнее "железяки х..во й"!  

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

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

Maksimus, Lua - это просто антипод C! Близко ничего похожего! Гениальный язык и бездарная поделка с этой долбаной "динамической типизацией". Один goto чего стоит! В Си это обычный JMP (в отличие от ассемблера, без возможности межпрограммного перехода), а здесь это кастрированное убожество, нафиг никому не нужное. Про сборщик мусора я ваще молчу. И вершина идиотизма: тип integer вообще уничтожен!

Насчёт таблицы: вот здесь это обсуждалось: https://forum.quik.ru/messages/forum10/message55233/topic6454/#message55233

Maksimus, Язык, конечно, полный отстой, но написать рабочую программу можно и на нём. Главное, на мой взгляд, избегать здешних глюков (вплоть до подвешивания Квика), иногда очень глубоко сидящих и редко проявляющихся, а потому пользоваться таблицами Квика и/или прерываниями лучше только в случае крайней необходимости. Я, например, таблицей "Лимиты по денежным средствам" не пользуюсь вообще (как, впрочем, и всеми остальными, кроме Orders, да и та привлекается только в "экзотических" случаях). Вот "создать таблицу и туда эти данные затолкать" - разумное предложение, только не "графическую", а свою Lua-таблицу, держать и обрабатывать данные именно там (в "графической" собственный набор глюков имеется - в частности, уже указанная необходимость соблюдения порядка вызова команд, с непривычки повергающая в шок).

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

BlaZed, Да уж, сколько людей, столько и мнений. А у меня шортов вообще нет.  

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

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

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

BlaZed, Именно! А от "дрочилова" у меня такое средство: если заявка по данному тикеру подана, выставляется тайм-аут в 5 минут (или 4, не помню), и пока он не истечёт, никаких новых заявок. При этом гарантированно все прерывания по сделкам (они же приходят пачками) уже пройдут. А каждое такое прерывание (если заявка в несколько лотов, и не все они реализуются за одну сделку) продлевает этот тайм-аут: время начинает отсчитываться уже с неё. Правда, эта скотина оказалась изобретательная: она честно выдерживает эти 5 минут, после чего снимает несработавшую заявку (или её остаток), и в ту же секунду выставляет новую - эту подлянку я до конца ещё не поборол.  

Александр, А за что меня банить, лапуль? Я ведь не спамлю, я как раз наоборот, спамящих вытравливаю.  И тыщу раз уж говорил: я спокоен как фараон в пирамиде!

Старатель, Что случилось?  

У меня сегодня ТРИ РАЗА ПОДРЯД пропадал текст в таблице! В смысле, не восстанавливался после трёх нажатий на Enter (у меня на него повешено DestroyTable + AllocTable) - только на четвёртый раз сподобился! И это вообще первый случай, когда эта "восстанавливающая" примочка не сработала! Куда катимся?..  

Артем, Так, про "гиперпараметры" мы более ничего сказать не можем? Поквакали - и в тину?

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

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

Вот скажите мне, сударь: НАКОЙХЕР вообще нужен этот грёбаный "сборщик мусора"? ВОТ ЧТО ЕМУ ДЕЛАТЬ, например, в моём скрипте? Гадить висячими ссылками? Мешать ему работать в реальном времени? ОТЛЕЗЬ, ГНИДА! Это МОИ объекты, и не твоё свинячье дело, когда их удалять! Нет ссылки? А может, она через пять минут появится!  *  ты лезешь своими грязными лапами туда, куда тебя не просят?

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

Это Вы плохо себе представляете что такое сборщик мусора! Если "работать не останавливая основной тред они не могут принципиально", то это ГОВНО, а не сборщик мусора! А вот если это составная часть диспетчера памяти, то он же эту память и выделяет. И "референсы" эти несчастные может держать в своих служебных полях и считать их сразу по мере возникновения - это практически НИЧЕГО не стоит! А вот если рыскать по данным и заниматься всей этой хернёй - тогда да, базара нет!

Чо там у нас Вики-то говорит?.. О, ещё  Джон Маккарти этим занимался!  Маккарти - это Голова! И я уверен, что у него-то был прекрасный сборщик мусора!

В промышленных процедурных и объектных языках сборка мусора долго не использовалась. Предпочтение отдавалось ручному управлению памятью, как более эффективному и предсказуемому. Но со второй половины 1980-х годов...

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

Roman Azarov, Ok, только это явно очень редкая штука - я такое увидел впервые.

Roman Azarov, Да без проблем!Снятие ещё проще:

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

Блоки всегда по 24 байта, если этого недостаточно для размещения необходимой информации, используется несколько блоков.

Блоки связаны в дерево, то есть у них есть два служебных поля: AR (адрес вправо) и AD (адрес вниз). В некоторых случаях поле AR может отсутствовать. При освобождении блоков они передаются в дерево свободных блоков для повторного использования. Блоки хранятся в файле мультиузлов, адрес (точнее, индекс) входа в первый блок данных (как и в первый блок дерева свободных блоков) хранится в паспорте этого файла. Сами блоки располагаются сразу после паспорта.

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

ЧИВО-ЧИВО-ЧИВО?! Это что там за зверь такой "настройки гиперпараметров алгоритма"? Лично у меня робот, главным образом, спит, и это ничуть не снижает способность робота вести торговлю в плюс (и размер этого плюса меня более, чем устраивает - он заметно выше моих первоначальных ожиданий).

Roman Azarov, Я пытался продавать через свой скрипт (там у меня какая-то пародия на диалог написана), а там все заявки лимитированные, все подаются единообразно и даже одним и тем же куском кода. Что до условия "Немедленно или отклонить", я так понимаю, что это задаётся перед отправкой sendTransaction, причём это EXECUTION_CONDITION =  «FILL_OR_KILL». Я считал, что это необязательный параметр и ничего не заполнял. Может быть, следует явно прописать в коде EXECUTION_CONDITION =  «PUT_IN_QUEUE»?

Артем, Кто Вам сказал эти глупости? Каким образом сборщик мусора может помешать работе в реальном времени? Разве что написан криворукими бездарями. Тем более, что диспетчер памяти идеологически как раз функция ОС.

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