The DAM annex B algorithm again

Wilson, Peter R peter.r.wilson at boeing.com
Tue Jun 4 13:22:57 EDT 2002


    I have to apologise for claiming that there were problems with the DAM
annex B algorithm for example 157. I used the EXPRESS-G figure as the basis
for hand checking the results, and the EXPRESS-G model is not the same as
the EXPRESS model.

    I wasted some considerable time trying to get my algorithm to match the
results for the EXPRESS-G before I realised that it was not the example 157
EXPRESS model. 

    I will try and write up the BMW (Barkmeyer Modified Wilson) logic-based
annex B algorithm before the Stockholm meeting starts.

    Would anyone care to send me any *short* EXPRESS models (a la annex B)
to act as further rests for my BMW implementation?

Peter W.

Dr Peter R. Wilson
Boeing Commercial Airplanes
PO Box 3707, MS 6H-AF, Seattle, WA 98124-2207
(Package Delivery: MS 6H-AF, 1601 E. Valley Frontage Road, Renton, WA 98055)
Tel: (425) 237-3506, Fax: (425) 237-3428
Email: peter.r.wilson at boeing.com
--------------------------------
Any opinions expressed above are personal;
they shall not be construed as representative of any organisation.
--------------------------------
 

> -----Original Message-----
> From: Wilson, Peter R [mailto:peter.r.wilson at boeing.com]
> Sent: Thursday, May 23, 2002 3:44 PM
> To: 'wg11'
> Cc: Wilson, Peter R
> Subject: The DAM annex B algorithm again
> 
> 
>     I have implemented my checking algorithm (at least for a 
> single schema)
> for evaluated sets. It produces the results as given in Annex 
> B for examples
> 155 and 156. It does not agree with the results as given for 
> example 157,
> which shows a final tally of 27 members of the evaluated set. 
> There should
> be either 26 or 39 members.
>  
>     The 27th member is the combination: (a b d l x y z). To me this is
> a valid combination even though there is no common subtype of a or x
> present. If this is a valid combination via the given 
> algorithm then there
> should be 39 combinations in all. If it is not meant to be valid, then
> either the algorithm is wrong or it has been interpreted incorrectly.
> Currently my algorithm produces the (a z + possibly subtypes) 
> combinations
> --- it is a lot simpler that way.
> 
>     I have tried some simpler versions of example 157. They 
> all have the
> same supsub graph, but I have used different versions of a
> SUBTYPE_CONSTRAINT. The ENTITY model is:
> 
> { iso standard 10303 part (11) version (4) }
> SCHEMA annexb;
> 
> ENTITY a; END_ENTITY;
> ENTITY b SUBTYPE OF (a); END_ENTITY;
> ENTITY c SUBTYPE OF (a); END_ENTITY;    
> ENTITY d SUBTYPE OF (a); END_ENTITY;
> ENTITY f SUBTYPE OF (a); END_ENTITY;
> (* 
> -- constraint 1
> SUBTYPE_CONSTRAINT a1 FOR a;
>   ONEOF(b, c) AND d ANDOR f;
> END_SUBTYPE_CONSTRAINT;
> 
> -- constraint 2
> SUBTYPE_CONSTRAINT a2 FOR a;
>   (ONEOF(b, c) AND d) ANDOR f;
> END_SUBTYPE_CONSTRAINT;
> 
> -- constraint 3
> SUBTYPE_CONSTRAINT a3 FOR a;
>   ONEOF(b, c) AND d;
> END_SUBTYPE_CONSTRAINT;
> 
> *)
> END_SCHEMA;
> 
>     My algorithm produces the following evaluated sets:
> constraint 1 (9 members):
> (a) (abd) (acd) (af) (abf) (acf) (adf) (abdf) (acdf)
> 
> constraint 2 (9 members):
> (a) (abd) (acd) (af) (abf) (acf) (adf) (abdf) (acdf)
> 
> constraint 3 (6 members):
> (a) (abd) (acd) (af) (abdf) (acdf)
> 
>     There is a significant difference between the first two 
> and the third
> one, which depends on whether or not the ANDOR is included in the
> SUBTYPE_CONSTRAINT.
> 
>     Does the DAM algorithm show the same difference? What is 
> the `real'
> meaning of an ANDOR? Does it differ if the ANDOR is explicit 
> or implicit?
> 
>     I gather, although I have never seen one in action, that there are
> implementations of the Edition 1 Annex B algorithm. Has 
> anyone implemented
> the DAM algorithm, and if so does it give the same results as 
> shown in the
> DAM, the same results as the Edition 1 algorithm, the ...? 
> Working through
> the published algorithm by hand is highly error prone (dropping the &
> notation in favour of the algebraic multiplication notation 
> (i.e., a&b&c =>
> abc) would much improve the clarity of the examples, and 
> probably any hand
> calculation). I think it very desirable that there should be 
> at least one
> implementation of the algorithm before the DAM is published.
> 
> Peter W.
> 
> Dr Peter R. Wilson
> Boeing Commercial Airplanes
> PO Box 3707, MS 6H-AF, Seattle, WA 98124-2207
> (Package Delivery: MS 6H-AF, 1601 E. Valley Frontage Road, 
> Renton, WA 98055)
> Tel: (425) 237-3506, Fax: (425) 237-3428
> Email: peter.r.wilson at boeing.com
> --------------------------------
> Any opinions expressed above are personal;
> they shall not be construed as representative of any organisation.
> --------------------------------
>  
> 



More information about the wg11 mailing list