• Конструирующий XPath? Алгоритмический XPath? Ничего, кроме XPath
    0
    В случае Var[@A=1 or @A=2] таблица истинности предиката включает единственную переменную A, при чем же здесь B?
    А случай Var[@A=1 or @B=2] породит три варианта:
    A=«1»
    B=«2»
    A=«1» B=«2»
  • Конструирующий XPath? Алгоритмический XPath? Ничего, кроме XPath
    0
    Относительно формальной постановки. Думаю, так:
    Генерация минимальных дополнений исходного XML, таких, что:
    1. Гарантированно истиннен каждый шаг заданного XPath;
    2. Если на шаг был наложен логический предикат [], то полученный XML удовлетворяет ВСЕМ случаям из его таблицы истинности, дающим в результате истинное значение.
  • Конструирующий XPath? Алгоритмический XPath? Ничего, кроме XPath
    0
    Отличается, повторюсь, применением XPath в конструирующем смысле, и минимализмом средств.
  • Конструирующий XPath? Алгоритмический XPath? Ничего, кроме XPath
    0
    Нет, по-моему, не похоже. И конструирующего XPath там нет, да и синтаксис там другой, разработчики XQuery явно не стремились к минимализму средств и разработали вполне классический алгоритмический язык.
  • Конструирующий XPath? Алгоритмический XPath? Ничего, кроме XPath
    0
    C [@A=2 or @A=3] вы что-то придумали, а как будете восстанавливать [@A>1]?

    Такой элемент выражения может присутствовать в конструирующем XPath. Но используется он только для фильтрации на очередном шаге, порождать новых вариантов такая часть, разумеется, не будет. Она просто отсечет порожденные варианты с @A>1, если они появятся, например, [(@A=1 or @A=6) and (@A>1)] просто тогда даст единственный вариант с @A=6.
    Как будете обрабатывать // и *

    Они присутствовать могут, и рассматриваться при интерпретации/продвижении по выражению тоже будут, здесь противоречий нет. Но, конечно, "*" ничего создать не может.
  • Конструирующий XPath? Алгоритмический XPath? Ничего, кроме XPath
    0
    Синтаксис — вопрос абсолютно открытый (я на своем варианте не настаиваю), если вдруг когда-нибудь эта идея дойдет до какого-то промышленного воплощения. Меня же интересовал почти исключительно вопрос о том, насколько возможна реализация идей, изложенных в посте.
  • Как можно упростить и ускорить вычисление нейронной сети прямого распространения
    0
    Нейросеть на ReLU не может превратиться в полином хотя бы потому, что ReLU — недифференцируемая функция

    По-моему, как раз может. На линейных положительных участках ReLU имеет вид y = x. Тогда на выходе y нейрона первого слоя имеем y = сумма w1*x, на выходе нейрона второго слоя имеем z = сумма w2*y =сумма w2*(сумма w1*x). Чем не полином, если скобки раскрыть?
    Зачем же было тогда от сигмоид возвращаться обратно к полиномам (пусть и с отрицательными степенями, степенями кратности 1/2)

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

    На разных.
  • Как можно упростить и ускорить вычисление нейронной сети прямого распространения
    0
    Да, было интересно написать и тщательно распараллелить, чтобы задача в-целом считалась как можно быстрее. Кстати, там чуть сложнее, чем просто вынесение common subexpressions — после всех подстановок упрощенных активационных функций в общую нейросетевую функцию обычно получается громоздкое алгебраическое выражение, которое последовательно приводится к дроби, где и числитель и знаменатель — полиномы (от множества переменных), и делается попытка, если возможно, символически поделить полином на полином.
  • Как можно упростить и ускорить вычисление нейронной сети прямого распространения
    0
    Но вроде как методологически вернее просто брать простую функцию уже на этапе обучения, как например уже писали про ReLU

    Что меня смущает в подходе с ReLU, так это то, что нейросетевая функция, вообще говоря, превращается, если не ошибаюсь, в обычный полином от множества переменных. Со всеми недостатками чисто полиномиальной интерполяции, например, с не очень качественным приближением заранее неизвестных точек, не входящих в обучающую выборку, а также с излишним количеством элементов (полином получен будет, но всегда есть опасность, что он будет иметь слишком большой порядок). Поэтому подход, при котором все же идем от интерполяции с сигмоидами, мне кажется методически также вполне оправданным.
  • Как можно упростить и ускорить вычисление нейронной сети прямого распространения
    0
    Определение нужного элемента в таблице все равно требует 3-5 операций процессора, это как минимум. И ещё — Вы, возможно не обратили внимания, после замены экспонент полученная функция символьно упрощается, это даёт дополнительный выигрыш, который одним табулированием экспоненты не получить.
  • Как можно упростить и ускорить вычисление нейронной сети прямого распространения
    0
    Иногда занимаюсь ускорением личных научных расчетов в области аэродинамики и сжатием полученных данных, собственно, именно там нейронные сети и применяю.
  • Как можно упростить и ускорить вычисление нейронной сети прямого распространения
    +1
    Сигмоиды тоже используются, например, в моей работе. Думаю, с их помощью, проще приближать сетью сложные многоэкстремальные данные — возможно, меньше нейронов требуется.
  • Автоматическое порождение программ, обратная задача и некоторые связанные с ними решения
    0
    Все изложенное основано на идее применения особого вида моделей, которые я называю объектно-событийными (ОСМ). В этом и состоит новизна, если в паре слов.
  • Создание ИИ методом «глокой куздры». Интеллектуальная одиссея
    0
    Хорошая статья. Идея построения интеллектуальной системы на механизме прямой и, отчасти, статистической интерпретации синтаксических конструкций созвучна моим идеям, хотя я занимаюсь в этой области не ИИ, а более частной задачей автоматического программирования. Если будете писать научную статью про Ваши эксперименты, пришлите, пожалуйста ссылку (pekunov@mail.ru). Буду признателен.
  • Автоматическое порождение программ, обратная задача и некоторые связанные с ними решения
    0
    Если в нескольких словах: речь идет о создании такой системы, которая во-многом заменяет программиста, поскольку позволяет:
    а) описывать решаемую задачу в виде некоторой схемы;
    б) автоматически генерировать по такой схеме программу, решающую данную задачу;
    в) решать обратную проблему: брать некоторую программу и, хотя бы частично, распознавать, какую задачу эта программа решает.
    Кроме того, речь идет о некоторых побочных применениях такой системы: о том, что можно генерировать программу не только по некоторой визуальной блочной схеме, но и по текстовому описанию этой задачи, например на русском языке (с упрощениями и ограниченими).
    Можно почитать про DSL (Domain Specific Language). Похожими вещами также занимается, например, программа Rational Rose. Кроме того, на схожие темы существуют бумажные книги (например, немного, но есть в книге К.Чарнецки, У.Айзенекера «Порождающее программирование: Методы, инструменты, применение»). Есть много научных книг и статей, например, про SWITCH-технологии, можете поискать в Интернете.
  • Автоматическое порождение программ, обратная задача и некоторые связанные с ними решения
    0
    DSL — действительно, одно из направлений прикладного автоматического порождения программ. Но ни решение задачи, обратной порождению, ни строгая верификация порождённой программы, для DSL-направления не характерны, насколько я знаю.
  • Автоматическое порождение программ, обратная задача и некоторые связанные с ними решения
    0
    Да, это учебный пример (можно использовать при обучении программированию, показывая, какие программы можно получать для решения различных простых задач). Профессиональному программисту такую программу, конечно, написать несложно. Порождение же программ оправданно для решения сложных задач, когда однократно затраченное на создание порождающих классов время намного меньше суммарного времени на написание требуемых программ специалистом.
  • Регулярные выражения + логическое программирование. Что в результате?
    0
    Сейчас у вас синтаксис получился с заметным потенциальным (а то и реальным) конфликтом с другим механизмом, который используется в таких выражениях — {} как установкой квантификаторов (например: \d{1,3}), и требуется сложный разбор вперёд, чтобы убедиться, что ->{что-то} это именно ваша конструкция

    Нет, разбор не такой уж и сложный. По крайней мере отличить предикаты в фигурных скобках от цифр не так сложно.
    Идея с предикатами неплоха, но 1) давно есть в некоторых движках, как в том же perlre

    Не нашел такого в pelre. Если Вы имеете в виду конструкции (??{}) и (?{}), то это не предикаты, а алгоритмический perl-код (или, возможно, код на ином языке). Здесь же предлагается языко-независимое логическое решение. Думаю, оно несколько компактнее и проще, чем (??{}) и (?{}). Если я ошибаюсь, поправьте меня.
    2) есть альтернативное движение, которое в столь сложных случаях вместо языка регулярных выражений подключает PEG-движки.

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

    Теоретически, можно написать произвольное количество предикатов, включить их в динамически подгружаемый модуль и придумать regex-директиву для подключения модуля.
  • Метаслой: идеи о применении предсказания для оптимизации программирования и распределения ресурсов в ОС
    0
    :) Да, конечно, до такого лучше не доводить. А если серьезно, то для такой ОС целесообразно ввести простое ранжирование приложений по требуемому уровню обслуживания (пасьянсу — нулевой).
  • Метаслой: идеи о применении предсказания для оптимизации программирования и распределения ресурсов в ОС
    0
    Дело не в оптимизации кода, а в свойствах реализуемого алгоритма. Там есть определенная доля нераспараллеливаемой работы, которая просто неподвластна оптимизации. Если эта доля растёт с увеличением числа потоков, то на определенном этапе попытка увеличить число потоков приведёт только к замедлению работы программы. В-общем, один землекоп копает яму за час, два землекопа — за полчаса, а сто землекопов только будут мешать друг другу и проработают два часа (если вообще не передерутся).
  • Метаслой: идеи о применении предсказания для оптимизации программирования и распределения ресурсов в ОС
    0
    Если таких наборов данных — один или два, то можно и по графикам. А если их пять-десять-больше, то я предпочту что-то вроде того, что предлагается в публикации. Потому в начале и было написано про потенциально «большие данные», где подход может оправдать себя.
  • Метаслой: идеи о применении предсказания для оптимизации программирования и распределения ресурсов в ОС
    0
    Если программа будет работать только на одной конкретной ЭВМ, то, конечно, можно и эмпирически. Но если ЭВМ заранее неизвестна, то все уже не так просто. Но это даже не главное. Объём вычислений в цикле может очень сильно зависеть от входных данных, соответственно и оптимальное число потоков может от них сильно зависеть. Если входные данные постоянно меняются, то единого эмпирического оптимального числа потоков просто нет. Вот тогда и может пригодиться построенная модель.
  • Идеи о новых возможностях обычного/параллельного программирования (расширение C++)
    0
    Да, обработано и вырезано. Что же касается пересечения со спецификацией исключения, то теоретически путаницы не будет, поскольку спецификация исключений может быть: throw(), throw(...), throw(тип), а спецификация параметров принимающей процедуры: throw(тип имя [, тип имя ...]). Однако в текущей демо-версии транслятора путаница возникнуть может (я проверю, если есть — поправлю).
  • Идеи о новых возможностях обычного/параллельного программирования (расширение C++)
    0
    В данном случае throw(...) — это не указание исключений, а спецификация параметров «принимающей» процедуры при работе в топологии. Эту часть конструкции можно не писать, если список параметров «передающей» процедуры совпадает со списком параметров «принимающей» процедуры.
  • Идеи о новых возможностях обычного/параллельного программирования (расширение C++)
    0
    «Инвазивный подход» все же упрощает распараллеливание и, экономя время и силы на программирование, при грамотной реализации в компиляторе будет вполне адекватен. Что же касается повышения эффективности/управляемости путем ручного распараллеливания, то я, в общем, конечно согласен. Предложенный подход не отрицает сосуществования с такими ручными средствами, они даже приветствуются иногда (в дополнение), если требуется выжать все, что только возможно.
    Что же касается организации компилятором работы в кластере (при работе с топологиями из ПППВ), то у меня подход вполне стандартный: программа в неизменном виде исполняется на каждом узле, каждый узел внутри программы идентифицируется номером, в зависимости от номера программой выполняется тот или иной фрагмент кода. В качестве низкоуровневого интерфейса транслятор использует MPI.
    Что же касается оптимизаций в компиляторе, то сравню с OpenMP. Например, если говорить о реализации обработки дерева, то можно, конечно написать на OpenMP 3.0 рекурсивную функцию, которая будет порождать подзадачи и затем ставить барьер на ожидание их завершения. Это две директивы, при этом транслятор, скорее всего, будет генерировать для каждой из них независимый код. В предложенном подходе можно написать ПППВ, причем потребуется одна директива распараллеливания, причем компилятор работает с ПППВ/ФППВ стандартным образом, который при желании можно попытаться довести до совершенства. Поэтому мне кажется, что в случае OpenMP у транслятора меньше информации для наиболее оптимальной организации параллельной работы.
  • Идеи о новых возможностях обычного/параллельного программирования (расширение C++)
    +1
    Работоспособную (хотя и не последнюю) версию транслятора можно скачать и посмотреть на моем сайте в разделе «Программы». Она написана на Free Pascal, простовата и не очень удобна, работает из командной строки (Linux, Windows), генерирует C++-код, который при компиляции требует OpenMP, а также может (в зависимости от транслируемой программы) требовать MPI и/или OpenCL. Что же касается интересностей, то это немного порождающего программирования, некоторые полезные применения ПППВ/ФППВ при использовании статического плана, «отчуждаемый» план и еще некоторые тонкости. Подробно (хотя и несколько тяжеловесно), если захотите, можно посмотреть в книге.
  • Идеи о новых возможностях обычного/параллельного программирования (расширение C++)
    +1
    Классическое распараллеливание на общем пуле потоков, обычно, тоже требует указания одной-двух директив (как в OpenMP) или, например, обертки Вашего кода в некий класс-пул, или вызова специальных функций, иными словами, обычно требуются дополнительные «ручные» манипуляции. С этой точки зрения предлагаемый подход, как минимум, не сложнее. При этом он, думаю, более органичен (и, не исключено, потенциально более эффективно реализуем компилятором) для распараллеливания обработки таких сложных структур данных, как граф (сеть, дерево и т.д.), а еще, возможно, больших таблиц. Кроме того, да, действительно, один и тот же прием программирования (с не очень большими декларативными изменениями) используется, вообще говоря, как для обычных многоядерных ЦПУ, так и для многоядерных видеокарт — это повышает переносимость кода и облегчает гибридное распараллеливание CPU+GPU. Применение же топологий позволяет дополнительно организовать распараллеливание на кластере. Все это, в комплексе, думаю оправдывает подход в смысле распараллеливания. Что же касается последовательного программирования, то там ПППВ/ФППВ — просто еще один способ записи некоторых алгоритмов, позволяющий не заботиться, например, о явном вводе переменной-очереди. Может быть, в таком случае это уже «синтаксический сахар».