On 2 November 2011 22:35, Chris Morley <c.mor...@gaseq.co.uk> 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. - Noel ------------------------------------------------------------------------------ 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 OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
