Проблема структуризации/упорядочивания в принципе интересна, и заключается как раз в том, что мы не знаем как должна быть упорядочена информация, поскольку часто не знаем ее будущий состав. Идеальное решение данной проблемы как раз и есть поисковик. Однако поисковик рождает другую проблему (имею ввиду классическую поисковую строку), если мы не знаем что искать, тоже например строка терминала. В случае с поиском в интернет, эта проблема как раз является не актуальной в связи с объемом информации, и учитывая факт глобальности, скорее всего если мы об этом думаем кто-то уже подготовил для нас информацию, и даже здесь появляется список-подсказка, облегчающий работу. Другой вопрос поиск в сравнительно малом объеме информации. Когда-то это вопрос был решен введением меню, что существенно упростило работу. Когда я работал над алгоритмом расчета KVL, решил данную задачу использованием как я его теперь называю статистическое дерево. Это дерево формируется из KVL конфигурации путем анализа статистики ключей формирующих конфигурацию. Таким образом оно является динамическим, оно формируется естественным образом, и постоянно меняется в процессе работы, соответствуя текущему состоянию системы. Этот принцип очень эффективен. Но ключ к успех как раз в том что дерево и есть информация. Сейчас я хочу опробовать данный механизм на сравнительно больших объемах информации…
Наверное все сразу. Я перекопал всю область прикладных и теоретических исследований ИИ, нейронных сетей и тд., Согласно моим вычислением, проблема сейчас не в недостатке ресурсов, а именно в отсутствие теории для реализации решения. В течение последних двух лет я прорабатываю теоретическую базу пытаясь выработать общую теорию информации. На основании которой разработал и реализовал прикладной алгоритм, сейчас дорабатываю легкую объектную библиотеку на С, на которой будет протестирована эта разработка. В параллельных проектах, подготовил систему наполнения этой штуки информацией из публичных источников, первоначально это книги. Это достаточно глобальная задача, где сталкиваешься с кучей технических проблем, и пожалуй с самой главной — недостаточно времени, нужно ведь и кушать что-то…
На счет специальной разметки, лично мне эта идея тоже не нравиться. Это как насаждение дополнительной отчетности на сотрудников компании. Никто не хочет делать дополнительную, а, что хуже, повторную работу. Сужу по себе. Не выношу однообразной механической работы! Для чего тогда нужны достигнутые вычислительные мощьности? Большинство из них сегодня тратиться впустую, так же на единообразные операции согласно жестким алгоритмам.
Проблема, все же, в теории. Я вижу решение в переосмыслении основ. Казалось бы простой вопрос — Что есть информация? Есть много определений. Ни одно не отражает сути…
При этом мы должны понимать, что поисковик покажет то, что кто-то оставил.
И еще заметьте, что Ваш запрос, достаточно популярен, и вы видите ответ человека, оставленный именно на этот вопрос. И, что самое плохое в этой схеме, вы не можете непосредственно у googla, доспросить, если этот ответ не понятен ( не имею ввиду почитать другой результат поиска), а именно переспросить у машины, которая поняв, что Вам нужно, домыслит, возможно задаст пару дополнительных попросов, но ответит точнее, и уже по Вашей конкретной задаче…
С точки зрения пользователя, я текущим уровнем поиска доволен очень (особенно google)! Наверное то, что мы обсуждаем, уже отчасти немного другая история, это консультация универсального специалиста.
И согласитесь, если завтра появиться такой продукт, и будет работать на уровне, он привлечет внимание так или иначе.
Думаю, что перекапывание интернета, отнимает не меньше ресурсов. Скорее проблема именно в теоретической базе.
Я вполне ясно понимаю принципы действия используемых сейчас методов. Однако подобраться к другой принципиальной идее удалось лишь не так давно. И шел я извилистым путем. И, честно говоря, впереди неизвестность хоть и с просветами…
Согласен, хотя я, все же, склонен считать подобный запрос в принципе подразумевает данную неоднозначность, хотя человек конечно в мыслях точно знает что именно ему надо. Данный вопрос как мне кажется более или менее решаемый, и его активно решают, оценивая контекстную информацию о пользователе. Например, если я сейчас в пути или формирую запрос из навигатора, то велика вероятность, что я ищу именно ресторан.
Мне интересен другой момент. Реализация системы которая поймет смысл моего вопроса. Пусть учитывает при этом прочие факторы, но она уже сможет вступить со мной в диалог, попросить уточнения. Принять более сложный логически запрос, и вернуть не целую страницу, а часть информации интересную мне здесь и сейчас.
Напримет вопрос — сколько мест в банкетном зале Санчо Панса. Google справляется в этим вопросом на ура, но он, даже умея синтезировать речь, не сможет ответить на мой вопрос так, как это сделает администратор по телефону.
И кстати. Заметьте, впервые столкнувшить с интернетом и поисковиком, люди пытаются задавать ему человеческие вопросы, спустя некоторое время, она подстраиваются и пишуть просто ключевые слова… )
Согласен. Но тогда наш запрос подразумевает множественный ответ. Имею ввиду например, Где можно заправиться в этом городе
При условии, что ответ верный и достаточно для наших целей полный.
Вот и я о том же. Абсолютная истина, это конечно тема отдельного обсуждения, я хотел выразить суть того, что у меня есть вопрос, я спрашиваю, и получаю ответ реально нужный мне. Согласитесь, что это очень серьезный уровень. Сегодня мы привлекаем свой мыслительный аппарат для извлечения необходимой нам в нашей конкретной ситуации информации, из обсуждения какой либо проблемы или идеи на форуме, решения кем-то аналогичной (аналогичной, но не в точности такой задачи). И принцип используемого поиска сегодня не может взять эту работу на себя…
Спасибо Автору! Для меня оказалось очень полезным. Вроде бы вполне очевидные вещи, но одно дело предполагать, а другое услышать из уст человека прошедшего через это, и использовать данные принципы на практике! Прочти я это лет эдак 5 назад…
Код тоже выложу, нужно над ним немного поработать, почистить. Когда начинал работу, еще не использовал CVS — много дублирующихся методов: f_1, f_2 и тд.
В цикл нельзя привнести асинхронность. Именно этот фактор, заставил искать другое решение. И, да, очень согласен, если конечно верно понял Вашу мысль, — необходимо и достаточно! Этим принципом руководствуюсь в работе. Приведенное решение нужно тогда и только тогда, когда мы в целевой (рекурсивной) функции имеем конструкцию? результат выполнения которой возвращается в calback. В этом случае цикл нам не подходит, именно поэтому было применено это решение…
Да. Именно это и требуется. Код в котором применялась конструкция, полностью асинхронный, те все эффективные функцию имеют определенную сигнатуру, и обязаны поддерживать асинхронность.
В предыдущей версии в основе лежал цикл, который перебирал символы шаблона, выискивал включения, и заменял на что нужно, ну вообщем как обычно.
— здесь я конечно хватил немного. Я имел ввиду, что принцип обработки шаблона так или иначе связан с перебором символов содержимого, по крайней мере, я не могу назвать какой либо другой возможный принцип поиска, допустим необходимого нам символа в тексте, без использования каких либо техник индексации и тд. Как правило(по крайней мере я бы точно сделал так), используется конструкция вида:
Где, f_var_replacer возвращает некоторое значение, помещаемое на место того что нам нужно заменить. Однако, насколько я знаю regexp — это конечный автомат, который так или иначе выполняет полный перебор всех символов в один проход.
Раньше с целью лучшего понимания, а теперь скорее с целью получения большего контроля над процессом, я выполняю данную операцию вручную — те в цикле перебираю символы строки, задавая на входе набор состояний, в которых может находится парсер, и обрабатываю текст. Не ручаюсь за производительность, решения. К сожалению в потоке работы, так и не протестировал (но обязательно сделаю) скорость работы regexp и реализованного алгоритма (думаю regexp безоговорочно выиграет, поскольку свой подход считаю очень примитивным).
Теперь что касается семи ста вызовов. Если честно, хотел бы расписать все по полочкам, с самого начала. Проект активно развивается и, сейчас, я наконец таки взялся за написание общедоступной документации. Где хочу расписать архитектуру, в том числе шаблонизатор, поскольку в него я вложил очень много труда. Конечно, я не претендую, на оригинальность, или самое лучшее решение, но удалось сделать то, что было запланировано, и это работает!
700 вызовов, это не чистая цифра, и складывается она из 1 вызова эффективной функции, +3 накладных (диспетчер задач). Отсюда и цифра. Реально это 150-200 вызовов. В результате оптимизации число накладных вызовов было снижено до 2.
Я не хочу углубляться в подробности отрывочно, поскольку не удастся передать суть, и обосновать те или иные решения… Статьи уже в работе. Буду рад если информация покажется Вам интересной и принесет пользу!
Не знаю как написать об этом в двух словах, когда разбирался с багом, долго не мог найти что приводило к переполнению.
Вообщем был разработан асинхронный шаблонизатор для проекта josi (как раз планирую статью о технике которую использовал при его написании).
В предыдущей версии в основе лежал цикл, который перебирал символы шаблона, выискивал включения, и заменял на что нужно, ну вообщем как обычно.
Появилась идея — добавить возможность, во время парсинга шаблона, подгружать динамически другие шаблоны, и включать, после обработки, в текущий, что то вроде include php. При это необходимо обеспечить ассинхронность естественно. В этом случае обычный цикл пришлось заменить рекурсивным вызовом по fdone (завершению подгрузки запрошенного шаблона), с передачей текущего контекста парсинга. Учитывая при этом накладные расходы фреймворка (+3 последовательных вызова служебных функций), для парсинга сложного шаблона порой требовалось сделать и 700 и более вызовов, что и приводило к проблеме.
Проблема, все же, в теории. Я вижу решение в переосмыслении основ. Казалось бы простой вопрос — Что есть информация? Есть много определений. Ни одно не отражает сути…
И еще заметьте, что Ваш запрос, достаточно популярен, и вы видите ответ человека, оставленный именно на этот вопрос. И, что самое плохое в этой схеме, вы не можете непосредственно у googla, доспросить, если этот ответ не понятен ( не имею ввиду почитать другой результат поиска), а именно переспросить у машины, которая поняв, что Вам нужно, домыслит, возможно задаст пару дополнительных попросов, но ответит точнее, и уже по Вашей конкретной задаче…
С точки зрения пользователя, я текущим уровнем поиска доволен очень (особенно google)! Наверное то, что мы обсуждаем, уже отчасти немного другая история, это консультация универсального специалиста.
И согласитесь, если завтра появиться такой продукт, и будет работать на уровне, он привлечет внимание так или иначе.
Я вполне ясно понимаю принципы действия используемых сейчас методов. Однако подобраться к другой принципиальной идее удалось лишь не так давно. И шел я извилистым путем. И, честно говоря, впереди неизвестность хоть и с просветами…
Мне интересен другой момент. Реализация системы которая поймет смысл моего вопроса. Пусть учитывает при этом прочие факторы, но она уже сможет вступить со мной в диалог, попросить уточнения. Принять более сложный логически запрос, и вернуть не целую страницу, а часть информации интересную мне здесь и сейчас.
Напримет вопрос — сколько мест в банкетном зале Санчо Панса. Google справляется в этим вопросом на ура, но он, даже умея синтезировать речь, не сможет ответить на мой вопрос так, как это сделает администратор по телефону.
И кстати. Заметьте, впервые столкнувшить с интернетом и поисковиком, люди пытаются задавать ему человеческие вопросы, спустя некоторое время, она подстраиваются и пишуть просто ключевые слова… )
Согласен. Но тогда наш запрос подразумевает множественный ответ. Имею ввиду например, Где можно заправиться в этом городе
Вот и я о том же. Абсолютная истина, это конечно тема отдельного обсуждения, я хотел выразить суть того, что у меня есть вопрос, я спрашиваю, и получаю ответ реально нужный мне. Согласитесь, что это очень серьезный уровень. Сегодня мы привлекаем свой мыслительный аппарат для извлечения необходимой нам в нашей конкретной ситуации информации, из обсуждения какой либо проблемы или идеи на форуме, решения кем-то аналогичной (аналогичной, но не в точности такой задачи). И принцип используемого поиска сегодня не может взять эту работу на себя…
Bижу это так:
В любом случае это не цикл while…
— здесь я конечно хватил немного. Я имел ввиду, что принцип обработки шаблона так или иначе связан с перебором символов содержимого, по крайней мере, я не могу назвать какой либо другой возможный принцип поиска, допустим необходимого нам символа в тексте, без использования каких либо техник индексации и тд. Как правило(по крайней мере я бы точно сделал так), используется конструкция вида:
Где, f_var_replacer возвращает некоторое значение, помещаемое на место того что нам нужно заменить. Однако, насколько я знаю regexp — это конечный автомат, который так или иначе выполняет полный перебор всех символов в один проход.
Раньше с целью лучшего понимания, а теперь скорее с целью получения большего контроля над процессом, я выполняю данную операцию вручную — те в цикле перебираю символы строки, задавая на входе набор состояний, в которых может находится парсер, и обрабатываю текст. Не ручаюсь за производительность, решения. К сожалению в потоке работы, так и не протестировал (но обязательно сделаю) скорость работы regexp и реализованного алгоритма (думаю regexp безоговорочно выиграет, поскольку свой подход считаю очень примитивным).
Теперь что касается семи ста вызовов. Если честно, хотел бы расписать все по полочкам, с самого начала. Проект активно развивается и, сейчас, я наконец таки взялся за написание общедоступной документации. Где хочу расписать архитектуру, в том числе шаблонизатор, поскольку в него я вложил очень много труда. Конечно, я не претендую, на оригинальность, или самое лучшее решение, но удалось сделать то, что было запланировано, и это работает!
700 вызовов, это не чистая цифра, и складывается она из 1 вызова эффективной функции, +3 накладных (диспетчер задач). Отсюда и цифра. Реально это 150-200 вызовов. В результате оптимизации число накладных вызовов было снижено до 2.
Я не хочу углубляться в подробности отрывочно, поскольку не удастся передать суть, и обосновать те или иные решения… Статьи уже в работе. Буду рад если информация покажется Вам интересной и принесет пользу!
Вообщем был разработан асинхронный шаблонизатор для проекта josi (как раз планирую статью о технике которую использовал при его написании).
В предыдущей версии в основе лежал цикл, который перебирал символы шаблона, выискивал включения, и заменял на что нужно, ну вообщем как обычно.
Появилась идея — добавить возможность, во время парсинга шаблона, подгружать динамически другие шаблоны, и включать, после обработки, в текущий, что то вроде include php. При это необходимо обеспечить ассинхронность естественно. В этом случае обычный цикл пришлось заменить рекурсивным вызовом по fdone (завершению подгрузки запрошенного шаблона), с передачей текущего контекста парсинга. Учитывая при этом накладные расходы фреймворка (+3 последовательных вызова служебных функций), для парсинга сложного шаблона порой требовалось сделать и 700 и более вызовов, что и приводило к проблеме.