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

Alexander, Кроме своего TRANS_ID использовать просто нечего - ничто другое не гарантирует, что транзакция наша. Да и эта айдишка не гарантирует  - иногда туда прилетают нули или явно левые айдишки вроде 10, 25 и т.п. Контроль исполнения у меня только по OnTrade, не вижу никакого смысла в использовании ни OnTransReply, ни OnOrder. Никакой очерёдности здесь не соблюдается от слова совсем - задержки в приходе прерываний или изменения содержимого таблиц Квика могут составлять 10 минут и более. Я присобачил какую-то пародию на нечёткий поиск, и у меня точность идентификации заявки, по которой пришла сделка, близка к 100%, но здесь мне очень помогает блокировка: подача заявки запрещена, если предыдущая заявка по этому тикеру не исполнена или не снята. И не только колбэки могут отправляться по нескольку раз, но и заявки могут исполняться в несколько сделок, причём прерывания по ним приходят крест-накрест собачьим шагом. А вот цена в разных сделках по одной заявке может и отличаться. И, наконец, Вы НИ В ЧЁМ не можете быть уверены. В частности, самые первые вызовы OnTrade (остальное прерывания я не использую) могут содержать как раз бракованные данные, а самые вторые или самые третьи - правильные. А могут врать и все до единого. И проверка полей таблиц trans_id со своим номером транзакции не поможет. Я делаю подобную проверку только при снятии неисполненных или частично исполненных заявок, и далеко не всегда там правильные значения, а заявки я снимаю через три минуты активности.

Alexander, Я не знаю, что там происходит - знаю только, что глюков там дохренища, и от версии к версии это число растёт. С загрузкой-то можно и потерпеть, если достаточно редко отключать скрипт, а работа с ТТТ организована вполне себе терпимо, она реально быстрая, и у меня никогда не было проблем со скоростью, даже при очень большом количестве тикеров. Если, конечно, не пользоваться ни стаканами, ни графиками, ни обезличенными сделками - для торговли ничего из этого не требуется. Вот что иногда вылетает, скотина - это сильно раздражает. Время от времени прилетает nil, в т.ч. там, где его уж никак быть не может. Ставлю проверки на nil в тех местах - обычно помогает. Но, по большому счёту, весь софт надо переписывать с нуля, хотя никто этого не делает и делать не собирается.

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

Сергей, Лапуль, ещё лет двадцать назад я писал: "Время от времени какая-нить сопля имитирует демарш, дескать, не может она больше этого идиот[изм]а выносить. Не верьте - никуда она, нафиг, не денется". Это на тему Вашего "прощайте". Вы правы - я Вас не знаю, и знать не хочу. Вы дурак и трус - это у Вас написано на лбу.

Сергей, Лапуль, а с какого бодуна Вам должно быть обидно это всё читать? Это же Вы про меня здесь раскукарекались, а не я про Вас. Это не я, а Вы тут плакались в жилетку модераторам. Мне АЮСОЛЮТНО насрать на Ваше отношение ко мне, на Ваши посты, на Ваши комплексы и на Вас лично. Так будут ответы на мои вопросы, лапуль? Я кого-то оскорбил? Кого именно? Когда именно? Чем именно? Может, я хотя бы лично Вас оскорбил, лапуль? Может, хотя бы Вы осмелитесь ответить на эти вопросы? Нет?  

Сергей, Лапуль, я затрахался объяснять, что оскорбить невозможно даже теоретически - на мой взгляд, это должно быть понятно любому дебилу. Я кого-то оскорбил? Кого именно? Когда именно? Чем именно? Ау, униженные и оскорблённые, поднимите руки. Может, я хотя бы лично Вас оскорбил, лапуль? Может, хотя бы Вы осмелитесь ответить на эти вопросы? Нет?

Да не кричу я, придурок, какая я звезда - это Ваши собственные комплексы о чём-то там кричат. Вы даже не представляете, до какой степени Вы меня не интересуете. Увидел очередные визги про меня, любимого, посмотрел - какой-то Сергей в истерике бьётся. Кто такой? Понятия не имею, но, очевидно, закомплексованный дурак и трус - сразу к мамке жаловаться побежал. Да и хрен бы с ним - повизжит немножко и заткнётся - не он первый, не он последний. А что и как мне делать, я всегда решаю сам, без сопливых.

TGB, Господи, да пусть хоть в три слоя до пупа справками обвешается - это никак не влияет на тот медицинский факт, что он есть неграмотный дурак.  

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

