Proposal for Requiring Save/Restore of Sets and Tags

[Mark Miller]

So, I think we're agreed that cycles in the set inclusion structure are
out, right? I mean, I am not seeing any strong opposition there. And, I
have to say that I strongly agree with Carl's observation that the only
'legitimate' case of cycles in set inclusion structure is for some,
possibility arbitrary long, chain of sets which are all equal to each
other. What value can allow that possibly serve? What use case requires
that and which NOT allowing cycles in set inclusion cause undue hardship
for? 

So, the real issue is with cycles int the Prnt/Chld structure, right?

Jason, you mention below "...naming the [Prn/Chld] functions in such a
way as to be least confusing for the majority of uses..."

I have to say that the whole concept of Prnt/Chld functions in the
interface was a major confusion to me when I first started learning it.
My source of confusion was that I thought the set inclusion structure
already imposed which sets were 'parents' of other sets by virtue of
their containment relationships. So, as far as naming these functions
go, I think Prnt/Chld is actually MORE confusing that something like

void addSetGraphDirectedLink(iMesh_instance inst,
    iBase_EntitySetHandle tail_set,
    iBase_EntitySetHandle head_set
    int *err);

void addSetGraphUndirectedLink(iMesh_instance inst,
    iBase_EntitySetHandle one_set,
    iBase_EntitySetHandle another_set,
    int *err);

And, I'd really, like to put tag data on graph links too.

So, if were going to say "hey even though we call these functions
'parent' and 'child' thingies, we're really handling a general graph',
then I'd like to see the functions renamed to something more appropriate
and the words 'parent' and 'child' stricken from the iMesh.h header file
(replaced, of course, with 'direct' or 'undirected link')

And, if its a general graph, then I don't see any reason cycles should
NOT be supported.

Mark

  




On Thu, 2010-10-21 at 10:04, 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 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?
> 
> - jason
-- 
Mark C. Miller, Lawrence Livermore National Laboratory
================!!LLNL BUSINESS ONLY!!================
miller86 at llnl.gov      urgent: miller86 at pager.llnl.gov
T:8-6 (925)-423-5901    M/W/Th:7-12,2-7 (530)-753-8511