October 2010 - Tstt-interface - mailman3.cels.anl.gov

iRel proposal: removing non-one-to-one relation functions
by James Porter 03 Nov '10

03 Nov '10

Currently in iRel, there are a handful of functions to get/set relations that aren't one-to-one (e.g. iRel_getEntEntArrRelation). It's my understanding that these are only meant to work in, say, Entity<->Set relations, and that the entity array returned is the contents of the set related to the entity on the left side. That is, it's equivalent to calling iRel_getEntSetRelation and then i(Mesh|Geom)_getEntities on the set you get back. I propose that these functions be removed. Here's why: Note 1: most of this is based on my discussion with Tim Tautges and our implementation, Lasso, so hopefully I'm not just misinterpreting the spec. Note 2: I use "left-" and "right-" prefixes to denote which side of the relation an entity or set is on. 1) Problems with setting relations The biggest problem with these functions is in setting relations. What you're actually doing is updating the contents of the related set to contain those new elements. That is, if left-ent A is related to right-set B, setting a relation between A and [C,D,...,Z] (where C-Z are right-ents) actually inserts C-Z into B. That's certainly not what I'd expect initially; I would expect iRel to only affect stuff in its own area (e.g. relation tags set on each interface). It gets worse because it's not clear what you should do when the set B doesn't exist (throw an error? create a new set? Lasso does the former, currently). This also presents further problems because there's no corresponding iRel_setEntSetArrRelation function, even though a set could be contained in a set just as easily as an entity. 2) Confusion about iRel's capabilities iRel really creates one-to-one (possibly asymmetric) relations, but these functions seem to imply that one-to-many or even many-to-many relationships are possible. This is not, as far as I can tell, the intention. 3) Not that useful In most cases, these functions only save a single line of code. If you're trying to be truly generic (i.e. you don't know what the set-side interface is), it's a little more complicated, but not much. 4) Hurts clarity of Python interfaces This is a mostly selfish reason, since I'm the developers of the ITAPS Python interfaces, but if all relation functions are one-to-one, I'm able to simplify the Python iRel interface's functions to "getRelation" and "setRelation", since I know a priori the type of element that should be returned when you call getRelation. - Jim

8 31

Re: iRel.h interface update [was iRel proposal: removing non-one-to-one relation functions]
by James Porter 01 Nov '10

01 Nov '10

