Не корректная сортировка в Map-e и Set-е. AX2009 RU5

[Pustik]

static void JobSortMap(Args _args)
{
    Map map = new Map(TYPES::String, TYPES::Real);
    MapIterator mit;
    ;
    
    map.insert('10', 0);
    map.insert('30', 0);
    map.insert('-10', 0);
    map.insert('-5', 0);
    map.insert('20', 0);
    map.insert('71', 0);
    map.insert('7-1', 0);
    map.insert('20-30', 0);
    
    mit = new MapIterator(map);
    while (mit.more())
    {
        info(mit.key());
        mit.next();
    }
}

Не давно заметили такую особенность, что при добавлении ключа типа String, который содержит в себе "тире" в Map, он не правильно его сортирует(размещает). Создается такое впечатление, что во время сортировки(размещения) в Map-e при добавлении таких вот записей он вообще "тире" не учитывает. Как будто выбрасывает, хотя ключ строит.
Результаты Job-a:
AX2009:
10
-10
20
20-30
30
-5
71
7-1
Axapta 3.0:
-10
-5
10
20
20-30
30
7-1
71
С Set-ами такая же хрень. Мне кажется в Axapta 3.0 сортировка более правильная.

[TasmanianDevil]

А как себя ведет MapEnumerator в таком случае ? MapIterator как-то был объявлен атавизмом ...

[Pustik]

Цитата:

Сообщение от TasmanianDevil

А как себя ведет MapEnumerator в таком случае ? MapIterator как-то был объявлен атавизмом ...

Проверил : точно так же.
Жаль, что испортили, неудобно.

[S.Kuskov]

Вот ещё про символ тире: Сортировка и сравнение строк

[Владимир Максимов]

Нет. Здесь другая проблема. Символ дефиса, в данном случае, выступает как некий управляющий символ. И режим сортировки тут вообще не при чем

static void Job_Test(Args _args)
{
    void comp(str _str1, str _str2)
    {
        if (_str1 > _str2)
        {
            info(_str1 + ' больше ' + _str2);
        }
        if (_str1 < _str2)
        {
            info(_str1 + ' меньше ' + _str2);
        }
        if (_str1 == _str2)
        {
            info(_str1 + ' равно ' + _str2);
        }
    }
    ;

    comp('1','-1');
    comp('2','-1');
    comp('10','-1');
    comp('10','-2');
    comp('20','-1');
    comp('20','-2');
    comp('20','-3');

}

Получаем "1 меньше -1", но "2 больше -1" и "10 больше -1". Значит, сортировка - не при чем. Что-то другое.

[S.Kuskov]

И всё-таки, видимо, всему виной collation
http://www.sql.ru/forum/actualthread...d=1&tid=414232
http://www.sql.ru/forum/actualthread.aspx?tid=290618

[Владимир Максимов]

Если исходить из предположения, что это связано с collate, то порядок, приведенный в начале темы соответствует collate с названием Cyrillic_General_CI_AS.

У нас на сервере настроена collate SQL_Latin1_General_CP1251_CI_AS, что дает "правильный" порядок сортировки на самом сервере

Значит, Axapta использует сортировку Windows (опять же, если предположение соответствует действительности). Может, кто в курсе как это проверить? И есть ли соответствующие настройки Axapta?

[someOne]

При чем тут collate и вообще сервер базы данных если речь идет о map ?

Наверное, намерено никто ничего "не портил", просто как то повлиял переход платформы на поддержку unicode.

Кстати что то подобное касается и временных таблиц : сортировка в них (для Ax2009) отличается от той, что была в Ax 3.0. Видимо, причина та же что и с map.

[Pustik]

Цитата:

Сообщение от someOne

Наверное, намерено никто ничего "не портил", просто как то повлиял переход платформы на поддержку unicode.

Мы тоже об этом сначала подумали.

Цитата:

Сообщение от Владимир Максимов

static void Job_Test(Args _args)
{
    void comp(str _str1, str _str2)
    {
        if (_str1 > _str2)
        {
            info(_str1 + ' больше ' + _str2);
        }
        if (_str1 < _str2)
        {
            info(_str1 + ' меньше ' + _str2);
        }
        if (_str1 == _str2)
        {
            info(_str1 + ' равно ' + _str2);
        }
    }
    ;

    comp('1','-1');
    comp('2','-1');
    comp('10','-1');
    comp('10','-2');
    comp('20','-1');
    comp('20','-2');
    comp('20','-3');

}

Получаем "1 меньше -1", но "2 больше -1" и "10 больше -1". Значит, сортировка - не при чем. Что-то другое.

Если логически порассуждать, то тире он все-таки учитывает, иначе не было бы "1 меньше -1", но "2 больше -1" логику рассуждений заводит в тупик!!!!!!
Может быть есть смысл в логику его сортировки добавить количество символов в строке?

[Владимир Максимов]

Цитата:

Сообщение от someOne

При чем тут collate и вообще сервер базы данных если речь идет о map ?

В данном случае Map - это частный случай сравнения (упорядочивания) символьных строк. Проблема касается ЛЮБЫХ вариантов сравнения символьных данных в Ax2009. Любым способом и в любом месте.

Посмотрите мой пример. Там нет никаких объектов. Банальное "в лоб" сравнение символьных строк вида (str1 > str2). Тем не менее, наблюдается та же проблема.

При этом тот порядок сортировки (правила сравнения на больше/меньше), который в результате получается, идеально совпадает с тем порядком сортировки, который получается при collate с именем Cyrillic_General_CI_AS

[Pustik]

Цитата:

Сообщение от Владимир Максимов

В данном случае Map - это частный случай сравнения (упорядочивания) символьных строк. Проблема касается ЛЮБЫХ вариантов сравнения символьных данных в Ax2009. Любым способом и в любом месте.

Понял это после Вашего примера.
(спасибо за пример)
Как победить?А если многие алгоритмы зависят от правильной сортировки?Менять тире на какой-нибудь хитрый символ(типа ###)?
Эх, считаю , что это баг!

[AndyD]

В трешке при сравнении строк используется String sort, а в 2009-й (и в четверке, по-видимому) Word sort

В сортировке символов все нецифро-буквенные символы имеют меньшее значение, чем любая цифра или буква и оказываются всегда впереди

В сортировке слов апостроф и дефис сортируются так, что-бы одинаковые слова, разделенные ими, стояли рядом. Т.е. при сравнении рассмотривается не только сам этот символ, но и следующие за ним
По-этому, '12' > '1-1', а '10' < '1-1'.
Что касается сравнения '11' и '1-1', то тут уже, по-моему, имеет значение так же длина строки. Т.е. '11' < '1-1'. Эксперименты с различными кодировками (включая китайские, арабские и японские) не влияли на результаты сравнения
А вот сравнение '11-' и '1-1' выявило разные результаты (причем и для трешки и для 2009-й) на WinXP ('11-' > '1-1') и на Win7/2008R2 ('11-' < '1-1') для одной и той же кодировки. Тут либо разная реализация функций сравнения в разных версиях винды, либо разные настройки локалей

[Logger]

Цитата:

Сообщение от AndyD

В трешке при сравнении строк используется String sort, а в 2009-й (и в четверке, по-видимому) Word sort

В сортировке символов все нецифро-буквенные символы имеют меньшее значение, чем любая цифра или буква и оказываются всегда впереди

В сортировке слов апостроф и дефис сортируются так, что-бы одинаковые слова, разделенные ими, стояли рядом. Т.е. при сравнении рассмотривается не только сам этот символ, но и следующие за ним
По-этому, '12' > '1-1', а '10' < '1-1'.

Вот еще интересная ссылка про сравнение:
http://stackoverflow.com/questions/3...or-string-sort