On Jun 20, 2013, at 1:47 PM, Felix Frolow <mbfro...@post.tau.ac.il> wrote:
> Intensity is subtraction: Inet=Iobs - Ibackground. Iobs and Ibackground can > not be negative. Inet CAN be negative if background is higher than Iobs. Just to reiterate, we know that the true value of Inet cannot be negative. Hence, the equation you quote is invalid and illogical --- it has no physical or statistical justification (except as an approximation for large Iobs and low Iback, when ironically background correction is unnecessary). That equation does not account for random statistical fluctuations (e.g., simple Poisson counting statistics of shot noise). > We do not know how to model background scattering modulated my molecular > transform and mechanical motion of the molecule, > I recall we have called it TDS - thermal diffuse scattering. Many years ago > Boaz Shaanan and JH were fascinated by it. > If we would know how deal with TDS, we would go to much nicer structures some > of us like and for sure to much lower > R factors all of us love excluding maybe referees who will claim over > refinement :-\ > Dr Felix Frolow > Professor of Structural Biology and Biotechnology, > Department of Molecular Microbiology and Biotechnology > Tel Aviv University 69978, Israel > > Acta Crystallographica F, co-editor > > e-mail: mbfro...@post.tau.ac.il > Tel: ++972-3640-8723 > Fax: ++972-3640-9407 > Cellular: 0547 459 608 > > On Jun 20, 2013, at 20:07 , Douglas Theobald <dtheob...@brandeis.edu> wrote: > >> How can there be nothing "wrong" with something that is unphysical? >> Intensities cannot be negative. How could you measure a negative number of >> photons? You can only have a Gaussian distribution around I=0 if you are >> using an incorrect, unphysical statistical model. As I understand it, the >> physics predicts that intensities from diffraction should be gamma >> distributed (i.e., the square of a Gaussian variate), which makes sense as >> the gamma distribution assigns probability 0 to negative values. >> >> >> On Jun 20, 2013, at 1:00 PM, Bernard D Santarsiero <b...@uic.edu> wrote: >> >>> There's absolutely nothing "wrong" with negative intensities. They are >>> measurements of intensities that are near zero, and some will be negative, >>> and others positive. The distribution around I=0 can still be Gaussian, >>> and you have true esd's. With F's you used a derived esd since they can't >>> be formally generated from the sigma's on I, and are very much undetermined >>> for small intensities and small F's. >>> >>> Small molecule crystallographers routinely refine on F^2 and use all of the >>> data, even if the F^2's are negative. >>> >>> Bernie >>> >>> On Jun 20, 2013, at 11:49 AM, Douglas Theobald wrote: >>> >>>> Seems to me that the negative Is should be dealt with early on, in the >>>> integration step. Why exactly do integration programs report negative Is >>>> to begin with? >>>> >>>> >>>> On Jun 20, 2013, at 12:45 PM, Dom Bellini <dom.bell...@diamond.ac.uk> >>>> wrote: >>>> >>>>> Wouldnt be possible to take advantage of negative Is to >>>>> extrapolate/estimate the decay of scattering background (kind of Wilson >>>>> plot of background scattering) to flat out the background and push all >>>>> the Is to positive values? >>>>> >>>>> More of a question rather than a suggestion ... >>>>> >>>>> D >>>>> >>>>> >>>>> >>>>> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Ian >>>>> Tickle >>>>> Sent: 20 June 2013 17:34 >>>>> To: ccp4bb >>>>> Subject: Re: [ccp4bb] ctruncate bug? >>>>> >>>>> Yes higher R factors is the usual reason people don't like I-based >>>>> refinement! >>>>> >>>>> Anyway, refining against Is doesn't solve the problem, it only postpones >>>>> it: you still need the Fs for maps! (though errors in Fs may be less >>>>> critical then). >>>>> -- Ian >>>>> >>>>> On 20 June 2013 17:20, Dale Tronrud >>>>> <det...@uoxray.uoregon.edu<mailto:det...@uoxray.uoregon.edu>> wrote: >>>>> If you are refining against F's you have to find some way to avoid >>>>> calculating the square root of a negative number. That is why people >>>>> have historically rejected negative I's and why Truncate and cTruncate >>>>> were invented. >>>>> >>>>> When refining against I, the calculation of (Iobs - Icalc)^2 couldn't >>>>> care less if Iobs happens to be negative. >>>>> >>>>> As for why people still refine against F... When I was distributing >>>>> a refinement package it could refine against I but no one wanted to do >>>>> that. The "R values" ended up higher, but they were looking at R >>>>> values calculated from F's. Of course the F based R values are lower >>>>> when you refine against F's, that means nothing. >>>>> >>>>> If we could get the PDB to report both the F and I based R values >>>>> for all models maybe we could get a start toward moving to intensity >>>>> refinement. >>>>> >>>>> Dale Tronrud >>>>> >>>>> >>>>> On 06/20/2013 09:06 AM, Douglas Theobald wrote: >>>>> Just trying to understand the basic issues here. How could refining >>>>> directly against intensities solve the fundamental problem of negative >>>>> intensity values? >>>>> >>>>> >>>>> On Jun 20, 2013, at 11:34 AM, Bernhard Rupp >>>>> <hofkristall...@gmail.com<mailto:hofkristall...@gmail.com>> wrote: >>>>> As a maybe better alternative, we should (once again) consider to refine >>>>> against intensities (and I guess George Sheldrick would agree here). >>>>> >>>>> I have a simple question - what exactly, short of some sort of historic >>>>> inertia (or memory lapse), is the reason NOT to refine against >>>>> intensities? >>>>> >>>>> Best, BR >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >
