Сортировка и фильтры в lua таблицах

Страницы: 1 2 След.
RSS
Сортировка и фильтры в lua таблицах, Можно ли использовать сортировку с учётом типа данных в стобце ?
 
Здравствуйте.
Не нашёл в документации как необходимо организовать создание таблицы средствами lua - для того чтобы можно было использовать встроенные в quik функции сортировки и фильтров по столбцу ?
Где об этом можно прочитать ?

По ощущениям - всегда учитывается только формат string.
Ни дату, время ни числа в созданной lua таблице не отсортировать ?
 
Цитата
Boris написал:
Здравствуйте.
Не нашёл в документации как необходимо организовать создание таблицы средствами lua - для того чтобы можно было использовать встроенные в quik функции сортировки и фильтров по столбцу ?
Где об этом можно прочитать ?

По ощущениям - всегда учитывается только формат string.
Ни дату, время ни числа в созданной lua таблице не отсортировать ?
а в чем разница число это или дата или string?
VMLua сравнивает строки как числа , используя для этого хеш.
 
а если это число то переводит его в число.
 
Цитата
nikolz написал:
а в чем разница число это или дата или string?VMLua сравнивает строки как числа , используя для этого хеш.
нет, сортировка по типу стринг идёт только по байтовому коду символов (по ansi)

разница очень большая

например


В таблице (не сортированной) столбец с числами
2
1
3
11
33

Сортировка по string даст
1
11
2
3
33

Сортировка по типу число должна выдавать
1
2
3
11
33

То что разница есть и она огромна - это очевидно.
Но в не зависимости от того какой тип данных прописывается столбцу в lua таблице - сортировка таблиц в столбце идёт только по string.

Не ужели в принципе нельзя использовать на lua таблицах встроенную в quik таблицы сортировку ?
Неужели подобная банальность до сих пор не реализована ?
 
Напишите свою функции сортировки строк. В чем проблема.
 
Цитата
Nikolay написал:
Напишите свою функции сортировки строк. В чем проблема.
в том что таблица очень "живая" - с ней постоянно работает lua сборщик статистики (сотни изменений в минуту)
Если её постоянно ещё и пересортировывать - то нагрузка будет дикая - приводящая к тормозам всего интерфейса.
Подобные вещи должны делаться - в отдельном слое.

Ну и
1. не умеет по сути lua адекватно работать с ассоциированными массивами со строковыми ключами
2. невозможно назначить тому же столбцу событие - чтобы при клике мышкой на лету происходило переключение направления сортировки и происходила сортировка

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

А если это будет таблица как внутренний объект lua типа 'table', то просто реализовать один из алгоритмов сортировки, удовлетворяющий задаче. Благо сейчас их много есть.
 
Nikolay, А подключать как будете "свою функцию сортировки"? :smile:

Boris, Подумаешь, "сотни изменений в минуту". Во-первых, это ничтожно мало, во-вторых, тормоза при таких объёмах данных, если и будут, то никак не на сортировке, а на прорисовке. Да и то вряд ли.
 
Цитата
Владимир написал:
Boris, Да не идёт сортировка даже по string, не говоря уже про остальные типы. Она игнорирует знак, так что будет выдавать примерно такое:
Впрочем, что я - вот фрагмент сегодняшнего скрина, сортировка выполнена именно по этому столбцу:
Очевидный ляп разрабов - всем глаза мозолящий и не могут до адекватного состояния до сих пор довести такую мелочь (даже в 9й реинкарнации Quik).

И это при том что нас при создании столбцов таблицы заставляют указывать им тип.
Становится только жутковато, от того что вообще непонятно, а зачем вообще в AddColumn указывается тип ?
 
Boris, Да я уже привык. А данные в таблицах Квика почти мгновенно стали ТОЛЬКО строковыми. А при подаче транзакции это и вообще обязательное требование.
 
Цитата
Владимир написал:
Nikolay, А подключать как будете "свою функцию сортировки"? ::

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


