6

私は現在、マンデルブロ集合のレンダリングを実験していますが、レンダリングごとに最大反復回数を再計算する必要がないことが便利であることにすぐに気付きました...一方、追跡するには大量のデータが必要ですの。（RDMSでの限られた経験に基づくと）データセットが大きくなるにつれてパフォーマンスに影響を与えたくないので、リレーショナルデータベースはおそらく行く方法ではないように思われます。ハッシュテーブルにはほぼ完璧な状況のようですが、これまで使用したことがなく、既存のWebサーバー言語（Python / PHPなど）のいずれかでハッシュテーブルを使用または管理する方法を理解できないようです。

もう少し明確にするために：保存される重要な値は次のとおりです。

  • 複素平面上の数の元の実数部
  • 複素平面上の数の元の虚数部
  • 最大反復回数
  • 最大反復回数に達する前、またはポイントが無限大になるまでの完了した反復回数 n
  • n回の反復後の複素平面上の数値の最後の実数部
  • n回の反復後の複素平面上の数値の最後の虚数部

いつでも、元の実数部、元の虚数部、および最大反復回数を考慮して、最終的な実数部と虚数部を含む結果セットを取得できるようにしたいと思います。

それで、あなたはどう思いますか？ハッシュテーブルは行く方法ですか？問題は、単なる致命的なデータ構造には複雑すぎますか？

どんな助けでも大歓迎です。前もって感謝します！

編集

julienaubertの親切なリクエストで、この問題について少し説明します。

私が持っている目標は、ユーザーが計算の遅延なしにマンデルブロ集合にズームインできるようにすることです（事前定義されたズームを使用している場合でも）。また、サーバーに新しいデータ配列を常に要求しているブラウザーでこれを実行できるようにしたいのですが、新しいx座標とy座標、および複素平面で表示される高さと幅を指定します。ただし、ピクセルの色の値の計算ははるかに高速に実行できるため（max_iter、real_final、およびimag_finalを指定）、ユーザーが色の設定を調整できるようにすると便利なので、ブラウザーのみを送信します。私の投稿に列挙されている変数を使用して、ユーザーのブラウザに色を計算させます。

これを見てください：

http://jsfiddle.net/xfF3f/

drawMandelbrot（）関数を見ると、ポイントループがデータセットと呼ばれる変数に重要な値を格納していることがわかります。次に、この変数はdrawMandelbrotFromData（）関数で使用され、各ピクセルの色を把握するために必要な残りの計算を実行します。

「cleardabrot」をクリックすると、キャンバスが白い長方形に置き換わります。「refilldabrot」をクリックすると、drawMandelbrotFromData（）関数が再度実行されます...これは、面倒な反復計算を実行する必要がない場合に、実際にセットをレンダリングできる速度を示すために行われます。

したがって、ここでの最終的な目標は、これらの値を任意の精度で計算できるようにすることです。これにより、ユーザーはセットの任意のレベルにズームし、サーバーにそれらの正確なポイント（またはできればNEARのポイント）のデータがあるかどうかを判断させることができます。それらの正確なポイント...ある種の範囲クエリを実行せずにこれをどのように実行できるかはわかりませんが）、ピクセルごとに情報を吐き出します。例えば...

  • ユーザーは300x300のキャンバスを使用しています。
  • 彼は左上隅がx = .000001とであるポイントにズームしy = .0000231ます。
  • このフレームで彼が選んだ幅と高さw = .00045はh = .00045

彼はそれらの番号をサーバーに送信し、次に300 * 300のインデックス（各ポイントを表す1つ）を持つ配列を受け取ります。各インデックスには、キャンバス上の各ピクセルの色を決定するために必要な情報が含まれています。ここでの私の質問は...ユーザーが任意のx、y、w、およびh値を入力し、その中の複素平面上の点の値をすばやく引き戻すことができるように、事前に計算されたマンデルブロデータを格納するための最良の方法は何ですか範囲。

4

1 に答える 1

2

いつでも、元の実数部、元の虚数部、および最大反復回数を考慮して、最終的な実数部と虚数部を含む結果セットを取得できるようにしたいと思います。

なぜこれが必要なのか、あなたの質問からは明らかではありませんか？なぜ同じ時点で再計算する必要があるのですか？

さまざまなmax_iterations設定を試している場合は、ピクセルごとに取得したactual_iterationsを、バイナリファイル、テキストファイル、画像、またはリレーショナルデータベースなど、ロード/保存に便利なものに保存できます。

リアルタイムレンダリングを行っていて、（同じ元のポイントで同じ最大反復回数で）漸化式を再計算する必要がある処理を使用している場合は、ルックアップを使用することでこれを高速化できると思います-ルックアップテーブル。

明らかに、ルックアップテーブルは計算を実行するよりも高速である必要があります。以下の操作の合計が、計算を再実行するよりも少ないルックアップテーブルが必要です。

  • インデックスを計算します（与えられたorigo_real、origo_imag、max_iter）
  • キャッシュされた計算をロードします（final_real、final_imag、actual_iter）
  • 1つの最初の店

同じポイントでの再計算/再アクセスの方法によっては、インデックスがルックアップテーブルにあり、ルックアップテーブルが十分に小さい可能性が高いように問題を分割できます。 L1またはL2キャッシュに格納されます。

それらはいくつかのアイデアです..しかし、あなたはあなたの本当の問題が何であるかを明確にする必要があります。

さらなる分析のためにこのデータを大量に必要とし、リアルタイムが要件ではない場合は、まあ...あなたの本当の問題が何であるかを明確にしてください:)

更新の答え

これは、マップサービス（ズームイン/ズームアウト、移動）を使用するのと似ているように見えます。つまり、基本的に、特定の領域の画像を配信してズームします。

ただし、この場合、ズームレベルが照会される可能性があるため、1人のユーザーに対してキャッシュしたものは、次のユーザーに対して再利用されない可能性があります。ユーザーがリアルタイムでズームできるクライアントソフトウェアを作成するのではなく、この方法で行うことが理にかなっている理由がわかりません（これは実行されています）。

とにかく。主な問題が帯域幅であるが、十分な計算能力がある場合は、計算されたパッチの画像を高圧縮ファイルに保存し、品質を少し下げて、これらの画像をキャッシュすることができます。次に、これらのパッチをつなぎ合わせて、ユーザーが希望する正確な領域を提供する必要がある場合があります。トリックは、ズームと領域を指定して、パッチの最小セットを照会することです。

ほとんどのクエリが存在しないパッチを要求するのではないかと心配しています（ズームレベルが可能であるため）。おそらく、Googleマップ/ GISシステムがどのように機能するかについてのいくつかの情報は、あなたにいくつかのアイデアを与えるかもしれません。主な問題がCPUである場合は、これを別の方法で実行し、ユーザーにアプレットで計算を行わせることができます（結果を返送することもできます）。

クライアントサーバー上でキャッシュ/計算する方法を学ぶためにこれを行っている場合、これはクライアント側で適切なコンピューターによって解決できるため、別の課題を検討することをお勧めします。

于 2010-09-05T10:13:14.003 に答える