Lazy Calculation(s)

[Igors]

Ну так вы выскажите свои подозрения? А мы их обсудим)

Ну я подозреваю что при выполнении 2 нитками алгоритм стартового поста будет при каждом запуске выдавать РАЗНЫЕ рез-ты (хотя входные данные одни и те же)

Более того, даже при выполнении 1 ниткой рез-ты воспроизводятся только если данные поступают в том же порядке (чего в общем случае никто не обещал)

В общем это та самая простота что "хуже воровства"

[m_ax]

Ну я подозреваю что при выполнении 2 нитками алгоритм стартового поста будет при каждом запуске выдавать РАЗНЫЕ рез-ты (хотя входные данные одни и те же)

Ну да, для данной реализации они вообще говоря каждый раз будут разными. Ну и что? Вон там Vanda в соседней ветке тоже каждый раз картинки разные получает..
Вопрос в том, на сколько это критично? И на сколько критично они "разные" будут в среднем..(Что такое "разные"?)

[Igors]

Вопрос в том, на сколько это критично? И на сколько критично они "разные" будут в среднем..(Что такое "разные"?)

Есть вещи которые инженер (или то же профессионал) улавливает интуитивно 
Напр "достаточность" задачи или "воспроизводимость" рез-тов.

Конкретно "чем это грозит"... Пример. Просчитали данным алгоритмом. Потом просчитали честно все точки (долго). Сравнили в фотожопе - все Ок, погрешность не превышает заданную напр 5%. Теперь, (веселые и счастливые) считаем какую-то последовательность картинок (анимацию). На втором кадре ничего не изменилось, он должен быть == первому. А он-то совсем не равен Анимация (мерзко) "дрожжит" (flick). Все ясно, тому козлу что делал - не платить, и больше с ним не связываться. Сразу, разговоров не будет.

[m_ax]

Тогда отказывайтесь от этого алгоритма. В противном случае, если речь идёт об анимации (много-много картинок) то в этой ситуации картинка неизбежно будет "дрожать".

[Igors]

Тогда отказывайтесь от этого алгоритма. В противном случае, если речь идёт об анимации (много-много картинок) то в этой ситуации картинка неизбежно будет "дрожать".

Ну почему "неизбежно". Предложите решение(я) этой проблемы

[m_ax]

Ну почему "неизбежно". Предложите решение(я) этой проблемы

А вы не ходите вокруг до около..) Я так сразу даже не предложу решения..
Если хотите плавности анимации, то это может оказаться совсем нетривиальная задачка..
Могу пока только сделать предположение, что этот метод должен быть строго детерминистическим и, наверное,
с фиксированной сеткой (без всякого random)

[Igors]

А вы не ходите вокруг до около..)

Ну вот, опять надо рассказывать как я делал, тогда уж (может быть) и покритикуют

Я так сразу даже не предложу решения.. Если хотите плавности анимации, то это может оказаться совсем нетривиальная задачка..

"Зашланговался". Ну это нормально, задача требует размышлений, это не футуры везде пихать

Могу пока только сделать предположение, что этот метод должен быть строго детерминистическим и, наверное,
с фиксированной сеткой (без всякого random)

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

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

[Racheengel]

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

Для инженера - всегда лучше
Ну в конечном счёте и для заказчика.
Но... бабло часто побеждает разум - обычно считается, что "там же только одну функцию починить надо!"

[Igors]

Для инженера - всегда лучше
Ну в конечном счёте и для заказчика.

А что Вы, батенька, все в оффтоп да в оффтоп Как бум решать проблему воспроизводимости? Там же есть простое решение, пусть не идеальное. Уж его-то Вы точно укажете, да и вообще, я в Вас верю, может и еще что толковое предложите

[m_ax]

Ну вот, опять надо рассказывать как я делал, тогда уж (может быть) и покритикуют  

Могу предположить, что это интерполяция (фильтр) между ближайшими кадрами. Т.е. аналог сглаживания одномерной кривой: блур, короче 

[m_ax]

Если моё предположение верно - то оно тоже ограничено: границы между контрастными областями также будут "дрожать"..

[Igors]

Могу предположить, что это интерполяция (фильтр) между ближайшими кадрами. Т.е. аналог сглаживания одномерной кривой: блур, короче 

Лично меня это интересует с точки зрения/задачи 3D рендера, хотя возможны и др применения за рамками моих интересов. Ну во всяком случае для рендера как-то лазить/считать/иметь 2 кадра одновременно - полная утопия  НО мы можем рендерить один кадр неск раз, и так часто делают для различных "буферных" фич (напр расчет битмаповских теней). Отсюда простая идея немного модифицировать алгоритм стартового поста:

- На первом проходе применяем lazy, но не бежим сразу считать "опорные" точки, а только маркируем/запоминаем их. Эту операцию придется делать в одной нитке, полагаем что она "достаточно быстрая". Заметим что kd-tree здесь не подходит (вставка слишком дорогая)

- После того как опорные точки накоплены, считаем их все наваливаясь всей тушей (нитками), это "разпоточивается" прекрасно.

- И наконец, веселые-счастливые, считаем второй (финальный) проход всеми нитками используя для интерполяции дерево (thread-safe) построенное на первом

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

Ну это на словах "так просто", на деле тут немало скользких мест, поэтому я бы с удовольствием послушал какие-нить идеи (пусть безумные).

[m_ax]

- На первом проходе применяем lazy, но не бежим сразу считать "опорные" точки, а только маркируем/запоминаем их. Эту операцию придется делать в одной нитке, полагаем что она "достаточно быстрая".

А у вас что, "опорные" точки для всех кадров одни и те же? Я предполагал, что если картинка движется, то и "опорные" точки индивидуальны для каждого кадра..

Заметим что kd-tree здесь не подходит (вставка слишком дорогая)

Для kd-tree это ещё пол беды.. После множества вставок оно у вас быстро станет несбалансированным. Я вообще считаю, что там не нужен метод insert.
Переписал, кстати, своё kd-tree, с учётом балансировки при его создании)

- И наконец, веселые-счастливые, считаем второй (финальный) проход всеми нитками используя для интерполяции дерево (thread-safe) построенное на первом

Как всегда всё очень мутно и туманно..
Ну мы привыкшие)

[Igors]

Как всегда всё очень мутно и туманно..
Ну мы привыкшие)

Как всегда, Вы не хотите подумать, даже немного, и спешите "клеить ярлыки" 

А у вас что, "опорные" точки для всех кадров одни и те же? Я предполагал, что если картинка движется, то и "опорные" точки индивидуальны для каждого кадра..

Ну ведь вверху подробно разжевано в чем разница между 2 кадрами и 2 проходами (одного и того же кадра). Конечно на каждом новом кадре все начнется с нуля, но если придут те же данные, то и рез-т будет точно тот же.

[Igors]

Для kd-tree это ещё пол беды.. После множества вставок оно у вас быстро станет несбалансированным.

Любое пополнение ведет к немедленной пере-балансировке, т.е. перестройке всего дерева (медиана-то убежала). Строго говоря, это не дерево а просто массив (хитро отсортированный)