From: Cody P. <cod...@gm...> - 2013-04-12 16:07:23
|
I just noticed that FE::get_normals(), get_tangents() and other related methods in that class return vectors of "Points". Any desire to change these return types to VectorValue types? Just curious, Cody |
From: Roy S. <roy...@ic...> - 2013-04-12 16:16:44
|
On Fri, 12 Apr 2013, Cody Permann wrote: > I just noticed that FE::get_normals(), get_tangents() and other related methods in that class > return vectors of "Points". Any desire to change these return types to VectorValue types? Sadly no - we'd hose backwards compatibility if we did. You can initialize a Point from a VectorValues, but you can't initialize a reference to a container of Points from a container of VectorValues. We might as well wait until we're abstracting those containers more anyway to handle the instruction vectorization problems that Derek first noticed. I agree that the VectorValue->TypeVector->Point hierarchy is a little dubious, though. --- Roy |
From: John P. <pet...@cf...> - 2013-04-12 16:34:43
|
On Fri, Apr 12, 2013 at 10:07 AM, Cody Permann <cod...@gm...> wrote: > I just noticed that FE::get_normals(), get_tangents() and other related > methods in that class return vectors of "Points". Any desire to change > these return types to VectorValue types? I'd say no, and anyway to be consistent you'd have to also change get_tangents, get_normals, and get_xyz and probably some other stuff. The reason for this interface is purely historical. Point and the FE interface using it existed before any of Point's templated base classes even existed. -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2013-04-12 16:37:39
|
On Apr 12, 2013, at 11:16 AM, "Roy Stogner" <roy...@ic...> wrote: > We might as well wait until we're abstracting those containers more > anyway to handle the instruction vectorization problems that Derek > first noticed. Huh? I missed this?? |
From: Roy S. <roy...@ic...> - 2013-04-12 16:56:37
|
On Fri, 12 Apr 2013, Kirk, Benjamin (JSC-EG311) wrote: > On Apr 12, 2013, at 11:16 AM, "Roy Stogner" <roy...@ic...> wrote: > >> We might as well wait until we're abstracting those containers more >> anyway to handle the instruction vectorization problems that Derek >> first noticed. > > Huh? I missed this?? You were in the second thread where we discussed it (if my brief mention counts as "discussion"). http://sourceforge.net/mailarchive/message.php?msg_id=30008942 You might have missed the first such thread, which was long enough ago that I can't recall enough keywords to find a link quickly. Now I'm tempted to write quick LibMesh1Array and LibMesh2Array shim classes to go into 0.9.1... --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2013-04-12 17:51:58
|
On Apr 12, 2013, at 11:56 AM, Roy Stogner <roy...@ic...> wrote: > http://sourceforge.net/mailarchive/message.php?msg_id=30008942 > > You might have missed the first such thread, which was long enough > ago that I can't recall enough keywords to find a link quickly. > > Now I'm tempted to write quick LibMesh1Array and LibMesh2Array shim > classes to go into 0.9.1... Ahh yes - thanks. So would these be simple wrappers for std::vector<std::vector<T> > ATM, and then use them to broaden the return type for future expansion or something? -Ben |
From: Roy S. <roy...@ic...> - 2013-04-12 17:58:08
|
On Fri, 12 Apr 2013, Kirk, Benjamin (JSC-EG311) wrote: >> Now I'm tempted to write quick LibMesh1Array and LibMesh2Array shim >> classes to go into 0.9.1... > > So would these be simple wrappers for std::vector<std::vector<T> > > ATM, and then use them to broaden the return type for future > expansion or something? Exactly. That way if we expand the API options for 1.0.0 we can still allow people to write code that makes use of those options but remains backward compatible for testing against 0.9.1. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2013-04-12 18:08:56
|
On Apr 12, 2013, at 12:58 PM, Roy Stogner <roy...@ic...> wrote: >> So would these be simple wrappers for std::vector<std::vector<T> > >> ATM, and then use them to broaden the return type for future >> expansion or something? > > Exactly. That way if we expand the API options for 1.0.0 we can still > allow people to write code that makes use of those options but remains > backward compatible for testing against 0.9.1. As for the schedule - your call - you were the primary schedule push for 0.9.1. I'd be interested to understand the differences between LibMesh1Array and LibMesh2Array, but like the approach… -Ben |