Александр, Совершенно верно: этот колбек вызывается при совершении сделки. Если Вы сделок не планируете совершать, он Вам не нужен. А всему прогрессивному человечеству очень даже пригодится. А узнать лучшую цену предложения проще всего (и эффективнее всего) узнать именно в ТТТ, параметр OFFER. Лезть для этого в стакан - полнейшая глупость. Равно как и в ТОС. И вообще, любая подписка - это тормоза и глюки. И ничего более.

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

Александр, Программным доступом - это путём обращения к ТТТ через getParamEx. А прогрессивная часть человечества использует OnTrade.

Александр, Где Вы увидели у меня противоречие? Скрипт прекрасно обслуживает те тикеры, которые вообще не включены в таблицу, программным доступом, и это тысячекратно доказано экспериментально. Инициировать обмен может действительно наличие тикера в видимой копии ТТТ - для того, чтобы в этом убедиться, даже скрипт не нужен. А "Я так понимаю" означает, что я понятия не имею, как там что реализовано, и понимаю это ТАК. А прогрессивная часть человечества на данном форуме вообще никак не использует OnParam.

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

Александр,Она в Квике, а на вкладках всего лишь отображаются какие-то её поля. У меня частенько скрипт прекрасно обслуживает те тикеры, которые вообще не включены в таблицу, а такие столбцы, как BID. OFFER LASTCHANGE и т.д. я вообще сроду туда не выводил. Даже если ТТТ вообще не будет открыта ни на одной из вкладок, программный доступ к её полям будет работать.

Александр, ТТТ здесь вообще ни при чём, хоть там ни столбцы, ни строки нужные вообще не открыты. И она одна на весь Квик, сколько бы чего ни было открыто на разных вкладках.

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

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

Фрагмент из моей давней переписки с брокером:

Добрый день. У меня в последнее время появились нарастающие проблемы с Квиком. Проблемы следующие:
1. Загрузка самого Квика происходит неприлично долго (3-4 минуты) причём это время постепенно увеличивается.
2. Сегодня Квик отвис "без объяснения причин" прямо на старте, второй раз - через 15-20 минут работы. Вчера было два аналогичных отвисания - приходилось убивать Квик через диспетчер задач. Иногда Квик вылетал сам, с диагностикой (как я понимаю, от операционки) от "неизвестное программное исключение" до "unknown hard error". Поведение нестабильное: может проработать несколько часов или даже весь день, а может вылететь через несколько минут. В данный момент снова работает - не знаю, надолго ли.
3. Никаких графиков у меня нет - открыты таблицы ТТТ, состояние счёта, таблица заявок и ещё пара-тройка, вроде "позиции по деньгам". Никаких других задач, кроме двух Квиков от двух брокеров, на этом компьютере не запускается - работает только мой скрипт, написанный на чистом Lua и полностью идентичный скрипту, запущенному на другом Квике, который работает без нареканий.
4. Проблемы проявляются всё чаще и уже начинают серьёзно раздражать. Мой сегодняшний звонок в службу техподдержки закончился рекомендацией написать это письмо. Что мне делать?

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

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

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

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

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

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

Ах, "если поставить в цикл sleep(), то не виснет", панимаш! Так поставьте, и забудьте про это дело! Тем более, что sleep там всё равно нужен для эмуляции отсутствующих прерываний по таймеру. У меня стоит sleep(250), и одна эта команда позволяет мне организовать целую кучу таких обработчиков: 0.25-секундного, 0.5-секундного, секундного, 2-секундного, 10-секундного, 0.5-минутного, минутного, 10-минутного... что там у меня... а, ну да - и получасового. И приятным бонусом имеем: нигде никогда ничего не виснет. И мне АБСОЛЮТНО плевать, что там будет, если локальную переменную туда впендюрить или глобальную или ещё что - мне нужен устойчиво и правильно работающий торговый скрипт, а не набор дурацких тестов ни о чём.

Про ловлю микросекунд и загрузку ядер процессора я много раз говорил: это идиотизм. Настолько большой, что даже аргументировать лень. Так что все эти бредни про использование событий ядра ОС, CreateEvent, WaitForSingleObject, пул потоков и прочая ахинея есть Бред Сивой Кобылы. А если "за 4 часа выставляется и снимается 200 тысяч заявок", то это просто смертный приговор алгоритму торговли. Заявки выставляются для того, чтобы они исполнялись, а не снимались! У меня в скрипте более 90%, а в некоторые дни и все 100% заявок именно исполняются, а кому и на кой нужен этот суходроч со снятием заявок - поднимите руки!

