Python *

Как переводчик-редактор, я интересуюсь темой NLP и автоматизации рутины бюро переводов. Изучая вопрос того, как смысл слов превращается в векторы, наткнулся на эту обзорную статью. Статья мне показалась изложенной доступно, поэтому я перевел ее для удобства других коллег. Работоспособность большей части кода проверял, вроде работает (см. Jupiter Notebook). Надеюсь, будет полезно.

===

Технологии NLP — Natural Language Processing, обработки естественного языка — позволяют компьютерам обрабатывать человеческий язык, понимать его значение и контекст, а также связанные с ним эмоциональную окраску и намерения, и далее, использовать эти данные для создания чего-то нового.

Как сделать слова понятными для компьютеров? Используется векторизация. Рассмотрим несколько техник такой векторизации.

В большинстве западных стран применяется прогрессивная шкала налогообложения про которую ходит много легенд (вполне обоснованных, но есть нюансы) какие большие налоги получаются по сравнению с Россией с плоской шкалой 13%. В этой статье мы обзорно рассмотрим налоговые системы десяти стран Европы (в целях простоты рассматриваются только страны Западной Европы и из рассмотрения исключаются карликовые государства, а также Швейцария, потому что там всё слишком сложно): Франция, Германия, Италия, Испания, Ирландия, Нидерланды, Бельгия, Португалия, Австрия, Великобритания.

Рассматривать будем НДФЛ. На мой взгляд, это самый субъективный налог, так как пенсионные, страховые и прочие отчисления конвертируются непосредственно в некую твёрдую сумму (например, пенсии, которую будет человек получать в старости). А вот именно НДФЛ идёт в некий "общий котёл", на который потом финансируются правительство, органы правопорядка, система образования и т. д. Читателям статьи следует держать в уме, что в Европе принято указывать сумму зарплаты не только до вычета НДФЛ, но и до вычета других отчислений, поэтому данную статью нельзя использовать для оценки итоговой суммы к выплате на руки, только для сравнения подоходного налога.

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

Анализирование

Как динамическое программирование может упростить нашу жизнь? Как можно оптимизировать решение задач?

Сегодня мы разберем динамическое программирование на пальцах с примерами на Python!

Усаживайтесь поудобнее, леди и джентльмены!

Всем привет, меня зовут Михаил, я младший разработчик в компании БФТ-Холдинг. Под катом делюсь кейсом, который недавно реализовал. В нем я написал консольное приложение, которое упростило сбор статистики для аналитиков и тестировщиков.

Привет, Хабр!

На связи Горбачёв Никита и Скиданова Анна, участники профессионального сообщества NTA.

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

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

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

Для асинхронного python-кода существует конечное количество специфических "узких мест", которые лучше перечислить заранее.

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

Рассказываю о том, как писал интерпретатор языка Brainfuck на Python (с показом исходного кода и его объяснения).

Лексикографический симлекс-метод.

Решение задачи линейного программирование симлекс-методом и лексикографическим симлекс-методом на Python!

Уже лет 50, со времён выхода первого издания «Языка программирования Си» Кернигана и Ритчи, известно, что «числа с плавающей запятой» одинарной точности имеют размер 32 бита, а числа двойной точности — 64 бита. Существуют ещё и 80-битные числа расширенной точности типа «long double». Эти типы данных покрывали почти все нужды обработки вещественных чисел. Но в последние несколько лет, с наступлением эпохи больших нейросетевых моделей, у разработчиков появилась потребность в типах данных, которые не «больше», а «меньше» существующих, потребность в том, чтобы как можно сильнее «сжать» типы данных, представляющие числа с плавающей запятой.

Я, честно говоря, был удивлён, когда узнал о существовании 4-битного формата для представления чисел с плавающей запятой. Да как такое вообще возможно? Лучший способ узнать об этом — самостоятельно поработать с такими числами. Сейчас мы исследуем самые популярные форматы чисел с плавающей запятой, создадим с использованием некоторых из них простую нейронную сеть и понаблюдаем за тем, как она работает.

Привет, Хабр! Меня зовут Катерина, я инженер по автотестированию в команде онлайн-кинотеатра PREMIER и сегодня я хотела бы поделиться с вами своим опытом в написании API автотестов на Python. Я работаю в сфере автотестирования уже довольно давно и на практике встречаю проекты из разных сфер деятельности (банкинг, ритейл, телекоммуникации, строительство, развлечения и др.) зачастую, работая над ними, я сталкивалась с одной общей проблемой - код автотестов был тяжелым в понимании и плохо масштабируемым. Приходилось его капитально рефакторить, а это совсем невесело;) В этой статье  я хочу поделиться советами, как сделать ваш код более «чистым», легким в понимании и расширении. Мне всегда хочется думать, что тот, кто будет работать с моим кодом в будущем, будет думать обо мне и моём коде в положительном ключе, а не ругаться на него. Если вы разделяете мою философию, прошу под кат.

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

Но что, если вы собираете автономно работающее устройство с микрокомпьютером, такое как как радиоуправляемый вездеход, робот присутствия, устройство управления шлагбаумом, систему IoT, турникет или что-то подобное?

Было бы неплохо оснастить это устройство чем-то, похожим по функциональности на смартфон. Тогда вы смогли бы определять его координаты GNSS, обмениваться данными через GPRS, Bluetooth или SMS, а также просто позвонить на свое устройство по телефону и поговорить с ним (или с тем, кто стоит рядом).

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

В этой статье мы расскажем о том, как настроить обмен данными по каналам GPRS мобильных провайдеров между микрокомпьютерами Raspberry Pi или Repka Pi с сервером, размещенном в интернете. Для обмена будем использовать модуль GSM/GPRS/GNSS Bluetooth HAT.

Привет, Хабр! В этой статье я хотел бы поделиться опытом создания своего языка программирования.

Предыстория

Мне 14. Обучаясь на втором году Яндекс Лицея, нужно было написать несколько проектов. Первым из них стал проект на PyQT5. Я долго думал над идеей и вспомнил, что летом я хотел создать свой язык, но у меня этого не получилось (Тогда я не понимал как работает парсер и абстрактное синтаксическое дерево, поэтому забросил). И вот, мне пришла идея - сделать свой язык программирования и написать для него IDLE (т.к. тема проекта все таки QT). Ещё полгода назад я изучал асинхронность и многопоточность, поэтому именно одну из этих идей я хотел воплотить в своём языке. В данной статье я хотел рассказать устройство интерпретируемых языков и как их создать.

Прошлая моя статья набрала хороший отклик.

И сегодня я решил написать продолжение той статьи.

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

Я надеюсь вам понравятся мои изменения и сама статья!

Привет, Хабр!

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

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

Первые идеи SSO зародились в конце 1990-х, когда корпоративные сети стали более сложными, и потребность в централизованном управлении доступом стала очевидной. Это был период, когда организации начали искать способы упростить управление учетными записями для своих сотрудников.
В начале 2000-х было активное развитие технологий SSO. Организации начали внедрять SSO для упрощения доступа к корпоративным приложениям и ресурсам. Это также был период появления стандартов, таких как Kerberos, который лег в основу многих ранних реализаций SSO.
С развитием облачных технологий и мобильных устройств SSO начало получать ещё большее распространение. Возникли такие стандарты, как OAuth и OpenID, которые позволили SSO выйти за пределы корпоративных сетей и обеспечить интеграцию с обширным спектром внешних онлайн-сервисов и приложений.

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