В период высокой волатильности на рынке сборщик заполняющий таблицу - иногда уходит секунд 50 в астрал разгребать свои задачи.
А вы предлагаете в том же потоке всё это ещё и сортировать на лету ??
Это очень плохая идея...
 
Отзывчивость интерфейса - важнее.
Можно и без сортировки и фильтров прожить, но хочется чтобы было красиво и удобно ...
 
Boris, Ну, если со стаканов, то там и будут тормоза. Да и 5000 столбца, но каждая строка - это отдельный тикер. Примерно на 1000-2000 тикеров появляются тормоза, а при 10000-20000 тикерах они становятся раздражающе заметными. Но в астрал ничего не уходит даже в этом случае. Что до сортировки - я почти ежедневно сортирую массивы в миллионы, а иногда даже в миллиарды элементов - вот там могут быть некоторые проблемы, а здесь-то откуда?
 
Строка пропала, а редактировать посты здесь низзя. Исходный текст:

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

Поэтому в идеале - выведение в асинхронный слой вывода и там сортировка уже итоговых данных - без ожидания lua обработки
 
Если перевести массив на численные ключи то проблем отсортировать массив нет.
Но есть проблемы интерактивно для пользователя - выводить всё это.
 
Boris, У меня данные в таблице обновляются раз в две секунды, и та самая встроенная корявая сортировка Квика ПОДДЕРЖИВАЕТ сортировку в актуальном состоянии, перебрасывая при необходимости строки на новые места. Никогда никаких проблем с этим не замечал.
 
Boris, Кстати, массивы - это на самом деле файлы, и весьма заметную или даже основную часть времени отжирают именно файловые операции. Но и там сортировка соизмерима с временем копирования - ну, наверное в 2-3-4 раза дольше - не проверял.
 
Цитата
Владимир написал:
Boris, Кстати, массивы - это на самом деле файлы, и весьма заметную или даже основную часть времени отжирают именно файловые операции.
O_o

Вы хотите сказать что в Quik lua любая переменная типа массив используемая в скрипте - порождает отдельный файловый дескриптор с потоком чтения/записи данных на диске ?
 
Boris, Нет, я хочу сказать, что мои сортировки с миллионами элементов - это сортировки строк в файлах. На сортировки в Квике я вообще не обращал внимания. А свои взятки в портфеле сортирую сам. Пузырьком. И это сортировки в ОЗУ.
 
И всё таки ...
Разработчики Quik как нибудь отреагируют на пожелания клиентов: довести до ума lua таблицы?
Для того чтобы на них адекватно работали уже имеющиеся в Quik встроенные функции сортировки и фильтрации - с учётом типа значений в столбце (число, строка, время, дата)
 
для тех,кто не в курсе.
читаем документацию:
-----------------------
Реализация таблиц (они же массивы, объекты или хеш-таблицы).
Таблицы содержат свои элементы в двух частях: часть массива и часть хэша.
Все неотрицательные целочисленные ключи являются кандидатами на сохранение в   части массива.
Фактический размер массива равен наибольшему 'n' такому, что   используется более половины слотов между 1 и n.
Хэш использует сочетание таблицы разброса в цепочке с вариацией Брента.
Основным инвариантом этих таблиц является то, что если элемент не находится  в своей основной позиции
(т. е. «исходной» позиции, которую его хэш дает ему ),
то конфликтующий элемент находится в своей собственной основной позиции.
Следовательно, даже когда коэффициент загрузки достигает 100%, производительность остается хорошей.
-------------------------
Для тех, кто не понял, поясняю:
---------------------
Массивы в луа - это массивы в памяти.
Если используете индексы - целые числа, то это фактически массивы  СИ.
---------------
Передача массивов в функции выполняется по ссылке,
т е копия массива не делается а передается указатель.
 
