Ну Lingvo не очень полная в онлайне, а платной подписки вроде бы нету. Про FineReader не знал, уже интересно. :)
Еще нет.
Когда же когда? :) Правильно я понимаю, что нам стоит ждать online версию?
Если так то это будет очень крутой удар по Google так и по Yandex. Желаю успехов! (самим, что ли начать такую систему писать...)
Большое спасибо!
Прочитал, очень интересно и очень похоже на то что думал я.
Хотя есть и отличия:
1. Я думал о графе, а не о дереве.
2. В графе бы хранились не настолько «языковые» понятия, а всё же более универсальные.
3. Я думал скорее о IBMовском Watson в разрезе перевода (или более универсального ИИ в будущем).
Я так понял ABBYY ещё не показала публике продукты на Compreno? И пугает то что ABBYY не очень любит веб приложения по этому на своём Linux я не факт, что смогу найти это чудное творение. (вспоминаю историю с Lingvo)
ЗЫ К слову, аналогичный подход я думал применять для распознование изображений.
У себя на сайте использую только средний цвет всей картинки, в том числе поиск. Если сделать 3 средних цвета то искать подобные картинки будет гораздо точнее.
Сам сайт тоже на Python+PIL но так как больше 200 000 надо бы такой алгоритм на С переписать.
А если ещё добавить кривезну контрастных участков то можно очень неплохо искать похожие картинки…
Это бы позволило писать независимо фронтенд (чтение текста), ядро (универсальный язык, смысл, граф ситуации) и бекенд (запись текста нанужном языке). ИМХО
Эта мысль мне очень нравится, реалистична ли?
А есть способы перевода акромя статистического и синтаксического? Мне всегда казалось, что для качественного перевода надо сначало понять о чём речь, а потом написать с 0 но сохранив смысл и передав отенки.
Если бы я сейчас занялся этой задачей то скорее делал что то типо «базы знаний» и промежуточного формализованого языка.
Т.е. сначало надо понять смысл фразы, разложиь её в некое представление, а потом собрать заного (в том числе с учётом синтакса). Существующие переводчики часто какойто бред выдают, даже синтаксически не верно.
Всегда мечтал работать близко к теме ИИ но как то не срослось пока :(
Декларативный шаблон сложнее сломать и сложнее криво написать — это особенно хорошо проявляется в проекте на 50 человек, где обрасть знания проекта у каждого разработчика сильно ограничена.
Не против, только может быть тут «плохому танцору»…
И опять же:
1. Если вам реально нужна производительность и вы ограничены в ресурсах то лучше императивный.
2. Если фич заложенных в декларативный шаблон не хватает то он превращается в куда более жуткую лапшу (шаблоны в django это показывают).
Абзац философии
Это всё же больше дело вкуса… кто то гоняет на мотоцикле, а кто то на машине. Везде есть свои плюсы и минусы, и тут скорее дело вкуса и навыков.
Я поддержу BVadim, декларативные шаблонизаторы местами становятся крайне не удобными. Они гораздо хуже расширяются, не говоря о том, что работают медленно.
И надо понимать, что в императивных вполне возможно применять одно-проходные алгоритмы (нет необходимости специально формировать данные для шаблонизатора).
На счёт каши: она возможна НО при правильном проектировании её не будет. Не декларативный стиль даёт больше свободы и только вам решать, получится у вас каша или быстрая стройная система по генерации html/dom.
ЗЫ а вообще у меня много претензий к xslt, и было много споров с сотрудниками yandex ;) единственный козырь xslt был в том что можно было разделить роли в разработке — программист, верстальщик. Но при использовании JSON и шаблнизации на клиенте как то этот довод уже мне кажется себя изжил.
К примеру в mako (который тоже не декларативный шаблонизатор, хоть и для Python) есть конструкция if,elif,else куда ваш пример великолепно ложится.
Кроме того никто не запрещает создавать шаблонные функции и красиво выносить обработку таких вещей туда. Мне кажется для JavaScript такое тоже можно вполне написать.
Это очень похоже на передачу указателя из С. Если поменяем сам указатель в функции то ничего не призойдёт, а вот если обратимся к объекту по этому указателю то сможем его поменять.
«Если вы не умеете писать качественный код на C++ с низкоуровневой оптимизацией, то нет смысла пытаться написать нативное расширение для ускорения производительности.» — вот с этим согласен. Тут так и хочется взять что то типа liboil или накрайняк самим на SSE перенести, гарантирую 4x прирост.
Никто не спорит что так нельзя, но это как минимум не удобно. Согласитесь apt-get install php (после 3 секунд уже стоит) куда быстрее чем война с инсталяторами, разворачиванием unix структуры каталогов в windows и прочее. Ну не предназначено изначально это ПО для работы в Win32/64 в итоге костылями её натягивают. Поверьте я тоже осиливал запуск всего веб обвеса на windows но этот гемор я никому не пожелаю… лучше один раз настроить gentoo или ubuntu и потом не париться. К тому же вы забываете что это ПО на до бы регулярно обновлять и тут оно вот сложновато (когда у тебя проект где то их 30-40 компонентов, даже раз в неделю проверять обновления трудно)
Завтра буду вникать в код и оптимизировать. Мне кажется там где то завязка на UI.
Ждёмс.
Еще нет.
Когда же когда? :) Правильно я понимаю, что нам стоит ждать online версию?
Если так то это будет очень крутой удар по Google так и по Yandex. Желаю успехов! (самим, что ли начать такую систему писать...)
Прочитал, очень интересно и очень похоже на то что думал я.
Хотя есть и отличия:
1. Я думал о графе, а не о дереве.
2. В графе бы хранились не настолько «языковые» понятия, а всё же более универсальные.
3. Я думал скорее о IBMовском Watson в разрезе перевода (или более универсального ИИ в будущем).
Я так понял ABBYY ещё не показала публике продукты на Compreno? И пугает то что ABBYY не очень любит веб приложения по этому на своём Linux я не факт, что смогу найти это чудное творение. (вспоминаю историю с Lingvo)
ЗЫ К слову, аналогичный подход я думал применять для распознование изображений.
Сам сайт тоже на Python+PIL но так как больше 200 000 надо бы такой алгоритм на С переписать.
А если ещё добавить кривезну контрастных участков то можно очень неплохо искать похожие картинки…
Эта мысль мне очень нравится, реалистична ли?
Если бы я сейчас занялся этой задачей то скорее делал что то типо «базы знаний» и промежуточного формализованого языка.
Т.е. сначало надо понять смысл фразы, разложиь её в некое представление, а потом собрать заного (в том числе с учётом синтакса). Существующие переводчики часто какойто бред выдают, даже синтаксически не верно.
Всегда мечтал работать близко к теме ИИ но как то не срослось пока :(
Не против, только может быть тут «плохому танцору»…
И опять же:
1. Если вам реально нужна производительность и вы ограничены в ресурсах то лучше императивный.
2. Если фич заложенных в декларативный шаблон не хватает то он превращается в куда более жуткую лапшу (шаблоны в django это показывают).
Абзац философии
Это всё же больше дело вкуса… кто то гоняет на мотоцикле, а кто то на машине. Везде есть свои плюсы и минусы, и тут скорее дело вкуса и навыков.
И надо понимать, что в императивных вполне возможно применять одно-проходные алгоритмы (нет необходимости специально формировать данные для шаблонизатора).
На счёт каши: она возможна НО при правильном проектировании её не будет. Не декларативный стиль даёт больше свободы и только вам решать, получится у вас каша или быстрая стройная система по генерации html/dom.
ЗЫ а вообще у меня много претензий к xslt, и было много споров с сотрудниками yandex ;) единственный козырь xslt был в том что можно было разделить роли в разработке — программист, верстальщик. Но при использовании JSON и шаблнизации на клиенте как то этот довод уже мне кажется себя изжил.
Кроме того никто не запрещает создавать шаблонные функции и красиво выносить обработку таких вещей туда. Мне кажется для JavaScript такое тоже можно вполне написать.