Теперь про маразм на тему "общего глобального стека VMLua". Ну какое ваше собачье дело до всего этого, господа? Даже C не позволяет работать со стеком, и когда мне в своё время потребовалось организовать вызов функций с неизвестными на этапе компиляции именами и, соответственно, с неизвестным количеством и типом их аргументов, мне пришлось написать две ассемблерные функции, которые готовили для этого стек соответствующим образом, а вы пытаетесь туда лезть своими потными ручонками из убогого и глючного интерпретатора? Ну, флаг в руки...

Ну и до кучи: closure есть очередной идиотизм, придуманный криворукими бездарями, ничего не понимающими в программировании. А эта долбаная "область видимости" прекрасно иллюстрируется присутствующим в языке goto, кастрированным до неузнаваемости по сравнению с сишным аналогом и почти ни на что не способным.

Занимайтесь торговыми алгоритмами, господа, а не написанием нафиг никому не нужных тестов. И будет вам ЩАСТЬЕ!

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

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

nikolz, Ну каких, в жопу, "вычислительных ресурсов", лапуль? Для такой примитивной задачи, как организация торговли через Инет вполне хватило бы даже дохленького 8086, и уж за глаза любого компа, выпущенного в 21 веке. Это Вы тут постоянно зудите про многоядерные чудовища, которые нафиг никому не нужны. А криворукие бездари сожрут с аппетитом ЛЮБЫЕ ресурсы, им всё равно будет мало. В который раз уж советую: займитесь чем-нибудь другим, кроме программирования - тем, где Вы хоть что-то соображаете.  

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

Владислав, Лучше всего организовать ОДИН скрипт, работающий в ОДНОМ потоке и использующий ОДИН коллбек, а не заниматься всей этой фигнёй. Размер кода у меня в данный момент 37050 байт (это с диалогом, работой с файлами, обработкой коллбеков и всем остальным для срочного и фондового рынка), так что дробить его на куски не вижу ни малейшего смысла.

nikolz, Лапуль, Вы вообще условие той задачи читали или как всегда? Цитирую:
задача простая - торгуем бумагу. Таких бумаг 40+
"Смотрю" на разных ТФ (их 6+ по каждому инструменту).

swerg, Я уже несколько раз описывал. лапуль. Там всё просто как трусы по рубль сорок. И про результаты писал - свечи считаются по десятку таймфреймов (в данный момент по восьми: 10, 30 секунд,1, 2, 5,10,30 и 60 минут) для 1-2 тысяч тикеров (в данный момент для 85 штук - спасибо Путину за это). То есть порядка 10000 этих несчастных "индикаторов".  

swerg, ЩАЗ! Лично я все свечи считаю сам, от десятисекундных до часовых (считал и более тяжёлые, но практика показала, что пользы от них как с козла молока), и это НЕВООБРАЗИМО меньше грузит систему, чем брать готовые значения с индикаторов. Даже если забыть про графику.

nikolz, Лапуль, брехать не надо. Этот "умелец" миллионы, десятки, сотни миллионов, а пару раз и миллиарды строковых элементов сортирует ВОРОНКОЙ, до которой Вашему сраному "фасту" как до Луны. А здесь он сортирует действительно пузырьком, но массивы сделок конкретного тикера конкретного таймфрейма, а там обычно единицы, редко десятки элементов. Скажу больше: в этих условиях пузырёк есть САМЫЙ эффективный способ сортировки - именно по причине своей простоты. А свои "потери в скорости уже 1000 и десятки тысяч раз" можете засунуть туда же, куда и свой вонючий "фаст".
 

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

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

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

Да, лапуль: ОТ ВАС мне никакие ответы не нужны, и я говорю это Вам не первый год. И не надо трусливо прятаться за "все и вся" - просто я тоже не раз уж говорил, что с детства не перевариваю распальцованных дураков.

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

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

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

Вот именно, лапуль, что документация про QLUA а не про QUIK. Здесь ЕСТЬ возможность написать фильтр на луа и подключить его к таблице, а не тыкать мышкой по экрану, и никакой колбек для этого не нужен. У меня в скрипте есть два независимых фильтра: по валютам и по наличию или отсутствию тикера в портфеле. Есть ещё третий, по таймфреймам, но это уже в одном из видов контекстного меню. Просто программировать надо уметь, хоть немножечко.

Boris, Ну почему же? Вот, например, одно из самых первых моих сообщений на этом форуме, от 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 интерпретировать строки как операторы языка (или, скажем, функции), то есть имеется ли здесь техническая возможность программирования данными.

