В любой момент времени, учитывая исходную вещественную часть, исходную мнимую часть и максимальное количество итераций, я хотел бы иметь возможность получить набор результатов с конечными действительными и мнимыми частями.
Из вашего вопроса не понятно, зачем вам это?Зачем вам нужно пересчитывать в одной и той же точке?
Если вы экспериментируете с разными настройками max_iterations, вы можете просто сохранить фактические итерации, полученные на уровне пикселей, в двоичном файле, текстовомфайл или изображение или все, что вы считаете удобным для загрузки / хранения, например, реляционная база данных.
Если вы выполняете рендеринг в реальном времени и используете некоторую обработку, которая требует пересчета уравнения повторения (в то же времяисходная точка и с теми же максимальными итерациями), тогда я мог бы предположить, что вы могли бы ускорить это, имея справочную таблицу.
Очевидно, что ваша справочная таблица должна быть быстрее, чем выполнять вычисления.Вам нужна справочная таблица, для которой приведенные ниже операции в целом занимают меньше времени, чем повторные вычисления.
- вычислить индекс (с учетом origo_real, origo_imag, max_iter)
- загрузить кэшированныйвычисления (final_real, final_imag, actual_iter)
- одно начальное хранилище
В зависимости от того, как вы будете повторно вычислять / повторно обращаться к одним и тем же точкам, вы можете разделить свою проблему на такиетаким образом, весьма вероятно, что индекс находится в справочной таблице, а справочная таблица достаточно мала для хранения в кэше L1 или L2.
Это некоторые идеи ... но вы должны уточнить, в чем заключается ваша настоящая проблема.
В случае, если вам просто нужно много этих данных для дальнейшего анализа, а в режиме реального времени это не требуется,тогда хорошо ... уточнить, что является вашей реальной проблемой:)
ответ за обновление
Это похоже на использование картографического сервиса (увеличение / уменьшение, перемещениевокруг), то есть вы, по сути, предоставляете изображение для данной области и масштабирования.
Однако в этом случае, так как любой уровень масштабирования может быть запрошен, независимо от того, что вы кешируете для одного пользователя, может не быть повторно-используется для следующего пользователя.Я не уверен, почему имеет смысл делать это таким образом, а не писать клиентское программное обеспечение, в котором пользователь может масштабировать в реальном времени (что было сделано).
В любом случае.Если вашей основной проблемой является пропускная способность, но у вас достаточно вычислительных мощностей, вы можете хранить изображения вычисленного патча в сильно сжатом файле с немного более низким качеством и кэшировать эти изображения.Затем вам может понадобиться сшить патчи из них вместе, чтобы получить точную область, которую хотел пользователь. Хитростью было бы запросить минимальный набор патчей с учетом масштаба и области.
Боюсь, что большинство запросов будет запрашивать патчи, которых не существует (поскольку возможен любой уровень масштабирования).Возможно, некоторая информация о том, как, например, работают Google Maps / GIS системы, может дать вам некоторые идеи.Если вашей основной проблемой является процессор, то, возможно, вы могли бы сделать это по-другому и позволить пользователю выполнять вычисления в апплете (и, возможно, отправить результат обратно)
Если вы делаете это, чтобы научиться кэшировать / вычислятьчерез клиент-сервер вы можете рассмотреть другую проблему, поскольку эта проблема может быть решена на стороне клиента любым приличным компьютером.