On Wed, 20 Oct 2010, John Peterson wrote:
On Wed, Oct 20, 2010 at 4:19 PM, Derek Gaston <[email protected]> wrote:To "fix" this I propose using relative_fuzzy_equals() like so: if (!(elem->point(n) - elem->point(0)).relative_fuzzy_equals((cached_nodes[n] - cached_nodes[0]))) But of course this could have the bad side effect of false positives... ie two elements that are _extremely_ similar but not exactly and still pass this check. So what do you guys think? Is this a valid thing to do... or is it just too unsafe? Is there a better option?Good catch.
Very good catch. I'm somewhat embarrassed that I didn't catch it myself; After I wrote the code I noticed that my app got way faster and I verified that the results didn't change but I don't think I bothered to do any double-checking of how much caching was being done.
I'll let Roy answer since he wrote that code, but I think what you propose doing sounds fine. You can specify a tolerance to relative_fuzzy_equals as well if you want to make it pretty precise.
Precisely. Using the default tolerance here (I think 1e-6 for doubles?) would be a big no-no, but using 1e-15 or so ought to be safe. Of course, the right way to do meshing (for any problem that doesn't happen to have exactly one very extreme singularity) is with a fixed-point scalar class rather than floating point... but it's going to be a long long time before we consider making libMesh do things like that. --- Roy
------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
