ну яПо стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111".
Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться?
Если типизации нет, и все хранится как строки, то как он отличает строку "111" от строкового представления числа 111? Или никак не отличает, а просто сортирует строки "неправильно"?

Т.е. если есть набор строк:
то в каком порядке все эти строки в кешовом "индексе" расположатся? В таком:
?

2 ну я
Пьяный Лох ну яПо стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111".
Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться?
Если сортировка должна быть как строк, то нужно выставлять глобали ascii collation если его поддерживает имплементация либо насильно приводить строку к виду, не представляющему число, например приписать спереди пробел. Обычно для переносимости пользуются вторым вариантом.
Оп-ля... Это как это - "приписать пробел"? У меня строка безо всякого пробела в начале, однако. С какой радости я её модифицировать должен?

-----------

2 Sergei Obrastsov
при числовой сортировке именно так. есть правда маленькая деталь,
а нафига совать в индекс разные логические типы данных?
там где нужны числа у меня будут числа, а там где строки - строки
Нафига? Не знаю... А нафига отсутствие типизации сделали? Значит это кому-нибудь нужно? Если это кому-нибудь нужно - наверное и работать с этим кому-нибудь приходится?

Были бы типы данных - не было бы таких вопросов. Поле числового типа сортировалось бы как набор чисел, и строку туда нельзя было бы записать, а в поле строкового типа можно было бы записать любую строку (хоть бы даже и содержащую "каноническое представление числа"), и сортировалось бы это как набор строк.

А так получается, что я могу записать в одно и то же поле и "строки", и "числа" (и это действительно иногда нужно). И если "строковое" подмножество содержит что-то, по несчастливой случайности совпадающее по внешнему виду с "каноническим представлением числа" - то отсортировать корректно полученное множество уже никак не получится, патамушта либо часть "строк" уедет в область "чисел" (при "числовой" сортировке), либо "числа" будут сортироваться как "строки" (при выставленном ascii collation'е для глобали).

2 ну я
Перед записью берешь и пишешь используя не твое значение а конкатенацию его с пробелом спереди. При получении значения из индекса первый символ отбрасываешь.
Т.е. все строки - с пробелом в начале? И тогда уж не "первый символ отбрасываешь", а "первый символ анализируешь, если пробел - отбрасываешь"?

Если бы в мампсе была типизация - то мы бы зашились с этими типами. Есть куча систем которые должны быть по своему устройству (как следствие их назначения) непрерывно изменяемы. В первую очередь бизнес-ориентированные. Если нам еще и типами заниматься - зашились бы точно.
Да ладно Вам. Я даже не буду спорить с тем, что иногда сильная типизация хуже, чем слабая (но только иногда, имхо). Речь не про то. Если уж система расчитана на слабую типизацию - кто мешает факт наличия этой самой слабой типизации унутре себя учесть? Хранили бы в месте со значением переменной еще один байт - "тип", не имели бы проблем с определением этого самого типа. Собственно предложенное решение ("при записи конкатенируешь с пробелом, при чтении пробел выкидываешь") и есть та самая информация о типе значения. Тока почему-то не на уровне системы, а ручками делать.

2 Sergei Obrastsov

интересно, как будет выглядеть массив, где все индексы рассортированы по разным принципам? :)
Кто мешает-то? В чем проблема отсортировать по разному? По-моему проблемы с сортировкой нет, более того, в вашем М именно по разному и сортируется - числа одним способом, строки другим, между собой еще как-то. Только у вас проблема с невозможностью определения типа для некоторых значений.

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

ну, так не бывает, чтобы нельзя было отсортировать. числа четко проверяются на принцип "str=+str", как справедливо заметил "ну я".
Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111. Так что не четко проверяются. Можно лишь четко определить случай, когда строка НЕ является строковым представлением числа.

ну яэто неверное правило.
Тогда какое верное?
Не всем строкам пробел спереди приписывать? А каким?

Если вам придется работать с мампсом
не дай бог :)

ну я Пьяный ЛохЯ Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111.
А зачем это может понадобиться?

А что, такого не может быть:
???

в общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное.
не видите разницу между "111" и 111 - говорить наверное больше не о чем.

ну яНет, первых три случая не может быть. Четвертый должен быть. Если нужна конкатенация - то ее и нужно использовать. Обозначается подчеркиванием.
Ок. Это, видимо, вопрос синтаксиса.

Что вернется в результате такой операции:
?
Т.е. операция "+" перегружена (в зависимости от типов операндов), или четко и строго является арифметическим сложением двух чисел (и ничем другим являться не может)?
Я, пардон, синтаксиса мумпса не знаю, потому и спрашиваю. Можно в какой-нибудь онлайн хелп послать, не обижусь.