Well what I gave you was non optimal for sure... And not exactly what we have implemented... But there will always be some overhead with this scheme. We get away with it by caching references/pointers to the data and only updating them when necessary. Also you don't have to use maps. You could use vectors and have an enum somewhere that tells you how to index it.... Along with lots of other schemes.
But yeah the flexibility might be overkill on your case. Derek Sent from my iPhone On Jan 9, 2009, at 5:49 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: > > On Fri, 9 Jan 2009, Derek Gaston wrote: > >> (Sorry if you get multiples.... I was having trouble sending it) > > In an odd coincidence, one thing I don't like about your idea is the > inefficiency. ;-) > > It sounds like you've got a pretty good solution for some cases, but > it won't work for my user applications (that data's Reals, but a big > vector-of-vectors of them that I don't want to individually name), it > doesn't work for the Diff/FEMSystem hierarchy (that data includes > vectors of QBase pointers and FE pointers), and I don't like the idea > of putting a few dozen map lookups per element in the FEMSystem loops. > > Thanks, though, > --- > Roy ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