nikolz, Почитай хотя бы Вики, придурок:
Худший случай.
В самом несбалансированном варианте каждое разделение даёт два подмассива размерами 1 и {\displaystyle n-1}n-1, то есть при каждом рекурсивном вызове больший массив будет на 1 короче, чем в предыдущий раз. Такое может произойти, если в качестве опорного на каждом этапе будет выбран элемент либо наименьший, либо наибольший из всех обрабатываемых. При простейшем выборе опорного элемента — первого или последнего в массиве, — такой эффект даст уже отсортированный (в прямом или обратном порядке) массив, для среднего или любого другого фиксированного элемента «массив худшего случая» также может быть специально подобран. В этом случае потребуется {\displaystyle n-1}n-1 операций разделения, а общее время работы составит {\displaystyle \textstyle \sum _{i=0}^{n}(n-i)=O(n^{2})}\textstyle \sum _{{i=0}}^{n}(n-i)=O(n^{2}) операций, то есть сортировка будет выполняться за квадратичное время. Но количество обменов и, соответственно, время работы — это не самый большой его недостаток. Хуже то, что в таком случае глубина рекурсии при выполнении алгоритма достигнет n, что будет означать n-кратное сохранение адреса возврата и локальных переменных процедуры разделения массивов. Для больших значений n худший случай может привести к исчерпанию памяти (переполнению стека) во время работы программы.

То есть худший случай для быстрой сортировки - УЖЕ отсортированный массив - ПОЗОРИЩЕ. Для Воронки это АДНАЗНАЧНА линейная сложность - хоть для прямой, хоть для обратной сортировки. А подобрать для неё худший случай практически невозможно (в моей заметке описано, как это сделать), но даже в этом случае сложность будет ЛОГАРИФМИЧЕСКАЯ.

nikolz, Какие тебе "доказательства" нужны, придурок? Алгоритм описан, разжёван до уровня, понятного любому головожопому (казалось бы), программа написана, отлажена, используется почти ежедневно, но распальцованному идиоту опять какая-то "конкретика" требуется.

Худший случай, лапуль, у каждого алгоритма РАЗНЫЙ, и никакого "поиска" нормальным алгоритмам не требуется ВААПЩЕ. А свой долбаный "фаст" можете засунуть себе в задницу - тольо пузырёк имеет право на существование. И воронка. Всё остальное можно смело относить на помойку.

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

Boris, Вы слишком оптимистичны.   Системная софтина не умеет адекватно работать отнюдь не только с массивами со СТРОКОВЫМИ ключами. У меня с самого начала все ключи были и остаются числовыми, и это лишь понижает, но не устраняет вероятность проявления самых разнообразных глюков. Вот, например, 25.03.2021 12:28:31 я писал:
Какие "индексируемые таблицы" - побойтесь Бога! Мне чуть ли не с первого дня стало очевидно, что тут постоянно путают индексы и имена, что является источником многочисленных глюков - в том числе, и в основном ПО Квика.

Или вот, 19.06.2021 19:08:23, в блоке пожеланий к техподдержке:
5. При удалении строк с помощью DeleteRow и/или вставке (InsertRow) могут проявляться разные неприятные эффекты (данные пропадают или записываются не в те строки). Похоже, здесь путаются понятия ключа и индекса (кстати, этот эффект проявляется в таблице заявок в Квике даже при ручной торговле: после обрыва связи часть строк могут оказаться пустыми, и помогает только перезапуск Квика).
Пожелание: исправить.

nikolz, Лапуль, Ваша потрясающая квалификация В ПРИНЦИПЕ не позволяет что-либо обнаружить - Вы глупы и малограмотны. А кусок скрина экрана с неправильной сортировкой я приводил прямо в этой ветке. В который уж раз: очки купите.  

Nikolay, Вы не наблюдаете - я наблюдаю. Даже как строки она сортировать не умеет, а когда я поставил числа, там вообще чёрт знает что творилось. И проблемы с добавлением и удалением строк никуда не делись. Не знаю, как у Вас, а у меня в таблице раз в 10 секунд может измениться состав строк в зависимости от текущего содержимого портфеля и установленных фильтров. Не помню уже подробностей, но суть в том, что данные попадают не в те строки, в которых они должны быть. Точнее, не всегда попадают.

Nikolay,
Мой пост от 14.10.2020 14:23:59

Сделал для себя два вывода из вчерашних-сегодняшних экспериментов:

1. Вставку строк (InsertRow) следует производить всегда в конец таблицы (код -1) - тогда индексы и ключи совпадают, а вот DeleteRow не следует делать вообще, поскольку в этом случае у исполнителя крыша едет, и данные начинают попадать не в те строки. Не нашёл ничего лучшего, чем при необходимости удалить строку обнулять всю таблицу (Clear) и заново перенабить в ней все строки, которые должны отображаться.

