Рисунок еще раз переделывать уже не буду, т.к. это всего лишь иллюстрация принципа. А вообще вы правы, и дело тут даже не в понятности. В dataflow системах стремятся избегать узлов с некоммутативными входами, так как появляется задача научить систему отличать «левый» операнд от «правого»: добавляются лишние поля в контекст, усложняется устройство сопоставления… Зачем нам лишние проблемы, проще заменить вычитание умножением на (-1) и сложением.

упс, читал невнимательно, про мышку у вас как раз написано.

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

Активность пользователя как раз часто и используют для генерации сида для ГСЧ. Например, TrueCrypt просит случайным образом подвигать мышкой в специальном окне минуту-другую.

Исправлено. Для некоммутативных узлов первый операнд слева, а второй — справа.

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

Думаю, далеко не каждый алгоритм обратим. Пример: на входе два простых числа, на выходе — их произведение. А обратно факторизовать результат уже гораздо сложнее.

Можно и так, просто хотелось проиллюстрировать возможность использования рекурсии в SISAL. Добавлю-ка ваш вариант в статью.

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

Абсолютно верно!

Там есть элементы dataflow, но также много черт controlflow-архитектуры, например, адресуемая память. По устройству GPU ближе к векторным процессорам. А ПЛИС там и рядом нет.

Может быть, удастся избежать еще большего количества шишек, если посмотреть на уже существующие программные реализации? Например, RiDE или ParalleX.

Dataflow-системы часто и реализуют на ПЛИСах, во второй части попробую этот вопрос осветить

Ага, прочел ваш пост. Странно, что не находил его в процессе подготовки статьи. Немножко сумбурно, но кратко и по делу :)

Лично — нет, а работы его читал

Их очень сложно сравнивать, поскольку одни задачи хорошо идут на dataflow и плохо на controlflow, а другие — наоборот. В своих статьях разработчики стремятся выбрать тесты, которые по максимуму используют преимущества их системы. Получаются вот такие красивые, но малообъективные картинки:

(Взято отсюда)

Два вопроса:
1) Пишет ли логгер третью координату, то есть высоту?
2) Каков минимальный возможный интервал между записями?

На уровне стандарта ZigBee поддерживает шифрование AES-128, протоколы обмена ключами (SKKE) и списки контроля доступа (ACL). Никто не мешает использовать свои протоколы шифрования поверх ZigBee, если встроенных недостаточно.

Сиськи все-таки подоспели за полчаса до конца пятницы! Ура!

<КапитанОчевидностьMode>

Капча должна быть легкой для людей и сложной для роботов.

</КапитанОчевидностьMode>

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

Не так давно был топик про дешевые АРМы.