Всем привет. Недавно меня тоже настигла переломная веха студенческой жизни — бакалаврская дипломная работа. Среди многих формальных деталей этого замечательного явления особо заметным стоит нормоконтроль. Нет, я понимаю и всячески поддерживаю, что стандарты необходимы, в том числе стандарты на оформление академического текста. Просто наши стандарты, в отличие от западных, достаточно идиотичны. Они не экономят ни чернила, ни бумагу, они не упрощают поиск литературы по номенклатуре, а усложняют чтение названия. Не говоря уже о том, что текст стандарта спроектирован и описан людьми, работающими в редакторе Microsoft Word. Опять-таки, я не имею ничего против Word, это мощнейшая система. Но технический текст в нем набирать неудобно, и по гибкости он во много раз проигрывает бессмертному творению Дональда Кнута — LaTeX.

Итак, мое написание диплома началось с того, что я потратил 4 часа на настройку преамбулы под нормы украинского стандарта оформления ДСТУ 3008-95. Насколько мне известно, он почти полностью соответствует русскому ГОСТу. Я знал, что существуют готовые решения (например, disser), но после пары проб предпочел настроить каждую деталь самостоятельно. Для тренировки. Тренировка удалась — я узнал бездну новых вещей о LaTeX, этого монстра невозможно выучить полностью :-)

Под катом я полностью опишу процесс настройки каждой конкретной детали и использование их при написании, а также разные мелочи, упрощающие написание диплома еще больше. Сразу предупреждаю: где-то мои решения могут показаться костылями. Где-то они не слишком универсальны. Я это знаю, понимаю, принимаю и приветствую критику и предложения в комментариях ;-)

– А ларчик просто открывался.
И.А. Крылов

О чём эта статья

В настоящей работе описываются способы автоматической организации нумерованных объектов при написании статей, рефератов, докладов, диссертаций и пр. При написании подобного рода материалов неизбежно возникает необходимость нумеровать те или иные объекты, например, формулы или пункты в списке используемой литературы. При этом многие авторы пользуются при написании текстовым редактором Microsoft Word.
В случае тривиальной «ручной» организации, при которой каждый номер прописывается непосредственно руками (обычно, в самом конце, когда текст полностью готов), автор работы может ошибиться в каком-либо номере, и все дальнейшие номера окажутся неверными. Более того, после рецензии те или иные части работы могут быть вставлены в текст или убраны из него. Последнее, зачастую, требует полной перенумерации объектов в документе. Таким образом, цель настоящей статьи состоит в доведении до читателя способов автоматической организации нумерации объектов, позволяющих избежать вышеописанные ситуации.
Предупреждение: в данную статью вошли лишь те приёмы, с которыми автор столкнулся при написании кандидатской диссертации. Описываемые способы организации нумерованных объектов не претендуют на единственность, полноту и оптимальность. Имеются другие интересные способы, например, в TeX. Несомненно, читатель сможет найти и иные способы достижения сформулированной цели. В любом случае, ознакомиться с подходами автора (хотя бы на досуге) следует любому заинтересованному читателю.

Основы работы с полями MS Word

В данном разделе описываются основные поля текстового редактора MS Word, необходимые для организации списков и ссылок на них, а также методы работы с ними.
Поле MS Word – это объект, принимающий то или иное значение в зависимости от ключевых слов и параметров этого поля. Для вставки поля в текст необходимо нажать сочетание клавиш Ctrl + F9 или выбрать соответствующее меню на ленте.

После вставки поля в тексте появятся серые фигурные скобки.

Продолжение по ссылкам: часть II и часть III.

На PDC2010 Хейсберг объявил, что следующая версия C# будет поддерживать примитивы для удобной организации асинхронных вычислений, кроме анонса была представлена CTP версия расширения для студии (скачать), которая позволяет попробовать улучшенное асинхронное программирование уже сейчас.

Улучшение создано, чтобы облегчить комбинацию асинхронных операций, а так же для того, чтобы асинхронных код выглядел максимально приближенно к синхронному. Учитывая, что Silverlight версия .NET Framework содержит только асинхронную модель для работы с сетью, данное улучшение очень уместно.

Не смотря на то, что упрошенное асинхронное программирование является нововведением в C#, сам подход нельзя назвать инновационным, так как реализация async на основе монад есть в Haskell, F# и Nemerle. На самом деле поддержка языком монад позволяет реализовать даже большее, поэтому я был немного удивлен, когда посмотрел презентацию Хейсберга и понял, что в язык был встроен только частный случай.

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

Продолжение: часть III.

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

