On Wed, 1 Feb 2012, John Peterson wrote:
On Wed, Feb 1, 2012 at 12:59 PM, Kirk, Benjamin (JSC-EG311)
<benjamin.kir...@nasa.gov> wrote:
I wonder if all this confusion is telling us something, that perhaps we've
overloaded the functionality in a pretty obtuse way?
Perhaps (at least from the public: perspective) we should implement a few
functions that are more clear:
contains_point(p); // really, i'm serious
close_to_point(p, tol=default_tolerance);
of course they might use the same private implementation if it makes
sense...
Yep, this is what I was thinking as well. Probably close_to_point()
is the more general, so contains_point() would call it...
I like this, except I'd leave tol=default_tolerance in contains_point.
We're dealing with floating point arithmetic here: "really, I'm
serious" is effectively impossible. While TOLERANCE might work for
most people it's still entirely possible that someone might want to
reduce it. And I'd like that reduction to be up to them - if we
consider K1 = {p \in Omega: elem1.contains_point(Point(p),tol)} and K2
likewise for an adjacent element, then I don't know where in between
TOLERANCE and 0.0 we go from "more points than necessary fall in {K1
intersection K2}" (not good) to "{K1 union K2} is no longer
homeomorphic to a ball" (horribly bad).
---
Roy------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