вот фрагмент из исходников обращения к элементу массива.
Кто знает СИ да увидит.
----------------
   for (; i <= lim; i++) {
     if (!ttisnil(&t->array[i-1]))
       lc++;
   }
   nums[lg] += lc;
   ause += lc;
 }
 
Boris, Упаси, Господи! Я откровенно боюсь новых версий, так что пусть эти таблицы хоть вообще не работают - они ведь только для юзера - лишь бы сделки нормально проходили. Я вообще завёл в своём скрипте "Спящий режим", когда таблица свёрнута в небольшую иконку, и только в заголовке время тикает раз в 10 секунд, чтобы показать, что скрипт работает, а не висит. И не читайте документацию без крайней необходимости - то, что там написано, как правило, весьма далеко от реального положения дел.
 
для тех, кто не знает.
-----------------------
В луа реализована сортировка, поэтому нет надобности городить сортировку.
-----------------------
сортировка пузырьками - это медленная сортировка.
------------------------
читаем документацию:
Внутри table.sort используется быстрая сортировка, и она написана на C.
 
мульон значений сортируется примерно за 0.5 сек  на 64-разрядной версии Windows 10. Intel Core I7-4500U  
 
если это медленно< то можно загрузить внешнюю функцию на СИ
в этом случае  1 миллион сортируется за 0.085 секунд
 
для тех,кто не знает:
 
 
nikolz, Лапуль, ну Вы бы хоть в сортировку не лезли, изображая из себя знатока. Уж это СОВСЕМ моя зона.

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

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

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

Вот, лапуль, моя заметка про сортировку - для общего развития: http://sint.wc.lt/sortir.htm
 
Цитата
nikolz написал:
Реализация таблиц (они же массивы, объекты или хеш-таблицы).
не запутывайте людей с C# программерским мозгом.
Таблицы - это те окна с табличной информацией, которые видно пользователю и которые он может "пощупать" указателем мыша, отсортировать колонки, настроить фильтр в колонке - для вывода только того что нужно.
Ветка - о сортировке с учётом типа данных в столбцах именно в таких таблицах!

А то что касается массивов.
Есть объекты и массивы.
Массивы могут быть с положительными целочисленными ключами (и тогда у lua проблем нет) или со строковыми ключами (включая отрицательные числа) и тогда в lua у любого программера привыкшего к стройному Си-синтаксису и функционалу - начинаются дебаг-разборки, которые заставляют его матюкаться и проклинать тот момент когда он "сел за баранку этого чёртового lua пылесоса..." ))
 
Что-то я не понял про "привыкшего к стройному Си-синтаксису". Lua для сравнения строк использует С функцию strcoll. Ничего не выдумывая http://www.lua.org/source/5.3/lvm.c.html#l_strcmp.
Сравнение строк - это всегда, не то чтобы проблема, но, как минимум, повод подумать. Кроме Вас никто не знает что и как Вы хотите от символов 1, 10, 11, 2.
 
Nikolay, Да какая разница, что там Lua для сравнения строк использует? Сортирует она неправильно, и этого уже достаточно, чтобы на код вообще не смотреть. А даже беглый взгляд на него по ссылке говорит, что он корявый до невозможности. Сравнение строк - это и не проблема и не повод подумать. Ни каких-то структур под это дело заводить не требуется, ни длины строк определять. И терминатор строки не обязан быть нулевым байтом.
 
Цитата
Nikolay написал:
Что-то я не понял про "привыкшего к стройному Си-синтаксису". Lua для сравнения строк использует С функцию strcoll. Ничего не выдумывая
отсортируте массив массивов со СТРОКОВЫМИ ключами в lua - по значению одному из столбцов вложенных массивов.
вот может тогда поймёте в чём вывих мозга lua


И повторяю с программерской точки зрения - у меня нет никаких проблем с сортировкой массивов в lua ( не смотря на то что делать это придётся не самым удобным образом)

