Особенности формата хранения чисел с плавающей точкой позволяют быстро находить приближённое значение логарифма, и, за счёт этого, выполнять умножение и деление. Результат при этом будет неточным, однако может быть применимым там, где особая точность не требуется.
С каждым новым спринтом кажется, что ты просто двигаешь тикеты по доске?
Не только тебе. Когда задачи теряют смысл, проект буксует, а мотивация тает где-то между дейликом и очередными «небольшими изменениями — вот здесь, здесь и здесь», возникает закономерный вопрос: где же те самые большие задачи, в которых хочется быть? Где простор для роста, свободы и влияния?
Если честно, мы знаем ответ. Но ведь так неинтересно! Поэтому мы нарисовали комикс о том, как карьерный тупик трёх IT-специалистов — разработчика, аналитика и DevOps-инженера — внезапно превращается в портал, за которым их ждут испытания: Legacy-Хаос, техдолг и поток данных, грозящий поглотить всё живое. Чтобы пройти их, героям понадобятся не суперсилы, а кое-что куда важнее: автоматизация, гибкие подходы и возможность делать то, что имеет значение. Погружаемся в комикс — и проверим, что будет, если карьерным мечтам действительно дать пространство для развития.
Все сервисы доставки рано или поздно сталкиваются с аббревиатурой VRP. За ней скрывается сложная и важная задача оптимизации доставки. От того, насколько эффективно вы её решите, зависит и удовлетворённость клиентов, и реальные показатели бизнеса: скорость доставки, расходы на логистику.
В этой статье я расскажу о типах VRP-задач, их отличиях, и о готовых решениях, которые вы можете затестить в ваших кейсах уже сейчас. Поделюсь подходами и инструментам, которые открыл в ходе исследования темы, опытом их использования и причинами, по которым я сразу отказался от некоторых из них.
Хочу поделиться знанием, которое не является секретом, в каких-то курсах по алгоритмам оно наверняка дается, но нагуглить его совсем не просто. Поэтому пусть будет.
Алгоритм Дейкстры можно обобщить на произвольную функцию длины пути, если только она удовлетворяет трем условиям:
Монотонность. При добавлении ребра к пути, его длина не уменьшается.
Консистентность. При добавлении одинакового ребра к путям одинаковой длины, получившиеся новые пути имеют одинаковую длину.
Оптимальность префикса. Если к двум путям приписать одинаковое ребро, то кратчайший путь останется кратчайшим.
Под катом я привожу доказательство корректности обобщенного алгоритма и показываю, как его применить в задаче на литкоде: Trapping rain water II.
В этой статье я расскажу о стеке и задачах в которых он применяется. Включая задачу с заключительного этапа Всероссийской олимпиады школьников по информатике 2025 года.
Доброго времени суток.
В качестве первой статьи решил выбрать разбор реализации отечественного шифра «кузнечик». Постараюсь объяснить сложные вещи простым языком.
В качестве рабочего примера моя реализация на C.
Привет! Меня зовут Дмитрий Бандурин, я заместитель директора департамента биллинговых решений в компании «СИГМА». Моя команда регулярно выполняет нетривиальные задачи для стабильной работы высоконагруженных систем. Сегодня расскажу, как мы переработали логику обработки пакетных процессов в нашей системе массовых операций, на примере расчета дебиторской задолженности. Нам было необходимо, чтобы она справлялась с возрастающим объемом данных — и всё это в жестких временных рамках и в условиях многопоточности.
И это решит 95% проблем типичного стартапа. Как-то так повелось, что по всему СНГ и его окрестностям на работу набирают зумеров с колоссальным опытом в три года, и они начинают создавать идеальные архитектуры. Да, каждый из вас, как только получает возможность взять на себя хоть малейшую ответственность, сразу вспоминает все прочитанные и не прочитанные книги и пилит свою уникальную архитектуру, непохожую ни на что.
Зачем программисту алгоритмы?
Многие компании, нанимающие программистов, требуют от них знания алгоритмов. Некоторые даже устраивают отдельное собеседование по алгоритмам, зачастую весьма нешуточное.
Однако сами программисты нередко удивляются, зачем всё это? Действительно, работа наших коллег часто заключается в поиске и устранении ошибок в залежах legacy кода. Какие уж там алгоритмы? Даже те, кому посчастливилось участвовать в новом проекте знают, что зачастую новый проект состоит на 80% из чужого, уже кем-то написанного и найденного на просторах гитхаба кода, а новый код - это, по сути, клей и обёртки, которые позволяют склеить эти уже готовые запчасти между собой, чтобы получить заданный продукт.
Сегодня я прочитал на Хабре статью о подготовке к алгоритмическому собеседованию в Яндексе. Видно, что ребята относятся к делу всерьёз. Однако на вопрос, зачем всё таки это нужно, статья отвечает в том духе, что алгоритмическая подготовка показывает полезную готовность кандидата поотжиматься (отмечу при этом, что это не мнение Яндекса, а личное мнение человека, получившего этот опыт с обеих сторон - и кандидата и интервьювера).
Однако всё же, действительно ли основная польза алгоритмической подготовки сводится к тому, чтобы продемонстрировать работодателю свою сообразительность и готовность потратить время жизни на подготовку к собеседованиям, а в целом она не слишком полезна для нормального рабочего процесса? Или всё же алгоритмы нужны?
В моих предыдущих статьях (1, 2) я подробно рассматривал, как работает React.memo, а также делился более эффективными подходами к оптимизации производительности с помощью компоновки. Однако для глубокого понимания работы React необходимо разобраться в основном механизме, лежащем в основе всех этих оптимизаций – алгоритме согласования (reconciliation).
Согласование – это процесс, в результате которого React приводит DOM в соответствие с деревом компонентов. Именно этот механизм позволяет реализовать декларативный подход к программированию на React: вы формулируете свои намерения, а React самостоятельно определяет, как выполнить эти намерения наилучшим образом и с наименьшими затратами.
В конце января мне написал рекрутер из Яндекса с предложением пройти алгоритмическое собеседование. На тот момент у меня было решено всего 55 задач на LeetCode, из которых 50 — по SQL. Знания в области алгоритмов были практически на нуле.
Я решил взять паузу на два месяца и сосредоточиться на подготовке. В конце марта я успешно прошёл первый этап. О том, как прошли остальные этапы, расскажу ближе к концу статьи.
В этой статье я хочу поделиться своим опытом подготовки: как я готовился, какие стратегии использовал и что в итоге действительно помогло.
Может кому-то это будет интересно, даст возможность лучше подготовиться; или наоборот кто-то примет решение не участвовать.
Коротко о себе: 41 год, senior software developer, стаж > 20 лет. Однако, как я понял, эти собесы все равно для всех одинаковые, так чтоб все написанное актуально и для молодежи.
Итак, угораздило меня согласиться на т. н. «Weekend Offer на позицию разработчика на Kotlin». Вообще‑то мне больше нравится Scala, и опыта по ней гораздо больше, но рекрутерша была сильно настойчива, и я решил обновить экспиренс, а возможно, и прибавку в деньгах. И вот что было дальше.
Приветствую! Меня зовут Егор Ершов, я руковожу группой «Цветовая вычислительная фотография» в AIRI, а также заведую сектором репродукции и синтеза цвета ИППИ РАН. Область моих научных интересов касается способов регистрации и обработки изображений, что в той или иной степени касается любого человека, кто хоть раз пользовался камерой, монитором или проектором.
Вычислительная фотография лежит на стыке сразу нескольких дисциплин: физики, физиологии, компьютерных наук. Из‑за этого в ней ещё много сложного, но вместе с тем интересного и неизвестного. Я подготовил полноценный курс по алгоритмам вычислительной фотографии для МФТИ и ВШЭ, но мне также хотелось бы поделиться со всеми желающими его материалами в текстовом формате.
Этот курс посвящен как феномену цвета, механизмам его восприятия, исследованию зрительной системы человека, так и непосредственно алгоритмам цветовой вычислительной фотографии. Но в этой статье я бы хотел в общих чертах обрисовать проблему регистрации изображений, а также дать введение в теорию цвета, которая потребуется в дальнейших частях.
Наверное, я очень опоздал с изучением CUDA. До недавнего времени даже не знал, что CUDA — это просто C++ с небольшими добавками. Если бы я знал, что изучение её пойдёт как по маслу, я бы столько не медлил. Но, если у вас есть багаж привычек C++, то код на CUDA у вас будет получаться низкокачественным. Поэтому расскажу вам о некоторых уроках, изученных на практике — возможно, мой опыт поможет вам ускорить код.
Привет, Хабр!
Когда-то я писал веб-приложения. Решал задачи бизнеса, деплой в прод, REST, тесты, метрики, кубики. Всё было нормально. Но в какой-то момент мне стало… скучно.
Да, задачи были интересными. Команда — отличной. Но где-то внутри появилась пустота. Хотелось делать что-то настоящее. Осязаемое. Что-то, где за твоим кодом — больше, чем UI и API. Хотелось влиять на реальный мир.
Так я попал в мир электропривода.
На хабре уже пару раз упоминался дизеринг, но в довольно узком ключе. Здесь, я хоть и буду делать упор на применение дизеринга в графике, я хочу продемонстрировать его недооценённость, из-за чего его снова и снова переизобретают.
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Сегодняшней статьей с простым использованием агрегирующих функций завершаем цикл. В итоге, PostgreSQL показал себя как очень удобное средство для решения разных алгоритмических задач, лишь несколько раз заставив нас изобретать совсем уж нетипичные подходы к написанию SQL-запросов.
Как запустить поисковый сервис, если у тебя всего три недели, а данные нужно агрегировать с десятков источников, каждый из которых работает по своим правилам? Как обойти жёсткие лимиты партнёров, которые ограничивают запросы в 500 RPM и p99 до 5 секунд, когда для быстрой загрузки первых результатов нужно минимум 1000 RPM? Как справиться с геопоиском, когда традиционные решения вроде Elasticsearch не подходят?
В 2022 году 2ГИС запустил сервис бронирования Отелло, и перед нами стояла амбициозная цель — не просто создать поиск, а сделать его быстрым, надёжным и масштабируемым, чтобы успеть занять место на рынке. Спойлер: мы справились. В этой статье расскажем, как именно.
Материал будет полезен бэкенд-разработчикам и продакт-менеджерам, которые сталкиваются с задачами интеграции сложных данных, высокой нагрузки и оптимизации поисковых алгоритмов. А если тебе понравится наш проект, рассмотри нашу вакансию — мы в поисках Senior Golang Engineer.
Многие знакомы с играми "Wordle" или с российским аналогом "5 букв" от Т-Банка, суть которых в том, чтобы отгадывать пятибуквенные слова. Словарного запаса среднестатистического человека вполне хватает для успешного прохождения этих игр, но иногда человеку тяжело подобрать загаданное слово, хотя он точно его знает.
Кажется, что компьютер справлялся бы с этой игрой очень хорошо, но насколько именно хорошо?
В рамках этой статьи мы подробно исследуем российскую версию игры "5 букв":
• Придумаем различные алгоритмы прохождения игры
• Посмотрим, как различные алгоритмы проходят игру на разных словарях
• Сравним результаты и сделаем выводы
В статье будут рассмотрены как теоретические расчеты, так и вполне применимые для человека на практике советы и подходы.
