On 29/11/2011 20:56, Noel O'Boyle wrote: > On 2 November 2011 22:35, Chris Morley<[email protected]> wrote: >> On 01/11/2011 02:27, Geoff Hutchison wrote: >>> >>> On Oct 11, 2010, at 4:18 PM, Chris Morley wrote: >>> >>>> A simpler and more obvious model for this purpose has essentially a single >>>> IMPVAL for each charge state of the molecule. (Only if you are interested >>>> in radicals or hydrogen on the higher valency states of second row >>>> elements do you need another rule for each higher valence.) There is no >>>> need for any skilful fine tuning. It is more maintainable and will be >>>> faster because not so many SMARTS patterns need to be matched. Up to now, >>>> It has worked for everything I've tried (although this not very >>>> extensive), except with test_formula, where the fault is in a couple of >>>> erroneous results in formularesults.txt, which at least shows the old >>>> model was error-prone and needs some more tweaking of phosphate structures. >>> >>> I'd like to re-visit this idea now that we have some flexibility in the >>> development trunk. I tried last-year's patch, and saw ~14% speedup when >>> computing 279,000 formulas from a SD file. (The improvement comes from >>> eliminating the hybridization assignment.) >>> >>> (It also has the side benefit that we can try out ideas for MolCore rules >>> while testing them against existing OB tests.) >>> >>> Thoughts? >> >> I think we need a 2.3.2 release fairly soon. There are a number of bugs, >> some of which were new in 2.3.1 which we need to correct. Could we aim >> for the beginning of January? There needs to be a tag copy of 2.3.1 and >> then I guess we can use the 2-3-x branch for these corrections, some of >> which are already in trunk. Will you make the tag and do the merging? >> >> We can then use the trunk to try the new valence model and your success >> with it is encouraging. I could upload it, unless you want to, when you >> have done the merging. I realize that it is not essential to wait, but >> it avoids possible complications. Since the trunk would then be aimed at >> 2.4.0 I guess it then would be appropriate to add mods which destroy the >> binary compatibility? (In the fingerprint code particularly, when I get >> round to it.) > > To resurrect this thread...I think we should just go with it. It's > possible to tag "after the fact" (see bottom of > http://svnbook.red-bean.com/en/1.0/re07.html) so let that not stop us. > > Anyway, I've finally gotten around to testing the code (sorry!). If > the code is merged, I can describe a test case which I think can be > used to flush them out. Currently, it looks twice as good as the > current code (if I've interpreted the results correctly) but there's a > bit of work to be done still.
OK, lets do it. But I'm away and can't contribute until next Tuesday. Chris ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ OpenBabel-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openbabel-devel
