Как может показаться, анализ сигналов и данных — тема достаточно хорошо изученная и уже сотни раз проговоренная. Но есть в ней и некоторые провалы. В последние годы словом «энтропия» бросаются все кому не лень, толком и не понимая, о чем говорят. Хаос — да, беспорядок — да, в термодинамике используется — вроде тоже да, применительно к сигналам — и тут да. Хочется хотя бы немного прояснить этот момент и дать направление тем, кто захочет узнать чуть больше об энтропии. Поговорим об энтропийном анализе данных.

Привет, Хабр! Перед вами перевод статьи Роберта Мартина Open-Closed Principle, которую он опубликовал в январе 1996 года. Статья, мягко говоря, не самая свежая. Но в рунете статьи дяди Боба про SOLID пересказывают только в урезанном виде, поэтому я подумал, что полный перевод лишним не будет.

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

• Ни одну программу нельзя «закрыть» на 100%.
• Объектно-ориентированное программирование (ООП) оперирует не физическими объектами реального мира, а понятиями — например, понятием «упорядочивание».

Алгоритм Левенберга-Марквардта прост. Алгоритм Левенберга-Марквардта эффективен.

А еще о нем говорят, что он где-то посередине между градиентным спуском и методом Ньютона, что бы это ни значило. Ну, с методом Ньютона и его связью с градиентным спуском вроде как разобрались. Но что имеют в виду когда произносят эту глубокомысленную фразу? Попробуем слегка подразобраться.

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

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

Исходные коды программы и пример портфеля для оптимизации выложены на GitHub.

UPDATE: Как и обещал, сделал простой веб-сервис, делающий возможности программы доступными всем без копирования и компиляции кода.
ссылка
Инструкция по использованию там же.
Если что-то не будет работать или нужно что-то подправить — пишите в комментарии.

Итак, имеем задачу сформировать эффективный портфель облигаций.

Правильный отбор признаков для анализа данных позволяет:

• повысить качество моделей машинного обучения с учителем и без, 
  
• уменьшить время обучения и снизить требуемые вычислительные мощности,
  
• а в случае входных данных высокой размерности позволяет ослабить «проклятие размерности».
  

Оценка важности признаков необходима для интерпретации результатов модели.

Мы рассмотрим существующие методы отбора признаков для задач обучения с учителем и без. Каждый метод проиллюстрирован open source-реализацией на Python, чтобы вы могли быстро протестировать предложенные алгоритмы. Однако это не полная подборка: за последние 20 лет было создано множество алгоритмов, и здесь вы найдёте самые основные из них. Для более глубокого исследования ознакомьтесь с этим обзором.

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

Как я писал в предисловии предыдущей статьи, я нахожусь в поисках языка, в котором я мог бы писать поменьше, а безопасности иметь побольше. Моим основным языком программирования всегда был C#, поэтому я решил попробовать два языка, симметрично отличающиеся от него по шкале сложности, про которые до этого момента приходилось только слышать, а вот писать не довелось: Haskell и Go. Один язык стал известен высказыванием "Avoid success at all costs"*, другой же, по моему скромному мнению, является полной его противоположенностью. В итоге, хотелось понять, что же окажется лучше: умышленная простота или умышленная строгость?

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

Многие приобрели «голубую таблетку» на попробовать. Но из-за сложности программирования данная вещь оказалась где то на полке, до лучших времен.

Будем считать, что «лучшие времена» — наступили.

Источник: xkcd

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

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

В последние годы C++ шагает вперед семимильными шагами, и угнаться за всеми тонкостями и хитросплетениями языка бывает весьма и весьма непросто. Уже не за горами новый стандарт, однако внедрение свежих веяний — процесс не самый быстрый и простой, поэтому, пока есть немного времени перед C++20, предлагаю освежить в памяти или открыть для себя некоторые особо «скользкие» места актуального на данный момент стандарта языка. 