Тестовым полигоном будет пример DiningPhilosophers, который идет вместе с расширением для асинхронного программирования. Это программа — визуализация знаменитой задачи Дейкстры об обедающих философах (ссылка). Прежде, чем читать дальше, лучше ознакомиться с условиями задачи.

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

Доброго времени суток!
Model-View-Presenter — довольно известный шаблон проектирования. С первого взгляда все выглядит просто: есть Модель (Model), которая содержит всю бизнес-логику экрана; Вид/Представление (View), который знает, как отобразить те или иные данные; Представитель (Presenter), который является связующий звеном — реагирует на действия пользователя во View, изменяя Model, и наоборот.
Сложность начинается, когда количество форм в проекте становится более одной.
В данной статье рассматривается:
— немножко теории;
— общие проблемы реализации MVP (а именно Passive View) под Windows Forms;
— особенности реализации переходов между формами и передача параметров, модальные окна;
— использование IoC-контейнера и шаблона Dependency Injection — DI (а именно Сonstructor Injection);
— некоторые особенности тестирования MVP приложения (с использованием NUnit и NSubstitute);
— все это будет происходить на примере мини-проекта и постарается быть наглядным.
В статье затрагивается:
— применение шаблона Адаптер (Adapter);
— простенькая реализация шаблона Контроллер приложения (Application Controller).
Для кого эта статья?
Главным образом для начинающих разработчиков на Windows Forms, которые слышали, но не пробовали, или пробовали, но не получилось. Хотя уверен, что некоторые приемы применимы и для WPF, и даже для веб-разработки.

При переделке старой формы столкнулся с забавной проблемой.

Задача – классическая: вывести пользователю информацию о происходящем в фоне процессе.

Казалось бы, ничего сложного. В основной форме мы стартуем поток, в нем проводим обработку данных, при получении новых статусов – сбрасываем обновление на форму, проводя синхронизацию с базовым UI Thread (Invoke / BeginInvoke call).

И все хорошо до момента, пока наш background поток не попытается создать еще один-два-… Которым делегирует дополнительную работу в рамках задачи. Вот с этими-то новыми потоками и начинается чехарда…

Здравствуйте, коллеги!

На этой неделе мы отдали в перевод амбициозную по своей сложности книгу "Concurrency in .NET" издательства Manning:



Автор любезно выложил на сайте Medium отрывок из 13-й главы, который мы и предлагаем оценить задолго до премьеры.
Приятного чтения!

Привет всем!

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

Желающие или подумывающие написать книгу, затрагивающую подобные темы — пишите в личку.

Хочу представить вашему вниманию перевод статьи Concurrency vs Multi-threading vs Asynchronous Programming: Explained.

В последние время, я выступал на мероприятиях и отвечал на вопрос аудитории между моими выступлениями о Асинхронном программировании, я обнаружил что некоторые люди путали многопоточное и асинхронное программирование, а некоторые говорили, что это одно и тоже. Итак, я решил разъяснить эти термины и добавить еще одно понятие Параллелизм. Здесь есть две концепции и обе они совершенно разные, первая синхронное и асинхронное программирование и вторая – однопоточные и многопоточные приложения. Каждая программная модель (синхронная или асинхронная) может работать в однопоточной и многопоточной среде. Давайте обсудим их подробно.

Почему мы воспринимаем background-color: #9B51E0 как этот конкретный фиолетовый цвет?



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

В интернете, в том числе и на хабре, можно найти много информации про фильтр Калмана. Но тяжело найти легкоперевариваемый вывод самих формул. Без вывода вся эта наука воспринимается как некое шаманство, формулы выглядят как безликий набор символов, а главное, многие простые утверждения, лежащие на поверхности теории, оказываются за пределами понимания. Целью этой статьи будет рассказать об этом фильтре на как можно более доступном языке.
Фильтр Калмана — это мощнейший инструмент фильтрации данных. Основной его принцип состоит в том, что при фильтрации используется информация о физике самого явления. Скажем, если вы фильтруете данные со спидометра машины, то инерционность машины дает вам право воспринимать слишком быстрые скачки скорости как ошибку измерения. Фильтр Калмана интересен тем, что в каком-то смысле, это самый лучший фильтр. Подробнее обсудим ниже, что конкретно означают слова «самый лучший». В конце статьи я покажу, что во многих случаях формулы можно до такой степени упростить, что от них почти ничего и не останется.

А помните, как вы просили меня про шейдеры написать? Помните? Нет? А вот я помню и даже написал. Милости просим, поговорим о прекрасном.

Сегодня я поведу речь о том, как я делал объемные вращающиеся планеты для нашей игры blast-off. Тоесть они, конечно, совершенно плоские, всего пара треугольников, но выглядят как объемные.



Заинтересовало? Прошу под кат. Картинок прилично.

Данная статья рассказывает не только о наиболее распространённых фильтрах обработки изображений, но в понятной форме описывает алгоритмы их работы. Статья ориентирована, прежде всего, на программистов, занимающихся обработкой изображений.

Этот пост хотелось бы написать скорее в философском ключе, нежели в математическом (точнее алгебраическом): не что это за страшный зверь — ЛСА, а какая от него может быть польза «нашему колхозу», т.е. ИИ.

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

На основах работы ЛСА, как уже упоминалось в начале статьи, я не буду сейчас останавливаться (планирую в следующем посте), а пока отошлю к Википедии, лучше даже английской (LSA). А вот основную идею этого метода постараюсь изложить на словах.

Формально:
ЛСА используется для выявления латентных (скрытых) ассоциативно-семантических связей между термами (словами, н-граммами) путем сокращения факторного пространства термы-на-документы. Термами могут выступать как слова, так и их комбинации, т.наз. н-граммы, документами – в идеале: наборы тематически однородных текстов, либо просто любой желательно объемный текст (несколько млн. словоформ), произвольно разбитый на куски, например абзацы.

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

Например, рассмотрим два простых сообщения из разных источников (просто пример для наглядности):

Когда-то давно я решил «потрогать» Fortran. Единственную задачу которую я придумал — генерация фракталов (заодно и OpenMP в Fortran'е можно было бы попробовать). В процессе написания я часто сталкивался с проблемами, решение которых приходилось додумывать самому (например в интернете не так много примеров использования чисел двойной точности или бинарной записи в файл). Но рано или поздно все проблемы решились, и я хочу написать этот текст, который возможно кому-нибудь поможет.

Писать я буду на диалекте Fortran 90, но с GNU расширениями (те же числа двойной точности).

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

Мне не очень нравится подход с voxelized / marching cubes при рендеринге воды (см. например, рендеринг симуляции жидкости в Blender). Когда объём воды находится в том же масштабе, что и используемая для рендеринга сетка, движение получается заметно дискретным. Эту проблему можно решить, увеличив разрешение сетки, но для тонких струй на относительно длинные расстояния в реальном времени это просто непрактично, потому что сильно влияет на время выполнения и занимаемую память. (Есть прецедент использования разреженных воксельных структур, улучшающий ситуацию. Но я не уверен, насколько хорошо это работает для динамических систем. Кроме того, это это не тот уровень сложности, с которым я бы хотел работать.)

Первой альтернативой, которую я исследовал, были меши экранного пространства Мюллера (Müller’s Screen Space Meshes). В них используется рендеринг частиц воды в буфер глубин, его сглаживание, распознавание соединённых фрагментов похожей глубины и построение из результата меша с помощью marching squares. Сегодня этот способ, вероятно, уже стал более применимым, чем в 2007 году (поскольку теперь мы можем создавать меш в compute-шейдере), но он всё равно связан с бОльшим уровнем сложности и затрат, чем бы мне хотелось.

В конце концов я нашёл презентацию Саймона Грина с GDC 2010 «Screen Space Fluid Rendering For Games». Она начинается точно так же, как и Screen Space Meshes: с рендеринга частиц в буфер глубин и его сглаживания. Но вместо построения меша получившийся буфер используется для затенения и композитинга жидкости в основной сцене (с помощью записи глубины явным образом.) Именно такую систему я и решил реализовать.

В рамках своей диссертации «Модель прогнозирования по выборке максимального подобия» мне нужно было делать обзор моделей прогнозирования. Кроме обзора, я сделала вариант классификации, который мне тогда не очень удался. Классификацию уже немного поправила, теперь хочется разобраться в существующих моделях прогнозирования временных рядов. Такие модели называют стохастическими моделями (stochastic models).

По оценке некто Тихонова в его «Прогнозировании в условиях рынка» на сегодняшний день (2006 год) существует около 100 методов и моделей прогнозирования. Эта оценка звучит бредово, я полно разбирала ее! Давайте теперь вместе разберемся, какие же модели прогнозирования временных рядов существуют на сегодняшний день.

1. Регрессионные модели прогнозирования
2. Авторегрессионные модели прогнозирования (ARIMAX, GARCH, ARDLM)
3. Модели экспоненциального сглаживания (ES)
4. Модель по выборке максимального подобия (MMSP)
5. Модель на нейронных сетях (ANN)
6. Модель на цепях Маркова (Markov chains)
7. Модель на классификационно-регрессионных деревьях (CART)
8. Модель на основе генетического алгоритма (GA)
9. Модель на опорных векторах (SVM)
10. Модель на основе передаточных функций (TF)
11. Модель на нечеткой логике (FL)
12. Что еще?...

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