Несмотря на известность алгоритма поразрядной сортировки, в интернете сложно найти приличную его реализацию на языке C++ (честно говоря, думаю, что и на других языках тоже). Почти всё, что находится поисковиками, чудовищно либо в плане кода, либо в плане эффективности. А чаще всего плохо и то, и другое.

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

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

Судьба завела меня (программиста практика, в основном использующего C#) на проект, в котором основной функционал разрабатывается на Go.

Изучая Go обратил внимание на непривычную практику обработки ошибок. Почитав разъяснения в статьях Ошибки — это значения и в Почему «ошибки это значения» в Go отметил, что предлагаемые там решения заставляют вспомнить одну особенность Visual Basic, которую очень не лестно комментировали программисты.

Что такое USDT и зачем он нужен
USDT, или Tether, — это стейблкоин. Это значит, что в отличие от обычных криптовалют, цена на него не скачет вверх-вниз. Один токен USDT всегда равен примерно одному доллару США. Почему это удобно? Представь, что у тебя есть биткоины — сегодня они стоят много, а завтра — на 20% меньше. Не очень приятно, да? А USDT стабилен. Это как цифровой доллар, только без банков.

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

Почему именно USDT популярен среди москвичей

Представь себе: ты в Москве, и хочешь перевести деньги родственнику за границу. Через банк — долго, куча проверок и комиссий. А с USDT всё просто: за пару минут токены улетят хоть в Индию, хоть в Аргентину. Без лишних вопросов.

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

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



В первом случае поиск занимает A?ⁿAⁿ времени, во втором — Aⁿ.

Степени обозначают повторяемость строк, то есть A?³A³ — это то же самое, что и A?A?A?AAA. Графики отражают время, требуемое для поиска через регулярные выражения.

Обратите внимание, что в Perl для поиска строки из 29 символов требуется более 60 секунд. А при втором методе — 20 микросекунд. Это не ошибка. При поиске 29-символьной строки Thompson NFA работает примерно в миллион раз быстрее. Если нужно найти 100-символьную строку, то Thompson NFA справится менее чем за 200 микросекунд, а Perl понадобится более 10¹⁵ лет. Причём он взят лишь для примера, во многих других языках наблюдается та же картина — в Python, PHP, Ruby и т. д. Ниже мы рассмотрим этот вопрос более детально.

Наверняка вам трудно поверить приведённым данным. Если вы работали с Perl, то вряд ли подмечали за ним низкую производительность при работе с регулярными выражениями. Дело в том, что в большинстве случаев Perl обращается с ними достаточно быстро. Однако, как следует из графика, можно столкнуться с так называемыми патологическими регулярными выражениями, на которых Perl начинает буксовать. В то же время у Thompson NFA такой проблемы нет.

Возникает логичный вопрос: а почему бы в Perl не использовать метод Thompson NFA? Это возможно и следует делать, и об этом пойдёт далее речь.

Как-то увидев очередную статью на Хабре, посвященную для меня совершенно новому и неизведанному языку Go, решил попробовать, что это за зверь и с чем его едят (В основном, конечно, понравился логотип). Конечно, язык имеет много возможностей и достаточно удобен. Но что меня сразу удивило, это отличный от C-подобных языков принцип объявления переменных, а именно тип переменных описывается справа от имени переменной. У меня как человека, практически выросшего на С, это вызывало удивление. Потом я конечно вспомнил Pascal, что там тоже тип переменной был справа. Заинтересовавшись этим вопросом, я попытался разобраться, почему используется тот или иной синтаксис описания типа переменных в этих 2-х языках.

Навеяно вот этой статьей.

Существует три мнения относительно производительности C++ и C#.

Те кто знают (или думают что знают) C++ считают, что C++ в разы или даже на порядки быстрее.
Те кто знают C++ и C# знают, что для обычных задач быстродействие C++ не нужно, а там где нужно — можно и C#-код заоптимизировать до невозможности. Верхний предел оптимизации у C++ выше, чем у C#, но такие рекорды никому не нужны.
Те кто знают только C# — никогда не испытывали проблем с его быстродействием.

Люди из первой категории все время пытаются доказать свою правоту. При этом приводят примеры оптимизированного кода на C++ и самого пессимизированного кода на C#.

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

К своему большому удивлению, я не нашел простейших и прозрачных примеров а-ля «Hello world». Да, есть coursera и потрясающий Andrew Ng, есть статьи про нейронные сети на хабре (советую остановиться тут и прочитать, если не знаете самых основ), но нет простейшего примера с кодом. Я решил создать перцептрон для распознования «AND» или «OR» на своем любимом языке C++. Если вам интересно, добро пожаловать под кат.

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

Disclaimer: идеи в этом посте более умозрительные, чем в предыдущих. Я буду рад дискуссии.

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

В конце предыдущего поста я просуммировал недостатки существующих интервалов:

• интервалы с ограничителями и бесконечные интервалы генерят плохой код
• им приходится моделировать более слабые концепции, чем они могли бы
• легко можно передать бесконечный интервал в алгоритм, который его не переварит
• их трудно использовать
• интервалы, которые могут быть бесконечными или очень большими, могут вызвать переполнение в difference_type

Первая проблема особенно трудная, поэтому начнём с неё.

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

Бесконечные интервалы

Необходимость бесконечных интервалов обосновать чуть сложнее. Программисты на С++ редко сталкиваются с бесконечностями. В других языках это случается сплошь и рядом. В Haskell можно создать бесконечный список целых чисел, просто набрав [1..]. Это просто «ленивый список», элементы в котором создаются по требованию. Все бесконечные интервалы ленивые.

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

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

Как мы уже писали конференцию C++ Siberia в Новосибирске будет открывать Эрик Ниблер. Чтобы поближе познакомить Хабр с этим замечательным человеком, мы решили перевести цикл его статей об интервалах. Сейчас Эрик работает над реализацией библиотеки Ranges по гранту, полученному от комитета стандартизации.

В последнее время я плотно занимался интервалами, и мне стало понятно, что это нечто большее, чем просто пара итераторов. В нескольких постах я хочу объяснить понятие интервала, описать несколько интервалов, которые не получается просто или эффективно выразить при помощи STL: интервалы с ограничителями и бесконечные интервалы. В этом посте мы рассмотрим задачу представления интервалов с ограничителями через итераторы STL.

Эрик Ниблер — известный эксперт по C++, один из важных контрибьюторов Boost, человек, который добавил в стандарт библиотеку Ranges.

26 августа в рамках C++ Party Эрик выступит в новосибирском офисе Яндекса, где как раз расскажет о библиотеке и поговорит с гостями о новых стандартах C++.



Я заранее поговорил с Эриком и задал ему несколько вопросов от себя и коллег о том, каким он видит настоящее и будущее C++, что ему кажется самым важным в программировании, будет ли в C++ когда-нибудь нормальный менеджер пакетов, модули, что будет со стандартной библиотекой и о многом другом.

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

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

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

1) Corona SDK