I think we're talking at cross purposes. The *only* differences between my position and Seegyoung's are that 1) I proposed adding something like "SetArr" for symmetry, and 2) I moved the suggested flag ("EntArr") to a different enumeration because doing so more closely reflects established terminology in relational databases. Unless you think #1 would be difficult/impossible to implement (which it may be, I don't know the internals of your software), we appear to be arguing about the name of a parameter. I can't speak for Tim, Jason, or anyone else at ANL or UW, but I'm agreeing with Seegyoung's proposal in every respect except the naming scheme. - Jim On 10/28/10, Mark Shephard <shephard(a)scorec.rpi.edu> wrote: > Jim, > > There is no disagreement that some of the suggestions are not optimal. However, when a very simple added function that would do exactly what was needed was suggested Tim indicated it, and as near as I and others can tell anything like it, was simply not acceptable to him. > > I believe that the early emails on the iRel problems by Mark Beall and papers that go back to the 90's have clearly defined the simple capability requested. To this point any of the suggestions from the MOAB team that come close to supporting the need you are calling an unacceptable hack. If you do not like any of them, then please work with Seegyoung on defining something that will work for all. > > Note that if we ever want to converge, the solution has to consider needs other than what one understands at this point in time to be a good implementation without hacks which is heavily based on the ITAPS interface implementations they work with. I can assure you that using sets as defined in iMesh do things we do very cleanly during mesh modifications would look very much like a hack. However, for other things, many of which MOAB focuses on, sets are a nice way to do it. What is common, that is in the ITAPS interfaces, needs to have some consideration of the needs of all implementations that are actually being used to do things. > > It would be nice to actually focus the iRel discussion on support of relations as they are used in simulations using unstructured meshes. That is let everyone state their requirements for relations and then define something that meets all of them. I though that irrespective of if specific options were "hacks" or not, Jason's email from earlier was in that direction. I also though that the suggestions made in Seegyoung 3:15am email were also in that direction (while trying to not change much of what was in place). > > Again, I request that you and Seegyoung work on something that you can both accept and then present it to the rest of us. This is the approach taken by Tim and I to define iGeom and that seamed to work. If successful at a minimum it should give us a starting point that can be build on that will work. In my opinion the seamingly simple nature of supporting relations, which is the stated goal of iRel, should be much easier that iGeom. > > Mark > > On 10/28/10 8:07 PM, James Porter wrote: > >On Thu, 2010-10-28 at 18:58 -0400, seol(a)scorec.rpi.edu wrote: > >>>On Thu, 2010-10-28 at 03:12 -0400, seol(a)scorec.rpi.edu wrote: > >>>>4. adding "EntArr" to "Relation Type" and removing iRel_getEntSetIter& iRel_getEntArrSetIterArr > >>>> > >>>> CURRENT Relation Type: Ent, Set, Both (Ent&Set) > >>>> NEW: Ent, Set, Both (Ent&Set), EntArr > >>> > >>>Assuming we end up agreeing that directly encoding one-to-many > >>>relationships in iRel (instead of relying on iMesh/iGeom to give us this > >>>though sets and/or iterators), I don't think this is a good way to go > >>>about doing it as it's really just a hack to work around implementations > >>>that don't support sets. > >> > >>vice versa. supporting set-only relation type is not a good way either as it requires a hack to work around > >>implementation that don't use sets as a way of grouping of multiple data > > > >You're talking about hacks to an implementation. I mean hacks to the > >interface; the EntArr proposal seems to be operating under the premise > >that we shouldn't change any of the other parts of iRel to help you guys > >out, so you have to "bolt on" a new feature. Really, the current way > >isn't good for you guys, but EntArr doesn't help us in any way. We'd end > >up with two parallel interfaces that the "other guys" would have no use > >for except as a compatibility layer. > > > >The problem here is that iRel obviously needs to support a one-to-many > >relation *somehow*, and currently, it tries to do this by piggybacking > >on sets from iMesh/iGeom. That's what the "Set" relation type is. > >Obviously this is bad for implementations that don't use sets, but I > >think it's bad in general. It makes the implementation less clear, and > >if we want to support one-to-many relations (without deferring > >*completely* to iMesh/iGeom sets), we should commit to that instead of > >doing it partway (EntArr doesn't help one-to-many-sets, for instance). > > > >Besides, there's no logical difference between "RelationType = {Ent, > >Set, EntArr, SetArr}" and "RelationType = {Ent, Set}, CardinalityType = > >{One, Many}"*, but the latter way pushes iRel closer to "traditional" > >relational DBs, which can only be a good thing, if for no other reason > >than that it's easier to write documentation for. > > > >* I'm ignoring Both for now, just for simplicity. > > > >>>Don't take the above suggestion as endorsement, though. As the > >>>maintainer of (currently) the only iRel implementation, I should note > >>>that doing this (either your way or mine) will significantly increase > >>>the complexity and decrease the potential for interoperability** of iRel > >>>unless the iMesh and iGeom specs are updated as well. > >> > >>It's not clear why not having EntArr relation type. Please describe the following. > >> - how iRel, iMesh and iGeom should be updated further by having EntArr relation type. > > > >Again, I'm not saying that something equivalent to "EntArr" is bad, but > >that calling it that is limiting to us (there's no "SetArr"). Pulling it > >out into a "cardinality" flag does the same thing but reads better. > > > >However, either EntArr or my cardinality alternative would require us to > >significantly change how our iRel implementation works. If we stick with > >represent "many" as just a set, then we have to add a lot of extra logic > >to handle creating a one-to-many relation that isn't already backed by a > >set. The code for EntEntArr relations is already fairly brittle in > >Lasso, and I'd rather it not get worse. > > > >The "clean" alternative is to store the "many" directly on a tag, but > >that would mean we need variable-length tags in iMesh/iGeom or we have > >to fall back to MOAB's native interface, which would make it more > >difficult to use Lasso with any other implementation (or to port it > >over). > > > >> - why EntArr and Set are not othorgonal so iRel shouldn't have EntArr relation type losing the generality (limiting > >>its capability to support one-to-(set)many only). > > > >I'm not sure what exactly you mean by this, but if two things are > >orthogonal, as you seem to be suggesting, I think it makes sense for > >them to be represented as different parameters. > > > >> - why MOAB/Lasso cannot support EntArr relation type to account for FMDB-like implementation as we do support set > >>relation type to account for MOAB-like implementation in all other interfaces. > > > >I haven't said that we can't do this, only that it makes things > >significantly more complicated for us. As I already mentioned, my > >alternative doesn't actually make things any simpler for us, it just > >makes the interface clearer. > > > >- Jim > >

