При написании приложений, одной из важнейших вопросов являются потребление памяти и отзывчивость (скорость работы).

Считается, что сборщик мусора – черный ящик, работу которого нельзя предугадать.

А еще говорят, что GC в .NET практически не настраиваемый. А еще, что нельзя посмотреть исходники как классов .NET Framework, так и CLR, GC и т.п.

А я скажу как бы ни так!

В данной статье мы рассмотрим:

• структура организации размещения объектов в памяти
• CLR 4.5 Background Server GC
• правильная настройка сборщика мусора
• эффективный апгрейд приложений до .NET 4.0+
• правильное ручное управление памятью

Недавно на хабре появилась неплохая статья про вычисление N-ного числа фибоначи за O(log N) арифметических операций. Разумный вопрос, всплывший в комментариях, был: «зачем это может пригодиться на практике». Само по себе вычисление N-ого числа фибоначи может и не очень интересно, однако подход с матрицами, использованный в статье, на практике может применяться для гораздо более широкого круга задач.

В ходе этой статьи мы разберем как написать интерпретатор, который может выполнять простые операции (присвоение, сложение, вычитание и урезанное умножение) над ограниченным количеством переменных с вложенными циклами с произвольным количеством итераций за доли секунды (конечно, если промежуточные значения при вычислениях будут оставаться в разумных пределах). Например, вот такой код, поданный на вход интерпретатору:

loop 1000000000
  loop 1000000000
    loop 1000000000
      a += 1
      b += a
    end
  end
end
end

Незамедлительно выведет a = 1000000000000000000000000000, b = 500000000000000000000000000500000000000000000000000000, несмотря на то, что если бы программа выполнялась наивно, интерпретатору необходимо было бы выполнить октиллион операций.

Читая статью об устройстве на работу в ABBYY, встретил в ней упоминание задачи:

быстро – за O( log N ) арифметических операций над числами – найти N-е число Фибоначчи

Я задумался над ней и понял, что сходу в голову приходят только решения, работающие за время O(N). Однако позже решение было найдено.

Вот, задался таким вопросом… С помощью гугл транслейта и такой-то матери, родилась такая блок-схемка:



картинка кликабельна

Кому нужен сорец (в .docx): тут

Не так давно я опубликовал на хабре первую часть статьи по восстановлению расфокусированных и смазанных изображений, где описывалась теоретическая часть. Эта тема, судя по комментариям, вызвала немало интереса и я решил продолжить это направление и показать вам какие же проблемы появляются при практической реализации казалось бы простых формул.

В дополнение к этому я написал демонстрационную программу, в которой реализованы основные алгоритмы по устранению расфокусировки и смаза. Программа выложена на GitHub вместе с исходниками и дистрибутивами.

Ниже показан результат обработки реального размытого изображения (не с синтетическим размытием). Исходное изображение было получено камерой Canon 500D с объективом EF 85mm/1.8. Фокусировка была выставлена вручную, чтобы получить размытие. Как видно, текст совершенно не читается, лишь угадывается диалоговое окно Windows 7.



И вот результат обработки:



Практически весь текст читается достаточно хорошо, хотя и появились некоторые характерные искажения.

Под катом подробное описание проблем деконволюции, способов их решения, а также множество примеров и сравнений. Осторожно, много картинок!

В комментариях к предыдущему посту про иероглифы сказали, что хорошо бы иметь такую же блок-схему для кракозябр.

Итак, вуаля!


За источник информации была взята статья из вики. В блок-схеме «UTF-16 → CP 866» означает, что исходная кодировка была «UTF-16», а распозналась она как «CP 866».

Как всегда — кликабельно. Исходник в .docx: здесь.

Эксклюзивно для Хабра.



(кликабельно)

Не знаю, как вы, уважаемый читатель, а я всегда поражался контрасту между изяществом базовой идеи, заложенной в концепцию двоичных деревьев поиска, и сложностью реализации сбалансированных двоичных деревьев поиска (красно-черные деревья, АВЛ-деревья, декартовы деревья). Недавно, перелистывая в очередной раз Седжвика [1], нашел описание рандомизированных деревьев поиска (нашлась и оригинальная работа [2]) — настолько простое, что занимает оно всего треть страницы (вставка узлов, еще страница — удаление узлов). Кроме того, при ближайшем рассмотрении обнаружился дополнительный бонус в виде очень красивой реализации операции удаления узлов из дерева поиска. Далее вы найдете описание (с цветными картинками) рандомизированных деревьев поиска, реализация на С++, а также результаты небольшого авторского исследования сбалансированности описываемых деревьев.

