Hi Harry,

Impressed, you probably have more () than I have ever seen in an email without code embedded ;o)

OK, if you are limited in what you are allowed to report (!) then I agree that there are more informative statistics you could report than Rmerge. I further agree that in isolation Rmerge is a poor indicator of data quality as detailed in the references you mention - certainly for small multiplicity it is a very poor indicator.

However, it *is* useful even if not as useful as the others. My response to this, which is perhaps a little direct, would be to include all of the statistics in the table even if the journal do not support this, and then argue if they ask you to include *less* information in the manuscript (I mean, really!?). Therefore keeping *all* of the statistics in the aimless output is still a good thing. It's pretty easy to ignore numbers you don't want to read, harder to discover those which are absent!

Perhaps we (the community) should highlight those journals which do not allow inclusion of additional statistics (& citations, grr) and propose to them that they reconsider this position? As someone who does not frequently publish structural papers I do not face this challenge, but anecdotal evidence suggests this is a problem? Or maybe I'm more annoyed by this than the average person?

Cheerio Graeme


From: Harry Powell [mailto:[log in to unmask]]
Sent: 16 November 2015 10:37
To: Winter, Graeme (DLSLtd,RAL,LSCI)
Cc: ccp4bb
Subject: Re: [ccp4bb] NSMB Still Has Rmerge?

Hi Graeme

First off, sorry for the profusion of parenthetic statements which follow!

The point of the original post was (I believe) that at least one recent paper in NSMB reports R(merge) and does not have R(meas), CC1/2, etc reported - each of which (on its own) is more informative about the data reduction, and is in the same table, so is no harder to find and report. I suspect that  if you have to choose only one, you (personally) would not choose R(merge). But my strong suspicion is that you would say something along the lines of "I will not choose a single number to represent my data reduction quality"

My point (perhaps not phrased very well) was that _if_ a statistic is reported in the table 1 by a scaling program, then (what I called "naive" and in a previous post (on another subject) another poster to ccp4bb called "ignorant" ;-)) users cannot be completely to blame if they quote the figure - particularly if they look at historical papers and find that's what is used there.

I'd avoid this particular problem by saying "you've had nearly 20 years to get used to the idea that this particular statistic isn't useful, there are better statistics that are reported in the same place, use them instead, because it isn't going to be reported any more in Table 1"

It's not a case of "not liking" R(merge) - it's just not as useful as the other measures that are in Table 1;  I haven't heard anyone (perhaps I'm not listening...) saying that it gives information that is even as good as R(meas) (which has been in Table 1 since the last millenium...). By including it in the output in a prominent place, the scaling program authors are saying "this is a particularly valuable piece of information" - which I don't think it is, and I don't think they think so, either.

Do you know of a published rebuttal of Diederichs' & Karplus' point in their 1997 paper that "... we prove that R(sym) is seriously flawed"? (For the new reader, R(sym) in this context is the same as R(merge)).

Of course, it's only a tiny bit harder to report more detail, even if the restrictions of the journal prevent you from including the full table 1. So yes, include more information, but when you can't, at least report the best measures, not the worst.

Harry
--
Dr Harry Powell, MRC Laboratory of Molecular Biology, Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge, CB2 0QH
Chairman of International Union of Crystallography Commission on Crystallographic Computing
Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)

On 16 Nov 2015, at 09:31, <[log in to unmask]<mailto:[log in to unmask]>> <[log in to unmask]<mailto:[log in to unmask]>> wrote:
HI Harry

I cannot see it being a *bad thing* for anyone to record additional statistics even if some people "don't like" them :)

Clearly the best story is told through unmerged data (or images, or ...) but the full table of stats from AIMLESS or other scaling programs can give a nice picture which removing anything from makes less complete.

Just MHO

Cheerio G

From: CCP4 bulletin board [mailto:[log in to unmask]] On Behalf Of Harry Powell
Sent: 15 November 2015 16:01
To: ccp4bb
Subject: Re: [ccp4bb] NSMB Still Has Rmerge?

hi

While I agree very strongly with Jacob's point here (I suggest that those of you who don't agree should have a good read of many discussions on this BB passim and also check the literature), I have to point out that there are scaling programs out there that still report R(merge) - the _naive_ user running these programs can be forgiven for reporting it, since it's there (presumably to be quoted).

My feeling is that the onus is on the authors of the scaling/merging programs to remove the temptation from users - if it ain't there, they can't quote it.
Harry
--
Dr Harry Powell, MRC Laboratory of Molecular Biology, Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge, CB2 0QH
Chairman of International Union of Crystallography Commission on Crystallographic Computing
Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)

On 15 Nov 2015, at 14:09, Keller, Jacob <[log in to unmask]<mailto:[log in to unmask]>> wrote:
It's more the lack of reporting Rmeas, Rpim, or CC1/2, each of which has a better mathematical basis for the types of structures we look at these days. Take a look at the papers on the subject.

There is no reason to continue using Rmerge whatsoever. Period. (Full stop.).

JPK

-----Original Message-----
From: CCP4 bulletin board [mailto:[log in to unmask]] On Behalf Of Quyen Hoang
Sent: Sunday, November 15, 2015 8:48 AM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [ccp4bb] NSMB Still Has Rmerge?

I also don't see a problem with reporting R-merge.

Quyen

Sent from my BlackBerry 10 smartphone.
  Original Message
From: Ed Pozharski
Sent: Saturday, November 14, 2015 2:46 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Reply To: Ed Pozharski
Subject: Re: [ccp4bb] NSMB Still Has Rmerge?

No objection here.

On 11/13/2015 05:04 PM, Tim Gruene wrote:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ed,

even better to make unmerged data a deposition requirement.

Best,
Tim

On Friday, November 13, 2015 02:07:22 PM Ed Pozharski wrote:
There is nothing wrong with reporting Rmerge per se. The best place
to address this is probably PDB - if CC1/2, for example, becomes a
deposition requirement, you can always track it down whether it's
included in the paper or not. Standardizing "Table 1" across journal
universe would be impractical.


Sent from a mobile device
- --
- --
Paul Scherrer Institut
Tim Gruene
- - persoenlich -
OFLC/102
CH-5232 Villigen PSI
phone: +41 (0)56 310 5754

GPG Key ID = A46BEE1A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iD8DBQFWRl5uUxlJ7aRr7hoRAq1qAKDJQ9D7mRmWz/q3swX3K3SSdbwjPgCgyTbW
1rRT+q/nZKfo1MVUM1q9+08=
=uEri
-----END PGP SIGNATURE-----



--

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom