Hi Ed,

changes like this generate more confusion then good, I guess. Current
phenix.refine behavior does not create any problem for phenix.refine users,
so I don't feel a strong reason for changing anything. It's not just a
flipping the flag value somewhere, but it's updating the documentation,
replying a whole lot of emails offline subjected "why is this", etc etc..
On the other hand, I would rather suggest making the other programs
automatically recognize the right flag in most cases - it is a trivial
coding exercise that any developer can do within an hour, and does not
require changing habits.

Pavel

On Fri, Dec 9, 2011 at 6:34 AM, Ed Pozharski <epozh...@umaryland.edu> wrote:

> On Fri, 2011-12-09 at 05:45 -0800, Pavel Afonine wrote:
> > just a remark: for phenix.refine it does not matter where the flags
> > come from and what is the "test"/"work" value since it automatically
> > scores the values in the flags array and guesses the right one. Still
> > one can imagine corner case, so it's good to be careful -:)
>
> Since it does not matter to phenix.refine and it will remain backward
> compatible, how about changing the default behavior so that when the
> test set is missing, it is created with test_value=0?  Unless the
> test_value=1 expectation is hard-coded somewhere else, this seems like
> an easy fix, and will prevent the problems Chris was having.
>
> I always thought that test_value=1 is essentially inherited from the CNS
> default.  But when you think about it, the way it's done in
> refmac/freeflag makes much more sense because of:
>
> a) tiny improvement in code readability, since bool(0)=False (a very
> python-esque argument);
> b) if one wishes to use a different test set, 1/fraction of them are
> already generated.
>
> Cheers,
>
> Ed.
>
> --
> After much deep and profound brain things inside my head,
> I have decided to thank you for bringing peace to our home.
>                                    Julian, King of Lemurs
>
>

Reply via email to