Почему-то с тех пор, как познакомился с основами функционального программирования, мне стало совершенно лень делать многие вещи на Си. Например, сейчас я пытаюсь написать сортирующую сеть, и мне совершенно лень выделять память под массив id'шников нитей, а потом выдумывать, как бы так поудобнее каждой нити передать не одно число, а пару (в POSIX Threads нити можно передать только один параметр типа void*). В то же время, я недостаточно хорошо знаю Haskell или любой другой язык (в данном случае самым удачным выбором видится Erlang), чтобы написать на нём.
Впрочем, я все равно не представляю — опять-таки, из-за недостатка знаний, — как мне синхронизировать доступ к сортируемому массиву (т.е. я не знаю, как в Haskell/Erlang/etc юзать STM или мьютексы) и как вообще его организовать в условиях чистой функциональности (глобальных переменных-то нет, да и менять свои аргументы функция не может).
В общем, печаль. Может, пора спать? :)
25 comments
recommend
bookmark
subscribe
Но ведь Си не нужен!
Си — няшка. Не слышал ни об одном императивном языке, который был бы круче старого доброго чистого Си.
Посмотри на окамль или хацкель :3
Ты прав.
А ты неправ.
Собственно, Haskell я немного (в пределах материала первых 7.68 глав RWH) знаю. Но этого мало.
Эх, была не была… Почему это не прав?
Может, потому что ты мудак?
А может, ты поищешь какие-то более обоснованные аргументы?
Я бы здесь map/reduce тупо захуячил.
Впрочем, надо сесть с карандашиком и повспоминать про эти сети.
Потому что ты сейчас имеешь геморрой с этим всем низкоуровневым говном. А на плюсцах у меня есть куча примитивов, существенно облегчающих жизнь.
По-моему, map/reduce здесь ни при чём вообще. Задача и так легко распараллеливается — просто выделяем под каждый компаратор по нити и ждём, пока все они завершатся.
Окей, нарисуй однослойную сеть, которая бы корректно сортировала.
На самом деле, при наличии даже одного упомянутого аргумента поиск остальных бессмысленен до устранения данной проблемы.
Мне не нравится ООП. Возможно, это из-за того, что я его на сравнительно малых (притом, учебных) задачах применял, но мне кажется, что оно только усложняет жизнь. А все эти примитивы наверняка потребуют от меня юзать классы и объекты.
> Мне не нравится ООП.
Это такой офигенный аргумент, что мне даже нечем возразить, кроме как намекнуть на его офигенность.
«Однослойную»? Я про эти сети только Википедию и читал, и там ни разу слово layer не используется.
Хорошо. Посмотри на картинку еще раз. Видишь, выход одного компаратора подключается на другой?
Выход*ы*. Да, вижу.
Или нет, таки выход — от компаратора к компаратору же. Таки пора спать :)
Ну, тем более. Я тут тебе почти алгоритм расписал а, оказывается, на вики все уже есть: http://en.wikipedia.org/wiki/Bitonic_sor... глянь сюда. Неплохо ложится на этакий map/reduce, вроде.
Почитал (здесь гораздо подробнее написано: http://www.iti.fh-flensburg.de/lang/algo... )
Оказалось, что я таки не совсем правильно понимал map/reduce. Теперь я, кажется, этот недочёт исправил, но теперь я не понимаю другого — чем MapReduce отличается от обыкновенной рекурсии? Что там такого Гугл особенного сделал, что аж целый фреймворк получился?
Тем, что это такой особый вид рекурсии, с двумя явно выделенными частями.
Олсо, это все описано в Кормене, я по нему в свое время ботал.
Чёрт, сколько же полезной литературы я ещё не прочёл… Спасибо за объяснения!
Это все == сортирующие сети и битоническая сортировка, в частности. Мапредьюс там едва ли есть.