Нет, по-моему, не похоже. И конструирующего XPath там нет, да и синтаксис там другой, разработчики XQuery явно не стремились к минимализму средств и разработали вполне классический алгоритмический язык.
C [@A=2 or @A=3] вы что-то придумали, а как будете восстанавливать [@A>1]?
Такой элемент выражения может присутствовать в конструирующем XPath. Но используется он только для фильтрации на очередном шаге, порождать новых вариантов такая часть, разумеется, не будет. Она просто отсечет порожденные варианты с @A>1, если они появятся, например, [(@A=1 or @A=6) and (@A>1)] просто тогда даст единственный вариант с @A=6.
Как будете обрабатывать // и *
Они присутствовать могут, и рассматриваться при интерпретации/продвижении по выражению тоже будут, здесь противоречий нет. Но, конечно, "*" ничего создать не может.
Синтаксис — вопрос абсолютно открытый (я на своем варианте не настаиваю), если вдруг когда-нибудь эта идея дойдет до какого-то промышленного воплощения. Меня же интересовал почти исключительно вопрос о том, насколько возможна реализация идей, изложенных в посте.
Нейросеть на ReLU не может превратиться в полином хотя бы потому, что ReLU — недифференцируемая функция
По-моему, как раз может. На линейных положительных участках ReLU имеет вид y = x. Тогда на выходе y нейрона первого слоя имеем y = сумма w1*x, на выходе нейрона второго слоя имеем z = сумма w2*y =сумма w2*(сумма w1*x). Чем не полином, если скобки раскрыть?
Зачем же было тогда от сигмоид возвращаться обратно к полиномам (пусть и с отрицательными степенями, степенями кратности 1/2)
В данном случае в итоге обычно получаем комбинации полиномов, обычно сводимые к дроби полином/полином. Это уже, возможно, немного лучше.
если вы обучали и тестировали нейросеть на одних и тех же данных
Да, было интересно написать и тщательно распараллелить, чтобы задача в-целом считалась как можно быстрее. Кстати, там чуть сложнее, чем просто вынесение common subexpressions — после всех подстановок упрощенных активационных функций в общую нейросетевую функцию обычно получается громоздкое алгебраическое выражение, которое последовательно приводится к дроби, где и числитель и знаменатель — полиномы (от множества переменных), и делается попытка, если возможно, символически поделить полином на полином.
Но вроде как методологически вернее просто брать простую функцию уже на этапе обучения, как например уже писали про ReLU
Что меня смущает в подходе с ReLU, так это то, что нейросетевая функция, вообще говоря, превращается, если не ошибаюсь, в обычный полином от множества переменных. Со всеми недостатками чисто полиномиальной интерполяции, например, с не очень качественным приближением заранее неизвестных точек, не входящих в обучающую выборку, а также с излишним количеством элементов (полином получен будет, но всегда есть опасность, что он будет иметь слишком большой порядок). Поэтому подход, при котором все же идем от интерполяции с сигмоидами, мне кажется методически также вполне оправданным.
Определение нужного элемента в таблице все равно требует 3-5 операций процессора, это как минимум. И ещё — Вы, возможно не обратили внимания, после замены экспонент полученная функция символьно упрощается, это даёт дополнительный выигрыш, который одним табулированием экспоненты не получить.
Иногда занимаюсь ускорением личных научных расчетов в области аэродинамики и сжатием полученных данных, собственно, именно там нейронные сети и применяю.
Сигмоиды тоже используются, например, в моей работе. Думаю, с их помощью, проще приближать сетью сложные многоэкстремальные данные — возможно, меньше нейронов требуется.
Все изложенное основано на идее применения особого вида моделей, которые я называю объектно-событийными (ОСМ). В этом и состоит новизна, если в паре слов.
Хорошая статья. Идея построения интеллектуальной системы на механизме прямой и, отчасти, статистической интерпретации синтаксических конструкций созвучна моим идеям, хотя я занимаюсь в этой области не ИИ, а более частной задачей автоматического программирования. Если будете писать научную статью про Ваши эксперименты, пришлите, пожалуйста ссылку (pekunov@mail.ru). Буду признателен.
Если в нескольких словах: речь идет о создании такой системы, которая во-многом заменяет программиста, поскольку позволяет:
а) описывать решаемую задачу в виде некоторой схемы;
б) автоматически генерировать по такой схеме программу, решающую данную задачу;
в) решать обратную проблему: брать некоторую программу и, хотя бы частично, распознавать, какую задачу эта программа решает.
Кроме того, речь идет о некоторых побочных применениях такой системы: о том, что можно генерировать программу не только по некоторой визуальной блочной схеме, но и по текстовому описанию этой задачи, например на русском языке (с упрощениями и ограниченими).
Можно почитать про DSL (Domain Specific Language). Похожими вещами также занимается, например, программа Rational Rose. Кроме того, на схожие темы существуют бумажные книги (например, немного, но есть в книге К.Чарнецки, У.Айзенекера «Порождающее программирование: Методы, инструменты, применение»). Есть много научных книг и статей, например, про SWITCH-технологии, можете поискать в Интернете.
DSL — действительно, одно из направлений прикладного автоматического порождения программ. Но ни решение задачи, обратной порождению, ни строгая верификация порождённой программы, для DSL-направления не характерны, насколько я знаю.
Да, это учебный пример (можно использовать при обучении программированию, показывая, какие программы можно получать для решения различных простых задач). Профессиональному программисту такую программу, конечно, написать несложно. Порождение же программ оправданно для решения сложных задач, когда однократно затраченное на создание порождающих классов время намного меньше суммарного времени на написание требуемых программ специалистом.
Сейчас у вас синтаксис получился с заметным потенциальным (а то и реальным) конфликтом с другим механизмом, который используется в таких выражениях — {} как установкой квантификаторов (например: \d{1,3}), и требуется сложный разбор вперёд, чтобы убедиться, что ->{что-то} это именно ваша конструкция
Нет, разбор не такой уж и сложный. По крайней мере отличить предикаты в фигурных скобках от цифр не так сложно.
Идея с предикатами неплоха, но 1) давно есть в некоторых движках, как в том же perlre
Не нашел такого в pelre. Если Вы имеете в виду конструкции (??{}) и (?{}), то это не предикаты, а алгоритмический perl-код (или, возможно, код на ином языке). Здесь же предлагается языко-независимое логическое решение. Думаю, оно несколько компактнее и проще, чем (??{}) и (?{}). Если я ошибаюсь, поправьте меня.
2) есть альтернативное движение, которое в столь сложных случаях вместо языка регулярных выражений подключает PEG-движки.
Насколько я почитал, PEG все-равно не решает даже проблему перечисления альтернатив (они все равно присутствуют в грамматике, а хотелось бы подкачивать их из таблицы). Не видел я там и нестрогого сравнения с образцом.
Ещё непонятно, как именно вы собрались подключать сложные внешние предикаты в движок — встроенные средства для этого, насколько я знаю, недостаточны.
Теоретически, можно написать произвольное количество предикатов, включить их в динамически подгружаемый модуль и придумать regex-директиву для подключения модуля.
:) Да, конечно, до такого лучше не доводить. А если серьезно, то для такой ОС целесообразно ввести простое ранжирование приложений по требуемому уровню обслуживания (пасьянсу — нулевой).
Дело не в оптимизации кода, а в свойствах реализуемого алгоритма. Там есть определенная доля нераспараллеливаемой работы, которая просто неподвластна оптимизации. Если эта доля растёт с увеличением числа потоков, то на определенном этапе попытка увеличить число потоков приведёт только к замедлению работы программы. В-общем, один землекоп копает яму за час, два землекопа — за полчаса, а сто землекопов только будут мешать друг другу и проработают два часа (если вообще не передерутся).
Если таких наборов данных — один или два, то можно и по графикам. А если их пять-десять-больше, то я предпочту что-то вроде того, что предлагается в публикации. Потому в начале и было написано про потенциально «большие данные», где подход может оправдать себя.
Если программа будет работать только на одной конкретной ЭВМ, то, конечно, можно и эмпирически. Но если ЭВМ заранее неизвестна, то все уже не так просто. Но это даже не главное. Объём вычислений в цикле может очень сильно зависеть от входных данных, соответственно и оптимальное число потоков может от них сильно зависеть. Если входные данные постоянно меняются, то единого эмпирического оптимального числа потоков просто нет. Вот тогда и может пригодиться построенная модель.
Да, обработано и вырезано. Что же касается пересечения со спецификацией исключения, то теоретически путаницы не будет, поскольку спецификация исключений может быть: throw(), throw(...), throw(тип), а спецификация параметров принимающей процедуры: throw(тип имя [, тип имя ...]). Однако в текущей демо-версии транслятора путаница возникнуть может (я проверю, если есть — поправлю).
Такой элемент выражения может присутствовать в конструирующем XPath. Но используется он только для фильтрации на очередном шаге, порождать новых вариантов такая часть, разумеется, не будет. Она просто отсечет порожденные варианты с @A>1, если они появятся, например, [(@A=1 or @A=6) and (@A>1)] просто тогда даст единственный вариант с @A=6.
Они присутствовать могут, и рассматриваться при интерпретации/продвижении по выражению тоже будут, здесь противоречий нет. Но, конечно, "*" ничего создать не может.
По-моему, как раз может. На линейных положительных участках ReLU имеет вид y = x. Тогда на выходе y нейрона первого слоя имеем y = сумма w1*x, на выходе нейрона второго слоя имеем z = сумма w2*y =сумма w2*(сумма w1*x). Чем не полином, если скобки раскрыть?
В данном случае в итоге обычно получаем комбинации полиномов, обычно сводимые к дроби полином/полином. Это уже, возможно, немного лучше.
На разных.
Что меня смущает в подходе с ReLU, так это то, что нейросетевая функция, вообще говоря, превращается, если не ошибаюсь, в обычный полином от множества переменных. Со всеми недостатками чисто полиномиальной интерполяции, например, с не очень качественным приближением заранее неизвестных точек, не входящих в обучающую выборку, а также с излишним количеством элементов (полином получен будет, но всегда есть опасность, что он будет иметь слишком большой порядок). Поэтому подход, при котором все же идем от интерполяции с сигмоидами, мне кажется методически также вполне оправданным.
а) описывать решаемую задачу в виде некоторой схемы;
б) автоматически генерировать по такой схеме программу, решающую данную задачу;
в) решать обратную проблему: брать некоторую программу и, хотя бы частично, распознавать, какую задачу эта программа решает.
Кроме того, речь идет о некоторых побочных применениях такой системы: о том, что можно генерировать программу не только по некоторой визуальной блочной схеме, но и по текстовому описанию этой задачи, например на русском языке (с упрощениями и ограниченими).
Можно почитать про DSL (Domain Specific Language). Похожими вещами также занимается, например, программа Rational Rose. Кроме того, на схожие темы существуют бумажные книги (например, немного, но есть в книге К.Чарнецки, У.Айзенекера «Порождающее программирование: Методы, инструменты, применение»). Есть много научных книг и статей, например, про SWITCH-технологии, можете поискать в Интернете.
Нет, разбор не такой уж и сложный. По крайней мере отличить предикаты в фигурных скобках от цифр не так сложно.
Не нашел такого в pelre. Если Вы имеете в виду конструкции (??{}) и (?{}), то это не предикаты, а алгоритмический perl-код (или, возможно, код на ином языке). Здесь же предлагается языко-независимое логическое решение. Думаю, оно несколько компактнее и проще, чем (??{}) и (?{}). Если я ошибаюсь, поправьте меня.
Насколько я почитал, PEG все-равно не решает даже проблему перечисления альтернатив (они все равно присутствуют в грамматике, а хотелось бы подкачивать их из таблицы). Не видел я там и нестрогого сравнения с образцом.
Теоретически, можно написать произвольное количество предикатов, включить их в динамически подгружаемый модуль и придумать regex-директиву для подключения модуля.