to SMAX
У одних коллектив это
0.3 * 0.3 * 0.3 ..... = 0
У других
0.3 + 0.3 + 0.3 ...../n = 0.3
У третьих
0.3 + 0.3 + 0.3 ..... = 0.3 * n 
Так что с килограммами и тоннами мозгов осторожнее надо быть

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

Только вчера я удалил с дискеты последнююсвою копию RTK-micro, а сегодня прочитал в теме, что ее еще помнят. Мне тоже было приятно. Мне повезло, что я имел полный пакет Р-технологии для ЕС-ки и внедрил ее на своем ВЦ. Потом очень долго программировал с использованием RTK-micro, даже несколько лет преподавал ее в курсе программирования. Это действительно был уникальный комплекс, но я больше нигде не встречался с ее развитием. Ведь это же была попытка уйти от кодирования и перейти на алгоритмический уровень Р-схем! Мне она здорово помогала. Если у кого есть информация про нее, просьба поделиться (по указанной ссылке я не попал).

to С.Тарасов (146)
>Вот теперь, с примерами, понятно.<
:)
>Мы могли унифицировать понятие параметра (ресурса), поскольку в нашем фреймворке все объекты были потомками одного корневого класса. Т.о. можно было представить набор параметров, как вектор из ObjectID.<
По-моему, Вы перепутали термины. Ресурсы/параметры - это зависимая часть (QTY из примера), а набор измерений (детерминант) на самом деле можно назвать вектором.

>выползла техническая проблема: обновление агрегируемого значения ФЗ по одному и тому же набору ресурсов происходит только при полной блокировке остальных "писателей"<
Мне кажется, что теперь с "новым пониманием" Вы по-другому прочтете мою статью о классах ФЗ. Насколько я помню, проблема блокировок там тоже кратко рассмотрена.

ДМ
Вот теперь, с примерами, понятно. У нас была реализована подобная схема для накопительных ФЗ (они использовались, как абстрактные регистры, то есть регистры для учета чего-то (количества, суммы) в зависимости от других параметров (ресурсов, по Вашей терминологии)). Мы могли унифицировать понятие параметра (ресурса), поскольку в нашем фреймворке все объекты были потомками одного корневого класса. Т.о. можно было представить набор параметров, как вектор из ObjectID.
Кстати, отвлеаясь от темы, при моделировании такой схемы средствами РСУБД выползла техническая проблема: обновление агрегируемого значения ФЗ по одному и тому же набору ресурсов происходит только при полной блокировке остальных "писателей", причем вследствии того, что один из параметров накопителя всегда временной (необязательно дата, может быть просто номер учетного периода), блокируются все логические записи (то же, что физическая запись в таблице, если моделируем схему одной таблицей) от самого начала и до того момента времени, который поступает значением этого параметра в порции данных для обновления.
Все-таки я не могу отделаться от ощущения, что это близко (ну оооочень) к ФП и в частности к Prolog :-)
Попробуем перейти к классической математической записи:
Y=F(X1,...,Xn), где Xi - параметр (ресурс), Y-значение ФЗ или результат.
В этом случае рассматриваеваемая Вами процедурная ФЗ
{Обувная фабрика, Валенки, Июль} -> {ВывестиСтроку("Подозрительная покупка!")}
будет иметь вид:
DATABASE
/* структуры для хранения ФЗ */
товар(string, string).
сезон(string, string)
CLASES
товар("валенки", "фабрика им. Комсомола")
сезон("зима", "валенки")
PREDICATES
покупка=Ф1(товар, дата).
поставщик=Ф2(товар).
сезон=Ф3(дата).  & встроенная функция возвращает 4 значения: "зима", "весна", "лето" и "осень"
сезон=Ф4(товар).
CLAUSES
совпадение_сезонов(А, В) :- сезон(А) = сезон(В).
подозрительная_покупка(А, В) :- совпадение_сезонов(А, В).
GOALS
подозрительная_покупка("валенки", "12.07.2001")
программа выводит утвердительный результат

Именно по этому я вместо "наследование" (inheritance) предпочитаю говорить "обобщение" (generalization)

