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

а если это число то переводит его в число.

Напишите свою функции сортировки строк. В чем проблема.

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

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

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

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

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

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

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

Если перевести массив на численные ключи то проблем отсортировать массив нет.
Но есть проблемы интерактивно для пользователя - выводить всё это.

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

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

для тех,кто не в курсе.
читаем документацию:
-----------------------
Реализация таблиц (они же массивы, объекты или хеш-таблицы).
Таблицы содержат свои элементы в двух частях: часть массива и часть хэша.
Все неотрицательные целочисленные ключи являются кандидатами на сохранение в   части массива.
Фактический размер массива равен наибольшему 'n' такому, что   используется более половины слотов между 1 и n.
Хэш использует сочетание таблицы разброса в цепочке с вариацией Брента.
Основным инвариантом этих таблиц является то, что если элемент не находится  в своей основной позиции
(т. е. «исходной» позиции, которую его хэш дает ему ),
то конфликтующий элемент находится в своей собственной основной позиции.
Следовательно, даже когда коэффициент загрузки достигает 100%, производительность остается хорошей.
-------------------------
Для тех, кто не понял, поясняю:
---------------------
Массивы в луа - это массивы в памяти.
Если используете индексы - целые числа, то это фактически массивы  СИ.
---------------
Передача массивов в функции выполняется по ссылке,
т е копия массива не делается а передается указатель.

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

мульон значений сортируется примерно за 0.5 сек  на 64-разрядной версии Windows 10. Intel Core I7-4500U  

для тех,кто не знает:
 

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

А то что касается массивов.
Есть объекты и массивы.
Массивы могут быть с положительными целочисленными ключами (и тогда у lua проблем нет) или со строковыми ключами (включая отрицательные числа) и тогда в lua у любого программера привыкшего к стройному Си-синтаксису и функционалу - начинаются дебаг-разборки, которые заставляют его матюкаться и проклинать тот момент когда он "сел за баранку этого чёртового lua пылесоса..." ))

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

В чем проблема - пишите свою анонимную функцию и сортируете.И это сортируется. Но, как я понимаю, Вас не устраивает как сортируется строковое представление чисел. Так делайте тип колонок числовой (QTABLE_DOUBLE_TYPE или QTABLE_INT_TYPE) и выводите числа, а не строки.

Да делайте как Вам угодно. Я не наблюдаю проблем сортировки для числовых колонок таблиц. Если хотите сортировать как строки, то да, тип строка, как число - число.
И проблем с добавлением и тем более удалением строк не наблюдается.

вы так ничего и не поняли ...

НЕ УМЕЕТ lua в принципе адекватно работать с массивами со СТРОКОВЫМИ ключами!
Отсортировать он их на прямую - тоже НЕ МОЖЕТ

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

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

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

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

сортировка пузырьковая:сортировка быстрая:Время сортировки 100001 элемента на компьютере с процессором Intel i5 (3.3Ггц). Время указано в сек.

Сортировка	Простая	Пузырьковая	Шейкерная	Расчёской	Быстрая (qsort)
Стабильная	+	+	+	-	-
Случайный	23.1	29.1	19.8	0.020	0.055
Проблемный	11.5	12.9	0.002	0.015	0.035
Обратный	18.3	21.1	21.1	0.026	0.037

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 худший случай может привести к исчерпанию памяти (переполнению стека) во время работы программы.

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