Checks whether another element is semantically equivalent to this one. Two elements are considered equivalent if they have the same specification (i.e. same tag appearing in the same context), the same attribute values, and all of their children are equivalent. The ordering of non-r
(self, other)
| 42 | |
| 43 | @abc.abstractmethod |
| 44 | def is_same_as(self, other): |
| 45 | """Checks whether another element is semantically equivalent to this one. |
| 46 | |
| 47 | Two elements are considered equivalent if they have the same |
| 48 | specification (i.e. same tag appearing in the same context), the same |
| 49 | attribute values, and all of their children are equivalent. The ordering |
| 50 | of non-repeated children is not important for this comparison, while |
| 51 | the ordering of repeated children are important only amongst the same |
| 52 | type* of children. In other words, for two bodies to be considered |
| 53 | equivalent, their child sites must appear in the same order, and their |
| 54 | child geoms must appear in the same order, but permutations between sites |
| 55 | and geoms are disregarded. (The only exception is in tendon definition, |
| 56 | where strict ordering of all children is necessary for equivalence.) |
| 57 | |
| 58 | *Note that the notion of "same type" in this function is very loose: |
| 59 | for example different actuator element subtypes are treated as separate |
| 60 | types when children ordering is considered. Therefore, two <actuator> |
| 61 | elements might be considered equivalent even though they result in different |
| 62 | orderings of `mjData.ctrl` when compiled. As it stands, this function |
| 63 | is designed primarily as a testing aid and should not be used to guarantee |
| 64 | that models are actually identical. |
| 65 | |
| 66 | Args: |
| 67 | other: An `mjcf.Element` |
| 68 | |
| 69 | Returns: |
| 70 | `True` if `other` element is semantically equivalent to this one. |
| 71 | """ |
| 72 | |
| 73 | @property |
| 74 | @abc.abstractmethod |
no outgoing calls