Frank von Delft wrote:
> Sharp people have a point, though, don't they? There's nothing
> mathematically or conceptually wrong with the A-B representation?
No.
But look at the options:
1. Fix one program (sharp) to write the data in the same format as
everyone else, or
2. Fix every program which reads MTZ files to read either phi/fom or A/B.
The cost is not just for me to modify clipper to allow it, but I'll then
be asked to modify every application I've written to read them. Every
user interface will be cluttered up with yet another input option. More
people are going to start writing the non-standard files. And anyone
else writing MTZ-based applications is going to get requests to support
it too.
I think option (2) is bad for me, bad for CCP4, and bad for crystallography.
> Won't there also be other cases where the 1-1 mapping breaks down?
The only other cases I have found where the 1-1 mapping doesn't work is
where there are multiple datatypes sharing a single file representation.
e.g. most map file formats (CCP4 included) do not distinguish between
crystallographic and non-crystallographic maps. In this case we have a
2-1 (true datatype - file representation) mapping. Clipper handles n-1
mappings like this just fine, although as a result you lose the benefits
of validating the file data - you just have to trust that it really
matches the type you are trying to read it as.
So the 1-1 and n-1 mappings are handled, although handling the n-1 case
is not without cost. The 1-n mapping is rather more costly. If there is
no other option, it can be done by specifying a user-defined datatype
with its own file representation, and then translating from the new
datatype to the old one internally, i.e. a sort of 1-n-n mapping.
|