to Evgeny (131)
>В целях упрятывания IF-ов и CASE-ов возможно использование инструментария таблиц решений.<
Спасибо за подсказку. Действительно, Таблицы Решений похожи на предложенные ПФЗ. Но все же упор в ТР (а также в деревьях решений), если я правильно понимаю, сделан на бинарность оператора "Если" и на комбинаторику входных условий. ПФЗ же выступает просто как некое расширение класса ФЗ применительно к процедурам (минимизация сущностей). То есть, к примеру, вполне можно представить некий JOIN разных ПФЗ по какому-либо измерению, что для терминологии ТР выглядит, наверное, довольно странно. Правда, со ссылкой ресурса ПФЗ на другую ПФЗ я переборщил. Для того, чтобы оставаться в рамках реляционных требований для вложенных условий можно использовать стандартный механизм подчинения одной ФЗ другой (отношение 1:m).

to Сергей Тарасов (132)
Чтобы понять друг друга, давайте еще раз попробуем отделить мух от котлет. Понятие ФЗ широко используется в теории БД (см. например, К.Дж.Дейт "Введение в системы БД"). Возможно, есть еще другие определения ФЗ, но мне они неизвестны. Суть простейшей ФЗ:
пусть Поставщик (#S), Товар (#P), Месяц (#M) однозначно определяют количество поставленного в указанный период товара QTY, тогда такое отношение можно представить в виде:
{#S, #P, #M} -> {QTY}.
Здесь слева в фигурных скобках - детерминант ФЗ с набором измерений, справа - зависимая часть. В теории хранилищ данных зависимую часть именуют параметром(ами). Мне больше нравится называть зависимую часть ресурсом. Если ресурс является агрегируемым (накопительным), то ФЗ действительно становится регистром. По определению ФЗ, в таблице, хранящей значения ФЗ, не может быть кортежей с одинаковым значением детерминанта. Вот и все определение.
"Процедурная ФЗ" - заменяем ресурс на набор операторов для заданного набора измерений. Например, {Обувная фабрика, Валенки, Июль} -> {ВывестиСтроку("Подозрительная покупка!")}.

День добрый, Сергей Тарасов,

"Вот мы с тобой, я твой предок, ты мой потомок, что в этом
случае будет инкапсуляция или наследование? Это ж что получается, если я гвозди хорошо забиваю, то и тебе такой 'метод'
(прикалывается) перейдет?"

Нет, зачем же, я, как потомок скажу просто inherited...И нехай тот,
кто умеет гвозди забивать, их и забивает :-)

С уважением,

Hi, All !

2 Сергей Тарасов

Конечные автоматы
http://www.softcraft.ru/
Р-технология
http://www.netman.ts.kiev.ua/VisLang/vislang.html
Много полезного
http://www.forth.org.ru/

2 Evgeny
Кстати:
Это помогло мне утвердиться в мысли, что нет ООП в чистом виде - есть ООП надстройки и реализации ООП.

С уважением

Кажется, что-то нашел... И кажется, почти вспомнил 1-2 курсы ВУЗа :-)
http://www.csu.ac.ru/~mzym/courses/progtech/speeches/Rtech_Elin_1999.zip
Вот тут форум
http://www.softcraft.ru/topic.shtml?key=3
на нем есть и другие ссылки.
Но мне там очень понравился раасказ одного прораммиста о беседе со своим отцом - доктором наук, которому он рассказывает про ООП. Вот абзац:
"...батя быстро смекнул
в чем дело и спрашивает: 'Что ж у вас, у программистов слова с делом-то расходятся. Слова вроде правильные применяете,
предок, потомок, наследование свойств и пр., а на деле то что получается. Вот мы с тобой, я твой предок, ты мой потомок, что в этом
случае будет инкапсуляция или наследование? Это ж что получается, если я гвозди хорошо забиваю, то и тебе такой 'метод'
(прикалывается) перейдет? (Я так несколько начинаю тормозить, поскольку привык к тому, что в книжках ООП и 'отношения
родственников' почти всегда вместе упоминаются) Почему вы (это он так про программистов, так, с высока :)) ) природу-то ломаете?..."