5 4

Notes from bootcamp on iRel interface
by Devine, Karen D 28 Oct '10

28 Oct '10

Attached are my notes from the iRel discussion at bootcamp.

1 0

Re: Proposal for Requiring Save/Restore of Sets and Tags
by Carl Ollivier-Gooch 26 Oct '10

26 Oct '10

On 10/05/2010 04:41 AM, Tim Tautges wrote: > With the current definition of set parent/child relations, you can embed > not only directed graphs in the data model, but also general graphs. In > this case you'd use only one of the parent/child types of links, and two > nodes in the graph linked by an edge would each have a parent link to > the other. Granted you'd need to be careful when traversing these, > because of the inherent cycles, but at least you'd be able to represent > them, in a part of the data model that is already fairly natural for > many of the other queries on graph nodes, and for representing other > types of (i.e. directed) graphs. > > As to what you'd use them for, choose any application of undirected > graphs on a mesh, e.g. maximal independent set, graph coloring, etc. These are things that one generally creates from a (undirected cyclic) graph of the individual entities (of a given type) in the mesh. So the only way I'm seeing a graph of sets here is if you create sets with exactly one entity apiece and string them together into a graph. I don't dispute that a general graph capability --- which isn't what our current data model supports --- would support this. But why would anyone ever do this this way? I mean, using iMesh sets to represent this graph is going to super-expensive because of the overhead of having a graph of -sets- instead of a graph of entities (unless there's some ultra-light-weight way to represent sets that I can't imagine). And the traversal isn't going to be any easier than representing the set in some other way, and is again going to be significantly more expensive. So you'll have to come up with some other example to convince me there's a realistic use case here. Finally, this definitely is outside either the subset/set member or parent-child relationships currently in the data model. My understanding is that we set out to do two kinds of things with set relationships. First, we wanted to be able to represent subsets. This our current data model does through adding sets to sets. Whether those sets are subsets (with entities belonging to both) or members (with entity members of the subset not necessarily being entity members of the containing set) is up to the application to decide, and to handle appropriately afterwards. This has obvious applications in things like representing all entities that are a certain material (for instance) and the entities that are on the bdry of that material. Second, we wanted to represent heirarchical relationships between collections of entities. For example, a fine mesh in a multigrid heirarchy (stored in a set) would be the parent of a coarse mesh in that same heirarchy (another set). Or an initial mesh in a refinement sequence (a set) would be the parent of a refined mesh in that same sequence (another set). This usage corresponds to a directed graph. It's semantically plausible that there be more than one route from one node in the graph to another. For instance, in multigrid semi-coarsening, one could have an initial fine mesh (A), two semi-coarsened meshes (in 2D; B_i and B_j), and fully coarsened mesh (C). A is a parent of both B_i and B_j, and B_i and B_j are both parents of C. This still isn't cyclic, of course. Both of these relationships have, IMO, well-defined semantics that were agreed upon a long time ago. (Maybe the "agreement" is overstated, but there's not been any objection to multiple write-ups of those semantics as I've stated them, which sounds like agreement to me.) Both of these are also directed relationships and --- semantically --- acyclic. As Mark M said, that's a tree. And I still haven't seen anything that looks --- to me --- like a compelling use case for graphs of sets that are undirected and/or cyclic. > I agree that embedding these types of graphs into a data model that > seems more geared to directed graphs is a stretch. But, in my view, we > should keep the possibility of embedding general graphs in the data > model, even if accessing those types of graphs is somewhat unnatural. If we're going to embed general graphs of entities in the data model, let's do that, instead of distorting a set data model with well-defined semantics to cover something it wasn't originally intended to (or at least, that I don't recall us ever discussing as an original intent). If nothing else, we can surely implement general graphs of entities in a much lighter-weight way than general graphs of sets, because we lose the set overhead. Carl -- ------------------------------------------------------------------------ Dr. Carl Ollivier-Gooch, P.Eng. Voice: +1-604-822-1854 Professor Fax: +1-604-822-2403 Department of Mechanical Engineering email: cfog(a)mech.ubc.ca University of British Columbia http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 http://tetra.mech.ubc.ca/ANSLab/ ------------------------------------------------------------------------

4 3

Re: Run-Time vs. Config-time error checking controls
by Tim Tautges 23 Oct '10

23 Oct '10

On 10/21/2010 12:53 PM, Mark Miller wrote: > On Thu, 2010-10-21 at 10:26, Jason Kraftcheck wrote: > >>> All the arguments for strict checking seem >> to center around helping developers avoid accidentally doing things that are >> not guaranteed to work with all implementations. While people may think >> that this is a good practice, mandating that our implementation conform to >> this practice seems well beyond the scope of the API specification. > > Why do we define iBase_ErrorType in iBase.h, then? Why don't we just let > all implementations decide what error codes to return or whether to > return any error code at all when the caller does something wrong or > something they shouldn't have or something that is 'not portable across > all implementations' (look for a follow-up email on this). > > I think specifying how the API responds to 'wrong' or 'erroneous' > actions by the caller is part of the API specification. In some cases, > its essential for implementors and users alike to know this. In other > cases, maybe the current issue at hand, it is not as critical. > I agree with this. However, I think the issue here is what some (Jason and I) believe is an over-zealous effort to disallow behavior in some implementations because it's outside some peoples' current understanding of what's useful today. So some people can't imagine an application that would use this capability; does somebody know of a real, not-contrived, case where an application had a problem with this? Does anybody know of a case where an application was turned off by inconsistency in the details between implementations? I can point to one of our (ITAPS') services that had trouble with this (swapping and lack of intermediate-dimension entities), but in that case we accommodated the various implementations, rather than disallowing specialized behavior. And on the subject of whether to change names, honestly, we're 9 years into a 10 year effort, and (some would say) already suffering from lack of uptake by applications. Changing names at this point won't help with that problem. Similarly, our problem isn't inconsistency between implementations that is being experienced by applications; it's there not being any or enough applications in the first place. Cutting the legs out of an implementation (i.e. disallowing the use of one of it's already-supported capabilities) doesn't send us in the right direction, IMO. - tim > Mark > -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706

1 0

Re: Proposal for Requiring Save/Restore of Sets and Tags
by Carl Ollivier-Gooch 23 Oct '10

23 Oct '10

