Я всегда говорил своему другу, что математика со своими изящными абстракциями обладают той магической силой, потенциал которой до сих пор полностью не раскрыт. Сегодня я хочу поговорить о том, как можно приблизить число Пи с помощью множества Мандельброта. Пару слов о множестве На самом деле на Хабре куча статей, описывающие множество Мандельброта (далее, множество М), рассматривающие его свойства, историю и удивительную красоту, подкрепляя всё это красочными картинками. Мне бы не хотелось останавливаться на его определении и прочих деталях, а сразу перейти к делу. Однако в силу того, что оно является центральным субъектом данной статьи, я все же освежу вашу память. Множество М — это множество всех комплексных чисел с, для которых функция при ее итерации с ограничена. Настолько просто. На практике мы применяем следующую теорему: если функция (вышеприведенная) в ходе итерации превосходит значение 2, то она 100% не ограничена. Поэтому, определить множество можно так: Я не буду затрагивать тему визуализации, туда мы сегодня копать не будем. Число Пи? Действительно, каким-таким образом? Все то, что покрыто черным на картинке принадлежит множеству М. Возьмем "координату соприкосновения двух частей" множества c = -0.75 + ix (где x ? ?). Проверим её принадлежность ко множеству М: начнем итерировать функцию n-раз от нуля и проверять, превосходит ли полученное значение 2. Если да, то функция разошлась, и значение с не принадлежит множеству при данном n. Иначе — принадлежит. x c n (кол-во итераций до расхода функции) 0.1 -0.75 + 0.1i 33 0.01 -0.75 + 0.01i 315 0.001 -0.75 + 0.001i 3143 0.0001 -0.75 + 0.0001i 31417 0.00001 -0.75 + 0.00001i 314160 Именно. Если поставить запятую на нужном месте, цифры напоминают число Пи. Наверное, совпадение Не будем заморачиваться с комплексной частью и возьмем число c = 0.25. Оно принадлежит множеству при бесконечно большом количестве итераций. Поэтому, будем "приближаться" к этой точке справа: возьмем c = 0.26, проверим его; c = 0.2501, проверим его, и т. д. c n (кол-во итераций до расхода функции) 0.26 30 0.2501 312 0.25001 991 0.250001 3140 0.2500001 9933 0.25000001 31414 Последовательность колеблется между двумя значениями, однако эхо числа Пи (поставив запятую в нужное место) никуда не исчезло. Немного истории Само множество М, названное в честь математика Бенуа Мандельброта — совсем недавное открытие. Бенуа даже выступал на TEDx, говоря в том числе и о нем. В 1991 Дейв Болл изучал, действительно ли "соприкосновение двух частей множества" М около c = -0.75 "бесконечно тонко". В ходе своего исследования он и обнаружил то, о чем мы сейчас говорим. И все-таки, наверное, совпадение Попытаемся понять, что происходит: действительно ли мы получаем число Пи или это какое-то иное трансцендентное число. Все это будем делать вокруг точки c = 0.25 (просто в силу отсутствия у него комплексной части — так легче). Рассмотрим рекурсивную функцию . При ее итерации от нуля заметим, что она очень медленно стремится к точке x = 0.5. Наглядно Чтобы не дать ей "застрять" на этом значении, мы подвинем данную функцию на ? единиц вверх (? бесконечно мало, не равно нулю). Тогда она примет вид . Данная функция медленно стремится к точке x = 0.5, а после того, как проходит её, быстро убегает в бесконечность. Будем копать дальше. Пусть x = y + 0.5. Наша задача — найти ноль. Делая замену в исходной функции, получим: Взяв в качестве ? любое малое значение, проитерируем функцию от нуля: y 0.001 ( = ?) 0.002001 0.0030050040010000004 0.004014034050046026 0.005030146519400955 0.006055448893407596 0.007092117354708267 0.00814241548328122 0.009208714413183598 0.010293514834327173 Видим, что она достаточно плавно и медленно возрастает возле нуля. Исходя из этого, мы в праве предположить, что разность (n+1)-го и n-го значений функции близка к её производной: . Учитывая это, наша исходная функция примет вид: , что является простейшим дифференциальным уравнением первого порядка. Решая его (например, методом разделения переменных), получим: Вспоминаем нашу цель — поиск нуля. Данное выражение равно нулю только в двух случаях: либо квадратный корень из ? равен нулю — невозможно по определению, либо тангенс равен нулю. Пренебрегая константой C: . Это подтверждает то, что мы сегодня увидели: ? nv? 0.01 3.0 0.0001 3.12 0.000001 3.140 0.00000001 3.1414 Видно, что множитель v? ставит ту самую запятую в нужное место. Заключение Построение числа Пи данным методом является, наверное, самым неэффективным способом: нужно проделать 314160 итераций для того, чтобы получить 3,14160. Кроме того, метод не обладает высокой точностью в силу больших погрешностей вычислений. Однако нам удалось соединить две, казалось бы, несоединимые точки: фрактал и отношение длины окружности к длине её диаметра.

Что такое Code Contracts Code Contracts были созданы командой разработчиков из Microsoft Research в 2008 году. Задача Code Contracts — описывать предположения о состоянии в коде, которые в последующем используются для генерации документации и проверки кода на корректность. Предполагалось, что Code Contracts станут частью платформы .NET и получат поддержку в компиляторе, платформе и Visual Studio. К сожалению, поддержка появилась только на платформе в виде классов пространства имен System.Diagnostics.Contracts. Для остального требуются плагины и дополнительные утилиты. В данный момент проект поддерживает SergeyT и еще несколько участников. Поддержка Code Contracts в Mono Для проектов, которые разрабатываются на Windows, инфраструктура Code Contracts понятна и более развита. Есть Build Steps для MSBuild, можно переписывать/верифицировать сборки с помощью утилит, есть плагины для VS и Resharper. Но с Mono дела обстоят не так хорошо, есть самодельный ccrewrite, который ломается на сложном коде. Поддержки в xbuild и MonoDevelop нет, и простым способом собрать проект нельзя. Причины для удаления Code Contracts из проекта: — Внешняя зависимость проекта от утилит Code Contracts, без которых проект не собрать. — Скорость компиляции ниже из-за дополнительного шага в виде перезаписи сборки. — Отсутствие поддержки в Mono. — Неудобств стало больше, чем пользы. Удаление Code Contracts из исходного кода Благодаря проекту Roslyn от Microsoft анализ и обработка исходного кода на C#/VB.NET стали довольно тривиальной задачей. И я выбрал этот путь для удаления Code Contracts из исходного кода. Само решение простое и состоит из CSharpSyntaxRewriter, который пробегает по коду и заменяет проверки Code Contracts на их эквивалент вне Code Contracts. Сам удалитель Code Contract'ов оформлен в виде пакета Nuget, доступен как утилита и работает под Mono. Install-Package CodeContractsRemover И команда на перезапись всех исходников в директории проекта: # code_contracts_remover.exe <Convert|Remove> <directoryPath> > Если вы не хотите попрощаться с контрактами навсегда, то можете использовать данную утилиту как шаг сборки на вашем билд сервере. Ссылки Проект на GitHub Nuget пакет

