Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Изменение алгоритма выделения sumti-мест в определениях #20

Open
nanouasyn opened this issue Aug 17, 2021 · 3 comments

Comments

@nanouasyn
Copy link

На данный момент, sutysisku выделяет в определении слова sumti-места разноцветными прямоугольниками, проводит стрелки между местами lujvo и местами его компонентов. Однако, алгоритм нахождения мест в определении оказывается очень чувствительным к ошибкам второго рода, потому что не требует следования формату, и распознаёт любую latex-формулу как указание на sumti-место. Так, например, формула {$m^3$} для него неотличима от выражения {$m_2$} в статье {caldectre}. Алгоритм видит sumti-место там, где его нет, и даже проводит к нему стрелку от mitre3. Я насчитал по крайней мере 178 слов в английском словаре, в которых либо алгоритм ошибается, видя наличие места там, где его нет, либо в словарной статье допущена критическая ошибка форматирования. К последним относится, например, {fadytu'i}. В общем случае, политика допущения отклонений от формата не приводит ни к чему хорошему: на месте выделенного sumti-места находится либо нечто совсем отличное от sumti-места, то есть, формула, которую автор определения и не планировал делать sumti-местом, либо ошибка автора, нечто, критически выбивающееся из формата, что само по себе, в подавляющем большинстве случаев, заставляет алгоритм ошибиться или по поводу границ sumti-места, или по поводу количества sumti-мест, или по поводу связей между sumti-местами разных слов. Другими словами, излишняя толерантность здесь практически не приносит пользы, не сокращает количество ошибок первого рода, а лишь плодит ошибки второго рода, маскирует ошибки форматирования и запутывает пользователей.

Решением в данной ситуации мне видится следующее. Алгоритм должен требовать от содержимого $...$-скобок следования формату, отказываясь воспринимать его sumti-местом в ином случае. Формат должен соответствовать требованиям, описанным в jbovlaste. Содержимое sumti-места должно представлять собой разделённый знаком {=}, возможно, окружённым пробельными символами, список меток. Каждая метка должна состоять из имени и индекса, причём имя должно представлять собой последовательность из не менее, чем одной ложбанской буквы в нижнем регистре ([a-z]+), индекс должен представлять собой последовательность из не менее, чем одной цифры, возможно, в фигурных скобках (\d+|{\d+}), при этом, имя и индекс могут быть разделены символом {_}.

На самом деле, указанное правило всё-ещё слишком мягко и допускает, например, {x12}, что допускается и форматом jbovlaste, используясь в 310 словах. Впрочем, это приводит к некой неряшливости на выходе, а иногда даже наблюдается смешение стилей в рамках одного определения (bi'argau). Также, можно предположить существование естественных ошибок вида {x_12}. Всё это можно легко и однозначно исправить силами sutysisku. Поэтому, предлагаю производить преобразование определения: каждую метку в найденном по предложенному выше алгоритму sumti-месте, необходимо преобразовать, добавив разделитель «_» между именем и индексом, если он отсутствует, а также поместив индекс в фигурные скобки, если они отсутствуют, и далее работать уже с таким определением.

@lagleki
Copy link
Contributor

lagleki commented Jan 29, 2022

Может быть, вы напишете регулярку, описывающую места, которые алгоритм должен делать кандидатами для концов/начала стрелок?

@lagleki
Copy link
Contributor

lagleki commented Jan 29, 2022

Посмотрел fadytu'i. Сейчас не вижу серьезных проблем.

@lagleki
Copy link
Contributor

lagleki commented Jan 29, 2022

bi'argau - это однозначно косяк автора определения. Уже поправлен. Аналогично надо поправить определения в других местах. это уже проблемы самого jbovlaste.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants