GTD (Getting Things Done, Доведение дел до завершения) — это методика организации и отслеживания задач и проектов. Но эта методика, правда, ориентирована на нечто большее, чем только на «доведение дел до завершения». (Ей стоило бы называться «Доведение дел до завершения гораздо лучшим способом, чем просто позволяя чему-то идти своим чередом, что часто получается не так, чтобы очень уж хорошо»). Цель GTD — сделать так, чтобы человек полностью доверял бы системе сбора задач, идей и проектов. Это относится и к туманным задачам, вроде «сделать самое великое изобретение», и к конкретным делам, вроде «позвонить Аде 25 августа чтобы обсудить программу конференции». Речь идёт абсолютно обо всём!

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

Но числа в Python — это гораздо больше, чем, собственно, их числовые значения. Поговорим о трёх особенностях чисел в Python, с которыми вы, возможно, не знакомы.

Современный человек много чем занимается в интернете: ходит по магазинам, слушает музыку, читает новости. Все эти задачи подразумевают поиск и выбор того, что ему нужно. При этом важную роль тут играют рекомендательные системы. Они помогают людям не утонуть в многообразии вариантов и увидеть именно то, что им подойдёт, то, что иначе им сложно было бы найти. Предоставление пользователям качественных рекомендаций — это важнейшая часть обеспечения первоклассного уровня удовлетворения клиента. Это — один из самых эффективных способов взращивания лояльности клиентов и повышения ценности продукта или услуги в их глазах. Всё это так важно, что целые бизнес-модели некоторых компаний построены вокруг предоставления их клиентам наилучших рекомендаций, что делает рекомендательные системы важнейшими факторами, влияющими на прибыль подобных компаний! В результате неудивительно то, что клиенты проекта Microsoft CSE часто обращаются к нам с просьбами, касающимися реализации эталонных рекомендательных техник. Один из таких проектов был моим первым опытом в данной сфере.

Прим. Wunder Fund: не спешите минусовать эту публикацию — её перевода на Хабре ещё не было :)

Это — продолжение моей предыдущей публикации (вот — первая, вторая и третья части перевода), посвящённой тому, как я создал алгоритм сортировки, который быстрее std::sort. Эта статья — мой шанс углубиться в те детали, о которых меня спрашивали в комментариях. Я собираюсь разъяснить здесь некоторые вещи, которые оказались непонятными аудитории, и поговорить о будущем моего алгоритма, о доработках, в которых он нуждается.

Кто-то, за что я этому неизвестному благодарен, разместил ссылки на мою статью на Hacker News и на Reddit. И хотя эти ссылки там разместил не я, я, всё же, прочитал большую часть комментариев, сделанных пользователями этих сайтов. По какой-то причине те комментарии, что были сделаны в моём блоге, оказались гораздо позитивнее, чем комментарии на Hacker News и Reddit. Но у меня такое ощущение, что причина появления негативных комментариев заключается, в целом, в неправильном понимании того, о чём я пишу. Здесь я собираюсь расставить все точки над «i».

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

Прим. Wunder Fund: ну, вы наверное, и сами догадываетесь, как мы любим быстрые алгоритмы и оптимизации. Если вы тоже такое любите — вы знаете, что делать)

Прим. Wunder Fund: ну, вы наверное, и сами догадываетесь, как мы любим быстрые алгоритмы и оптимизации. Если вы тоже такое любите — вы знаете, что делать)

Публикуем вторую часть перевода материала об очень быстром алгоритме сортировки — «Ska Sort». В первой части говорилось о временной сложности алгоритмов и о том, какие улучшения базового алгоритма «Американский флаг» позволили автору «Ska Sort» повысить скорость сортировки. Сегодняшний материал посвящён рассказу о том, почему новый алгоритм быстрее других алгоритмов сортировки.

Прим. Wunder Fund: ну, вы наверное, и сами догадываетесь, как мы любим быстрые алгоритмы и оптимизации. Если вы тоже такое любите — вы знаете, что делать)

В наши дни сказать, что изобрёл алгоритм сортировки, который на 30% быстрее того, что считают эталонным, это значит — сделать довольно смелое заявление. Я, к сожалению, вынужден сделать ещё более смелое заявление. Дело в том, что я создал алгоритм сортировки, который, для многих вариантов входных данных, вдвое быстрее std::sort. И, за исключением сортировки специально созданных входных последовательностей, на которых алгоритм упирается в свой худший случай, он всегда быстрее std::sort. (А когда появляются данные, приводящие к худшему случаю алгоритма, я эту ситуацию детектирую и автоматически перехожу на std::sort).

Почему я сказал: «…к сожалению, вынужден…»? Вероятно из-за того, что мне, скорее всего, предстоит нелёгкое дело убеждения читателя в том, что я действительно увеличил скорость сортировки в два раза. Поэтому материал, который я начинаю писать, вполне может получиться достаточно длинным. Но весь мой код открыт — это значит, что вы можете попробовать мои наработки на данных, характерных для вашей сферы деятельности. Поэтому я могу убедить вас в достоинствах моего алгоритма с помощью массы аргументов и результатов измерений. А ещё вы можете просто попробовать алгоритм самостоятельно.

Учитывая то, о чём я писал в моём прошлом материале, это, конечно, вариант поразрядной сортировки (radix sort). То есть — его временная сложность ниже, чем O(n log n). Вот два основных направления, по которым я усовершенствовал базовый алгоритм:

Первая и вторая части перевода материала о трансформерах были посвящены теоретическим основам этого семейства нейросетевых архитектур, рассказу о способах их использования, демонстрации их реализации с применением PyTorch. Сегодня речь пойдёт об истории трансформеров, будет дан обзор современного состояния дел в этой сфере.

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

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

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

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

Здесь можно найти видеолекции о трансформерах. А в этом репозитории имеется реализация простого трансформера с использованием PyTorch.

Прим. Wunder Fund: короткая статья о том, как эмбеддинги могут помочь при работе с категориальными признаками и сетками. А если вы и так умеете в сетки — то мы скоро открываем набор рисерчеров и будем рады с вами пообщаться, stay tuned.

Создание эмбеддингов признаков (feature embeddings) — это один из важнейших этапов подготовки табличных данных, используемых для обучения нейросетевых моделей. Об этом подходе к подготовке данных, к сожалению, редко говорят в сферах, не связанных с обработкой естественных языков. И, как следствие, его почти полностью обходят стороной при работе со структурированными наборами данных. Но то, что его, при работе с такими данными, не применяют, ведёт к значительному ухудшению точности моделей. Это стало причиной появления заблуждения, которое заключается в том, что алгоритмы градиентного бустинга, вроде того, что реализован в библиотеке XGBoost, это всегда — наилучший выбор для решения задач, предусматривающих работу со структурированными наборами данных. Нейросетевые методы моделирования, улучшенные за счёт эмбеддингов, часто дают лучшие результаты, чем методы, основанные на градиентном бустинге. Более того — обе группы методов показывают серьёзные улучшения при использовании эмбеддингов, извлечённых из существующих моделей.

Эта статья направлена на поиск ответов на следующие вопросы:

1. Что такое эмбеддинги признаков?
2. Как они используются при работе со структурированными данными?
3. Если использование эмбеддингов — это столь мощная методика — почему она недостаточно широко распространена?
4. Как создавать эмбеддинги?
5. Как использовать существующие эмбеддинги для улучшения других моделей?

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

Иногда, чтобы полностью разобраться с тем, как что-то устроено, нужно это сначала разобрать, а потом собрать. Уверен, многие из тех, кто это читают, в детстве часто поступали именно так. Это были дети, которые хватались за отвёртку для того, чтобы узнать, что находится внутри у чего-то такого, что им интересно. Разбирать что-то — это невероятно увлекательно, но чтобы снова собрать то, что было разобрано, нужны совсем другие навыки.

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

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

Зачем мне это? Дело в том, что после того, как я дописал книгу CPython Internals, разработка на ассемблере всё ещё была для меня чем-то весьма таинственным. Я начал изучать ассемблер для x86-64 по этой книге, понял какие-то базовые вещи, но не мог связать их со знакомыми мне высокоуровневыми языками.

Вот некоторые вопросы, ответы на которые мне хотелось найти:

— Почему расширения для CPython надо писать на Python или на C?
— Если C-расширения компилируются в общие библиотеки, то что такого особенного в этих библиотеках? Что позволяет загружать их из Python?
— Как воспользоваться ABI между CPython и C, чтобы суметь расширять возможности CPython, пользуясь другими языками?

Прим. Wunder Fund: в этой длииинной статье вы найдете ряд полезных советов по работе с Docker, как общего характера, так и Python-специфичных. Хоть мы и давно используем Docker в работе, про некоторые советы мы подумали "а что, так можно было?". Советуем вначале пролистать статью, и отметить штуки, которые покажутся актуальными для вашей текущей ситуации.

Прим. Wunder Fund: в статье рассказано, зачем появилась и существует глобальная блокировка интерпретатора в Питоне, как она работает, и как она влияет на скорость работы Питона, а также о том, куда в будущем, вероятно, будет двигаться Питон. У нас в фонде почти всё, что не написано на плюсах — написано на Питоне, мы пристально следим за тем, куда движется язык, и если вы тоже — вы знаете, что делать )

Как вы, наверное, знаете, глобальная блокировка интерпретатора (GIL, Global Interpreter Lock) — это механизм, обеспечивающий, при использовании интерпретатора CPython, безопасную работу с потоками. Но из-за GIL в конкретный момент времени выполнять байт-код Python может лишь один поток операционной системы. В результате нельзя ускорить Python-код, интенсивно использующий ресурсы процессора, распределив вычислительную нагрузку по нескольким потокам. Негативное влияние GIL на производительность Python-программ, правда, на этом не заканчивается. Так, GIL создаёт дополнительную нагрузку на систему. Это замедляет многопоточные программы и, что выглядит достаточно неожиданно, может даже оказать влияние на потоки, производительность которых ограничена подсистемой ввода/вывода.

Здесь я опираюсь на особенности CPython 3.9. По мере развития CPython некоторые детали реализации GIL, определённо, изменятся. Материал опубликован 22 сентября 2021 года, после публикации в него внесено несколько дополнений.

Прим. Wunder Fund: В статье описаны базовые подходы к работе с корутинами в 20м стандарте С++, на паре практических примеров разобраны шаблоны классов для промисов и фьючеров. По нашему скромному мнению, можно было бы реализовать и поизящнее. Приходите к нам работать, если имеете сильные мнения о корутинах хе-хе.

Возникает такое ощущение, что тема реализации корутин в C++20 окутана серьёзной неопределённостью. Полагаю, это так из-за того, что в проекте технической спецификации C++20 сказано, что работа над механизмами корутин всё ещё ведётся, в результате в данный момент нельзя ожидать полной поддержки этих механизмов компиляторами и стандартной библиотекой.Множество проблем, вероятно, возникает из-за отсутствия официальной документации по работе с корутинами. Нам дали синтаксическую поддержку корутин в C++ (co_yield и co_return), но не всё то, что я счёл бы признаками их полной библиотечной поддержки. В стандартной библиотеке имеются хуки и базовый функционал поддержки корутин, но нам приходится самостоятельно встраивать всё это в наши собственные классы. Я ожидаю, что полная поддержка корутин-генераторов появится в C++23.

Если вы — Python- или C#-разработчик и ожидаете увидеть в C++ простую механику работы с корутинами, то вас ждёт разочарование, так как фреймворк общего назначения C++20 недоработан. Учитывая это, можно отметить, что в интернете имеется множество публикаций, в состав кода, обсуждаемого в которых, входит шаблонный класс, поддерживающий корутины-генераторы. В этом материале вы найдёте шаблон корутины, применимый на практике, а также примеры кода. Всё это предваряется общими сведениями о корутинах.

Прим. Wunder Fund: в этой статье из блога VSCode рассказана увлекательная алгоритмическая история о решении проблемы раскрашивания скобок. Господам удалось достичь значительногоускорения этого процесса. Нам самим очень нравится решать подобные задачи при работе над торговой системой, а если они вам тоже интересны, то пишите:)

Когда имеешь дело с глубоко вложенными скобками в Visual Studio Code — может быть непросто понять то, у каких скобок есть пары, а у каких — нет.

Для того чтобы упростить решение этой задачи, в 2006 году пользователь CoenraadS разработал восхитительное расширение для VS Code — Bracket Pair Colorizer, позволяющее раскрашивать парные скобки, и опубликовал его в VS Code Marketplace. Это расширение стало весьма популярным, теперь оно, с более чем 6 миллионами установок, входит в 10 самых скачиваемых расширений.

Для того чтобы решить проблемы, касающиеся производительности и точности работы расширения, в 2018 году CoenraadS выпустил расширение Bracket Pair Colorizer 2, которое тоже стало популярным и было установлено более 3 миллионов раз.

Я собираюсь рассказать историю о еде, раскрывающую различные возможности конкурентного и параллельного выполнения кода в Python.

Прим. Wunder Fund: для задач, где не критичны экстремально низкие задержки — при сохранении и обработке биржевых данных, мы используем Питон, и естественно применяем описанные в статье подходы. Статья будет полезна начинающим разработчикам.

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

А именно, я раскрою здесь следующие вопросы:

▪ Отличия конкурентности от параллелизма.
▪ Различные варианты организации конкурентного выполнения кода (многопоточность, модуль asyncio, модуль multiprocessing, облачные функции) и их сравнение.
▪ Сильные и слабые стороны каждого подхода к организации конкурентного выполнения кода.
▪ Выбор конкретного варианта организации конкурентного выполнения кода с использованием специальной блок-схемы.

В этом материале я хочу сделать подробный обзор такого понятия, как «перплексия» («коэффициент неопределённости»), так как оно применяется в обработке текстов на естественном языке (Natural Language Processing, NLP). Я расскажу о двух подходах, которые обычно используются для определения этого понятия, и о тех идеях, которые лежат в основе этих подходов.