Regex & AdvancedFilter criteria

[eeigor]

Описал как-то такой баг, который был оставлен без внимания.
Суть дела в том, что если надо отфильтровать строку по числовому фрагменту, то этот фрагмент-подстрока преобразовывается к числу, и фильтр работает неверно.
Напр., надо отобрать записи с кодом "Д01", но не "Д10", "Д11" или "Д21" по критерию "01" (содержит - именно так работает расширенный фильтр по умолчанию).
REGEX вернет то, что просим: "Д01" только, а расширенный фильтр преобразует "01" к числу 1 и вернёт: "Д01", "Д10","Д11" и "Д21" (содержит ведь). В этом и была суть бага.

Противоречивый подход налицо, конечно... Однако, откуда "ноги растут"? Есть новая информация.

Warning:
When using functions where one or more arguments are search criteria strings that represents a regular expression, the first attempt is to convert the string criteria to numbers. For example, ".0" will convert to 0.0 and so on. If successful, the match will not be a regular expression match but a numeric match. However, when switching to a locale where the decimal separator is not the dot makes the regular expression conversion work. To force the evaluation of the regular expression instead of a numeric expression, use some expression that can not be misread as numeric, such as ".[0]" or ".\0" or "(?i).0".

Теперь так и делаю...

И похоже, что AdvancedFilter работает как в цитате выше, но относительно недавно появившаяся функция REGEX в такой "преобразовательной" деятельности не замечена. Где правда?

Upd
Всё сказанное выше верно при использовании расширенного фильтра в макросе, в отличие от использования того же фильтра посредством команд меню.

[mikekaganski]

REGEX не имеет отношения к понятию Criterion, о котором написано в справке.

И даже не только Criterion, но и Scalar, используемому в MATCH.

[eeigor]

Пытаюсь понять, откуда "ноги растут", ведь работает AdvancedFilter с рег. выражением также, как та же функция MATCH, что следует из описания выше.

Правильно это или нет, неясно. Решение выше тоже есть. Нет единообразия. Однако такая разница в работе с функцией REGEX мне непонятна. Что-то здесь не так...

Но в диапазон условий расширенного фильтра я ввожу именно критерий, как описал в стартовом сообщении.
Баг по ссылке содержит готовый пример, кому интересно.

[mikekaganski]

Всё тут правильно.

Функция REGEX принимает строку, которая семантически является именно регулярным выражением. Функция MATCH принимает скаляр - любое одиночное значение, которое может быть интерпретировано по-разному, в том числе и как регулярка - в порядке очереди (то есть сначала проверим, не число ли это; если да - проверим набор данных на совпадение с числом; иначе перейдём к варианту "не регулярка ли это"; а если регулярки не разрешены, то наконец попробуем простое текстовое сравнение...)

[eeigor]

Михаил, тогда вопрос: расширенный фильтр работает правильно или нет?

Upd
Для фильтра я устанавливаю флаг: использовать рег. выражения. Но строка критерия подвергается преобразованию. В ячейках условий – тип данных текстовый, потому что в поле эти данные.

[eeigor]

Правильно ли, разумеется, в рамках примера данных.

[mikekaganski]

Да, правильно. Нужно только документацию поправить.

[eeigor]

Ну, тогда то выше замечание для MATCH распространяется и на ряд других функций (?), а также на стандартный и расширенный фильтры, полагаю.

Upd
Как я писал, поле данных текстовое, значение в диапазоне условий для этого поля – строка с ведущим нулём. При этом строка будет преобразована в число и ноль обрезан, если не заключить его в квадратные скобки или не предварить \0

Upd2
Раньше я полагал, что если в ячейке диапазона условий я задал тип данных текстовый (иначе 0 при вводе 01 удаляется), то этого достаточно, чтобы «застолбить» критерий: что вижу, то и верно...

[mikekaganski]

Ну, тогда то выше замечание для MATCH распространяется и на ряд других функций (?)

Непонятно, что за замечание (и чьё) распространяется на что, и что из этого следует.

[eeigor]

AdvancedFilter работает также

«Предупреждение:
При использовании функций, в которых один или несколько аргументов являются строками критериев поиска, представляющими регулярное выражение, первой попыткой является преобразование строковых критериев в числа. Например, ".0" преобразуется в 0.0 и так далее. В случае успеха совпадение будет не совпадением с регулярным выражением, а числовым совпадением. Однако при переключении на язык, где десятичный разделитель не является точкой, преобразование регулярных выражений работает. Чтобы принудительно вычислить регулярное выражение вместо числового выражения, используйте какое-либо выражение, которое нельзя неправильно интерпретировать как числовое, например ".[0]" или ".\0" или "(?i).0"».

Upd
А решение проблемы – в последнем предложении.
Только одно дело – последовательно преобразовывать значение строки аргумента функции, а другое, кмк, значение в ячейке диапазона условий, тип данных которой пользователь задал явно – ТЕКСТ.
Но эта установка не принимается в расчёт.

[mikekaganski]

Блин. Вы просто считаете ненужным писать "нужно добавить в справку ...", как написано в tdf#143438?

[eeigor]

Спасибо, Михаил. Вы высказали позицию и показали, что ноги "растут оттуда". Однако я в ходе своих рассуждений допускал и другой подход, поэтому не был уверен, где правда. Как работать "с этим", мы уже знаем.

[eeigor]

Я должен оговориться и уточнить суть дела.
Так, как описано выше (преобразовывает "01" в 1) AdvancedFilter работает в макросе (и именно так я использую этот фильтр), но через команды меню работает правильно иначе, то есть оставляет как есть.

Подробный анализ в примере, кому интересно.