Да, интересное решение, я даже не думал в эту сторону. А правда же, да, сам-то слушатель знает, какие события он умеет обрабатывать.
Хотя наверное понятно, почему не думал, в жизни у методов aChanged(), bChanged() разные сигнатуры были, но как реализовать вашу идею понятно и в этом случае.
А наблюдаемый класс, знает только о каком-то слушателе реализующий интерфейс AListener или DListener. В методах же aChanged() и bChanged() используется только один из «трансляторов».
В статье я явно не написал, что есть множество слушателей, которые взаимодействуют с наблюдателями, реализующими интерфейс AListener, а есть множество тех, которые взаимодействуют с наблюдателями, реализующими интерфейс DListener. И заставить вторые работать со слушателями реализующими только AListener не удастся, чего и добивались.
Несколько странное у вас определение гомоморфизма. И я не понял, что именно нарушает hom(+, one, 0).
А про изоморфизм скажу следующее: грубо говоря, раз два объекта изоморфны, то мы в можем не различать их и выбирать наиболее удобное для нас представление.
По мне так очень читабельно. После того как реализован редьюсер (а он реализуется в несколько строчек), произведение элементов массива записывается в виде:
reducer_prod prod;
cilk_for (int i = 0; i < n; ++i) {
prod *= a[i];
}
Просто для произведения нет стандартного редьюсера, но находить произведения элементов массивов редко нужно. Для большинства частых практических случаев стандартные редьюсеры уже есть.
Много лет назад меня посещала идея использовать подобные перчатки в качестве составной части тренажёра печати на клавиатуре. Цель же тренажёра заключается в том, чтобы нужными пальцами нажимать на нужные клавиши. Но программно это же никак не отследишь. А с помощью подобных перчаток понятно, каким пальцем произведено нажатие. Всё, теперь программная часть может как-то реагировать, на то, что пользователь нажал клавишу не тем пальцем.
Группа — это моноид, в которой каждый элемент обратим. Так что любая группа является моноидом, но не каждый моноид — группа. Например множество натуральных чисел с нулём снабжённое операцией сложения — моноид, но не группа, так как 1 не имеет обратного в силу того, что -1 не является ни натуральным, ни нулём.
Но процессоров-то всего p. Поэтому одновременно можно вычислять только p свёрток. Конечно, если у нас неограниченное число процессоров, то такую асимптотику получим, да.
Например в том, что в OpenMP с помощью директивы reduction можно распараллеливать вычисления только для скалярных типов и только для фиксированного набора операций +, *, -, &, |, ^, &&, ||, min и max.
Да я как-то тоже, пока не приступил к написанию скрипта. Как-то сами собой синие клетки назвались морем, а серые сушей) А потом оказалось, что и в других источниках так.
Хотя наверное понятно, почему не думал, в жизни у методов aChanged(), bChanged() разные сигнатуры были, но как реализовать вашу идею понятно и в этом случае.
В статье я явно не написал, что есть множество слушателей, которые взаимодействуют с наблюдателями, реализующими интерфейс AListener, а есть множество тех, которые взаимодействуют с наблюдателями, реализующими интерфейс DListener. И заставить вторые работать со слушателями реализующими только AListener не удастся, чего и добивались.
А как бы вы сделали?
А про изоморфизм скажу следующее: грубо говоря, раз два объекта изоморфны, то мы в можем не различать их и выбирать наиболее удобное для нас представление.
Просто для произведения нет стандартного редьюсера, но находить произведения элементов массивов редко нужно. Для большинства частых практических случаев стандартные редьюсеры уже есть.
bash -i ./xonix.sh