Для начала краткий ликбез:

Last.fm — интернет-проект музыкальной тематики, основным сервисом которого является сбор информации о музыке, которую слушает пользователь, и её каталогизация в индивидуальных и общих чартах. (с) Wikipedia

Давным-давно, когда трава была зеленее, а заинтересованные индивиды IT-сообщества ещё не знали, что такое Instagram — проект Last.FM был в целом бесплатным и давал возможность слушать «радио», составленное из композиций любимых и похожих на них исполнителей без каких-либо ограничений. Затем коммерческая составляющая начала брать свое, бесплатное радио оставили только для некоторых стран, что заставило жителей стран СНГ заниматься поиском прокси либо платить 3$ в месяц за возможность использования сервиса.

Заморачиваться с прокси, понятное дело, никому не хотелось, и пользователи начали искать способы слушать радио бесплатно. Как оказалось, Last.FM фактически не закрыл доступ к возможности бесплатного прослушивания, однако официальным клиентом последней версии это было невыполнимо. Итог: часть аудитории перешла на альтернативные клиенты, часть прекратила обновлять свой старый клиент, а прочие либо заплатили, либо ушли на другие сервисы.

Так в чем же состояло изменение, которое привело к невозможности бесплатного прослушивания радио в новых версиях клиента? Попробуем в этом разобраться.

Перевод статьи Джона Скита, известного гуру языка C#, автора книги C# In Depth, сотрудника Google, человека #1 по репутации на stackoverflow.com и наконец героя Jon Skeet Facts. В этой статье Джон доступно объясняет, что представляют из себя карринг и частичное применение функции, концепции, пришедшие из мира функционального программирования. Кроме того, он подробно поясняет в чём их различие. Признаюсь, что я и сам их путал до прочтения этой статьи, поэтому мне показалось полезным сделать перевод.


Это немного странный пост, и прежде чем читать его вам, пожалуй, следует отнести себя к одной из этих групп:

• Те, кто не интересуются функциональным программированием и находят функции высшего порядка запутанными: вы можете пропустить эту статью полностью.
• Те, кто знают всё о функциональном программировании и хорошо понимают разницу между каррингом (currying) и частичным применением функции (partial function application): пожалуйста, внимательно прочтите этот пост и отпишитесь в комментариях, если найдете неточности.
• Те, кто частично знаком с функциональным программированием, и заинтересован узнать больше: отнеситесь к этому посту скептически и внимательно прочтите комментарии. Прочитайте другие статьи более опытных разработчиков для получения дополнительной информации.

В общем-то, я знаю, что некоторые люди иногда путают термины карринг и частичное применение функции — используют их взаимозаменяемо, когда этого делать не следует. Это одна из тех тем (как, например, монады), которую я до некоторой степени понимаю, и я решил, что лучшим способом удостовериться в своих знаниях будет написать об этом. Если это сделает эту тему более доступной для других разработчиков, тем лучше.

В настоящей статье я хотел бы сделать обзор популярных алгоритмов для решения задачи нахождения максимальной общей подпоследовательности или LCS (longest common sequense). Так как акцент сделан на обучении, а не на реальном использовании, в качестве языка для реализации выбран Python, что позволит сократить количество кода и сконцентрироваться на основных идеях.

Вы думали, что новые аутентичные шрифты создают дизайнеры? Может быть и так, но и программист тоже на это способен — особенно, если у него есть художественный вкус. Разработчик Дэн Сэйверс (Dan Sayers) сделал очень красивый фонт Avería, просто усреднив все шрифты, установленные на его компьютере.

Доброго времени суток. Это статья — перевод заинтересовавшего меня поста в блоге аспиранта Университета штата Нью-Йорк в Стоуни-Брук. Статья в доступной форме описывает основные концепции функционального программирования, их преимущества и недостатки. Думаю она будет полезна широкому кругу читателей, которые сомневаются, нужно ли им углубляться в мир функционального программирования или нет. Пожелания, предложения и замечания по переводу и терминологии принимаются по личной почте.

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

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

Преобразование Хафа служит для поиска на изображении фигур, заданных аналитически: прямых, окружностей и любых других, для которых вы сможете придумать уравнение с небольшим количеством параметров. О преобразовании Хафа написано немало, и данная статья не ставит цели подробно осветить все аспекты. Я лишь объясню общий принцип, останавливаясь на особенностях, мешающих его реализации на GPU «в лоб» и, конечно же, предложу решение. Те, кто знают проблемы и хотят сразу видеть решение, могут пропустить пару-тройку разделов.

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