Богатый инструментарий для создания игр и приложений за рекордно короткое время



Обеспечивает возможность очень быстрой разработки. Элегантный API упрощает добавление сложных функций, технологический процесс позволяет сразу же видеть внесённые изменения, сама же разработка идёт на Lua – простом для изучения языке. Всё это приводит к рекордной скорости разработки.

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

От переводчика:
Это вольный перевод статьи «Purify code using free monads» Габриэля Гонзалеса, посвященный использованию свободных монад для представления кода как синтаксического дерева с последующей управляемой интерпретацией.
На хабре имеются другие статьи Габриэля — «Кооперативные потоки с нуля в 33 строках на Хаскеле» и «Чем хороши свободные монады».
Для прочтения этой статьи необходимо знать, что такое свободная монада и почему она является функтором и монадой. Узнать об этом можно в указанных двух переводах или в статье, на которую ссылается сам автор.
Все замечания переводчика выделены курсивом.
По всем замечаниям, связанным с переводом, обращайтесь в личку.

Опытные программисты на Хаскеле часто советуют новичкам делать программы настолько чистыми, насколько это возможно. Функция называется чистой, если она детерминированная (возвращаемое значение однозначно определяется значениями всех формальных аргументов) и не имеет побочных эффектов (то есть не изменяет состояние среды исполнения). В классической математике, λ-исчислении и комбинаторной логике все функции чистые. Чистота предоставляет множество практических преимуществ:

• можно формально доказать какие-то свойства написанного кода,
• кроме того, можно легко обозревать код и сказать, что он делает,
• наконец, можно прогнать через QuickCheck.

Для демонстрации я буду использовать такую простенькую программу echo:

import System.Exit

main = do x <- getLine
          putStrLn x
          exitSuccess
          putStrLn "Finished"

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

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

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

Microsoft рапортует об успехах: в первый же день выхода новой, десятой версии Windows, её установили на 14 миллионов компьютеров. В течение нескольких недель автоматическое обновление станет доступным для всех желающих обновиться обладателей 7-й и 8-й версий операционки. Параллельно Microsoft выпускает патчи с исправлениями к ошибкам, которые были найдены в последние дни.

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