Сегодня я расскажу: почему if constexpr не является заменой макросов, каковы «внутренности» работы структурного связывания (structured binding) и его «подводные» камни и правда ли, что теперь всегда работает copy elision и можно не задумываясь писать любой return. 

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

Встреча в Кёльне прошла, стандарт C++20 приведён к более или менее законченному виду (по крайней мере до появления особых примечаний), и я хотел бы рассказать об одном из грядущих нововведений. Речь пойдёт о механизме, который обычно называют operator<=> (стандарт определяет его как «оператор трёхстороннего сравнения», но у него есть неформальное прозвище «космический корабль»), однако я считаю, что область его применения гораздо шире.

У нас не просто будет новый оператор — семантика сравнений претерпит существенные изменения на уровне самого языка.

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

Если вы уже наигрались с Go, устали от копипасты, ручного жонглирования мьютексами и всерьёз подумываете о приобретении протезов для рук, то позвольте предложить вашему вниманию перевод Tour of the Go с эквивалентным кодом на D и краткими пояснениями.

Часть первая. Основы.

Часть пятая. Сопрограммы.

Этот хабрапост объединяет десять лучших докладов от таких спикеров, как Nicolai Josuttis, Timur Doumler, Андрей Давыдов и многих других.

C++17/20/23, concepts, immutable data structures, concurrency, parallelism, metaprogramming — всё это темы конференции C++ Russia 2019, прошедшей этой весной в Москве. Более шести сотен участников, известные международные спикеры, глубокие доклады. Обратите внимание — доклады такие, что устареют очень нескоро, а применить полученные знания можно хоть сейчас.

Формат таков:

• Обязательное видео на YouTube
• Подробное описание доклада на русском языке (со слайдами, если они есть)
• Краткая биография докладчика

Не стесняйтесь писать комментарии! Кстати, в плейлисте, опубликованном под катом, есть не только топ-10. И мы выключили рекламу на YouTube, так что никто не будет мешать.

Компилятор — часть Emscripten. А что, если удалить все свистелки и оставить только его?

Emscripten необходим для компиляции C/C++ в WebAssembly. Но это гораздо больше, чем просто компилятор. Цель Emscripten в том, чтобы полностью заменить ваш компилятор C/C++ и запустить в вебе код, который изначально не предназначен для Сети. Для этого Emscripten эмулирует всю операционную систему POSIX. Если программа использует fopen(), то Emscripten предоставит эмуляцию файловой системы. Если используется OpenGL, то Emscripten предоставит С-совместимый контекст GL, поддерживаемый WebGL. Это немалая работа, и немало кода, который придётся внедрить в итоговый пакет. Но можно ли просто… удалить его?

Коллеги, кто использует на своих почтовых серверах Exim версий 4.87...4.91 — срочно обновляйтесь до версии 4.92, предварительно остановив сам Exim во избежание взлома через CVE-2019-10149.

Потенциально уязвимы несколько миллионов серверов по всему миру, уязвимость оценивается как критическая (CVSS 3.0 base score = 9.8/10). Злоумышленники могут запускать на Вашем сервере произвольные команды, во многих случаях от рута.

Классическое объяснение word2vec как архитектуры Skip-gram с отрицательной выборкой в оригинальной научной статье и бесчисленных блог-постах выглядит так:

while(1) {
   1. vf = vector of focus word
   2. vc = vector of focus word
   3. train such that (vc . vf = 1)
   4. for(0 <= i <= negative samples):
           vneg = vector of word *not* in context
           train such that (vf . vneg = 0)
}

Действительно, если погуглить [word2vec skipgram], что мы видим:

• Страница Википедии, которая описывает алгоритм на высоком уровне
  
• Страница Tensorflow с тем же объяснением
  
• Блог Towards Data Science c описанием того же алгоритма, и список продолжается.

Но все эти реализации ошибочны.

С момента своего анонса технология WebAssembly сразу привлекла внимание разработчиков фронтенда. Веб-сообщество с энтузиазмом восприняло идею запустить в браузере код, написанный на других языках, кроме JavaScript. Главное, что WebAssembly гарантирует скорость намного выше, чем JavaScript.

Наши инженеры внимательно следили за развитием стандарта. Как только поддержку WebAssembly 1.0 внедрили во всех основных браузерах, разработчики сразу захотели опробовать её.

Но тут возникла проблема. Хотя многие приложения выигрывают от WebAssembly, но область применения технологии в электронной коммерции всё ещё примитивна. Мы не смогли сразу найти правильный вариант её использования. Было несколько предложений, но во всех вариантах JavaScript подходил лучше. Когда мы в eBay оцениваем новые технологии, то первый вопрос: «Какова потенциальная выгода для наших клиентов?» Если здесь нет ясности, мы не переходим к следующему шагу. Очень легко увлечься новой модной технологией, даже если она не имеет никакого значения для клиентов и только усложняет существующий рабочий процесс. Пользовательский опыт всегда важнее опыта разработчика. Но с WebAssembly иначе. У этой технологии огромный потенциал, просто мы не могли найти правильный вариант использования. Впрочем, в итоге всё-таки нашли.

UPD. CardInfo больше не работает. Используйте BinKing.

Гайд по использованию: habr.com/ru/post/527796
Сайт сервиса: binkng.io

Тут и демо, и документация: cardinfo.online — это API. Вы ему 6 первых цифр банковской карты, оно вам ссылку на логотип банка, его фирменные цвета, бренд (Visa, MasterCard, и т.д.) и прочее в формате JSON. CardInfo нужен тем, кто создаёт форму для приёма банковских карт у себя на сайте, чтобы улучшить UX (удобство, впечатления, чувство безопасности) пользователей. Принимать платежи прямо у себя на сайте позволяет cloudpayments.ru в России и странах СНГ, и stripe.com во всём остально мире.

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

Однако, крупные компании уже давно сделали свои формы такими, а мелкие всё ещё нет. Почему? Создание такого решения для своей формы займёт около 7 дней работы программиста и ещё 7 работы дизайнера (логотипы выкачивать, обрабатывать, перерисовывать). Крупные компании могут себе позволить потратиться на создание такой формы. Мелкие компании считают ценность такой формы не достаточной, чтобы платить за неё столько.

CardInfo позволит превратить уже существующую форму для приёма банковских карт в такую же, как у Яндекс.Кассы, за пол дня работы программиста. Я предполагаю, что после выхода CardInfo определение логотипа банка и цветов банка для платёжных форм станет стандартом. Потому что такие формы лучше. Потому что теперь такие формы смогут позволить себе все.

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

Идея была простая — взять историю своих чатов из Telegram и на их основе обучить seq2seq сеть, способную по началу диалога предсказывать его завершение. Такая сеть может работать в трех режимах:

• Предсказывать завершение фразы пользователя с учетом истории разговора
• Работать в режиме чат-бота
• Синтезировать логи разговоров целиком

Вот что получилось у меня

Бот предлагает завершение фразы

Бот предлагает завершение диалога

Бот общается с живым человеком

User: привет
Bot: привет
User: как ты?
Bot: собираюсь
User: баг пофиксил?
Bot: нет
User: почему?
Bot: да не получается
User: ты сегодня когда дома будешь?
Bot: не знаю пока
User: ты занят?
Bot: в магазин еду 

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

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

* * *

При грамотном исполнении push-уведомления для мобильных устройств могут обеспечить пользователя полезной информацией и побудить далее взаимодействовать с приложением. А вот плохая реализация уведомлений может оттолкнуть и даже заставить удалить приложение.

В 2016 году, согласно исследованию Telefonica Research в Испании, пользователи мобильных телефонов получали в среднем 56 уведомлений в день. Сегодня это число, скорее всего, выросло. Поэтому к их разработке следует подходить с большим вниманием, иначе такой поток уведомлений может несомненно навредить пользовательскому опыту.