From - Thu Feb 18 09:05:55 1999 Received: from db.stanford.edu (Seaotter.Stanford.EDU [171.64.75.89]) by DB.Stanford.EDU (8.8.8/8.8.8) with ESMTP id QAA01743 for ; Wed, 17 Feb 1999 16:52:06 -0800 Message-ID: <36CB6517.58C8D5D1@db.stanford.edu> Date: Wed, 17 Feb 1999 16:55:51 -0800 From: Dorothea Beringer Organization: Stanford University X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: chaims@DB.Stanford.EDU Subject: Progressive, partial extract Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mozilla-Status: 8001 Date[ February 17, 1999 ] Recordnr[ ] Who[ ns, lm, wp, db Agenda[ Minutes[ A general solution for progressive extract: this is the summary of our discussion, enhanced by some clarifications from me. Do you agree? If yes: Neal take over the lead for implementing the additional parameters (progress, resultname) in CLAM, CPAM, (also updating documentation about syntax and semantic on web), compiler, wrapper, Neal's demo example. If no: please mail me alternative proposals. Syntax: ======= (mystat = status, myprogr = progress) = h1.EXAMINE("resultname") progress and resultname are individually optional. status takes the values PARTIAL, DONE, NOT_DONE, ERROR. EXAMINE returns one or two results, depending on if the client requests one or both results. status is like now, yet with the added value of PARTIAL. progress is an integer. Semantic: ========= DONE (NOT_DONE): In case EXAMINE has taken no resultname as input parameter: all (not yet all) results are completely computed. In case EXAMINE has taken a resultname as input parameter: this result is (is not) completely computed PARTIAL: Invocationstatus PARTIAL expresses that the method as a whole has not yet completed, yet there are some meaningful results (either just some of the parameters, or some parameters only with a limited accuracy) ready for extraction though the computation will go on until all results are available with maximum accuracy. In case EXAMINE has taken no resultname as input parameter: some results are at least to some degree accurate and can be extracted. In case EXAMINE has taken a resultname as input parameter: this result can be extracted and contains some meaningful value. More information about the accuracy is in the progress parameter. progress: Progress gives qualitative information about the method or a specific result. Default-semantic is a value between 0 and 100, and gives the accuracy of the result in percents. This default semantic can be overriden by a megamodule provider by providing another semantic in the comment field of a method. The megamodule provider is free to attach any meaning he wants to the integer value of progress, as long as it has something to do with progress, yet the provider has to keep in mind the limited capabilities of CLAM in dealing with integers. CLAM can only compare an integer to a constant or another integer, but it cannot perform any bit-operations in it. In case EXAMINE has taken a result-name as input parameter: progress indicates the accuracy of this result parameter. In case EXAMINE has not taken a result-name as input parameter, but the invoked method only has one result-parameter: progress indicates the accuracy of this result parameter. In case EXAMINE has not taken a result-name as input, but has several result-parameters: meaning unspecified unless specified by the megamodule provider in the repository (possibilities: progress of method execution, accuracy for one specific result-parameter, average accuracy of all result parameters). Connection PARTIAL - progress: progress only has a valid value in connection with the status PARTIAL, with other stati, its value is undefined (unless specified otherwise by the megamodule provider). Qualitive information about result parameters is contained in progress. There is no parameter (like e.g. a list) with quantitative information about result parameters. This information is received implicitly, by calling EXAMINE for each possible result parameter. Partial extraction: =================== Above syntax and semantic can also be used for partial extraction of completed results, as well as for partial and progressive extraction combined. It means that the megaprogrammer has to call EXAMINE for each result that could be ready. Assuming that normally there will not be that many possible results, that should not be too bad. Postponed, alternative approach: ================================ Partial and progressive extraction with other syntax, e.g. returning a list of all the parameters that are ready with the degree to which they are ready, is postponed. Main issue of these approaches: they requite the concept of lists in the CLAM language, together with all the operations that are necessary to deal with leasts; comparing parameter names; maybe other issues? For now we assume that normally there will not be that many result parameters per method. Partial extract of completed results: ========================================= Partial extraction of results where all results are completed, yet are not exracted all at once, is already implemented. For this case the normal EXAMINE statement can be used, and extraction can start as soon as DONE and no more NOT_DONE is returned. -- Dorothea Beringer Stanford University beringer@db.stanford.edu http://www-db.stanford.edu/people/beringer.html --