Adding to this: the current test set generation in freerflag has one brilliant feature and that is reproducibility. If you misplace your test set, you can reproduce the same one if you run freerflag on the same complete set of reflections. This was an excellent design choice. It has proved very useful in the past and it even pointed out cases in the PDB where only the working set of reflections was deposited.
Any change to freerflag that would remove this feature would be a loss. Cheers, Robbie Sent from my Windows 10 phone Van: Tim Gruene<mailto:tim.gru...@psi.ch> Verzonden: dinsdag 31 januari 2017 18:10 Aan: CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK> Onderwerp: Re: [ccp4bb] variation in freerflag Hi Ville, it actually does not affect the quality of the Rcomplete value that I am computing, so from my point of you this discussion was rather a matter of interest and you should only invest time in case someone else has a reason. Best regards, Tim On Tuesday 31 January 2017 03:54:09 PM Ville Uski wrote: > Hi Tim > > thanks for the clear explanation. Currently it separately and randomly > draws the flags for each reflection, but the reflections related by twin > or symmetry operations (NCS is ignored) get the same flag, unless the > 'NOSYM' keyword is used. This doesn't guarantee that each flag occurs > the same number of times. > > this could be done if there's interest. > > best wishes > Ville > > On Tue, Jan 31, 2017 at 03:06:46PM +0100, Tim Gruene wrote: > > Hi Ville, > > > > let's assume you have 5,000 reflections and want 50 reflections to be in > > the same bin (i.e. flagged with the same Rfree flag). > > > > You enumerate your reflections and create a parallel list with 50 zeros, > > 50 > > ones, 50 twos, ... 50 onehundreds. > > > > Then you run through the second list, and swap every number with an random > > position, and place this back next to your list of reflections. When you > > bin all zeros, all ones, etc, you end up with a random distribution > > across all relfections and each bin has (about) the same size. > > > > In most cases, the bin size won't divide the total number of reflections. > > In that case you could either leave the last bin smaller, or you could > > distribute the remaining reflections randomly across the remaining bins. > > > > When you create the initial 'parallel list', you can take various special > > cases into account, like flagging reflections related by NCS, or twin law, > > etc. > > > > I've attached the code how I did it in crossflaghkl, which does not take > > any special cases into account and which assumes merged data. > > > > Best wishes, > > Tim > > > > On Tuesday 31 January 2017 11:45:16 AM Ville Uski wrote: > > > On Tue, Jan 31, 2017 at 03:29:15AM +0100, Tim Gruene wrote: > > > > I had long wondered how to flag the fields in game minesweeper with a > > > > deterministic algorithm. When I read about 'random sort and bin' I > > > > though > > > > this was quite a beautiful way. I wonder if there is any reason behind > > > > not doing it this way in freerflag. > > > > > > it could do that if requested.. What exactly means 'random sort > > > and bin'? > > > > > > Ville > > > > -- > > -- > > Paul Scherrer Institut > > Dr. Tim Gruene > > - persoenlich - > > Principal Investigator > > Biology and Chemistry > > OFLC/102 > > CH-5232 Villigen PSI > > > > Phone: +41 (0)56 310 5297 > > > > GPG Key ID = A46BEE1A -- -- Paul Scherrer Institut Dr. Tim Gruene - persoenlich - Principal Investigator Biology and Chemistry OFLC/102 CH-5232 Villigen PSI Phone: +41 (0)56 310 5297 GPG Key ID = A46BEE1A
