Scala rule-based inference engine

[@knott]

Почему у фактов такой тяжелый синтаксис?

when
   true
then
   minsavings = 5000 * dependents

Наверное было бы здорово писать сразу:

fact
  minsavings = 5000 * dependents

[@kosiakk]

Вот что было бы здорово — так это использовать синтаксис Scala прямо для записи правил.
Благо компилятор там мощный, а сейчас даже макросы есть. Так что нет наких причин тратить время на свой собственный синтаксис.

Там даже SQL вполне естественно выглялит: circumflex.ru/projects/orm/index.html

[@GoodGreenTea]

Если честно подумал об этом же только вчера :) Первая мысль — можно ли будет создать правила и подсунуть движку динамически? Чтобы они динамически скомпилировались в байт код. Вобщем, можно будет поисследовать этот вопрос. Вот нашел www.scala-lang.org/node/12073

[@StrangeAttractor]

C SQL в Scala я намучался. Circumflex, правда, не пробовал, пробовал более мэйнстримные фрэймворки: ScalaQuery/Slick и Squeryl. Во-первых гибкость формирования запросов всё-равно сильно снижается (я, например, так и не нашёл как сделать INSERT IGNORE в MySQL), во-вторых ScalaQuery/Slick — это такое немыслимое нагромождение имплиситов, что «х-й проссышь» что к чему и где. В результате, после многократных проб и попыток, раскуривания исходников самих библиотек и примеров, вернулся к голому JDBC и SQL-запросам в строках.

[@GoodGreenTea]

Да… Можно добавить. Как синтаксический сахар.

[@GoodGreenTea]

Добавил… Спасибо за идею :)

[@kosiakk]

Здорово! Получается столь любимый фантастами мир-multiverse, где все (квантовые) исходы существуют, просто в параллельных мирах.

[@sap1ens]

Спасибо за статью! Сейчас в компании как раз интересуемся возможностью заменить текущий тяжеловесный набор Drools-правил на Scala-based решение.

[@kingu]

А расскажите — какие проблемы вы решаете данным способом?

[@GoodGreenTea]

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

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

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

[@kosiakk]

А в чём принципиальные отличия от dyna.org?

Там тоже декларативное «логическое» программирование в любых типах (значения могут быть не только boolean) и есть агрегация переменных (схлопывание при помощи функции-агрегатора). Та система мне безумно понравилась, жаль последняя версия пока не опубликована

[@GoodGreenTea]

Бегло посмотрел dyna… Вообще различия довольно существенные. Например у меня нельзя сделать нечто такое www.dyna.org/wiki/index.php?title=Shortest_path_in_a_graph. Т.е. выражаясь простым языком в fusie нельзя декларативно обьявлять функцию (с возможно разными обьявлениями для разных наборов аргументов). В то же время в dyna я не увидел вывода с множеством вероятных исходов и подсчетом вероятностей для каждого. Кстати понравился оператор min=, который из множества исходов справа выбирает в итоге минимальный. Возможно добавлю такой же.

[@kosiakk]

min это лишь один из аггрегаторов. По-сути, там может стоять что угодно — max, последнее значение (пишется := ), mean, sum и т.д.
Т.е. если в каком-то из значений автор хранит вероятность (-1… +1), то sum как раз и даёт итоговую вероятность по всем посчитанным переменным такого типа!

[@javax]

А есть ли Rules Engines которые умеют работать с partial data? Т.е. часть свойств объектов могут быть неизвестны и он скажет — true, false, или "не хватает данных"?