[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: DDLm implementation discussion
- To: comcifs@iucr.org
- Subject: Re: DDLm implementation discussion
- From: Doug <doug.duboulay@gmail.com>
- Date: Mon, 16 Mar 2009 10:12:34 +1100
- In-Reply-To: <49B6C363.3080604@mcmaster.ca>
- References: <49B6C363.3080604@mcmaster.ca>
On Wed, 11 Mar 2009, David Brown wrote: > There seems to be a consensus here that branching is built into dREL and > is desirable in a definition. It is not clear if this has to be > achieved using if-then constructs or an ordered loop defining the > different branch methods. If one goes for the if-then construction, how > does one ensure the tested item is present, or can one make provision > for a default procedure if it is not? If the definitions form a tree > (rather than a network with closed loops) it should not be possible to > get stuck in a loop as mentioned below by DD. If-then branching works in the case where the adp_type flag exists, but if it didn't, and there was no defalt value, the dREL implementation of that method should (and probably does), behind the scenes raise an exception. The nearest parent up the call hierachy that invoked this method should (but probably doesn't) catch it, look for the next comparable method in the adp_type method list and try that instead (this wasn't implemented that I know of). If the next alternative fails, or doesn't exist, the exception should propagate up to the next level of the call-stack hierarchy. I *think* the proto-prototype might just have caught it at the top level of the evaluation chain and aborted the whole evaluate call (probably because multiple eval methods weren't on the drawing board) One alternative would be littering the dREL syntax with try: except: blocks for in case the data_item access/evaluate methods fail. Once upon a time I thought that it would be a good idea to have the full flexibility of python available in the methods, but actually the syntax and expressions are easier to read and understand without it and I think Syd and Nick got that right. Another alternative would be just to add a builtin function to test availability of a data item, trap any exceptions generated and return true or false on success - for if-elsif-else testing. Actually, that might be more like a preprocessor/compile-time macro function than a run time function. Not sure. It could look like If ThisItemExist(a.adp_type) but that might force the eval before the function call. Or it might be simpler as a quoted string? If ThisItemExist("a.adp_type") About method calls in a recursive loop, that *might* be trappable by the dREL parser. It could be that a given method might be called more than once in an eval call-stack hierarchy but with a different argument for each call. That might be quite complicated to check. Possibly you would need to duplicate the whole CIF instance with each call so you could check that absolutely nothing had changed in between each repeated method call. Not sure how that would work though. > AMBIGUITY IN THE USE OF THE BETA FORM OF THE ADP > IDB Comment: > Nick is referring here to the way matrices are constructed from the > individual matrix elements stored in the CIF. The assumption is that > experimental information will be given as matrix elements and the > matrices themselves would only be created under dictionary control. So > Nick is right as long as no-one enters the beta matrix as a matrix > because individual matrix elements do not appear in the dictionary. > However, there is nothing I am aware of in DDLm that prevents the matrix > from being generated by external software or a word processor, and the > convenience of doing so may encourage users to take this shortcut. The > question is how to prevent this. Assuming the current generation of CIF editors read the dictionaries and expose the text based descriptions to users, could you not simply add a warning to the description saying something like: "Don't use this in a real CIF"? I know some items have deprecation warnings already (despite the fact that any backwards compatible CIF reading software still need to check and handle such items). Also people are free to put all manner of junk in a CIF file, but if they want to get it published they typically need to go through checkcif. So you still have that as a beta blocker, and any other use they make of it would be entirely at their own risk. > A further danger is one that > Herbert pointed out in Osaka. He suggested that DDLm CIF dictionaries > would make CIF more dynamic compared with the static character of CIF1 > and CIF2, and if some experimental or assigned value (e.g., the cell > constants), were changed there would be no way we could ensure that all > the derived items would be automatically updated. Syd and Nick used to talk of adding validation methods as well as evaluation methods. Presumably a validation method would establish an item's veracity, even if it was included. > Which seems perfectly logical to me. dREL is a Turing complete language and > while there is one evaluation method in an item definition you can create a > multitude of paths to the answer - and that is a GOOD THING. except for the halting problem. > > As is well known, the devil is in the details, and in adapting the CIF > dictionaries I will have to make many decisions in matters of detail. > But if there is agreement on splitting the dictionaries into archive and > derived-item dictionaries as described above, I will have a guideline to > work with. I will undoubtedly come back with other problems in the > future but this split seems to be in the spirit of DDLm and appears to > solve a number of important problems. One possible fly in the ointment might be some of the category.id elements, which I gather are important for uniqueness in the relational database model, but were significantly redundant e.g. _geom_torsion.id, at least in the early DDLm core dictionary. Don't know if that would have any impact by being relegated to a backup method dictionary? > Is this plan acceptable to everyone? If so, I will start to apply it > and move this discussion on to the next problem. Sorry, my info is quite old, but hopefully it might help a little bit. cheers Doug
Reply to: [list | sender only]
- References:
- DDLm implementation discussion (David Brown)
- Prev by Date: DDLm implementation discussion
- Next by Date: IUCr CIF website upgrade
- Prev by thread: DDLm implementation discussion
- Next by thread: A DDLm problem
- Index(es):