У меня есть большой массив данных, который выводится в ВИЗУАЛЬНУЮ таблицу и мог бы быть интерактивно и удобно для пользователя отсортирован в этой таблице - вообще без обращения к функциям lua - чисто уже имеющимся функционалом quik

Но разработчики Quik - видимо решили "забить, или положить ..."
 
Цитата
Boris написал:
отсортируте массив массивов со СТРОКОВЫМИ ключами в lua - по значению одному из столбцов вложенных массивов.вот может тогда поймёте в чём вывих мозга lua
В чем проблема - пишите свою анонимную функцию и сортируете.
Цитата
Boris написал:
У меня есть большой массив данных, который выводится в ВИЗУАЛЬНУЮ таблицу и мог бы быть интерактивно и удобно для пользователя отсортирован в этой таблице - вообще без обращения к функциям lua - чисто уже имеющимся функционалом quik
И это сортируется. Но, как я понимаю, Вас не устраивает как сортируется строковое представление чисел. Так делайте тип колонок числовой (QTABLE_DOUBLE_TYPE или QTABLE_INT_TYPE) и выводите числа, а не строки.
 
Nikolay,
Цитата
Вас не устраивает как сортируется строковое представление чисел. Так делайте тип колонок числовой (QTABLE_DOUBLE_TYPE или QTABLE_INT_TYPE) и выводите числа, а не строки.
Мой пост от 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. Ну и, конечно, как мне тут подсказали, любой чих, любые действия с таблицей должны заворачиваться в проверку флага, что кнопка останова скрипта не нажата.
 
Цитата
Владимир написал:
Мой пост от 14.10.2020 14:23:59
Да делайте как Вам угодно. Я не наблюдаю проблем сортировки для числовых колонок таблиц. Если хотите сортировать как строки, то да, тип строка, как число - число.
И проблем с добавлением и тем более удалением строк не наблюдается.
 
Nikolay, Вы не наблюдаете - я наблюдаю. Даже как строки она сортировать не умеет, а когда я поставил числа, там вообще чёрт знает что творилось. И проблемы с добавлением и удалением строк никуда не делись. Не знаю, как у Вас, а у меня в таблице раз в 10 секунд может измениться состав строк в зависимости от текущего содержимого портфеля и установленных фильтров. Не помню уже подробностей, но суть в том, что данные попадают не в те строки, в которых они должны быть. Точнее, не всегда попадают.
 
Цитата
Nikolay написал:
В чем проблема - пишите свою анонимную функцию и сортируете.
вы так ничего и не поняли ...

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

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

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

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

Вот, лапуль, моя заметка про сортировку - для общего развития:  http://sint.wc.lt/sortir.htm
Ну вы и дуб ВИ,
Вы хотя бы  таблицу выше посмотрели
Там правда без Вашего поноса словесного написано,
что быстрая сортировка имеет сложность в худшем случая N^2, а в среднем это N*logN.  а для пузырька в среднем это N^2
т е для 1024 элементов быстрая сортировка дает в среднем сложность 10 000 а пузырек 1 000 000.
т е пузырек в 100 раз медленнее чем быстрая уже на 1000 элементах.
вы же хвастаетесь сортировкой миллионов записей, а это будет уже тысячи  раз.
---------------------
Быстрая сортировка пишется 4 секунды.
 
Boris, Вы слишком оптимистичны.  :smile: Системная софтина не умеет адекватно работать отнюдь не только с массивами со СТРОКОВЫМИ ключами. У меня с самого начала все ключи были и остаются числовыми, и это лишь понижает, но не устраняет вероятность проявления самых разнообразных глюков. Вот, например, 25.03.2021 12:28:31 я писал:
Какие "индексируемые таблицы" - побойтесь Бога! Мне чуть ли не с первого дня стало очевидно, что тут постоянно путают индексы и имена, что является источником многочисленных глюков - в том числе, и в основном ПО Квика.

