» GoldenDict

ramix

Цитата:

Я правильно понял, что в данной системе поиска, даже если мы ищем одно слово, то всё равно происходит обращение GD к самим словарям?

Да.

Цитата:

(Как я заметил, обращение к словарям идет в первой половине поиска, а во второй GD там что-то внутри себя перелопачивает, интенсивно нагружая уже не диск, а процессор.)

Пополнение списка найденных заголовков, сортировка - это тоже время при тысячах слов в списке. Если функция просмотра статьи не выделила заголовок, он ищется в основном индексе по адресу статьи, опять время. И т.д. Дальше будет видно, что там можно ещё оптимизировать, а что нет.

Цитата:

А что если подсветку организовать, так сказать, штатными средствами - щелчок по заголовку карточки в окне со списком найденных автоматически запустит штатный "поиск на странице (Ctrl+F)" с включением подсветки всех найденных результатов?

А он совсем не обязательно что-то найдёт. К примеру, полнотекстовый поиск "такая картина" с допустимым интервалом 2 слова найдёт сочетание в статье "такая замечательная картина". А штатный поиск по странице будет искать именно "такая картина" и обломается. Причём искомых словарей может быть для конкретного заголовка несколько, и в общем случае искомые словосочетания в них будут разные.

Abs62

Цитата:

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

Ну я то сделал то чего вы не решались сделать... И бог знает сколько бы нам пришлось ждать того доброго дядю о котором я не раз упоминал... Но дело вовсе не в том у кого код лучше. И собственно я знал на что иду. Мне смешно с вами соревноваться. Я программистом то себя называть стесняюсь.. Просто к тому - к чему надо стремиться. Если можно быстрее значит надо быстрее.
По поводу кода. Не раз уже говорил, если какая идея нравится я не прочь ее опубликовать и работать вместе и искать решения вместе. А не с той практикой как принята здесь и как мне ту заявили - идеи ничего не значат и вообще я попрошайка, работа моя отстой... Выкладывать весь код бессмысленно.


Цитата:

Высылайте, посмотрим. А насчёт особой сложности - не обратили внимания, что в вашем варианте штатный поиск по странице умирает в мучительных судорогах?

Ну в общем то опять смешно. Мне на штатный поиск почти что наплевать (как и в большинстве своем пользователям) и на нем я не зацикливался (залатать его можно). Внештатный заменяет его полностью. Кроме того я и не говорил, что у меня идеально все (еще повод не выкладывать все разом). Мне бы ваши 10 лет опыта я бы не сутками (может и месяцами) дела то, что можно сделать в течении вечера.

Код выслал (в личку, может разберетесь в каракулях), может поймете почему бессмысленно его выкладывать.

Цитата:

Но тега [/m2] в DSL нет, только [/m]

Может, просто опечатка, может, ещё что. Смотреть надо.

Цитата:

Если бы парсер был так любезен сообщить, про какую статью и словарь идет речь...

Сейчас он просто принимает строку на вход и понятия не имеет, откуда она взялась. Надо посмотреть, что там можно сделать, чтобы конкретизировать диагностику.

С точки зрения программирования код не блещет идеалом (речь о высланном), но с другой стороны это то и радует (есть перспектива).
И с точки зрения пользователя - навигация и подсветка почти идеальны. Аналогов нет.
И хотелось бы, что бы в официальной сборке было бы не хуже.

Добавлено:
Далее из того, что бы хотелось видеть в официальной сборке (ну раз уж дальше не имеет смысла развивать свой вариант, будем попрошайничать) - вариант перебора. На сколько понял его сейчас нет. Может я и ошибаюсь, поскольку нет возможности скопировать результат и проверить своей подсветкой. Просто этот простой вариант наиболее востребован и дает наиболее полную информацию.
Из того, что не успел реализовать: В перебор подставлять словоформы. Т.е необходимо, что то вроде простейшего Лематизатора.