2. При описании столбцов (AddColumn) не задавать им никаких QTABLE_INT_TYPE, QTABLE_DOUBLE_TYPE - оставить только QTABLE_STRING_TYPE, и при занесении значения в ячейки (SetCell) заворачивать значения в tostring - тогда, по крайней мере, сортировка по столбцам работает именно как сортировка строк, а не выдаёт результаты, от которых глаза на лоб лезут.

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

Nikolay, Да какая разница, что там Lua для сравнения строк использует? Сортирует она неправильно, и этого уже достаточно, чтобы на код вообще не смотреть. А даже беглый взгляд на него по ссылке говорит, что он корявый до невозможности. Сравнение строк - это и не проблема и не повод подумать. Ни каких-то структур под это дело заводить не требуется, ни длины строк определять. И терминатор строки не обязан быть нулевым байтом.

nikolz, Лапуль, ну Вы бы хоть в сортировку не лезли, изображая из себя знатока. Уж это СОВСЕМ моя зона.

В луа БЕЗОБРАЗНО реализована сортировка, поэтому нет смысла ею пользоваться вообще.

Сортировка пузырьком - это ПРОСТЕЙШАЯ сортировка, пишется в 5 секунд и в 99.999% случаев она достаточна для практического использования.

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

Вот, лапуль, моя заметка про сортировку - для общего развития: http://sint.wc.lt/sortir.htm

Boris, Упаси, Господи! Я откровенно боюсь новых версий, так что пусть эти таблицы хоть вообще не работают - они ведь только для юзера - лишь бы сделки нормально проходили. Я вообще завёл в своём скрипте "Спящий режим", когда таблица свёрнута в небольшую иконку, и только в заголовке время тикает раз в 10 секунд, чтобы показать, что скрипт работает, а не висит. И не читайте документацию без крайней необходимости - то, что там написано, как правило, весьма далеко от реального положения дел.

Boris, Нет, я хочу сказать, что мои сортировки с миллионами элементов - это сортировки строк в файлах. На сортировки в Квике я вообще не обращал внимания. А свои взятки в портфеле сортирую сам. Пузырьком. И это сортировки в ОЗУ.

Boris, Кстати, массивы - это на самом деле файлы, и весьма заметную или даже основную часть времени отжирают именно файловые операции. Но и там сортировка соизмерима с временем копирования - ну, наверное в 2-3-4 раза дольше - не проверял.

Boris, У меня данные в таблице обновляются раз в две секунды, и та самая встроенная корявая сортировка Квика ПОДДЕРЖИВАЕТ сортировку в актуальном состоянии, перебрасывая при необходимости строки на новые места. Никогда никаких проблем с этим не замечал.

Строка пропала, а редактировать посты здесь низзя. Исходный текст:

Ну, если со стаканов, то там и будут тормоза. Да и 5000 столбцов для таблиц Квика многовато. У меня сейчас 23 столбца, но каждая строка - это отдельный тикер. Примерно на 1000-2000 тикеров появляются тормоза, а при 10000-20000 тикерах они становятся раздражающе заметными. Но в астрал ничего не уходит даже в этом случае. Что до сортировки - я почти ежедневно сортирую массивы в миллионы, а иногда даже в миллиарды элементов - вот там могут быть некоторые проблемы, а здесь-то откуда?

Boris, Ну, если со стаканов, то там и будут тормоза. Да и 5000 столбца, но каждая строка - это отдельный тикер. Примерно на 1000-2000 тикеров появляются тормоза, а при 10000-20000 тикерах они становятся раздражающе заметными. Но в астрал ничего не уходит даже в этом случае. Что до сортировки - я почти ежедневно сортирую массивы в миллионы, а иногда даже в миллиарды элементов - вот там могут быть некоторые проблемы, а здесь-то откуда?

Boris, Да я уже привык. А данные в таблицах Квика почти мгновенно стали ТОЛЬКО строковыми. А при подаче транзакции это и вообще обязательное требование.

Nikolay, А подключать как будете "свою функцию сортировки"?

Boris, Подумаешь, "сотни изменений в минуту". Во-первых, это ничтожно мало, во-вторых, тормоза при таких объёмах данных, если и будут, то никак не на сортировке, а на прорисовке. Да и то вряд ли.

Boris, Да не идёт сортировка даже по string, не говоря уже про остальные типы. Она игнорирует знак, так что будет выдавать примерно такое:
1
-11
2
-3
33
Впрочем, что я - вот фрагмент сегодняшнего скрина, сортировка выполнена именно по этому столбцу: