Задать вопрос
  • Доказано ли, и можно ли сжать произвольные данные до 20 байтов к примеру?

    @rPman
    Объем seed для генерации универсальных данных будет больше или равен в среднем их размеру

    Отличный пример - внутри числа pi есть все последовательности данных которые в принципе могут существовать и даже есть формула которая выдает позицию, начиная с которых она есть - πfs.

    p.s. есть алгоритмы с потерей, например сжатие изображения и звука, вот тут поле не пахано да
    ну и вишенка на торте - нейронная сеть размером несколько килобайт на видеокадр позволяет сгенерировать весь видеоряд (не смог найти, на хабре была статья, понятно там качество ужасное, нейросеть не справлялась с лицами но сама идея шикарная)
    Ответ написан
    Комментировать
  • Доказано ли, и можно ли сжать произвольные данные до 20 байтов к примеру?

    @Akina
    Сетевой и системный админ, SQL-программист.
    Допустим, существует некий алгоритм, который преобразует последовательность X длины M в последовательность Y, причём существует обратное преобразование. Неважно, что это за алгоритм конкретно - сжатие, создание "зерна" и пр. Но очевидно, что:

    1. Количество вариантов последовательности X составляет K в степени M, где K - размер словаря, т.е. количество возможных различимых значений одного элемента последовательности X. В случае байтовой последовательности это байт, т.е. K=256.

    2. Каждая последовательность X после преобразования даёт последовательность Y, причём две разные последовательности X дают разные последовательности Y.

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

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

    Что же до "зерна", которое разворачивается в гигабайты - во-первых, количество финальных миров определяется количеством значений "зерна", то есть вовсе даже не такое бесконечно большое, как кажется, во-вторых, созданный образ мира содержит значительное число повторяющихся элементов, а создание копий - это немножко не декомпрессия.
    Ответ написан
    Комментировать
  • За счет чего увеличивается общая память графического процессора?

    AlexNest
    @AlexNest
    Работаю с Python/Django
    Если коротко, да память для встройки выделяется из оперативной во время инициализации Биоса.
    Да, работает примерно так как вы описали, хотя насчёт такого большого объёма сомневаюсь - сейчас делают "потолок" в 2-3 ГБ и, в таком случае, после запуска система будет видеть не все 16 а 13-14 гигабайт.
    Что касается скорости, то видеопамять непосредственно видеокарты куда быстрее оперативной памяти и оптимизирована для работы с графикой.
    Насчёт того, зачем нужна видеокарта - несмотря на то, что сейчас существует много удачных* решений, работающих на встроенной в проц видеосистеме, большинство новых технологий, доступных на ПК (трассировка, dlss,и прочее), пока что доступны только в полноценных видеокартах. К тому же, встройки это, по большей части затычка, на которой, безусловно, можно работать/играть, но при любом раскладе она будет уступать по мощности видюхам, выпущенным в то же период.
    * Как минимум последние три консоли от Сони, xbox (кроме самого первого), steam deck, ну и многие другие консоли, но за их железо я не в курсе.
    Ответ написан
    Комментировать
  • За счет чего увеличивается общая память графического процессора?

    @Drno
    Мы говорим про отдельную видяху или про встройку?

    1. Имеется ввиду для встроенного видеоядра в процессор. Из оперативки
    2. Общая - общее кол памяти на видяхе. Выделенная - занятая на данный момент. ( думаю так, зависит от контекста). Но в вашем случае имеется ввиду память видяхи + видеокарты. И просто видеокарты.
    3. Отличается в разы по скорости
    4.ну если память занята, система уйдет в своп, потом процесс(игры) крашнется просто
    5.сколько можно поставить зависит от видеоядра встройки
    Видео нужна для просчет физики, отражений и прочего. Нужна потому что там чип заточенный на эти алгоритмы и он намного быстрее чем встройка в ЦП.
    Встройка подходит для базовой работы и ютубчиков.
    Если надо активно работать с видео, физикой играми - она просто не справится, тк медленная
    Ответ написан
    Комментировать
  • Какой паттерн, как организовать структуру проекта для разных форматов пикселей RGB и YUV?

    wataru
    @wataru Куратор тега Алгоритмы
    Разработчик на С++, экс-олимпиадник.
    Я бы посоветовал делать абстракцию не на уровне пикселя, а на уровне картинки. Ибо так можно оптимальнее организовывать расположение пикселей в памяти да и обрабатывать изображение быстрее. Вместо функции, которая для каждого пикселя проверяет, а что там у него брать R или Y, используют функции, которым передается plane - один канал. Что там конкретно R, G, Y, V - обычно не важно. Если вы ищете контур или сглаживаете изображение, то работа идет абсолютно одинаково в каждом канале.

    В качестве примера можно посмортреть вот тут или тут.
    Ответ написан
    Комментировать
  • Как вырезать область изображения под контуром, Алгоритм?

    wataru
    @wataru Куратор тега Алгоритмы
    Разработчик на С++, экс-олимпиадник.
    FillPolygon работает через обход в ширину.

    Сначала одним циклом покрасьте все точки контура.
    Потом берите любую точку внутри полигона, красьте ее и кладите в очередь. Пока очередь не пуста берете точку оттуда, берете 4 или 8 ее соседей и если они не покрашены еще - красите их и кладете в очередь.

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

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Берём матрицу, размером с изображение, заполняем нулями. Отмечаем единицами точки, принадлежащие линиям контура.
    Добавляем в очередь точку, заведомо лежащую внутри контура и ставим в неё единицу.
    Забираем точку из очереди, добавляем в очередь соседей этой точки (слева, справа, сверху и снизу), в которых ещё не стоит единица, и ставим в них единицы. Повторяем, пока очередь не опустеет.
    Ответ написан
    1 комментарий
  • Как заблокировать сайт ( или ссылки в поисковом запросе) в Google Chrome браузере?

    dollar
    @dollar
    Делай добро и бросай его в воду.
    Конечно же есть такие расширения.

    Даже я когда-то создал поделку на данную тему. Не знаю, работает ли сейчас, но должна работать.
    Ответ написан
    Комментировать
  • Как получить минимальную рамку кривого контура по границам контура?

    wataru
    @wataru Куратор тега Алгоритмы
    Разработчик на С++, экс-олимпиадник.
    Есть алгоритм за O(n log n), где n - количество точек в кривой.

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

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

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

    Удобно это реализовывать, если взять углы наклона всех сторон оболочки, их же сдвинутые на 90, 180 и 270 градусов и отсортировать. Далее надо перебирать рамки с такими углами наклона певрой стороны (можно в пределах [0,90) градусов). Первую рамку найдите перебором, а дальше какие-то точки надо будет сдвигать.

    Итак, весь алгоритм:
    1) построить выпуклую оболочку
    2) добавить в массив углы всех сторон и их копии повернутые на 90, 180 и 270 градусов и отсортировать, но не добавлять углы не в [0,90).
    3) для первого угла в массиве найдите 4 точки касания рамки.
    4) Для каждого отрезка углов в отсортированном массиве проверить, а надо ли сдвинуть точки касания вперед (каждую из четырех точек со своим углом), потом найти площадь рамки в известных точках с известным наклоном.

    Вместо работы с углами, для чего нужны тригонометрические функции, можно работать с векторами на единичной окружности. На отрезке углов можно легко взять середину, просто сложив два вектора-границы и нормировав. Для тернарного поиска не обязательно брать 1/3 и 2/3 на отрезке, поэтому можно так же просто просуммировать вектора с коэффициентами 1 и 2 и опять нормировать (v1+2*v2). Сортировать по углу тоже можно сравнивая вектора через векторное произведение векторов (иногда его называют псевдоскалярным).

    Чтобы найти рамку с заданным углом на точках не надо ничего пересекать (кроме ответа в конце, если вам надо координаты рамки вывести, а не только площадь найти). Надо представить прямые в виде cosa*x + sina*y + c = 0. Отсюда, зная точку (x, y) и угол прямой (a), можно найти c. cosa и sina считать не надо - это координаты вектора, перпендикулярного к известному вектору наклона прямой. Когда вы нашли два значения c для двух параллельных сторон, эти коэффициенты можно сложить - это и будет расстояние между сторонами (надо складывать, потому что cosa и sina в этих двух прямых будут с разными знаками, ведь у одной прямой угол на пол оборота больше). Остается подсчитать это два раза для перпендикулярных прямых и перемножить.

    Код для пересечения прямых в конце можно посмотреть тут.
    Ответ написан
    7 комментариев
  • Как избежать преждевременной оптимизации? Или как не зная что будет потом в проекте, обрабатывать исключения?

    @Akela_wolf
    Extreme Programmer
    Для вашей ситуации придумали интерфейсы.

    Вот смотрите, есть логика вывода (Котлин, надеюсь понятно что этот код делает):
    interface Report {
      fun getAverageTime(): BigDecimal
    }
    
    fun printReport(report: Report) {
      println("Average time: ${report.getAverageTime()}") 
    }

    Мы получаем данные из отчета. И нас в этом месте мало волнует как именно эти данные рассчитаны и как обрабатывается 0. Это логика отчета. Мало того, у нас может быть несколько разных реализаций интерфейса Report, каждая из которых обрабатывает этот случай каким-то собственным образом, вплоть до того что кидает исключение и, в результате, возникает ошибка (обработка такого исключения за рамками этого примера).

    Теперь у нас возникает необходимость добавить еще один параметр в отчет:
    interface Report {
      fun getAverageTime(): BigDecimal
      fun getCountWithZeroTime(): Int
    }
    
    fun printReport(report: Report) {
      println("Average time: ${report.getAverageTime()}") 
      println("Participants have zero-time: ${report.getCountWithZeroTime()}")
    }


    И никакой преждевременной оптимизации, только структурированный код.
    Ответ написан
    Комментировать