Для информации:
При попытке поиска очень распространенного слова (в моих условиях это было слово dictionary с итоговым кол-вом совпадений более 55 тыс.) без установки ограничения по max arts per dic, время поиска резко увеличивается (непропорционально нелинейно). Грубо говоря, если 22 тыс. совпадений находятся за 3 мин., то 55 тыс. - более чем за 30 мин.

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

Надо полагать, данные артефакты связаны с RAM.
* * *
Может, это случайность, но на время FTS-поиска у меня блокируются (именно блокируются, а не откладываются из-за занятости системы) операции копирования по шорткату Ctrl+C, а по контекстному меню работают. По окончании поиска всё восстанавливается.

Добавлено:
Есть такая возможность в списке найденного ставить слова с кавычками рядом с этими же словами без кавычек - чтобы не искать нужное слово в двух разных местах?

Поясню на примере. Ищем в словаре автомашину под названием Cobra. Но мы не знаем, как автор словаря написал название этой машины в заголовке - то ли Cobra, то ли "Cobra". Из-за этого приходится смотреть в двух разных местах - в начале списка, где идут закавыченные слова, и по алфавиту на букве C.

А так, применив наше френдли-юзабилити, мы поставим оба заголовка рядом и сэкономим пару драгоценных секунд на поиске.

ramix

Цитата:

При попытке поиска очень распространенного слова (в моих условиях это было слово dictionary с итоговым кол-вом совпадений более 55 тыс.) без установки ограничения по max arts per dic, время поиска резко увеличивается (непропорционально нелинейно). Грубо говоря, если 22 тыс. совпадений находятся за 3 мин., то 55 тыс. - более чем за 30 мин.

Да, проблема больших списков. Найденные заголовки хранятся в формате "заголовок + список ссылок на словарь", поэтому по приходу новой пачки результатов сначала проводится просмотр уже имеющегося списка на предмет присутствия уже таких заголовков. Для уже имеющихся просто добавляется словарь в список ссылок, остальные добавляются к списку заголовков. После этого список сортируется.
Если размер списка N элементов, время на бинарный поиск растёт как log2(N), время на сортировку как N*log2(N). Нелинейно, ясен пень, при всех стараниях.
Не знаю, стоит ли ломать голову над дальнейшей оптимизацией, если в десятках тысяч итоговых результатов всё равно разобраться на мой взгляд нереально.

Цитата:

Может, это случайность, но на время FTS-поиска у меня блокируются (именно блокируются, а не откладываются из-за занятости системы) операции копирования по шорткату Ctrl+C, а по контекстному меню работают. По окончании поиска всё восстанавливается.

Хм. У меня не блокируются. Да и нечему там вроде блокировать.

BKSRU
Меряться с вами сами знаете чем я и не думал, стар я уже для подобных вещей. Если видите где неэффективность, ткните пальцем, будем посмотреть. Я далёк от мысли, что мой код идеален. И не думайте, что всё это сделано за один вечер - ошибётесь даже не на порядок.
Идеи всегда важны, только не всегда они приемлемы с моей точки зрения. С чем-то я соглашаюсь, с чем-то нет.
На штатный поиск мне не наплевать. Не скажу, что используется он часто, но бывает. И полнотекстовый поиск ему не замена. Так что не стоит ломать имеющиеся фичи, если можно и без этого обойтись.
За код спасибо, посмотрю.

Цитата:

Далее из того, что бы хотелось видеть в официальной сборке (ну раз уж дальше не имеет смысла развивать свой вариант, будем попрошайничать) - вариант перебора.

Это как?

Идеи-размышления на светлое будущее (если оно будет светлым :

1) Может, стоит сделать поиск по ссылкам и пометам опциональным?
С одной стороны, бывает полезным найти слова на данную тему, например, "полит." - тему политики.
С другой стороны, пометы и (реже) ссылки могут сильно засорять поиск.
А так, если надо, поставил птичку и веди расширенный поиск...

2) Неплохо было бы реализовать экспорт списка найденных заголовков - ищущему может понадобиться вернуться к списку и просмотреть его, проанализировать, подумать...


Добавлено:
Abs62

Цитата:

Не знаю, стоит ли ломать голову над дальнейшей оптимизацией, если в десятках тысяч итоговых результатов всё равно разобраться на мой взгляд нереально.

Думаю, не стоит. Кто будет искать иголку в стоге сена? Лучше где-то что-то оптимизировать в рефайнинге.

Abs62

Цитата:

Это как?

Ищем Have Any. Находит не только:
have sold scarcely any
но и:
any reason to have

Может поиск у вас именно так и работает, но проверить несколько затруднительно. Нет ни подсветки ни копирования результатов.
В моей сборке Enumeration работает именно так.

Но в идеале должен находить и:
had any
having any



Добавлено:
Abs62

Цитата:

Не знаю, стоит ли ломать голову над дальнейшей оптимизацией, если в десятках тысяч итоговых результатов всё равно разобраться на мой взгляд нереально.

Т.е. в очередной раз предпочитаем недодел. Это при том, что ограничение в 4 символа великовато.

ramix

Цитата:

Есть такая возможность в списке найденного ставить слова с кавычками рядом с этими же словами без кавычек - чтобы не искать нужное слово в двух разных местах?

Сделал. И дополнил диагностику непарных тегов в DSL. Теперь парсер должен сообщать в логе имя словаря и заголовок статьи.
goldendict-1.5.0-RC-302-g362acce(EXE only).7z - 1.18 MB

BKSRU

Цитата:

Может поиск у вас именно так и работает, но проверить несколько затруднительно. Нет ни подсветки ни копирования результатов.
В моей сборке Enumeration работает именно так.

Нет, такого режима нет и пока что не планируется. Не уверен я в его востребованности.
Хотите - добавьте сами в свой в свой вариант. Вся обвязка уже есть, так что остаётся всего-навсего:
- добавить значение в enum SearchMode в fulltextsearch.hh;
- добавить его занесение в комбобокс ui.searchMode в конструкторе FullTextSearchDialog;
- доработать напильником parseSearchString() в ftshelpers.cc (разбор строки поиска);
- сунуть свой код поиска в checkArticles() там же.
И будет оно работать, причём для всех типов словарей.

Цитата:

Т.е. в очередной раз предпочитаем недодел.

Есть предложения, как это улучшить? Давайте.
А я лучше пока подумаю, как подсветку впендюрить, чтобы оно работало и при этом ничего не поломалось.

Цитата:

Это при том, что ограничение в 4 символа великовато.

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

Abs62

Цитата:

Нет, такого режима нет и пока что не планируется. Не уверен я в его востребованности.
Хотите - добавьте сами в свой в свой вариант. Вся обвязка уже есть, так что остаётся всего-навсего:
- добавить значение в enum SearchMode в fulltextsearch.hh;
- добавить его занесение в комбобокс ui.searchMode в конструкторе FullTextSearchDialog;
- доработать напильником parseSearchString() в ftshelpers.cc (разбор строки поиска);
- сунуть свой код поиска в checkArticles() там же.
И будет оно работать, причём для всех типов словарей.

Т.е. посмотрели мой код и он вполне может быть совместим при желании?
На самом деле режим перебора самый востребованный и есть. Остальное баловство, хотя все они у меня присутствуют и подсвечиваются. Разве, что для энтузиастов изучающих язык годятся. Ну например найти примеры с ing-овым окончанием. Ну и я рассчитывал попытаться снабдить кое каким инструментом создателей словарей.


Цитата:

А я лучше пока подумаю, как подсветку впендюрить, чтобы оно работало и при этом ничего не поломалось.

Эта часть кода навела хоть на какие мысли?
На самом деле штатный поиск по карточке в таком виде не востребован. Слишком далеко он запрятан. Во внештатной работает лучше и подсвечивает как надо и все, что надо. Конечно же согласен, что конфликтов не должно быть. Но об этом не было сообщений (такова его необходимость) и я особо не обращал внимания.


Цитата:

Есть предложения, как это улучшить? Давайте.

В своем коде я исключил повторное сканирование в случае:
- добавления новых словарей
- если не меняется строка поиска или иные настройки. Имеется ввиду не просто сигал об изменении строки или настроек, а с возможностью проверки, что строка действительно изменилась. Ведь пользователь может передумать.
В этих случаях просто складывается результат.
Это повышает комфорт и в общем то скорость поиска (по ощущениям).

Ну а на счет реальной скорости. Ну для этого мне надо будет с вашим кодом разобраться (я со своим то путаюсь через пару недель, переключаясь на разные типы работы). Сами наверное поняли (по коду) кроме железной логики опыта у меня нет. Ну а потом попытаюсь понять почему у меня раз в 10-20 считает быстрее (с индексом). Но в общем то догадываюсь. Все это в угоду веса индекса. Опять компромисс.
Но так полагаю, что индекс годится и для других режимов.

Для размышления Advanced Learner's Dictionary, 8th Edition (En-En)
Поиск: Have any
Официальный вариант (с индексом) - 30 сек

Экспериментальный вариант (как раз режим перебора):
Сжатый словарь - 12 сек
Не сжатый - 6 сек
С индексом - меньше секунды.
Это просто к тому, что стоит или не стоит. Конечно стоит.
Обход Википедии несколько минут. Разве некуда стремится? Я не говорю, что это плохо. Вполне приличная скорость. Но разве некуда стремиться? И вы это сделаете лучше меня. Да и полагаю пока я буду пытаться разобраться, вы все равно сделаете как надо. В холостую нет желания работать.

Справедливости ради надо сказать, что например с мультилексом ситуация иная.

BKSRU

Цитата:

Т.е. посмотрели мой код и он вполне может быть совместим при желании?

Вставить рядом с другими такими же блок кода, который получает на вход строку и выдаёт решение да/нет - задача не самая сложная.

Цитата:

Эта часть кода навела хоть на какие мысли?

Навела.

Цитата:

Ну для этого мне надо будет с вашим кодом разобраться

getArticleText() в словарях (получение текста статьи из словаря) и checkArticles() (его анализ). Копайте в первую очередь здесь.

Цитата:

Ну а потом попытаюсь понять почему у меня раз в 10-20 считает быстрее (с индексом). Но в общем то догадываюсь. Все это в угоду веса индекса. Опять компромисс.

Отчасти индекс, если у вас оба слова проиндексированы, отчасти работа с текстом. У меня сейчас текст разбирается через тот же парсер, что и для перевода в html. Если перейти на простую вырезку тегов через регекспы, перевод DSL в текст можно ускорить, и чем больше тегов, тем сильнее это скажется. Просто парсер уже готов и вылизан, а с регекспами надо заново тестировать все неочевидные варианты. Задача на перспективу.

Цитата:

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

Индекс годится для всех режимов - по нему производится предварительная выборка статей, что может сильно сократить объём поиска непосредствено в тексте.

Ну на счет подсветки и навигации подождем изменений и покритикуем.

Но повторные перерасчеты надо исключить. Крайне полезно. Превентивным методом увеличиваем скорость.

Добавлено:

Цитата:

Навела.

Хоть в хорошем смысле или все так плохо?

BKSRU

Цитата:

Хоть в хорошем смысле или все так плохо?

Да нет, идея в целом рабочая, думаю. Только сделать всё надо аккуратно.

Abs62
По поводу индекса. Не особо представляю как он в идеале делается.
Как понял. Просто вытягиваем статью в строку убираем мусор, убираем дубли и заменяем бинарным кодом?

Добавлено:
Abs62

Цитата:

Да нет, идея в целом рабочая, думаю. Только сделать всё надо аккуратно.

Да вот так у меня весь код. GD для меня, что то вроде черновика. Ну и как я должен этот код публиковать, заведомо зная, что на публику он не годится и его надо дорабатывать?
Я ведь никогда не был против и часто напоминал, если что то нравится я готов обсудить и попытаться совместно откорректировать и внести в официальный код. Но во многих случаях от моего кода опять же останется только идея. В общем то дорогое удовольствие доказывать состоятельность той или иной идеи.

BKSRU
Если не вдаваться в технические подробности, задача индекса проста - сопоставить слову набор адресов статей, в которых оно встречается. Поэтому разделяем статью на слова, убираем дубликаты, и добавляем в общий список. Если слово в нём уже есть, просто добавляем к соответствующему ему вектору адресов адрес статьи. И так по всему словарю.
При поиске извлекаем из индекса вектора адресов для каждого слова, находим их область пересечения и получаем набор адресов статей, в которых имеются все слова из запроса. А дальше уж идёт обычный поиск заданного выражения в тексте каждой найденной статьи.

Цитата:

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

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

Abs62

Цитата:

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

В общем я так и делал (никто не жаловался). Просто в данном случае уследить было сложно, ведь подобный труд коллективный. А сообщений о такой проблеме не поступало. Ну да бог с ним. Свое отношение к такой поисковой строке я высказывал давно - отстой, которым никто в конечном итоге пользоваться не будет в виду бесполезности по нескольким причинам. И надо с ней все равно, что то делать.


Цитата:

Если не вдаваться в технические подробности, задача индекса проста - сопоставить слову набор адресов статей, в которых оно встречается. Поэтому разделяем статью на слова, убираем дубликаты, и добавляем в общий список. Если слово в нём уже есть, просто добавляем к соответствующему ему вектору адресов адрес статьи. И так по всему словарю.
При поиске извлекаем из индекса вектора адресов для каждого слова, находим их область пересечения и получаем набор адресов статей, в которых имеются все слова из запроса. А дальше уж идёт обычный поиск заданного выражения в тексте каждой найденной статьи.

Примерно так и думал. А оценивали на каком этапе тормоза больше. С тем же Оксвордом. Куда 30 сек уходят?
У себя экспериментировал иначе. Убирал мусор, статьи вытягивал в строчку, дубли не убирал. Файл ложил рядом со словарем. Все вместо 30 секунд меньше секунды. Да понимаю платим размером. Тот же Оксвород индекс - 30 Мб. Но я рассчитывал разобраться как это делается и подменить слова бинарным кодом и упаковать. Пусть не секунда, но 2 было бы то же не плохо. Вот так методом проб и ошибок...

BKSRU

Цитата:

Примерно так и думал. А оценивали на каком этапе тормоза больше. С тем же Оксвордом. Куда 30 сек уходят?

А задайте не повсеместно встречающиеся слова, а более редкое, "nautical", к примеру, и оцените скорость в таком варианте.
Там индекс небольшой, главное время - перевод статей в текст и поиск в них.

Цитата:

У себя экспериментировал иначе. Убирал мусор, статьи вытягивал в строчку, дубли не убирал. Файл ложил рядом со словарем.

Это не индекс. Это именно что переведённый в чистый текст сам словарь. Не вариант.

Abs62

Цитата:

Это не индекс. Это именно что переведённый в чистый текст сам словарь. Не вариант.

Кроме как предвзятости к такому подходу не услышал. Если вариант работает быстрее значит он лучше, если медленней значит хуже. И в любом случае это модель индекса. Убирал я дубли. К сожалению информативность резко теряется, приходится применять двойной обход и скорость резко падает.
Проблему только одну вижу - размер индекса. Но поэкспериментировать было бы интересно. Заменить слова на короткий бинарный код и запаковать. Скорость оставалась бы высокой. Еще лучше разбить на блоки и это могло бы резко увеличить скорость. Но вот на сколько бы удалось ужать индекс?


Добавлено:

Цитата:

А задайте не повсеместно встречающиеся слова, а более редкое, "nautical", к примеру, и оцените скорость в таком варианте.

Попробовал. В общем ясно. Однако, неужели ничего еще нельзя предпринять для исключения такой зависимости от частотности?

Цитата:

Там индекс небольшой, главное время - перевод статей в текст и поиск в них.

Из этой парочки получается, что львиная доля уходит на перевод статей в текст. Сам же поиск должен быть мгновенным и не должен зависеть ни от количества найденных слов, ни от состава запроса.

BKSRU

Цитата:

Кроме как предвзятости к такому подходу не услышал. Если вариант работает быстрее значит он лучше, если медленней значит хуже.

А вы попробуйте то же слово "nautical" на действительно большом словаре, вроде Urban dictionary, там и поймёте разницу между бинарным поиском в индексе и простым перебором подготовленного текста.

Цитата:

Заменить слова на короткий бинарный код

Вот с этим поподробнее, пожалуйста. Как вы себе это представляете?

Цитата:

и запаковать.

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

Цитата:

Попробовал. В общем ясно. Однако, неужели ничего еще нельзя предпринять для исключения такой зависимости от частотности?

Частотность в первую очередь определяет количество статей, которые надо перебрать (размер векторов адресов тоже сказывается, конечно, но в значительно меньшей степени, нежели работа с текстом).

Цитата:

Сам же поиск должен быть мгновенным и не должен зависеть ни от количества найденных слов, ни от состава запроса.

Предлагайте алгоритм такого мгновенного поиска.

Abs62

Цитата:

Вот с этим поподробнее, пожалуйста. Как вы себе это представляете?

Так я же говорил, что не представляю механизм создания индекса. Делал как сам представляю это. И в общем то оно так и делается. Методы разные.

Экспериментировал я так: Вытягивал статью в строку. Убирал все лишнее.
Далее проверяем результат: Создал цикл на предварительную проверку цепочки слов. Операция эта фактически мгновенна оказалась для того же Oxforda. В случае нашего варианта выходим из цикла и тут уже отлавливаем наше/не наше регеспом. Заметьте везде исключен двойной обход словаря.
А вот эта предварительная проверка и дала хороший прирост. И фактически поиск стал равен времени обхода словаря и не зависим от количества и качества слов в цепочке (до этого зависимость росла прямо пропорциональна количеству слов в цепочке). На порядок же дал прирост вытягивание в строки (ясно, строк не мерено в оригинале).

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

Код мой не был до конца оптимизирован и скорее еще позволял процентов на 10-20 подвинуться (да я максималист ). Ну а если не построчно обходить, а бить на блоки, то скорее всего при большом объеме словарей станет так же ощутимым.
Ну а дальше сами знаете, отделил поиск от подсветки и все встало на свои места .

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

Ну по поводу бинарного кода и паковки. Рассчитывал слова заменить на короткие бинарные последовательности. А поскольку я не исключал повторы, то с последующей паковкой в ZIP. Повторяю, что я не особо вдавался в подробности да и от куда мне набраться опыта в течении года. Да и в общем то важно было начать сначала с оптимизации самого поиска, выжить как можно больше, а затем уже пытаться создавать индекс.

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

Добавлено:
Такой момент.
Заголовки все таки должны быть включены в найденное если в них имеется соответствие. На то он и полнотекстовый.

BKSRU

Цитата:

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

Я вам уже сказал, где он главным образом спрятан. Возьмите просто для эксперимента функцию getArticleText() в dsl.cc и замените
Код: ArticleDom dom( gd::normalize( articleText ), getName(), articleHeadword );

articleText.clear();

text = gd::toQString( dom.root.renderAsText( true ) );

Abs62

Цитата:

Вот опять же хотелось бы поподробнее. Слово - это набор символов, символы - это бинарные коды размером от 1 до 6 байт в зависимости от кодировки. То есть вы собираетесь заменить одну бинарную последовательность другой, более короткой. Вот и хочется понять, как вы это себе представляете.

Я ни как себе это не представляю. Вроде ясно пояснил. Я мог только предположить, что вполне возможно заменить, например, слово Work на w. Еще раз повторяю, что понятия не имею о механизме создания индексов.


Цитата:

Полнотекстовый поиск - это поиск по телу статей. И если заголовки не являются неотъемлемой частью статьи, а представляют собой отдельную сущность, то и включаться в поиск они, думаю, не должны.

Опять приехали. Пока не разругались может проще поступим. Проголосуем? Как скажут так и будет. Полнотекстовый поиск должен быть полным.

Добавлено:
Подключил режим перебора. Результаты скорости поиска аналогичны режиму Whole words. Ну не хуже уже радует .
Однако, без подсветки проверить правильность работы и отладить затруднительно.
Ждем.

Abs62

А что если для full-text поиска использовать SQLite с его замечательным FTS4?

data man
Это значит все словари целиком в базу данных загонять?

Abs62
Нет, не обязательно.
Есть возможность Contentless FTS4 Tables
SQLite FTS3 and FTS4 Extensions п.6.2.*

GoldenDict на основе сборки 1.5RC302 (не UI Revolution). Вариант с режимом перебора (Enumeration).
GoldenDict_FTS_ENUM.7z(EXE only).7z
Но пока конечно, без подсветки, для пользователя это набор карточек.

Abs62
Симплифид заголовков надо бы сделать.
Там где в середине скобки убраны двойные пробелы.

После выбора предложенного, идет в общую полку. Возможно это удобно. Ели бы не включал выключенный онлайн мультитран при этом .

BKSRU

Цитата:

Симплифид заголовков надо бы сделать.
Там где в середине скобки убраны двойные пробелы.

Это как? Пример можно?

Цитата:

После выбора предложенного, идет в общую полку. Возможно это удобно. Ели бы не включал выключенный онлайн мультитран при этом

Вот здесь хотелось бы поподробнее. В какой момент он включается и при каких действиях?

Abs62
Сделайте поиск в Advanced Learner's Dictionary, 8th Edition (En-En) - DSL
Берем для поиска - have any
Далее в найденном выберете - feel in your bones
Станет все ясно.

В окне будет предложен вариант - Близкие слова. Жмем и GoldenDict скажет все, что по этому поводу думает .

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

Пока разбираетесь с подсветкой, можно было бы штатную строку поиска по тексту допилить. Что бы не было автозакрытия этой самой строки и не лез в нее заголовок при каждом выборе карточки, с возможностью при перетаскивании текста в нее, что бы была подмена а не вставка. Вот тогда можно будет назвать ее строкой поиска по тексту. И при выборе любого ключевого слова из FTS уже можно было бы ориентироваться как рыба в воде.

Добавлено:
Может все таки не ясно пояснил:
Заголовок - feel (it) in your bones (that … )
Скобки убраны. Два пробела осталось. Соответственно, заголовок не найден.

Уффф, наконец-то я смог скачать все обновления и начать тестить ...
Пару моментов по мелочи:
1) Может быть стоит сделать короткое сообщение, если поиск (FTS) ничего не нашёл? Типа No result, Search is done. В области результатов, например. А то и не понятно, ГД всё ещё ищет или уже ничего не нашёл? Только потом понимаешь что надо на кнопку Search смотреть, когда она активизируется, то значит поиск завершился. Но это вроде как-то неочевидно и неаккуратно.
2) На мой взгляд, не хватает горячей клавиши для перевода фокуса между основным окном и модальным (как FTS, так и Headwords). Например F6, классически. Сделал я тут выборку по окончаниям в Headwords и нужно было все карточки просмотреть по очереди. Заголовок выбираю - фокус улетает в главное окно. Обратно только мышкой, а список не маленький. А то бы пальцы положил на клавиши и, не отвлекаясь от текста, F6 - стрелка вниз, F6 - стрелка вниз -- как хорошо!