Стандартизация qtype_correctwriting_string_pair

[GoogleCodeExporter]

У нас сейчас этот класс представляет собой 
свалку информации, при которой однородная 
информация от разных анализаторов 
хранится в разных формах, а хранимая 
информация многократно дублируется 
(например перечни индексов перемещнных, 
добавленных и т.д. лексем вычисляются из lcs, 
и sequence mistakes тоже).

Это надо устаканить, для чего составить 
описание что есть и проект, а потом уже 
делать.

Принципы:
1) информация должна дублироваться только 
там, где она многократно используется;
2) однотипная информация должна хранится в 
стандартном виде
3) дублированная информация должна 
вычисляться по мере надобности, чем позже 
тем лучше, т.к. более поздние анализаторы 
могут корректировать данные более ранних;
4) информация должна хранится по 
возможности в наиболее удобной для 
использования форме.

Original issue reported on code.google.com by oasyc...@gmail.com on 25 Nov 2014 at 1:06

[GoogleCodeExporter]

К началу обзора: block_formal_langs_string_pair
matches - хранит набор объектов matched_pair и 
агрегирующую информацию. matched_pair является 
одним соответствием и хранит тип 
соответствия, массивы индексов 
участвующих лексемы из обеих строк и 
дополнительные данные типа веса ошибки и 
сообщения о ней.

Я так понимаю mappings играют ту же роль, но 
хранят данные по другому - в виде двух 
массивов, элементы с одинаковыми индексами 
которых соответствуют друг другу.

Мне кажется, что в данном случае 
использование потомков matched_pair 
перспективнее, т.к. они хранят данные о 
соответствии в одном объекте и содержат 
массу полезной дополнительной информации.

Однако возможно актуальна также доработка 
полей и методов в matches_group с целью более 
производительного получения списка всех 
соответствий одного типа или от одного 
анализатора.

Дмитрий, ваше мнение? Остальные тоже могут 
высказываться...

Original comment by oasyc...@gmail.com on 25 Nov 2014 at 1:13

[GoogleCodeExporter]

Original comment by oasyc...@gmail.com on 25 Nov 2014 at 1:13

[GoogleCodeExporter]

Здесь большую роль будет играть мнение 
Матюшечкина - ему как раз под него 
подстраиваться. Пускай он за неделю 
выяснить степень удобства. Я - тем временем 
решу те старые проблемы, что у нас есть пока.

Original comment by mamontov...@gmail.com on 25 Nov 2014 at 2:46

[GoogleCodeExporter]

Не лучшее решение, это уж нам с вами 
обсуждать надо как общую архитектуру и с 
учетом квалификации.
Как у нас сейчас хранятся mistakes?

Original comment by oasyc...@gmail.com on 25 Nov 2014 at 10:29

[GoogleCodeExporter]

Как мы уже смотрели в понедельник - в 
массиве объектов.

Original comment by mamontov...@gmail.com on 26 Nov 2014 at 5:16

[GoogleCodeExporter]

Ясно что в массиве, вопрос как ведется 
индексация этого массива.

Original comment by oasyc...@gmail.com on 26 Nov 2014 at 10:41

[GoogleCodeExporter]

Просто обычный линейный массив объектов.

Original comment by mamontov...@gmail.com on 27 Nov 2014 at 4:52

[GoogleCodeExporter]

Original comment by oasyc...@gmail.com on 3 Jul 2015 at 8:15

• Changed state: Done