В одной из прошлых публикаций мы рассказывали о программном продукте EMC Capital Projects, входящем в пакет EMC Documentum EPFM (Engineering, Plant and Facilities Management). Он позволяет следующее: компаниям-проектировщикам — готовить документацию и согласовывать её перед передачей подрядчикам, компаниям-подрядчикам — принимать эту документацию, проверять её комплектность, рассматривать, вносить правки. Но чем сложнее спираль проектирования, то есть чем больше участников вносят в проект изменения и дополнения, тем выше вероятность возникновения ошибок: несовместимости и конфликтов требований к оборудованию с выбранными для проекта моделями, массогабаритной несовместимостью объектов строительства, несоответствия элементов объекта особенностям рельефа, и т.д. Ситуация сильно усложняется, если в работу вовлечено одновременно несколько географически распределённых команд, работающих по множеству проектных дисциплин: требуется управлять изменениями с помощью Digital Enterprise-решений, чтобы не нарушать и не задерживать рабочий процесс. В EMC Capital Projects эта задача решается благодаря использованию технологий AVEVA NET. Что такое AVEVA NET Workhub and Dashboard Это интеграционный комплекс, который помогает пользователям организовывать совместную работу над проектными данными и документами. Информация может поступать из всевозможных источников — таблиц, баз данных, прочих структурированных хранилищ. В основе комплекса лежит идея накопления и систематизации знаний об объекте, с параллельным извлечением метаданных по каждому элементу. AVEVA NET Workhub and Dashboard может работать с данными любого формата, включая: трехмерные модели, данные лазерного сканирования, цифровые фотографии, 2D-чертежи, отсканированные документы, данные из систем ERP и т.д. Вся информация систематизируется и объединяется в едином рабочем пространстве. Специалист может сразу посмотреть все характеристики элемента и все документы, в которых он фигурирует: чертежи, 3D-модели, фотографии и т.д. Экономия времени получается колоссальная, ведь обычно инженеры-проектировщики тратят на поиск информации от 50% до 80% рабочего времени, перебирая залежи документов, таблиц и баз данных. Помимо этого, комплекс содержит инструменты анализа, проверки и контроля технической информации, позволяющие избежать принятия инженерных решений на основании ошибочных исходных данных. Интеграция Capital Projects и AVEVA NET Workhub and Dashboard Итак, AVEVA NET Workhub and Dashboard выполняет роль инструмента объединения и визуализации всей технической информации по проекту, с проверкой данных и автоматическим присвоением документам перекрёстных ссылок. Этот комплекс позволяет также контролировать комплектность документации и проводить проверки по метаданным объектов. Но, помимо этого, для эффективной работы над проектом необходимо точно управлять всеми этапами работ по подготовке документов: организовать процесс приемки и отправки документов, осуществлять маршрутизацию, распределять задачи по сотрудникам, назначать сроки выполнения работ по каждому документу, отслеживать своевременность выполнения, осуществлять рецензирование и проверку документации. Все эти задачи решает Capital Projects: он играет роль транспорта, позволяющего проектировщикам и подрядчикам обмениваться документацией с заказчиком, а заказчику — направлять документацию на рассмотрение правильным специалистам внутри организации. При этом Capital Projects позволяет управлять всеми стадиями процесса подготовки документа — от создания шаблона до утверждения финальной версии. Пример рабочего процесса: При планировании работ по проекту заказчик, зная какие документы он хочет получить от подрядчика, создаёт в Capital Projects заглушки для будущих документов. Эта информация автоматически передается на портал Supplier Exchange, где подрядчику сообщается, что для заглушки требуется наполнение — сам документ, например, DWG-чертёж. Разработчик документации (Supplier) загружает документ. Проводится предварительная проверка (Document control) на наличие ошибок в версиях, проверка правильности наименований и т.д. Затем документ передаётся в Capital Projects, где он оценивается инженером со стороны заказчика. В соответствии с правилами маршрутизации этот документ приходит на рассмотрение инженеру в виде PDF-файла. Допустим, это какой-то чертёж. Чтобы проверить точность ассортимента оборудования, всех параметров и размеров, инженер вынужден самостоятельно найти, открыть и проанализировать множество другой документации, имеющей отношение к представленному на чертеже оборудованию и конструкциям. В зависимости от сложности полученного чертежа ручной поиск и сверка данных может занимать от нескольких часов до нескольких дней. Благодаря интеграции с AVEVA NET Workhub and Dashboard процесс рассмотрения может проходить гораздо легче. Интеграция позволяет открывать и просматривать загруженные в Capital Projects документы, полученные от подрядчика, с помощью специального просмотрщика. Из поступающих чертежей система извлекает все инженерные данные. Каждый элемент распознается по уникальному имени, и вся новая информация дополняет уже имеющиеся метаданные, загруженные ранее. Теперь инженер оперирует не простым PDF-файлом, а полноценным чертежом, по каждому элементу которого можно сразу получить необходимую техническую информацию, связанные документы из любых проектных дисциплин: электрика, вентиляция, теплоснабжение и т.д. Помимо этого, появляется возможность просмотра трёхмерных моделей представленных на чертеже объектов, которые встраиваются в общую модель всего проекта. Система самостоятельно проверяет соответствие данных в чертежах и спецификациях, избавляя инженера от длительных поисков и сверок бумажных документов: По завершении анализа чертежа инженер вносит свои комментарии и отправляет чертёж на доработку. Заключение Интеграция EMC Capital Projects с AVEVA NET Workhub and Dashboard позволяет: Просматривать документы в виде чертежей или трёхмерных моделей, сразу получая всю связанную техническую информацию по каждому элементу. Автоматически обнаруживать несоответствия данных, полученных на разных стадиях проекта от разных дисциплин и специалистов. Многократно ускорить проверку проектной документации и снизить вероятность ошибок проектирования, строительства и дальнейшей эксплуатации.