DRAKON.SU

Это не алгоритм и не правило. Это летопись

В быту можно руководствоваться такими определениями:

Алгоритм - это конкретно расписанный порядок действий для достижения результата.

Правило - это может быть отдельная, ни к чему не привязанная директивная информация. Например, "входной билет стоит 100 руб, пенсионерам и школьникам 50% скидка".
Часто в правило входит и описание последствий при отклонении от правила.
Правило может быть конкретизировано почти до алгоритма (правила оказания первой помощи пострадавшему, например).

И, повторю, ни то, ни другое не применимо к уже свершившейся последовательности событий.
В результате анализа произошедшего можно сравнивать эти события с алгоритмом действий, который предписывают правила (если есть таковые), но сами события - это всего лишь события.

А из чего и как получаются алгоритмы и правила?
Вот понятно, что есть "летопись".
Мы должны что-то сделать, чтобы получить из неё правила или алгоритмы?
А что делать-то?

Главный вопрос: зачем?
Я не понимаю вашу задачу.

В большинстве случаев человеческой деятельности правила и особенно алгоритмы разрабатываются заранее, а не постфактум.
Разве что правила безопасности вроде ПДД "пишутся кровью".

Ещё не знаем о чём, но уже знаем в каком порядке?
Что-то сомневаюсь.
Как-то иначе процесс получения нового алгоритма себе представлял.
Предполагал:
1. Собираются результаты опытов.
2. Выявляется закономерности.
3. Из закономерностей выводятся предположения о правилах или алгоритмах (не могу всё-таки понять кто есть кто).
Если проще, то:
1. Взяли летопись.
2. Выявили: что с чем связано.
3. Выявленные связи выстроили в цепочку действий, которые могут происходить не только в данном случае, но и в других случаях, которые чем-то (чем?) похожи на летопись.
И вот эта цепочка действий - она алгоритм или правило?

В моём распоряжении много маленьких летописей (судебная практика, бухгалтерские ситуации). Как из них (по возможности автоматически) вытащить правила или алгоритмы?
Ведь эти летописи - частное проявление каких-то более общих алгоритмов.
Летописи - вариант хода выполнения более общей программы.
Как восстановить программу по наблюдению результатов её выполнения.
Пусть восстановление не будет сразу полным. Пусть оно идёт постепенно, по мере сбора летописей.

Ну а я о чём и говорю вам с самого начала: вы ставите телегу впереди лошади.
Мы здесь говорим о программировании, а вы - об анализе. Для анализа такой инструмент не очень-то подходит.

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

Правила - совсем другое. Это в том числе и крупицы опыта. Например, "пельмени следует класть в кипяток, иначе они совсем разварятся".
Однако правила тоже зачастую формируются изначально. Вот, к примеру, я создаю блог и пишу правила: "мат запрещается, нарушители уходят в бан".

Правила - набор отдельных требований. Их в деятельности может быть миллион, и они могут даже противоречить друг другу.
Алгоритм - формализованное описание цельного процесса (деятельности). Он предназначен для того, чтобы его кто-то исполнял и получал нужный результат.
К анализу всё это имеет мало отношения.

А юридическая практика (да и бухгалтерия в известной мере) является как раз набором правил. Которыми, как заплатками, в течение веков пытаются покрыть практику, но безуспешно. Всегда найдётся какой-нибудь способ эти правила обойти. Потому что создавали их не систематически, не как законченное произведение, не как программу для выполнения.

Ваша попытка найти там "глубинный алгоритм" представляется потому совершенно неадекватной.
В лучшем случае вы можете выстроить всю систему заново, но поднять что-то из уже существующего (тем более автоматически) - утопия. Хотя делать это необходимо (потому что законы кривые и их надо исправлять). Но не через алгоритм. А через математическую полноту анализа, например.

Alexey_Donskoy, приведите, пожалуйста, пример аналоговой программы.

Теперь понятно.


На эту тему можно долго спорить, но сейчас это неинтересно.


Скорее не "глубинный", а "верховный". Для конкретной темы.
Практика она такая: есть статья какого-нибудь Кодекса (обычно часть, пункт или абзац), есть варианты применения этой статьи. И мой интерес: выстроить из этих вариантов приемлемую схему. Чтобы было понятно чего и куда крутить при попадании под эту статью. Статья - уже алгоритм. Но очень общий. А набор примеров - это в том числе и определение границ применения статьи (алгоритма). Поэтому с ними и приходится возиться, а не делать схемы из Кодекса (хотя это тоже полезно).


Выстраивать Законы заново - это не моя компетенция. Хотя дело, наверное, любопытное.
Через алгоритмы (с использованием Дракона и ИС Дракона), по-моему будет нагляднее.
А что такое: "математическая полнота анализа"?

К сожалению, нет.
В статье есть перечисление отдельных случаев, а не порядок действий...

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

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

Ну тогда всё.
Это уже из серии "Как всех сделать счастливыми."

Я бы больше чем инлайн функция не дал бы
Не удержался.

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


Где, какая инлайн-функция? Здесь программа, которая непосредственно набирается на наборном поле АВМ.
Вы, конечно, можете сделать аналог этой программы в цифровом (дискретном) виде, но это будет уже ДРУГОЙ метод решения и другая программа по сути.

Человек может выполнить эту "программу"?

ИМХО, эта программа не предназначена для исполнителя-человека.

Исполнитель есть, программа есть - что не так? Причём тут человек?

Кстати, выше упоминались попытки расширить понятие алгоритма - как раз для данного случая речь шла об "аналоговом алгоритме". На мой взгляд, это лишнее. Достаточно признать, что программа в данном случае неалгоритмическая.

А кстати, чего это прога делает-то ?

Решает дифур 1 порядка (интегратор, охваченный отрицательной обратной связью, есть инерционное звено):

Она ж не решает, она просто знает ответ.

Интересно, чем же это тогда десятки лет занимались на аналоговой технике? И зачем её вообще изобрели?

Кто изобрел взаимодействие зарядов? Боженька? Или Кулон?