Discussion :

[Kalith]

D'accord, mais tout ca se sont des choses qui dépendent de la position dans le référentiel, tu ne crois pas que chaque point devrait connaitre sa position dans un référentiel ? Du coup ca serait une donnée des objet en eux même et pas une du conteneur.

C'est possible, mais ce faisant tu doubles la quantité de mémoire utilisée. Le fait est que chaque point dispose déjà d'une adresse en mémoire, adresse qui peut être interprétée comme une information de position si l'on sait comment les points sont agencés en mémoire (et on le sait). Selon le volume de donnée que l'on traite, ça peut être un sacré gâchis (imagine un format d'image où chaque pixel stockerait à la fois l'information sur sa couleur mais aussi sur sa position : c'est le même combat).

En fait utiliser les indices d'un conteneur comme coordonnées spatiales/temporelles lorsque ce qui est caractérisé c'est les points de l'espace/du temps (ie f(r,t), typiquement un champs), mais quand on cherche l'évolution spatial d'un point il me semble plus logique de considérer la position comme la donnée qui évolue (en fonction du temps).

C'est effectivement pour traiter des champs que j'ai commencé à travailler sur cette bibliothèque.

Et donc dans le cas d'une fonction f(r,t) la FFT est vraiment, AMA, l'outil le plus adapté pour les calculs numérique faisant intervenir des dérivés (temporelles ou spatiales).

Pour entrer un peu dans les détails, l'un de cas que je voulais traiter est l'équation de Liouville (une version simplifiée de l'équation de Boltzmann, où l'on néglige les collisions entre les particules). Dans ce formalisme, les fonctions considérées sont des densités de probabilité dans l'espace des phases f(r, p, t), où p est l'impulsion. Je ne sais pas si c'est applicable dans ce cas précis, je n'y ai pas réfléchi à vrai dire, et il est tard donc je ne vais pas le faire de suite. Je fais vraiment ça pour m'amuser à la base, ça n'a pas vocation à servir à quelque chose Mais j'aime faire les choses proprement, et qui sait, ça pourra peut être me servir plus tard ?

Pour la FFT, je te demandais ca car avec une FFT les dérivés ca va tout seul ^^.

Je serais un bien piètre physicien si je ne savais pas ça

[Flob90]

Ca double pas vraiment l'information. Dans une image l'information utile c'est justement le pixel, et le conteneur est utilisé pour représenter les positions. Mais un point matériel l'information c'est justement ces coordonnées, et un conteneur de points c'est juste un ensemble de points sans ordre précis. A moins que tu considères que l'information c'est juste une coordonnée et que la position (qui ne varie donc pas) représente l'autre ? Dans ce cas je suis d'accord. Dit autrement que tu considères le graph Y(X,t) dans l'exemple de ta corde ?

Quoiqu'il en soit, si tu as besoin de travailler avec la position des éléments au sein d'un conteneur, alors un for range-based ne me semble vraiment pas adapté, et les solutions pour l'adapter ressemble plus à un hack qu'autre chose à mon goût (ca reste un avis personnel ).

[Kalith]

A moins que tu considères que l'information c'est juste une coordonnée et que la position (qui ne varie donc pas) représente l'autre ? Dans ce cas je suis d'accord. Dit autrement que tu considères le graph Y(X,t) dans l'exemple de ta corde ?

Oui, désolé si ça n'était pas clair dès le début ! Dans le cas contraire je suis tout à fait d'accord, il faudrait stocker la position quelque part.

[Matthieu Brucher]

Je pense comprendre l'idée des ranges. Je suis tombé sur ce message sur stackoverflow, qui donne une idée de ce qu'on peut faire avec, et c'est vrai que c'est joli. Au passage, le fait qu'il existe au sein de boost une fonctionnalité similaire à celle que j'essaye tant bien que mal de défendre depuis le début (boost::indexed) montre que ça a une utilité.

Cool, je cherchais l'autre jour cette fonction bien pratique, d'autant qu'elle est native dans mon autre langage de tous les jours, à savoir Python !