Из сюрпризов, которые ожидали новых пользователей системы, можно отметить следующие.

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

Скачивание дистрибутива Windows сделано по системе peer2peer – так Microsoft подстраховалась от перегрузки своих серверов. Эта система, которую впервые представил протокол BitTorrent, давно используется разными компаниями для распространения цифрового контента (например, для купленных цифровых версий игр). Если по каким-то причинам вам жалко вашего исходящего трафика, эта функция отключается в настройках.

Содержание

1. Что такое тензор и для чего он нужен?
2. Векторные и тензорные операции. Ранги тензоров
3. Криволинейные координаты
4. Динамика точки в тензорном изложении
5. Действия над тензорами и некоторые другие теоретические вопросы
6. Кинематика свободного твердого тела. Природа угловой скорости
7. Конечный поворот твердого тела. Свойства тензора поворота и способ его вычисления
8. О свертках тензора Леви-Чивиты
9. Вывод тензора угловой скорости через параметры конечного поворота. Применяем голову и Maxima
10. Получаем вектор угловой скорости. Работаем над недочетами
11. Ускорение точки тела при свободном движении. Угловое ускорение твердого тела
12. Параметры Родрига-Гамильтона в кинематике твердого тела
13. СКА Maxima в задачах преобразования тензорных выражений. Угловые скорость и ускорения в параметрах Родрига-Гамильтона
14. Нестандартное введение в динамику твердого тела
15. Движение несвободного твердого тела
16. Свойства тензора инерции твердого тела
17. Зарисовка о гайке Джанибекова
18. Математическое моделирование эффекта Джанибекова

Введение

В прошлый раз мы рассмотрели один из способов получения дифференциальных уравнений движения твердого тела исходя из принципа Даламбера. Мы остановились на общей форме уравнений движения


Однако, внимательно взглянув на эти уравнения, меня следовало бы раскритиковать — дело в том, что в данных уравнениях число неизвестных слишком велико. К неизвестным следует отнести ускорение полюса и угловое ускорение тела , а также реакции связей . И если движение тела ограничено хотя бы одной связью, число неизвестных величин в (1) и (2) превышает число уравнений.

Это происходит потому, что левая часть уравнений (1) и (2) содержит ускорения, вычисляемые для случая свободного движения тела, то есть в них имеются избыточные координаты. Поэтому, систему (1), (2) следует дополнить уравнениями связей, описывающими ограничения, налагаемые связями на координаты, скорости и ускорения точек тела.

Этим мы сейчас и займемся — посмотрим, во что превращаются уравнения (1) и (2) при добавлении уравнений связей, и что дают нам полученные уравнения в практическом смысле.

Peter Welch
30 апреля 2014 г.
Об авторе. Peter Welch писатель и программист, автор книги «And Then I Thought I Was a Fish», автор блога «Still Drinking».


Изображение: Joe Raedle/Getty Images

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

Они правы. Мордор — отстой, и копание тоннеля гораздо трудозатратнее, чем тыкание в клавиши, если конечно вы не муравей. Но для галочки, давайте договоримся о том, что стресс и безумие — это плохо? Отлично.

^{We can save the day from dark, from bad
There's no one we need}

Многие из вас используют VPN или прокси в повседневной жизни. Кто-то использует его постоянно, получая доступ к заблокированным на государственном или корпоративном уровне ресурсам, многие используют его изредка, для обхода ограничений по географическому положению. Как вы можете знать, крупные интернет-игроки в сфере стриминга видео, музыки и продажи игр никогда не любили пользователей, которые легко обходят географические ограничения, разблокируя недоступный в их стране контент, или совершая покупки заметно дешевле. За примерами не нужно далеко ходить: Netflix изменил свое соглашение об использовании, добавив пункт о блокировке VPN, всего 2 месяца назад; Hulu тоже грешил блокировкой пользователей, а Steam вообще подозрительно смотрит на не-русскоязычных пользователей из России. В последнее время, компании пытаются блокировать уже не конкретных пользователей, а сами IP-адреса VPN-сервисов, создавая определенные неудобства уже самому VPN-сервису и его пользователям. Похоже, они не используют никаких спецсредств, а блокируют выборочно и вручную. Хоть я и не поддерживаю какие-либо блокировки вообще, меня заинтересовала техническая часть вопроса: можно ли как-то определить использование прокси-серверов и VPN со стороны сервера, не прикладывая особых усилий?
Можно, при определенных условиях. И достаточно точно.