В этой статье вы… наконец, поймёте саму суть квантовых вычислений.
Как умножать матрицы с помощью Haskell, понять из статьи можно, но в ней так и не объяснено, почему и как этот самый алгоритм Дойча работает (и зачем нужно преобразование Адамара, например).
Рискую высказать непопулярное мнение, но, честно говоря, совершенно не понимаю смысла всего этого упражнения. На мой взгляд, Haskell здесь притянут за уши: зачем городить функциональное программирование, если можно все это гораздо нагляднее записать в виде традиционных математических формул (на том же LaTex'е, например).
Ведь практического смысла в запуске этой программы на Haskell нет никакого, разве что проверить корректность этого «игрушечного» алгоритма. Если действительно хочется поумножать матрицы, то куда проще использовать MATLAB (или GNU Octave): там различные матричные произведения ялвяются частью языка, и не надо писать никаких велосипедов.
Более того, в статье скорее смесь Shadow Mapping и Shadow Volumes (aka Stencil Shadows), поскольку в итоге явно рисуются освещенные области в виде геометрии.
Надо только добавить, что «программирование» здесь — синоним слова «оптимизация» (то есть как «линейное программирование», а не «функциональное программирование»).
Можно, например, с хорошей точностью приблизить каждую окружность выпуклым многоугольником и применить готовый алгоритм пересечения выпуклых многоугольников. Надо только заметить, что пересечение двух выпуклых многоугольников — снова выпуклый многоугольник.
Можно и вот так: нетрудно заметить, что пересечение нескольких кругов будет представлять собой фигуру, граница которой будет состоять из кусков окружностей. Прямо как многоугольник, только вместо прямых ребер — дуги. То есть, можно придумать алгоритм, похожий на алгоритм пересечения многоугольников, но по-другому работающий с «ребрами». Затем уже полученную фигуру приблизить многоугольником и вычислить площадь. Точность будет лучше, но и реализация сложнее.
Попробуйте электромагнитный клапан омывателя для ВАЗ-2108, должен неплохо справляться. Стоит рублей 150, потребляет всего 12В/420мА. Можно, думаю, включать через мощный npn-транзистор, не заморачиваясь с mosfet или реле.
Скажите пожалуйста, а это общепринятый способ установки выводных резисторов, или Ваше изобретение? Я имею в виду то, что они стоят вертикально, а не горизонтально.
Есть интересный open-source проект по созданию современного кросс-платформенного клона игры — openxcom.org/. Для установки нужны данные из оригинальной игры. Полгода назад играл в него: все довольно неплохо работало, хотя отправил им тогда один патч. Игровая механика местами отличась мелкими деталями, но в целом дух игры был полностью сохранен. Финальная битва на Цидонии тогда еще не была реализована. Теперь же, судя по новостям, с выходом версии 0.9 игру стало возможно пройти до конца, и вообще проект недалек от законченного состояния.
CMake генерирует Makefile. С общепризнанными проблемами make можно ознакомиться по ссылкам в начале этой статьи: habrahabr.ru/post/144127/ (статья про QBS).
Я в курсе проблем make, спасибо. У любой системы сборки есть проблемы, и идеальной системы никогда не будет. Или вы думаете, что переписав все с нуля, у вас таковая получится? Максимализм в сфере разработки ПО обычно не приводит к положительным результатам.
Игнорирование было про 1 342 копипасты криптографических алгоритмов, а цитату я привёл в тему изолированных пакетов. Раз нам пофиг на место на диске, то можно было бы сделать как в OS X — изолированные пакеты со своими копиями библиотек.
Вот только не надо бросаться из крайности в крайность.
Про 1342 копипасты криптоалгоритмов: наверняка речь про какие-нибудь простые хеш-функции. Реализация MD5 или SHA256 занимает около сотни строк, и линковаться с отдельной динамической библиотекой только ради того, чтобы уметь вычислять хеш, не очень целесообразно. И вряд ли вам когда-либо понадобится обновить версию такой библиотеки — MD5 он и есть MD5, нечего там обновлять.
Согласитесь, есть разница между копированием себе в проект 100-строчной функции, вычисляющей MD5-хеш, и включением в пакет своей версии библиотеки Gtk3. Никто не предлагает делать последнее.
Треть — не такие уж и большие накладные расходы. Веб-браузер — действительно очень сложная система, и на мой взгляд, такой длинный список зависимостей вполне оправдан.
Любая система — в той или иной мере костыль. Autotools — не самый ужасный костыль из существующих, если разобраться, и не такой уж и «бред». И почему вы говорите, что никто не решится исправить? Существуют альтернативные системы сборки (cmake и прочие), и вполне хорошо себя чувствуют.
Если бы подобное игнорирование методологии повторного использования...
Не понимаю, где здесь игнорирование методологии повторного использования?
Причем здесь вообще autotools? Разве не поколение этого самого «собора» их написало?
И что плохого в том, что firefox требует libtiff? Он же не напрямую требует, а через цепочку типа firefox -> gtk -> libtiff. Места на жестком диске нынче всем хватает, так почему бы не установить все пакеты с максимальной функциональностью? То, что автор собирает всю систему из исходников вместо бинарных пакетов, — его личные проблемы.
Как умножать матрицы с помощью Haskell, понять из статьи можно, но в ней так и не объяснено, почему и как этот самый алгоритм Дойча работает (и зачем нужно преобразование Адамара, например).
Рискую высказать непопулярное мнение, но, честно говоря, совершенно не понимаю смысла всего этого упражнения. На мой взгляд, Haskell здесь притянут за уши: зачем городить функциональное программирование, если можно все это гораздо нагляднее записать в виде традиционных математических формул (на том же LaTex'е, например).
Ведь практического смысла в запуске этой программы на Haskell нет никакого, разве что проверить корректность этого «игрушечного» алгоритма. Если действительно хочется поумножать матрицы, то куда проще использовать MATLAB (или GNU Octave): там различные матричные произведения ялвяются частью языка, и не надо писать никаких велосипедов.
Можно и вот так: нетрудно заметить, что пересечение нескольких кругов будет представлять собой фигуру, граница которой будет состоять из кусков окружностей. Прямо как многоугольник, только вместо прямых ребер — дуги. То есть, можно придумать алгоритм, похожий на алгоритм пересечения многоугольников, но по-другому работающий с «ребрами». Затем уже полученную фигуру приблизить многоугольником и вычислить площадь. Точность будет лучше, но и реализация сложнее.
Я в курсе проблем make, спасибо. У любой системы сборки есть проблемы, и идеальной системы никогда не будет. Или вы думаете, что переписав все с нуля, у вас таковая получится? Максимализм в сфере разработки ПО обычно не приводит к положительным результатам.
Вот только не надо бросаться из крайности в крайность.
Про 1342 копипасты криптоалгоритмов: наверняка речь про какие-нибудь простые хеш-функции. Реализация MD5 или SHA256 занимает около сотни строк, и линковаться с отдельной динамической библиотекой только ради того, чтобы уметь вычислять хеш, не очень целесообразно. И вряд ли вам когда-либо понадобится обновить версию такой библиотеки — MD5 он и есть MD5, нечего там обновлять.
Согласитесь, есть разница между копированием себе в проект 100-строчной функции, вычисляющей MD5-хеш, и включением в пакет своей версии библиотеки Gtk3. Никто не предлагает делать последнее.
Не понимаю, где здесь игнорирование методологии повторного использования?
И что плохого в том, что firefox требует libtiff? Он же не напрямую требует, а через цепочку типа firefox -> gtk -> libtiff. Места на жестком диске нынче всем хватает, так почему бы не установить все пакеты с максимальной функциональностью? То, что автор собирает всю систему из исходников вместо бинарных пакетов, — его личные проблемы.