потыкал replicate, и вижу, что любой выбор scheduler даёт приемлимые результаты при 10 шагах (картинка, а не шум гранулами, как у меня)

возможные причины косяка:
1. я неправильно декодирую латенты в картинку на ранних этапах, а только на финальных. может надо нормализовать перенасыщенные/saturated пиксели
2. планировщики в diffusers как-то отличается по имплементации от stability-ai
3. может быть дело в нестандартном автоэнкодере sd-vae-ft-mse
4. или что-то другое :)

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

по этому эксперименту он за 100 шагов выдает результаты, которые и запросу не соответствуют. возможно, есть ошибка при патчинге `scheduler = sched_class.from_config(config)`. Поделитесь результатами, где за 10 шагов хорошо получается

А есть ли возможность драйверы привязывать процедурно?

И зачем в этом именно в этом примере нужен драйвер?

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

Потому что Алгоритм не переопределяет кратчайшие пути. Вершина C добавилась в граф первым шагом, и был определен кратчайший путь AC. Путь ABC короче, но если вершина C уже посещена, то этот факт игнорируеется.

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

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

Привет. Поправили текст, была ошибка find_max_and_comp это тоже самое, что find_max_comp в старом варианте. Описание этой функции есть в сниппете

И правда, а я под другими комментариями с похожей идеей тоже говорю, что O(N logN) получится :) Спасибо!

Ваше решение мне также кажется валидным. Но скорее всего, итоговая сложность также будет O(NlogN), поскольку нужно искать место, куда воткнуть очередной элемент N раз. Столько раз, сколько в онлайне нам предоставили новое число

UPD: дали хороший комментарий, что вставка занимает O(N) (в вашем комменте это также говорится). Поэтому решение с поиском за O(logN) и вставку, осуществляемую N раз, по итогу даст квадратичную сложность. А не как я выше написал

Часто медиана не равна среднему. Плюс, среднее в онлайне поддерживать тоже можно с некоторой точностью, точно посчитать, нужно каждый шаг складывать все N элементов

Да, постановка задачи именно такая. В онлайне добавлять элемент и уметь доставать медиану.

Да, именно так в онлайне. Хорошо задачу описали в этом комментарии, в статье я пытался это менее формальным языком описать. Эффект простоты описания не был достигнут :)

Привет. В целом, кажется реально реализовать поддержание массива отсортированным, вставляя за O(logN) очередной элемент на место, найденное бинарным поиском, затем выдавать центральный элемент массива по запросу.

Привет. Нужно посчитать сложность такого подхода, насколько он будет сопоставим.

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

Каждый новый элемент может быть вставлен либо во множество "большие медианы", либо "меньшие медианы". пусть он больше медианы, тогда нам повезёт, если он между элементами тройки <"слева", "медиана", "справа">, в этом случае мы сможем запросто обновить тройку. Но если он окажется далеко справа, то нужно быстро добыть из правого множества наименьший элемент. Для этого кучу здесь используем.

Надеюсь, пример на пальцах понятен :)

Согласен, очень интересный вопрос, насколько похожи математические нейронные сети, созданные человеком, и сети в головах животных