Или вот, 19.06.2021 19:08:23, в блоке пожеланий к техподдержке:
5. При удалении строк с помощью DeleteRow и/или вставке (InsertRow) могут проявляться разные неприятные эффекты (данные пропадают или записываются не в те строки). Похоже, здесь путаются понятия ключа и индекса (кстати, этот эффект проявляется в таблице заявок в Квике даже при ручной торговле: после обрыва связи часть строк могут оказаться пустыми, и помогает только перезапуск Квика).
Пожелание: исправить.
 
nikolz, Лапуль, это только распальцованные дебилы смотрят на всякие полурекламные штучки-дрючки, а нормальные люди ориентируются именно на худший случай. Так, моя "воронка" имеет логарифмическую сложность именно В ХУДШЕМ случае, а так она почти всегда линейная - особенно, если учитывать время загрузки и выгрузки данных, т.е. РЕАЛЬНОГО быстродействия, а не "по документации". :wink:  
 
Цитата
Владимир написал:
nikolz, Лапуль, это только распальцованные дебилы смотрят на всякие полурекламные штучки-дрючки, а нормальные люди ориентируются именно на худший случай. Так, моя "воронка" имеет логарифмическую сложность именно В ХУДШЕМ случае, а так она почти всегда линейная - особенно, если учитывать время загрузки и выгрузки данных, т.е. РЕАЛЬНОГО быстродействия, а не "по документации".  
Ну я понял , что ты распальцованный м..к, поэтому всегда кроме бла бла ничего в доказательство не пишешь.
----------------
худший случай у быстрой сортировке - это когда у тебя все сортируемые данные находятся в самом конце их поиска.
Но если худший случай у пузыря и фаст сортировки требует одинаковых затрат, то в среднем фаст всегда выигрывает и НИКОГДА не проигрывает.
но у тебя как всегда и труба ниже и дым жиже, но твое дебильное свое.
 
как я понял, никто конкретно ничего сказать не может, все лишь как Владимир пальцы растопырили и экран заплевали.
 
сортировка пузырьковая:
Код
void sortb(int *m,int n) 
{   int tmp,k;
   while(n>1) { // проход проверят, не пора ли заканчивать 
      k=0; // нет перестановок
      for (int i=1; i<n;++i) {
         if(m[i]/10<m[i-1]/10) {
            tmp=m[i-1];
            m[i-1]=m[i];
            m[i]=tmp;    
            k=i; // в к будет последний переставленный элемент
         }
      }
      n=k; // с k все отсортировано
   }
}
сортировка быстрая:
Код
// компаратор для qsort
int fcomp(const void *i, const void *j) 
{   return (*(int *)i)/10 - (*(int *)j)/10;
}
void sortq(int *m,int n) 
{
   qsort(m,n,sizeof(int),&fcomp);  
}
Время сортировки 100001 элемента на компьютере с процессором Intel i5 (3.3Ггц). Время указано в сек.
СортировкаПростаяПузырьковаяШейкернаяРасчёскойБыстрая (qsort)
Стабильная+++--
Случайный23.129.119.80.0200.055
Проблемный11.512.90.0020.0150.035
Обратный18.321.121.10.0260.037
 
nikolz, Какие тебе "доказательства" нужны, придурок? Алгоритм описан, разжёван до уровня, понятного любому головожопому (казалось бы), программа написана, отлажена, используется почти ежедневно, но распальцованному идиоту опять какая-то "конкретика" требуется.

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

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

По ощущениям - всегда учитывается только формат string.
Ни дату, время ни числа в созданной lua таблице не отсортировать ?
В Lua и в QUIK есть два разных понятия, определяемых одним термином "таблица".
1) Таблицы как тип данных языка Lua.
2) Таблица как элемент визуального интерфейса.

Вы о чем спрашиваете? Хорошо бы уточнять всегда, когда вы применяете термин "таблица" в рамках QLua / QUIK.
Иначе, как  видно по теме, "всё смешалось", каждый понял своё.
Страницы: 1 2 След.
Читают тему
Наверх