In practice, regex APIs are not set up to match parts of characters or handle discontiguous selections.
Там же наоборот говорится, что регексы не умеют обрабатывать разные представления. Тем, кому это нужно там дана рекомендация "нормализуйте строку перед матчингом".
Applying the matching algorithm on a code point by code point basis, as usual.
И дальше подтверждается тезис, что регексы матчатся по кодпоинтам.
Я спорю с тем, что у редакторов могут возникнуть хоть какие-то сложности со вставкой в середину.
Или, если хотите, могу по-другому сформулировать: время поиска "предыдущего режима в середине строки" есть O-большое от времени собственно самой вставки в середину строки (например для случая utf-8).
Чисто потому, что, грубо говоря, редакторы никогда не занимаются вставкой "в середину строки". Там задачу переформатируют таким образом, чтобы этого никогда не нужно было делать.
Есть структуры данных, которые умеют быстро находить последний код переключения страницы в производьном диапазоне. И эти структуры данных в любом случае уже используются в редакторах.
Edit: не везде используются стропы, разумеется. Там где не используются эти операции поиска могут быть не всегда быстрыми — однако в таких случаях операция "вставки в середину" тоже оказывается очень медленной. Просто потому что редакторам и так приходится отвечать на всякие запросы типа "найди последний перевод каретки до этой позиции курсора".
В качестве патологического примера, откройте в виме файл со строкой длинной в несколько МБ, включите wrap, и где-нибудь в середине этой строки введите несколько символов. На тех версиях, на которых я такие файлы редактировал у меня уходило по 3-30 секунд на нажатие.
И нет, "её последний режим кодирования" не будет работать, потому что в текстовом редакторе можно делать вставку в середину строки. Дальше подумайте, что вы будете делать с исходной "ненаивной" строкой и как будете использовать позицию курсора.
В текстовых редакторах и так есть всякие структуры данных, которые позволяют считать всякие статистики на тексте (количество строк, количество софт-строк, номера колонок и прочее). Добавить к ним ещё одну статистику — не сложно (например номер текущей страницы). Поэтому конкретно в этом аспекте проблемы толком нет.
Вообще, Вы сейчас пытаетесь на скорую руку залатать концепцию. Так ничего хорошего не выйдет.
По хорошему, Вам нужно сначала сформулировать какими свойствами должны обладать Ваши операции. В идеале, хочется что-то типа аксиом поля. Но честного поля у Вас не получится, т.к. флоаты уже им не удовлетворяют. Но можно строить более слабые аналоги: например можно затребовать чтобыдля какого-то разумного выбора функциии для любыхиз какого-то достаточно большого множества. И так с остальными аксимомами.
Дальше нужно посмотреть а следует ли из заданных аксиом ожидаемое поведение. Посмотреть на практические задачи и как в них себя ведут эти аксиомы.
Если всё устраивает, то нужно доказать выполнение заданных аксиом для всех операций. И в целом, поведение операций нужно выбирать очень аккуратно, постоянно сверяясь с аксиомами.
И вот эти вот аксиомы/теоремы - это неотъемлимая часть документации. Именно их нужно выписывать в статье. Без них пользоваться библиотекой/подходом невозможно. Просто потому что никогда не знаешь, когда он начнёт врать =/
Такая кодировка не позволяет делать zerocopy парсинг. Плюс, она не позволяет брать подстроки (что часто используется в дедупликации).
Вообще кодировка скорее похожа на доменноспецифичный алгоритм сжатия, чем на собственно кодировку. Но в таком случае, кажется, можно сделать сильно эффективнее(быстрее, компактнее), если подходить к этому именно как к сжатия (и можно жать не байты, а напрямую кодпоинты).
P.S. кажется Вы это подразумевали, но было бы хорошо добавить в статью чёткое указание, что это кодировка для передачи, а не для использования в оперативной памяти.
Не совсем. Это чисто вычислительный трюк, чтобы работать с бесконечномалыми на компьютере.
Например, через обычные дуальние числа можно автомагически считать точные производные функций.
Гипердуальные числа есть просто обобщение на другие степени. Например, можете рассматривать числа вида:
Где d — означает бесконечномалую, а A — плюс бесконечность. Дальше осталось ввести только таблицу умножения, например:
Тогда в определённых пределах такие числа будут давать корректные результаты. А если заменитьна NaN/исключение, то она даже будет предсказуемой.
Подразумевается, разумеется, что данные числа определены с точностью до. Можно также хранить признак, является ли число "точным", или же там есть o-малое. Тогда можно будет отличать ситуации деления на 0.
Tl;Dr; Если не замахиваться на универсальность, можно достичь хороших результатов с гораздо более простым представлением чисел (и для него будет проще определить границы применимости)
Это Ваше высказывание было, что движки регексов учитывают нормализацию. Я с этим высказыванием как раз не согласен
А кто это спеку реализует, какие движки регексов?
Там же наоборот говорится, что регексы не умеют обрабатывать разные представления. Тем, кому это нужно там дана рекомендация "нормализуйте строку перед матчингом".
И дальше подтверждается тезис, что регексы матчатся по кодпоинтам.
А что Вы тогда подразумеваете под словом "символ"? Я подразумевал "абстрактный символ" из юникода.
И раз уж Вы так уверенно говорите, можете привести примеры регексов, которые умеют обрабатывать разные представления символов?
Я спорю с тем, что у редакторов могут возникнуть хоть какие-то сложности со вставкой в середину.
Или, если хотите, могу по-другому сформулировать: время поиска "предыдущего режима в середине строки" есть O-большое от времени собственно самой вставки в середину строки (например для случая utf-8).
Чисто потому, что, грубо говоря, редакторы никогда не занимаются вставкой "в середину строки". Там задачу переформатируют таким образом, чтобы этого никогда не нужно было делать.
Потому что при работе с ней в памяти возникает много сложностей. Да и вроде автор в комментариях не говорит о внедрении как стандарт.
Так он и не должен учитывать, т.к. разные представления одного и того же символа — это разные наборы кодпоинтов.
Есть структуры данных, которые умеют быстро находить последний код переключения страницы в производьном диапазоне. И эти структуры данных в любом случае уже используются в редакторах.
Для примера, строп.
Edit: не везде используются стропы, разумеется. Там где не используются эти операции поиска могут быть не всегда быстрыми — однако в таких случаях операция "вставки в середину" тоже оказывается очень медленной. Просто потому что редакторам и так приходится отвечать на всякие запросы типа "найди последний перевод каретки до этой позиции курсора".
В качестве патологического примера, откройте в виме файл со строкой длинной в несколько МБ, включите wrap, и где-нибудь в середине этой строки введите несколько символов. На тех версиях, на которых я такие файлы редактировал у меня уходило по 3-30 секунд на нажатие.
Матчинг по кодпоинтам тоже не учитывает.
Матчинг по байтам может быть кратно быстрее. Особенно для статичных фрагментов/поиска подстроки.
В текстовых редакторах и так есть всякие структуры данных, которые позволяют считать всякие статистики на тексте (количество строк, количество софт-строк, номера колонок и прочее). Добавить к ним ещё одну статистику — не сложно (например номер текущей страницы). Поэтому конкретно в этом аспекте проблемы толком нет.
Ну, это как бы логично. Но создаётся впечатление, что онтоп кодировка не предназначена для использования в памяти. Поэтому и аргумент
Если тот же пример вычислить во флоатах, то получится NaN/ошибка. В этом и несоответствие
Тут опять же нарушается логика. Например,
Для достаточно больших
- например для
.
Вообще, Вы сейчас пытаетесь на скорую руку залатать концепцию. Так ничего хорошего не выйдет.
По хорошему, Вам нужно сначала сформулировать какими свойствами должны обладать Ваши операции. В идеале, хочется что-то типа аксиом поля. Но честного поля у Вас не получится, т.к. флоаты уже им не удовлетворяют. Но можно строить более слабые аналоги: например можно затребовать чтобы
для какого-то разумного выбора функции
и для любых
из какого-то достаточно большого множества. И так с остальными аксимомами.
Дальше нужно посмотреть а следует ли из заданных аксиом ожидаемое поведение. Посмотреть на практические задачи и как в них себя ведут эти аксиомы.
Если всё устраивает, то нужно доказать выполнение заданных аксиом для всех операций. И в целом, поведение операций нужно выбирать очень аккуратно, постоянно сверяясь с аксиомами.
И вот эти вот аксиомы/теоремы - это неотъемлимая часть документации. Именно их нужно выписывать в статье. Без них пользоваться библиотекой/подходом невозможно. Просто потому что никогда не знаешь, когда он начнёт врать =/
Кстати об этом. Чему равно
? Это уже из области реализации, но вопрос в том, как Ваши числа взаимодействуют с флоатами
Да вроде всё тот же пример:
. У Вас в статье всё ещё не отражено наличие нуля.
Каким образом может быть zerocopy парсинг, если нам в памяти нужен utf-8/utf-16? Или Вы о чём конкретно говорите?
Такая кодировка не позволяет делать zerocopy парсинг. Плюс, она не позволяет брать подстроки (что часто используется в дедупликации).
Вообще кодировка скорее похожа на доменноспецифичный алгоритм сжатия, чем на собственно кодировку. Но в таком случае, кажется, можно сделать сильно эффективнее(быстрее, компактнее), если подходить к этому именно как к сжатия (и можно жать не байты, а напрямую кодпоинты).
P.S. кажется Вы это подразумевали, но было бы хорошо добавить в статью чёткое указание, что это кодировка для передачи, а не для использования в оперативной памяти.
Не очень, т.к. очень много зависимостей по данным (из-за переключения режимов)
Не совсем. Это чисто вычислительный трюк, чтобы работать с бесконечномалыми на компьютере.
Например, через обычные дуальние числа можно автомагически считать точные производные функций.
Гипердуальные числа есть просто обобщение на другие степени. Например, можете рассматривать числа вида:
Где d — означает бесконечномалую, а A — плюс бесконечность. Дальше осталось ввести только таблицу умножения, например:
Тогда в определённых пределах такие числа будут давать корректные результаты. А если заменить
на NaN/исключение, то она даже будет предсказуемой.
Подразумевается, разумеется, что данные числа определены с точностью до
. Можно также хранить признак, является ли число "точным", или же там есть o-малое. Тогда можно будет отличать ситуации деления на 0.
Tl;Dr; Если не замахиваться на универсальность, можно достичь хороших результатов с гораздо более простым представлением чисел (и для него будет проще определить границы применимости)