Алгоритмы *

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

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

Меня зовут Алмаз Хуснутдинов. Я занимаюсь проектом "Теория цифрового интеллекта" - бесплатный и открытый проект, направленный на развитие мышления в направлении создания программы, обладающей интеллектом.

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

Содержание: идея слоя прямого распространения, новые операции: операция умножения и деления матрицы на число, линейный слой и дополнительный функционал, задача «логическое или», как происходит обучение линейного слоя и набор данных digits.

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

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

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

В предлагаемой вниманию читателей модели роль исследуемого числа отводится модулю N КЧКВ, т.е. N задан (может быть большим) и требуется в одной из задач отыскивать делители N.

Для моделирования выбрана простая зависимость (линейная) N = х1 + хо. Очевидно, что список представлений такой модели конечен, и для чисел ограниченного размера может быть легко построен в форме таблицы, содержащей S =½ (N –1) строк. Модель названа списочной многострочной моделью и кратко обозначается (СММ, СМ-модель).

Игра Fillwords популярна благодаря своей простоте и увлекательности: она развивает словарный запас, тренирует внимательность и логику. Миллионы игроков по всему миру используют её как способ расслабиться и одновременно размять мозг, а сложные уровни делают процесс поиска слов настоящим вызовом.

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

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

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

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

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

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

"Лежит на струнах пыль
Ржавеет под окном
Разбитый телевизор
Ты сгладил все углы
И жизнь твоя сплошной
Проклятый компромисс
Ни вверх ни вниз"

Так поёт группа Би-2 в песне "Компромисс" и с ними трудно не согласиться. Наша жизнь действительно состоит из сплошных проклятых компромиссов между несколькими решениями. Мы пытаемся найти максимально дешёвую, но качественную электронику, ищем экономичный, но быстрый автомобиль и красивого, но надёжного партнёра для отношений.

Каждая из этих повседневных задач заключается в поиске оптимума нескольких конфликтующих между собой функций. Это называется многокритериальная оптимизация (Multi-objective optimization). В этой статье мы ближе познакомимся с этой задачей, посмотрим на 2 популярных метода её решения и узнаем, как с её помощью заработать на криптовалюте с минимальным риском.

Structured Concurrency это одна из главных фишек Kotlin Coroutines, позволяющая оперировать иерархиями корутин через единый интерфейс, благодаря такой организации можно легко отменить сразу все корутины, имея ссылку только на самый высокоуровневый объект. В этой статье я разберу две базовые штуки на основе которых строится Structured Concurrency - CoroutineContext и CoroutineScope. Поехали!

В реляционных СУБД есть дефолтный тип индекса — B‑Tree: Tree в названии однозначно указывает на дерево, ну а В это, наверно, Binary? Или Balanced? Или Balanced Binary? Почему‑то долгое время я полагал, что это Balanced Binary, и эта версия даже «работала». На деле всё куда интереснее, предлагаю проследовать под кат, чтобы посмотреть на этот на самом деле скорее низкорослый куст и сравнить его с Red‑Black Tree на Java.

Как уместить словарь размером 250 КБ в 64 КБ ОЗУ с возможностью выполнения быстрого поиска? Для справки: даже современные методики сжатия наподобие gzip -9 не могут сжать этот файл до размера меньше 85 КБ.

В 1970-х Дуглас Макилрой столкнулся с этой непростой задачей при реализации проверки правописания для Unix в AT&T. Из-за ограничений компьютера PDP-11 весь словарь должен был умещаться всего в 64 КБ ОЗУ. Кажется, подобную задачу решить невозможно.

Вместо того, чтобы использовать стандартные методики сжатия, Дуглас воспользовался преимуществами свойств данных, разработав алгоритм сжатия, отличавшийся от теоретического минимума сжатия всего на 0,03 бита. И по сей день этот рекорд остаётся непревзойдённым.

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

Итак, это продолжение моих попыток в новый алгоритм решения Судоку. Начало было тут, на текущий мой взгляд довольно глупое и неудачное.

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

