[cctbxbb] rt_mx inconsistencies

[Phil Evans]

Thank you for that clear explanation
Phil

On 19 Jul 2012, at 10:34, Luc Bourhis wrote:

> Hi Phil,
> 
>> Is there a reason why "==" test of rt_mx or rot_mx would do anything other than test them element by element? Or is this a side-effect of providing a rank order?
> 
> I hinted at the answer in my original email. Let me elaborate.
> 
> The new comparisons < and > rely on the geometrical elements of the compared rt_mx instances. That is sensible since, in any application I can think of, one will want e.g. higher orders to come first, then for the same orders, rotations about cell axis a to come before rotation about cell axis b, etc. I don't remember in details the implementation of those inequality operators, so I am making it up for the sake of illustration! Using element-wise comparison for those > and < operators is pretty pointless on the contrary.
> 
> But then, for any objects for which x > y and x < y are defined, we must have the following equivalences:
> x <= y  equivalent to   not(x > y);
> x >=y   equivalent to   not(x < y);
> x == y  equivalent to   x >= y and x <= y.
> Those are general mathematical rules that have nothing to do with crystallography.
> 
> Thus it is highly sensible, having defined operators > and < to implement operator== using those rules. This is precisely what has been done in the revision that broke the code in your regression test.
> 
> Now, the key question we must asked ourselves is: because one particular algorithm needs an ordering on the set of rt_mx, is it a good idea to implement that ordering in the rt_mx class? Related question: is it likely that another algorithm may need another ordering? or that one may want to tweak the ordering for one algorithm? If the answer to any of the last two question is a lukewarm "yes", then the answer to the first question is a resounding "no". I had faced the very same issue when I worked on reconstructing the space-group from FFT map and my take at it was to wrap rt_mx instances in a proxy and to define the order on that proxy. That way, I can use different orderings by using different proxy classes and the essential brick rt_mx can keep its straightforward definition of comparison. I haven't studied in enough depth the symmetry-equivalent pair interaction table generation algorithm to be sure that this approach can work but I am reasonably optimistic that this pattern is applicable.
> 
> Sorry for the exaggeratedly long email(s), best wishes,
> 
> Luc
> 
> _______________________________________________
> cctbxbb mailing list
> cctbxbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/cctbxbb