itaps-parallel Proposal for Requiring Save/Restore of Sets and Tags

[Carl Ollivier-Gooch]

On 10/21/2010 12:35 PM, Jason Kraftcheck wrote:
> On 10/21/2010 02:10 PM, Carl Ollivier-Gooch wrote:
>> On 10/21/2010 11:45 AM, Jason Kraftcheck wrote:
>>> On 10/21/2010 01:30 PM, Carl Ollivier-Gooch wrote:
>>
>>>> The -real- issue is that there are internal checks that should be done
>>>> to help API users with debugging.  This is why we return errors.  Yes,
>>>> this is something the compliance tests check for, but that's not why
>>>> they're there.
>>>>
>>>
>>> We return errors when things fail.  That is an obviously well accepted
>>> programming practice.  Failure to return an error flag of some kind
>>> when an
>>> operation fails is a bug (regardless of whether or not one is in a
>>> "release"
>>> mode.)  That is distinct from helping users with debugging, which
>>> should be
>>> an implementation issue.
>>
>> But those error returns are precisely the debugging aid to which I
>> refer.
>
>
> No, success or failure is not the same as verifying conformance (of the
> application) with the iMesh spec.

No, it isn't, in that some failures aren't due to violation of the spec. 
  But violations of the spec (including bizarre input) are errors, and 
if the spec mandates that certain requests aren't legal, those errors 
should be identified by the implementation (perhaps with user control of 
the degree of checking for efficiency).

>> If the iMesh spec says that an error code should be returned
>> when someone tries to iterate over all faces of topology prism, then
>> users should get that error code when they make that silly mistake.
>
> I'm not sure why that would be an error, but anyway keeping with your
> example:  If moab cannot return a valid result given the input (e.g. because
> the spec specifically prohibits us from doing so), that is an error and that
> is why we have error codes.  If on the other hand the spec did not prohibit
> us from satisfying that request we could certainly return the faces of a
> prism (or any other region element.)  If the spec said that getting the
> faces of a prism is not supported but does not mandate that implementations
> fail in that case, we could still successfully handle that query.  Not
> returning an error code in that case would be more of a refusal to do
> conformance testing for the application than a failure of MOAB to conform to
> the standard.

I was referring to the case of requesting an -iterator- over faces that 
are also prisms.  That's pretty clearly a malformed call.  Retrieving 
the faces of a prism is equally clearly not.

>> Same
>> goes for other behavior the spec says is erroneous.  This is different
>> than returning failures for internal errors, which, as you say, an
>> implementation should also do.
>>
>
> I didn't say anything about internal errors.  I've been discussing only
> validation of user input.  We must return an error code if the user input is
> such that the request cannot be satisfied.  And the distinction between
> those that are due to invalid input vs. implementation limitations vs. those
> that are neither but must fail because the standard mandates that they do.

In many (most?) cases, the existence of your third case is a matter of 
definition of invalid input, IMO.  (There may be cases I'm not thinking 
about.)  In principle, the standard should describe what constitutes 
valid input, so things that fail because the standard mandates that they 
do are by definition invalid input -for- -this- -API-.  We have to be 
careful to avoid definitions that make people point and laugh, of 
course... the case that Jason thought I was describing above would be 
one of those.

>>> If the implementation is unusable in "testing" mode because it is
>>> doing some
>>> O(n^2) checking operation then have we really helped the developer?
>>
>> No.  But I don't know that mandate any error checking that's that
>> expensive, at least with good implementation.
>>
>
> But this whole thread of discussion started out of the proposal that the
> spec mandate that we must do an O(n) check that will result in O(n^2)
> behavior.  And then got into your and Mark's recommendations about best
> practices for how one should implement error checking in libraries and how
> if our implementation conformed to those practices we could avoid this whole
> issue by conforming to the standard only in a "debug" build.

Okay, I'll concede that one can construct a graph for which this test 
would be O(n) --- a graph that can be mapped onto a straight line.  And 
for balanced trees, I guess the check is still O(log n), for total 
complexity of O(n log n).  That still isn't great, but it's no worse 
than the complexity for constructing the tree itself.

I will say that this is a fairly strong argument --- at least when 
combined with the principle that implementations should always check for 
all error conditions that the spec describes --- in favor of changing 
the semantics of whatever we end up calling what's currently 
parent-child relationships.

>> Checks for conditions that the iMesh spec says should return an error
>> don't fall into the category of implementation choices,
>
> I certainly agree.  Thus the discussion of whether or not this check should
> be mandated in the spec.  And if it were mandated in the spec, I'd be
> somewhat dubious about disabling it for "release" builds, regardless of
> whether or not the conformance test checked for it.

Good point.

>> I suppose not in a practical sense.  But in this case, users who are
>> developing against your implementation may be doing things that aren't
>> supported by other implementations.  This is something we should avoid
>> wherever we can.
>>
>> Coming back to the present case, we seem to have two choices:
>>
>> 1.  Keep the present semantics and (to keep interoperability) mandate
>> the check.
>>
>
> This isn't keeping interoperability.  It is requiring implementations do
> interoperability checks for applications.  If they want those checks then
> they can test with reference implementation.

Huh?  If the spec says that X must happen, and all implementations but 
one do that, then an implementation that doesn't isn't interoperable 
with the others, in the sense that code written to exploit that feature 
of that implementation fails on the others.  As you've all probably 
gathered, I'm in favor of narrowing down the possibilities of this sort 
of thing in the API; after all, we're advertising interoperability as a 
major selling point.

>> 2.  Change the current semantics, rendering the check irrelevant.  If
>> we're going to do this, we face the issue of supporting both directed
>> and undirected graphs, presumably.  Here the interoperability problem
>> would be limited to a transition period when we have some
>> implementations that don't fully support undirected and/or cyclic
>> graphs.  I think I could support cyclic directed graphs by removing a
>> check.  Undirected graphs could be really easy or could require
>> significant re-write; I'm not sure without dissecting the code.
>>
>
> 3.  Don't mandate that implementations refuse to create cyclic graphs.

If this is made interoperable, in the sense of my last paragraph, how 
does it differ from 2 (leaving aside the directed/undirected issue)?

For what it's worth, I can imagine a use case for -undirected- cyclic 
graphs of sets of entities: lumped partitioning and related tasks. 
That's two changes in semantics, but we actually get a use case for our 
trouble this way.

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/
------------------------------------------------------------------------