Hello, world! Это вторая часть хабростатьи Smart Engines про быструю фильтрацию изображений. Да-да, создавая топовый продукт по распознаванию документов, нам приходится разбираться в методах обработки изображений на экспертном уровне (иначе не получилось бы распознать изображение паспорта за 150 мс на мобильном телефон). В предыдущей части мы начали обсуждать быстрые аппроксимации гауссовского фильтра, которым была посвящена наша недавняя публикация в научном журнале MDPI Applied Sciences [1]. О том, как работает оригинальный фильтр Гаусса, мы уже писали, сейчас мы только напомним о его использовании всюду, где возникает обработка изображений: от редактирования фотографий на смартфоне – для размытия фона за объектом в режиме "портрет", до анализа рентгеновских снимков – чтобы убрать шум и улучшить читаемость изображения.

[Прим. пер.: на Хабре уже был перевод этой статьи, но незавершённый примерно на четверть.]

Неправда.

Калькулятор должен показывать результат введённого математического выражения. А это намно-о-ого сложнее, чем кажется.

В этом посте я расскажу величайшую историю о разработке приложения-калькулятора.

На изображении выше показан калькулятор из iOS.

Заметили что-нибудь?

Он посчитал неправильно.

(10¹⁰⁰) + 1 − (10¹⁰⁰) равно 1, а не 0.

Android считает правильно. А причина, по которой он это делает, абсолютно безумна.

Изначально, когда я решил написать компилятор за выходные, я решил, что нет смысла заморачиваться, и использовал сторонний лексический / синтаксический анализатор. Мой выбор пал на SLY, довольно известную библиотеку. И действительно, пара часов работы, и мой компилятор прекрасно строил синтаксические деревья из исходного кода на wend. Я пытался было заглянуть под капот, утонул в море технических терминов (LL(1), LR, LALR(1) и тому подобное), и решил, что парсинг своими руками - это не для меня, теория формальных языков меня слабо интересует. Однако же в итоге выяснилось, что базовый синтаксический анализатор - это не так сложно, и я закатал рукава.

Зачастую в программисткой практике необходимо нагенерировать множество случайных строк. Либо для тестового примера, либо как источник обезличивания, либо просто, чтобы наполнить разработческую БД. Задача, в принципе, понятная и легкая для любого уровня программиста. Но если это нужно сделать быстро, например, если набор случайных строк нужен здесь и сейчас, то можно использовать предлагаемое решение. Строки получаются разной длины, со 100%-ной хаотичностью (полностью несортированные). Выглядят эти строки вот так (спойлер):

Наверное, большинству людей, связанных с программированием игр, известен алгоритм AStar.

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

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

Данный пробел я постараюсь восполнить в рамках этой статьи.

Всем привет👋🏻

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

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

Присаживайтесь поудобнее, заварите кофейку и запаситесь печеньки, нам предстоит интересный путь🍪

Год назад мне пришлось взять на себя курс лекций по теории компиляторов. Вы встречались некомпетентными преподавателями? Это я, здравствуйте! Прежде чем учить других, я всё-таки решил заглянуть в учебник сам, и это вылилось в серию статей "компилятор за выходные" (да, я помню, что за мной должок с описанием лексера/парсера). В итоге я уложил компилятор со мной придуманного си-подобного языка на GNU ассемблер в шестьсот строк кода, причём без внешних зависимостей, включая парсинг.

Всё бы хорошо, вроде работает, но кажется, самое веселье осталось за бортом. Мой компилятор, по факту, это простой pretty print вокруг синтаксического дерева, подумаешь. А как работают оптимизирующие компиляторы? И поставил я себе задачу попробовать уложить игрушечный, но всё же рабочий оптимизирующий компилятор в тысячу строк кода. Как думаете, получится?

Итак, тема сегодняшнего разговора - вынос переменных из памяти в регистры, оно же оптимизационный проход mem2reg, см. кпдв.