Сортировка массива & compare Function

[Ieshua]

Существует массив объектов, у которых есть поле title:String
Информация в нем может быть представлена любыми доступными на клавиатуре символами

Вопрос, как отсортировать массив так, чтобы сначла шли объекты, в которых первые символы title были русские, затем английские, а затем цифры?

Правда ли, что единственный возможный вариант реализации - это использование "compareFunction" внутри которой будет проверка по ASCII коду?

[__i]

в твоем случае нужно просто сортировать по убыванию )

(русские буквы > английские букв > цифры )
если например нужно чтобы сначало цифры потом рус потом англ то придеться свою функцию писать полюбому

[Kikasso]

Нужно наверное еще опцию выставить - "независимо от регистра". А что такого страшного в сортировке по функции?

[Ieshua]

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

Задача - есть ничто иное как список пользователей.

Сначала - русские от А до я, затем английские от A до z, затем цифры от 0 до 9

А что такого страшного в сортировке по функции?

Ничего страшного, просто в некоторых случаях придется сравнивать не только первые буквы title'ов

[INK•]

а раздели на 3 массива
с помощю charCodeAt
русские начинаются после тысчи с чем то

[Ieshua]

Сообщение от INK•

а раздели на 3 массива
с помощю charCodeAt
русские начинаются после тысчи с чем то

Уже так и сделал, сначала разделил на 3 массива, затем каждый из них отсортировал как мне нужно, а затем слепил обратно в нужном порядке...

[Dr.OH]

внутри которой будет проверка по ASCII коду

русские начинаются после тысчи с чем то

...а я всегда думал, что в ASCII 256 символов...

Уже так и сделал, сначала разделил на 3 массива, затем каждый из них отсортировал как мне нужно, а затем слепил обратно в нужном порядке...

Данная задача (сортировка массива и сравнение строк) уже решалась миллиард миллионов раз. Ты выбрал самый неоптимальный вариант.

[WindWalker]

А в чём неоптимальность-то?

Во Flash используется алгоритм Quick Sort, трудоёмкость которого от n*log(n) до n^2 (в зависимости от исходных данных).
От того, что массив сортируется по частям, мы практически ничего не проигрываем, а в некоторых случаях даже выигрываем.

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

[Dr.OH]

а кто тебе мешает применить любой из алгоритмов быстрой сортировки сразу ко всему массиву, просто немного изменив условие сравнения? И как ты выигрываешь, сортирую массив по частям?

[WindWalker]

Ещё раз говорю: условие сравнение будет трудоёмким, так как потребуется использовать цикл: сперва сравнить первые буквы, если они равны, то вторые, и так далее.
И всё это скриптом на AS, который явно проиграет нативному сравнению строк.

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

Кроме того, quick sort хоть и имеет в идеале трудоёмкость пропорциональную n*log(n), но на некоторых исходных данных трудоёмкость может достигнуть n*n.

Вот предположим нам и попались как раз такие нехорошие данные.
Если массив у нас разбивается на три равные части, то трудоёмкость будет пропорциональна (n/3)^2 + (n/3)^2+(n/3)^2, т.е. 1/3 * n^2.
В случае же сортировки всего массива, трудоёмкость получиться в три раза больше.

Разбиение массива и последующая склейка (по идее) имеют линейную трудоёмкость, и таким образом для здоровых массивов будут незначительными по сравнению с сортировкой.