Quelle pourrait être la meilleure méthode de stockage des valeurs Mandelbrot dans une base de données?

Question

J'expérimente actuellement avec le rendu d'un ensemble Mandelbrot et je me suis rapidement rendu compte qu'il serait utile de ne pas avoir à recalculer le nombre d'itérations maximum pour chaque rendu ... d'un autre côté c'est beaucoup de données à suivre. Il me semble (basé sur mon expérience limitée avec RDMSes) qu'une base de données relationnelle n'est probablement pas la voie à suivre parce que je ne veux pas que la performance soit affectée pendant que l'ensemble de données devient plus grand. Cela ressemble presque à la situation idéale pour une table de hachage, mais je n'en ai jamais utilisé auparavant et je n'arrive pas à comprendre comment utiliser ou gérer un des langages du serveur web existant (Python/PHP/whatever).

Pour être un peu plus explicite: les valeurs importantes à stocker sont:

• La partie réelle originale d'un numéro sur le plan complexe
• La partie imaginaire d'origine d'un certain nombre sur le plan complexe
• le nombre d'itérations maximum
• le nombre de itérations achevéesn avant itérations max est atteint ou jusqu'à ce que le point va à l'infini
• La partie réelle finale d'un numéro sur le plan complexe après n itérations
• La partie imaginaire finale d'un numéro sur le plan complexe après n itérations

à tout moment, étant donné la partie réelle originale, le partie imaginaire originale, et le nombre maximum d'itérations, je voudrais être en mesure d'obtenir un ensemble de résultats avec les parties finales réelles et imaginaires.

Alors, qu'en pensez-vous? Est-ce qu'une table de hachage est le chemin à parcourir? Le problème est-il trop complexe pour de simples structures de données mortelles?

Toute aide serait grandement appréciée. Merci d'avance!

Modifier

Je vais exposer sur le problème un peu à la demande de type de julienaubert.

Le but que j'ai est de permettre à un utilisateur de zoomer sur un ensemble Mandelbrot sans le délai de calcul (même si c'est par des zooms prédéfinis). Je veux aussi pouvoir le faire dans un navigateur qui demande constamment au serveur un nouveau tableau de données donnant les nouvelles coordonnées x et y ainsi que la hauteur et la largeur à visualiser sur le plan complexe. Cependant, comme le calcul de la valeur de la couleur du pixel peut être fait beaucoup plus rapidement (avec max_iter, real_final et imag_final), et aussi parce que ce serait sympa de permettre à l'utilisateur d'ajuster les paramètres de couleur, je vais envoyer le navigateur les variables énumérées dans mon message et laissez le navigateur de l'utilisateur calculer la couleur.

Jetez un oeil à ceci:

http://jsfiddle.net/xfF3f/

Si vous jetez un oeil à la fonction drawMandelbrot(), vous pouvez voir que les boucles de points stockent les valeurs importantes dans une variable appelée ensemble de données. Cette variable est ensuite utilisée dans la fonction drawMandelbrotFromData() où elle exécute les calculs restants nécessaires pour déterminer la couleur de chaque pixel.

Si vous cliquez sur "cleardabrot", le canevas est remplacé par un rectangle blanc. Si vous cliquez sur "refilldabrot", il exécute à nouveau la fonction drawMandelbrotFromData() ... ceci est fait pour vous montrer à quelle vitesse il peut réellement rendre l'ensemble si seulement il n'avait pas à effectuer les calculs itératifs douloureux. Donc le but ultime ici est de pouvoir calculer ces valeurs avec une précision arbitraire, afin qu'un utilisateur puisse zoomer à n'importe quel niveau de l'ensemble, demander au serveur de déterminer s'il y a des données pour ces points précis (ou, de préférence, des points près de ces points précis ... bien que je ne sois pas sûr de la façon dont cela pourrait être fait sans effectuer une requête de gamme de quelque sorte), puis cracher l'information sur une base pixel par pixel. Par exemple ...

• Un utilisateur utilise un canevas 300x300. Il effectue un zoom sur un point où le coin supérieur gauche est x = .000001 et y = .0000231.
• Sa largeur choisie et de la hauteur dans ce cadre est w = .00045 et h = .00045