On 10/20/2010 06:43 AM, Jason Kraftcheck wrote: > On 10/05/2010 10:35 AM, Carl Ollivier-Gooch wrote: > >> These are things that one generally creates from a (undirected cyclic) >> graph of the individual entities (of a given type) in the mesh. So the >> only way I'm seeing a graph of sets here is if you create sets with >> exactly one entity apiece and string them together into a graph. >> > > While our current use of tests is limited to tree-like graphs (geometric > topology, spatial subdivision trees, etc.) I'm hesitant to agree with the > premise that it will never be a useful capability to be able to construct > more general graphs of groups of entities. 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 anything that's got cycles will fail to have a set-theoretic meaning that's compatible with what we currently have in the data model. Allowing cycles would necessarily change the semantics of one of those two relationships, and I'm not prepared to do that because we -might- -someday- identify a use case for it. > Of course, if one really wanted to construct graphs of iBase_EntityHandle > type entities, thandle-type tags might be a better choice. But it wouldn't > use a lot more memory to use sets in MOAB. > >> I don't dispute that a general graph capability --- which isn't what our >> current data model supports --- would support this. >> >> But why would anyone ever do this this way? I mean, using iMesh sets to >> represent this graph is going to super-expensive because of the overhead >> of having a graph of -sets- instead of a graph of entities (unless >> there's some ultra-light-weight way to represent sets that I can't >> imagine). And the traversal isn't going to be any easier than >> representing the set in some other way, and is again going to be >> significantly more expensive. So you'll have to come up with some other >> example to convince me there's a realistic use case here. >> > > Well, as I said above, we do use sets for some graphs now. It is actually > much cheaper if one is creating graphs from groups of entities. But our > spatial search trees perform quite well constructed from sets and in that > case the non-leaf nodes don't have any entities. Our data model doesn't > really have anything else suitable to use for such graph nodes. Whether it's cheaper to use sets or some other, non-iMesh method to create the graph is going to depend heavily on the set implementation, I suspect. I'm sure my implementation of sets would use more memory for this than a purpose-built ADT (and frankly I'm surprised it's possible to beat the purpose-built ADT with any set implementation). Not saying that creating the graph this way is a bad thing, or that it doesn't make like easier for an app programmer... > But there very well could be in the future. We didn't imagine using sets > for spatial search trees when initially considering the data model. If and when a use case arises, we should discuss it then, IMO, rather than breaking well-defined semantics for a possibility. >>> I agree that embedding these types of graphs into a data model that >>> seems more geared to directed graphs is a stretch. But, in my view, we >>> should keep the possibility of embedding general graphs in the data >>> model, even if accessing those types of graphs is somewhat unnatural. >> >> If we're going to embed general graphs of entities in the data model, >> let's do that, instead of distorting a set data model with well-defined >> semantics to cover something it wasn't originally intended to (or at >> least, that I don't recall us ever discussing as an original intent). If >> nothing else, we can surely implement general graphs of entities in a >> much lighter-weight way than general graphs of sets, because we lose the >> set overhead. > > I don't have a strong opinion about this. But I am adamantly opposed to > requiring implementations to check for and refuse to create cyclic graphs. > We do some stuff involving very large graphs (e.g. millions of sets). The > performance penalty would be significant. And we already correctly handle > cyclic graphs in queries. 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. Carl -- ------------------------------------------------------------------------ Dr. Carl Ollivier-Gooch, P.Eng. Voice: +1-604-822-1854 Professor Fax: +1-604-822-2403 Department of Mechanical Engineering email: cfog(a)mech.ubc.ca University of British Columbia http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 http://tetra.mech.ubc.ca/ANSLab/ ------------------------------------------------------------------------

4 4

Re: Proposal for Requiring Save/Restore of Sets and Tags
by Jason Kraftcheck 21 Oct '10

21 Oct '10

On 10/21/2010 12:35 PM, Mark Miller wrote: > 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. Well, I still think that enforcing such a restriction will be too expensive. I'd rather deal with handling cycles correctly in queries and IO than traverse an entire graph for every link creation. > 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); > We don't really need the latter. One could construct an undirected graph by creating pairs of directed links. We'd probably implement it that way underneath anyway. It's a little bit more work for the application, but unless it is a widely used feature, I'm not worried about that. > And, I'd really, like to put tag data on graph links too. > I've also considered that in the past, but it would rather large implementation change late in the game. - jason

1 0

Re: Proposal for Requiring Save/Restore of Sets and Tags
by Carl Ollivier-Gooch 21 Oct '10

21 Oct '10

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(a)mech.ubc.ca University of British Columbia http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 http://tetra.mech.ubc.ca/ANSLab/ ------------------------------------------------------------------------

2 1

Re: Run-Time vs. Config-time error checking controls
by Jason Kraftcheck 21 Oct '10

21 Oct '10

On 10/21/2010 12:53 PM, Mark Miller wrote: > On Thu, 2010-10-21 at 10:26, Jason Kraftcheck wrote: > >>> All the arguments for strict checking seem >> to center around helping developers avoid accidentally doing things that are >> not guaranteed to work with all implementations. While people may think >> that this is a good practice, mandating that our implementation conform to >> this practice seems well beyond the scope of the API specification. > > Why do we define iBase_ErrorType in iBase.h, then? Why don't we just let > all implementations decide what error codes to return or whether to > return any error code at all when the caller does something wrong or > something they shouldn't have or something that is 'not portable across > all implementations' (look for a follow-up email on this). > That is a somewhat disingenuous argument. If we're going to provide error codes at all then clearly the definition of those error codes belongs in the API spec. Otherwise code that checked for errors wouldn't even compile if used with a different implementation (if we can't even guarantee that then our API spec has some issues). And clearly if any implementation returned success when an operation failed then that implementation has a bug. That is quite different from strong requirements on when an implementation must return an error code (if it things it can successfully do something.) > I think specifying how the API responds to 'wrong' or 'erroneous' > actions by the caller is part of the API specification. In some cases, > its essential for implementors and users alike to know this. In other > cases, maybe the current issue at hand, it is not as critical. > Well, now you've changed the discussion from how an implementation handles failures to mandating what must be considered a "wrong" action on the part of the caller. - jason

1 0

Re: Run-Time vs. Config-time error checking controls
by Jason Kraftcheck 21 Oct '10

21 Oct '10

On 10/21/2010 11:53 AM, Mark Miller wrote: > On Thu, 2010-10-21 at 09:35, Carl Ollivier-Gooch wrote: >> 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, > > So, I don't recall there being an ITAPS-wide, agreed upon config-time > switch names to control this. Do we have any defined? > > I know projects like HDF5 use something like --enable-production or > --enable-debug but I don't honestly know what the adopted 'ITAPS-way' > for this is, if there is one. If not, we might ought to propose one > ASAP. > >> 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. > > There are indeed config-time ways of managing the amount of work a > library is required to perform for error-checking, etc. And, honestly, > if the ITAPS project as a whole wants to do it using ONLY a config-time > control mechanism, I think that would be ok. > > My very strong personal preference, based on a lot of experience with > this kind of thing though, is a run-time check the default behavior of > which is controlled at config-time. > > If you config for 'release mode', the checks are OFF by default but can > be turned ON at run-time. If you config for 'development mode', the > checks are ON by default but can be turned off at run-time. > > Finally, the run-time controls consist of a) a function in the library > an application can call to affect ON/OFF control and b) an env. variable > or command line argument a user can set to override everything else > (note that a command-line argument appraoch would require a change to > iMesh_newMesh to accept argc/argv from the command line much like > MPI_Init does). > > Yeah, there is probably a tiny, imperceptable, run-time cost associated > with doing it this way. However, the flexibility it affords has always > trumped concerns for that ;) > If the iMesh API clearly states that developers should not expect an implementation to support cyclical links, why is that not sufficient? (I'm not saying that I think such a limitation is desirable, but that isn't the point I'm trying to make here.) All the arguments for strict checking seem to center around helping developers avoid accidentally doing things that are not guaranteed to work with all implementations. While people may think that this is a good practice, mandating that our implementation conform to this practice seems well beyond the scope of the API specification. If someone wants to verify the portability of their code across iMesh implementations then they can test it against the reference implementation (or whatever other iMesh implementations they expect to use it with.) If they need to do things that are beyond guarantees of the API then they should a) choose an implementation that will do what they want and b) be aware that their code may not work with all implementations. - jason

2 1