Симуляция физики делает небольшие предсказания на основании законов физики. Эти предсказания на самом деле достаточно просты, что-то вроде «если объект вот здесь и он движется с такой скоростью в этом направлении, то за краткий промежуток времени он окажется вот тут». Мы создаём такие предсказания с помощью математической техники под названием интегрирование.

Темой этой статьи как раз и будет реализация такого интегрирования.

Интегрирование уравнений движения

Вы можете помнить из курса старшей школы или вуза, что сила равна произведению массы на ускорение.

$$

Преобразуем это уравнение и увидим, что ускорение равно силе, делённой на массу. Это соответствует нашим интуитивным ожиданиям, потому что тяжёлые объекты труднее бросать.

$$

Ускорение — это темп изменения скорости от времени:

$$

Аналогично, скорость — это темп изменения позиции от времени:

$$

Это значит, что если мы знаем текущие позицию и скорость объекта, а также приложенные к нему силы, то сможем проинтегрировать, чтобы найти его позицию и скорость в определённый момент времени.

Евгений Сафронов, Senior Developer, DataArt

«Тестирование можно использовать для того, чтобы доказать наличие ошибок в программе, и никогда — для того чтобы доказать их отсутствие!»
Эдсгер Дейкстра

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

Тестирование — это проверка работоспособности программы, предмета или любой промышленной разработки. Как и в любом деле, здесь есть свои тонкости и своя философия. Она, наверное, ближе тестировщикам, которые на произведенные нами вещи смотрят деструктивно — они с самого начала думают о том, как сломать предложенный разработчиками продукт. Это не очень типично для пользователей, которые более предсказуемы и обычно находят ошибки, случайно пытаясь сделать с нашей программой что-то нетипичное. У разработчиков подход к программам в принципе другой, но мы должны помнить: тестировщики должны ломать то, что мы создали — это их хлеб.

Когортный анализ возвратности пользователей является мощным способом для понимания разных групп клиентов — их поведения и значимости для бизнеса. Однако итоговые таблицы бывает трудно понять с первого раза, а с ходу придумать, как их построить, ещё сложнее.

В статье будет описан относительно простой, но полезный алгоритм построения когортой таблицы, а также приведены наброски кода с Python/Pandas и SQL. Если Вам необходимо программно реализовать построение когортного отчёта или просто интересно узнать этот алгоритм — прошу под кат.

Введение

На финансовом рынке обращается, как правило, несколько типов ценных бумаг: государственные ценные бумаги, муниципальные облигации, корпоративные акции и т.п.

Если у участника рынка есть свободные деньги, то их можно отнести в банк и получать проценты или купить на них ценные бумаги и получать дополнительный доход. Но в какой банк отнести? Какие ценные бумаги купить?

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

Программные средства для анализа портфелей ценных бумах должны работать с матрицами доходности и решать задачи нелинейного программирования с ограничениями в виде строгих и нестрогих неравенств. Символьное решение на Python некоторых типов задач нелинейного программирования мною уже рассматривалось в публикации [1]. Однако, применить предложенные в указанной публикации методы для анализа портфеля ценных бумаг нельзя из-за ограничений в виде строгих неравенств.

Целью настоящей публикации является разработка методов оптимизации портфелей ценных бумаг с использованием библиотеки scipy.optimize. Пришлось исследовать и применить при программировании такие мало известные возможности указанной библиотеки, как введение дополнительных ограничений в функцию цели [2].

Данная статья является перевом статьи от Mladen Rakonjac

Очень сложно найти один проект, который охватывал бы всё новое в разработке под Android в Android Studio 3.0, поэтому я решил написать его. В этой статье мы разберём следующее:

1. Android Studio 3
2. Язык программирования Kotlin
3. Варианты сборки
4. ConstraintLayout
5. Библиотека привязки данных Data Binding
6. Архитектура MVVM + паттерн repository (с mapper'ами) + Android Manager Wrappers
7. RxJava2 и как это помогает нам в архитектуре
8. Dagger 2.11, что такое внедрение зависимости, почему вы должны использовать это.
9. Retrofit (Rx Java2)
10. Room (Rx Java2)

Каким будет наше приложение?

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

Я попытаюсь объяснить как можно больше строк кода. Вы всегда можете посмотреть код, который я опубликовал на GitHub.

Алиасинг (aliasing) — это, возможно, наиболее фундаментальный и самый широко обсуждаемый артефакт 3D-рендеринга всех времён. Однако в игровом сообществе его часто недопонимают. В этой статье я подробно расскажу о теме сглаживания (антиалиасинга, anti-aliasing, AA) в реальном времени, особенно о том, что касается игр, и в то же время буду излагать всё достаточно простым языком.

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

Эту программу можно скачать здесь.

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

В мае 2017 года исследователи из Google Brain представили проект AutoML, который автоматизирует проектирование моделей машинного обучения. Эксперименты с AutoML показали, что эта система может генерировать маленькие нейросети с очень хорошими показателями — вполне сравнимые с нейросетями, которые спроектированы и обучены экспертами-людьми. Однако поначалу возможности AutoML были ограничены маленькими научными наборами данных вроде CIFAR-10 и Penn Treebank.

Инженеры Google задумались — а что если поставить перед генератором ИИ более серьёзные задачи? Способна ли эта система ИИ сгенерировать другую ИИ, которая будет лучше созданного человеком ИИ в какой-нибудь важной задаче вроде классификации объектов из базы ImageNet — самого известного из крупномасштабных наборов данных в машинном зрении. Так появилась нейросеть NASNet, созданная практически без участия человека.

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

В данной статье я опишу разработку простого плагина для локализации UI Text-компонентов с возможностью динамической смены языка и редактирования текста в редакторе.

Предисловие

В Интернете можно найти достаточно много примеров по созданию резервных копий баз данных, а также по их восстановлению. Приведем еще один пример встроенными средствами в MS SQL Server.

В данном примере будут собраны сразу несколько подходов-от проверки целостности базы данных перед созданием резервной копии до восстановления этой базы по уже созданной ранее резервной копии.

В свободное и не свободное время[1] я развиваю несколько своих проектов на github, а также, по мере сил, участвую в жизни интересных для меня, как программиста, проектах.

Недавно один из коллег попросил консультацию: как выложить разработанную им библиотеку на github. Библиотека никак не связана с бизнес-логикой приложения компании, по сути это адаптер к некоему API, реализующему определённый стандарт. Помогая ему, я понял что вещи, интуитивно понятные и давно очевидные для меня, в этой области, совершенно неизвестны человеку делающему это впервые и далёкому от Open Source.

Я провел небольшое исследование и обнаружил что большинство публикаций по этой теме на habrahabr освещают тему участия (contributing), либо просто мотивируют каким-нибудь образом примкнуть к Open Source, но не дают исчерпывающей инструкции как правильно оформить свой проект. В целом в рунете, если верить Яндекс, тема освещена со стороны мотивации, этикета контрибуции и основ пользования github. Но не с точки зрения конкретных шагов, которые следует предпринять.

Так что из себя представляет стильный, модный, молодёжный Open Source проект в 201* году?

Часть 1
Часть 2
Часть 3

Люди иногда спрашивают, почему код, скомпиливанный в LLVM иногда генерирует сигналы SIGTRAP, когда оптимизация была включена. Покопавшись, они обнаруживают, что Clang сгенерировал инструкцию «ud2» (подразумевается код X86) — то же, что генерируется __builtin_trap(). В этой статье рассматривается несколько вопросов, касающихся неопределённого поведения кода на C и того, как LLVM его обрабатывает.


В этой статье (первой из трёх) мы попытаемся объяснить некоторые из этих вопросов, чтобы вы могли лучше понять связанные с ними компромиссы и сложности, и возможно, изучить немного больше тёмные стороны С. Мы выясним, что C не является «высокоуровневым ассемблером», как многие опытные программисты на C (особенно те, кто сфокусирован на низком уровне) предпочитают думать, и что C++ и Objective-C напрямую унаследовали множество таких проблем.

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

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

В этой части туториала мы рассмотрим следующие темы:

• Простое распознавание коллизий
• Генерирование простого многообразия
• Разрешение импульсов силы

Один из главных вопросов криптоинвесторов ранних стадий, ставящий стартапы в тупик, звучит так: "как вы будете бороться с падением стоимости своего токена?" Ответить на него надо и в бизнес-бумаге, и очно, если вы собираете первые деньги на очных встречах.

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

Давайте разберёмся с этим подробнее.

В прошлой статье мы уже обсудили с вами причины, по которой Python нельзя назвать идеальным языком для новичков, хотя на том же Хабре бытует мнение, что Python – это выбор номер один и вообще топчик.

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

Предлагаю читателям Хабра мой перевод статьи «44 урока управления технарями» Славы Ахмечета, сооснователя RethinkDB. В оригинальной статье используется термин «инженеры», но в контексте статьи я буду использовать также термин «технари» – более емкое, как мне кажется, с точки зрения русского языка слово, охватывающее профессии в сфере ИТ, частью которой я тоже являюсь.

Немного об оригинальном тексте. Статья была написана в 2014 году в личном блоге автора, в октябре 2016 компания RethinkDB не смогла выйти в прибыль и закрылась, о чем на Хабре писали тут и тут, а Слава поразмышлял об этом здесь.

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

Источник