Il enverrait ces numéros hors du serveur et de recevoir, à son tour, un tableau avec 300 * 300 index (un représentant de chaque point), chacun contenant les informations requises pour déterminer la couleur de chaque pixel sur sa toile. Ma question ici est ... quelle est la meilleure façon de stocker des données Mandelbrot précalculées de telle sorte qu'un utilisateur peut entrer des valeurs x, y, w et h arbitraires et de retirer rapidement les valeurs des points sur le plan complexe dans ce gamme.

Answer 1

À tout moment, étant donné la partie réelle originale, la partie imaginaire d'origine, et le nombre maximum de itérations, je voudrais être en mesure d'obtenir un jeu de résultats avec la finale réelle et parties imaginaires.

D'après vous, pourquoi votre besoin? Pourquoi avez-vous besoin de re-calculer au même point? Dans le cas où vous expérimentez avec différents paramètres max_iterations, vous pouvez simplement enregistrer les enregistrements réels pris au niveau du pixel dans un fichier binaire, un fichier texte ou une image ou tout ce que vous trouvez pratique à charger/stocker, par ex. une base de données relationnelle. Si vous effectuez un rendu en temps réel et que vous utilisez un traitement qui nécessite de recalculer l'équation de récurrence (au même point d'origine et avec les mêmes itérations max), alors j'imagine que vous pourriez l'accélérer en avoir une table de consultation.

De toute évidence, votre table de recherche doit être plus rapide que de faire le calcul. Vous avez besoin d'une table de consultation pour laquelle les opérations ci-dessous prennent moins de temps que de faire le calcul.

• indice de calcul (donné origo_real, origo_imag, max_iter)
• charge le calcul cache (final_real, final_imag, actual_iter)
• un magasin initial

Selon la façon dont vous re-compute/ré-accéder aux mêmes points, vous pouvez diviser votre problème de telle manière qu'il est hautement probable que l'index soit dans la table de recherche et que la table de recherche soit suffisamment petite pour être stockée dans un L1 ou un L2 cache

Ce sont quelques idées .. mais vous devriez clarifier quel est votre vrai problème.

Dans le cas où vous avez juste besoin de beaucoup de ces données pour une analyse plus approfondie et en temps réel est pas à l'exigence, alors bien ... :) clarifier ce qui est

votre vraie question réponse à la mise à jour

Cela semble similaire à l'utilisation d'un service de carte (zoom avant/arrière, se déplacer), c'est-à-dire que vous fournissez essentiellement une image pour une zone et un zoom donnés.

Cependant, dans ce cas, comme tout niveau de zoom peut être interrogé, tout ce que vous cachez pour un utilisateur ne peut pas être réutilisé pour l'utilisateur suivant. Je ne suis pas sûr pourquoi il serait logique de le faire de cette façon plutôt que d'écrire un logiciel client dans lequel l'utilisateur peut zoomer en temps réel (ce qui a été fait).

Dans tous les cas. Si votre problème principal est la bande passante mais que vous disposez de beaucoup de puissance de calcul, vous pouvez stocker des images d'un correctif calculé dans un fichier hautement compressé, avec une qualité légèrement inférieure et mettre en cache ces images. Vous devrez peut-être assembler des patchs pour fournir la zone exacte souhaitée par l'utilisateur. L'astuce consiste à interroger l'ensemble minimal de patchs en fonction du zoom et de la zone.

Je crains que la plupart des requêtes ne demandent des correctifs qui n'existent pas (puisque tout niveau de zoom est possible). Peut-être quelques informations sur comment, par exemple. Le fonctionnement des systèmes Google Maps/GIS pourrait vous donner quelques idées. Si votre problème principal est CPU, alors peut-être que vous pourriez le faire différemment et laisser l'utilisateur faire le calcul dans une applet (et éventuellement renvoyer le résultat)

Si vous faites cela pour apprendre à mettre en cache/calculer sur le client -serveur, vous pouvez envisager un défi différent, car celui-ci peut être résolu du côté client par n'importe quel ordinateur décent.