Proposal for Requiring Save/Restore of Sets and Tags

[Carl Ollivier-Gooch]

On 10/21/2010 10:04 AM, Jason Kraftcheck wrote:
> On 10/21/2010 11:35 AM, Carl Ollivier-Gooch wrote:
>
>>
>> It's possible that it's a useful capability, but it's semantically
>> incompatible with either of the two mechanisms we currently have
>> (subset/set membership and parent/child).  Semantically, the only way to
>> have a cycle there is something as silly as set A is an improper subset
>> of B is an improper subset of A --- with A and B necessarily identical
>> sets.  Parent-child relationships can't semantically have cycles at all.
>>
>
> So we have a capability to construct graphs of sets (parent/child links).
> We have functions for querying and manipulating such links named in
> accordance with or initial intended uses.  Your argument is to constrain the
> functionality based on a semantic argument about the function names.
> Wouldn’t it be better (cost nothing and not limit future functionality) to
> just rename the functions?  By why even do that?  I just don't see the
> problem with a) having this functionality (or at least not prohibiting us
> from providing it) and b) naming the functions in such a way as to be least
> confusing for the majority of uses.

My perception is that we started out with a way to represent 
hierarchical relationships between sets of mesh entities, such as mesh 
refinement history, etc.  This turns out to be usable also to create 
things like search trees, which also are interpretable as hierarchical. 
  The question, really, is whether we should change the semantics of 
that from tree to general graph, to support as-yet-unknown use cases. 
(And, as a side issue, possibly change the names.)

Personally, I don't see a use case for the general graph, but then I 
wouldn't construct a geometric search tree using iMesh sets, so maybe 
I'm not the one to ask.

>> My memory is that we had already agreed that an implementation is free
>> to skip expensive (and even cheap) checks when compiled in release mode,
>> though it should do all checks in debug mode.  The latter is very
>> important to help developers debug code, but once it's working (i.e.,
>> nothing stupid being done by accident), a lot of those checks are
>> unnecessary, so turning them off for release code is no problem.
>> Conditionally-defined macros will do this.  As Mark said, there are
>> run-time configurable methods for this, too, though I suspect they add a
>> small amount of overhead in practice.
>>
>
> You are stating that implementations must conform to a standard behavior of
> prohibiting cyclical links.  And then recommending that we disable such
> restrictions in the version/build of the code that will be used in practice.
>   Then why even make this a requirement?  What's the point of making us jump
> through hoops implementing a "strict conformance" build that will only be
> used in practice with the conformance tests?  How much code can we change
> between the two?  Would instead building a copy of the reference
> implementation if strict conformance is requested be okay?

Look, having checks like "does this entity have this tag on it" is  very 
useful for debugging mode (I presume we can all agree to that?).  In 
fact, we mandate that implementations will return an error for many of 
these things.  This is much more than a matter of passing the compliance 
tests, it's a debugging aid for programmers using the API.  However, in 
the interests of efficiency, we don't (as I understand the current state 
of things, anyway) require that all implementations will do all (or any) 
of these checks in production mode.

As for differences between debug and production code, a sensible rule of 
thumb is to execute all of the production code in debug mode and just 
turn off checking for production.  This makes it so the production code 
is actually believably correct.  That doesn't mean you can't make more 
changes than that, but it's probably not really wise.

And for this particular case, the test --- though possibly expensive --- 
is trivial to code, and surround with an #ifdef so that it gets built 
conditionally.  So the argument of burden of writing testing code isn't 
a strong one here.

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Professor                                           Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------