Roman Cortes для конкурса любви 2012 js1k сделал 3D розу на javascript (canvas), используя метод Монте-Карло.

Кратко о методе Монте-Карло

Ме́тод Мо́нте-Ка́рло — общее название группы численных методов, основанных на получении большого числа реализаций стохастического (случайного) процесса, который формируется таким образом, чтобы его вероятностные характеристики совпадали с аналогичными величинами решаемой задачи. Используется для решения задач в различных областях физики, химии, математики, экономики, оптимизации, теории управления и др.

Механический дисплей из лего и Arduino, о котором я писал в начале января оказался, по-моему, довольно неплох для конструкции собранной за вечер. Однако в комментариях справедливо указали на возможности его улучшения. Заодно, читая отзывы, я узнал что такое «POV», спасибо всем откликнувшимся!

Выявленные недостатки

• Малый размер «экрана», недостаточный для написания слова «Хабрахабр»
• Монохромность
• Неравномерность шага пикселей, расчитанного простым делением времени цикла на разрешение
• Разочарование ожидавших увидеть видео хаброюзеров
• Необходимость вручную побитово кодировать изображение каждой буквы
• Общая нестабильность конструкции — «дисплей» при работе сильно раскачивается
• Холостой обратный ход планки со светодиодами. Они подсвечиваются только во время движения справа налево

За прошедшие четыре недели конструкцию удалось доработать, и вот что получилось в результате:

Работа с числами порой преподносит интересные сюрпризы. Некоторые математики делали карьеру, находя такие интересные, но в большинстве случаев бесполезные случаи.

К сожалению, большинство инструментов, которые применяются для вычислений, будут прятать результат, но если вы найдете такой, который этого (1/998001=1.002003004005006e-06) не делает, то, может, не сразу заметно, но деление 1 на 998001 дает в результате все числа от 001 до 999.

Если вам интересна такого рода математика, то 1/9801 выдаст похожий результат, последовательность чисел от 01 до 99

Можно посмотреть в WolframAlpha. Нажимайте «More digits» в блоке «Decimal approximation»:
www.wolframalpha.com/input/?i=1%2F998001
www.wolframalpha.com/input/?i=1%2F9801

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

Почему же для устранения смаза и расфокусировки практически ничего нету (unsharp mask не в счет) – может быть это в принципе невозможно? На самом деле возможно – соответствующий математический аппарат начал разрабатываться примерно 70 лет назад, но, как и для многих других алгоритмов обработки изображений, все это нашло широкое применение только в недавнее время. Вот, в качестве демонстрации вау-эффекта, пара картинок:



Я не стал использовать замученную Лену, а нашел свою фотку Венеции. Правое изображение честно получено из левого, причем без использования ухищрений типа 48-битного формата (в этом случае будет 100% восстановление исходного изображения) – слева самый обычный PNG, размытый искусственно. Результат впечатляет… но на практике не все так просто. Под катом подробный обзор теории и практические результаты.
Осторожно, много картинок в формате PNG!

Если в докомпьютерную эпоху набор текста и подготовка оригинал-макета были отдельной профессией, то ныне любой человек, установивший верстальную программу (или даже Word) способен готовить документы к печати.

В компьютерную эпоху пробелы, как самая несодержательная часть текста, часто обходят должным вниманием при подготовке изданий. Зачастую в документе присутствуют всего два вида пробелов: обыкновенный и неразрывный (в Word'е фиксированной ширины, в InDesign'е — нет). Между тем, пробелов существует около двух десятков, и некоторые из них очень пригождаются в русской типографике.

Обычный растяжимый пробел, который ставится почти везде, работает аналогично механизму линотипа: при выключке по формату полосы (в компьютерных терминах выравнивание по ширине) пробелы, выполненные в виде клинышков, опускались между словами до тех пор, пока строка не занимала всю отведённую ширину.

Неразрывный пробел ничем не отличается по ширине и растяжению от обычного пробела, но не может быть заменён переводом строки. Неразрывные пробелы необходимо ставить после почти всех однобуквенных слов (а, в, и, к, о, с, у, я) и до «б» и «ж», иногда после двухбуквенных слов в начале предложения, между числом и единицами измерений (100 грамм, 5 м), между частями названия (InDesign 5.5).

Этот список может поначалу казаться неполным, потому что в остальных случаях, где мы привыкли ставить неразрывный пробел, ставятся пробельные символы другой величины.

В прошлых двух статьях мы познакомились с тем, как работают тени в CSS3: box-shadow и text-shadow. Сегодня, продолжая последнюю тему, мы посмотрим на еще несколько красивых примеров использования теней для текста для достижения интересных эффектов.