Menu
▾
▴
cclib-devel
|
From: Karol L. <kar...@kn...> - 2007-04-27 13:41:15
|
I changed all references to NumPy, but left the Numeric imports (when importing numpy fails). Some method names had to be changed. All the tests and regressions go fine, although I'm worried we don't have tests for all the methods, since that's where the most Numeric functions are used. - Karol -- written by Karol Langner Fri Apr 27 17:36:53 CEST 2007 |
|
From: Noel O'B. <bao...@gm...> - 2007-04-27 13:47:25
|
Let's leave a few days "cooling off period" to look through the code for anything that doesn't seem right. On 27/04/07, Karol Langner <kar...@kn...> wrote: > I changed all references to NumPy, but left the Numeric imports (when > importing numpy fails). Some method names had to be changed. All the tests > and regressions go fine, although I'm worried we don't have tests for all the > methods, since that's where the most Numeric functions are used. > > - Karol > > -- > written by Karol Langner > Fri Apr 27 17:36:53 CEST 2007 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Karol L. <kar...@kn...> - 2007-04-28 07:45:03
|
Sure. I'll just mention the more important changes in names: Numeric.matrixmultiply -> numpy.dot Numeric.outerproduct -> numpy.outer LinearAlgebra.inverse -> numpy.linalg.inv Numeric.typecode -> numpy.dtype The last was the problematic one, since Numeric.typecode is a function, while numpy.dtype is a type. On Friday 27 April 2007 15:47, Noel O'Boyle wrote: > Let's leave a few days "cooling off period" to look through the code > for anything that doesn't seem right. > > On 27/04/07, Karol Langner <kar...@kn...> wrote: > > I changed all references to NumPy, but left the Numeric imports (when > > importing numpy fails). Some method names had to be changed. All the > > tests and regressions go fine, although I'm worried we don't have tests > > for all the methods, since that's where the most Numeric functions are > > used. > > > > -- > > written by Karol Langner > > Fri Apr 27 17:36:53 CEST 2007 -- written by Karol Langner Sat Apr 28 11:36:59 CEST 2007 |
|
From: Noel O'B. <bao...@gm...> - 2007-04-28 10:17:44
|
Nice work! On 28/04/07, Karol Langner <kar...@kn...> wrote: > Sure. I'll just mention the more important changes in names: > > Numeric.matrixmultiply -> numpy.dot > Numeric.outerproduct -> numpy.outer > LinearAlgebra.inverse -> numpy.linalg.inv > Numeric.typecode -> numpy.dtype > > The last was the problematic one, since Numeric.typecode is a function, while > numpy.dtype is a type. > > On Friday 27 April 2007 15:47, Noel O'Boyle wrote: > > Let's leave a few days "cooling off period" to look through the code > > for anything that doesn't seem right. > > > > On 27/04/07, Karol Langner <kar...@kn...> wrote: > > > I changed all references to NumPy, but left the Numeric imports (when > > > importing numpy fails). Some method names had to be changed. All the > > > tests and regressions go fine, although I'm worried we don't have tests > > > for all the methods, since that's where the most Numeric functions are > > > used. > > > > > > -- > > > written by Karol Langner > > > Fri Apr 27 17:36:53 CEST 2007 > > -- > written by Karol Langner > Sat Apr 28 11:36:59 CEST 2007 > |
|
From: Adam T. <a-t...@st...> - 2007-05-07 18:44:31
|
So does this mean that Numeric will no longer work and NumPy is now required? Just curious... Adam On Apr 28, 2007, at 3:17 AM, Noel O'Boyle wrote: > Nice work! > > On 28/04/07, Karol Langner <kar...@kn...> wrote: >> Sure. I'll just mention the more important changes in names: >> >> Numeric.matrixmultiply -> numpy.dot >> Numeric.outerproduct -> numpy.outer >> LinearAlgebra.inverse -> numpy.linalg.inv >> Numeric.typecode -> numpy.dtype >> >> The last was the problematic one, since Numeric.typecode is a >> function, while >> numpy.dtype is a type. >> >> On Friday 27 April 2007 15:47, Noel O'Boyle wrote: >>> Let's leave a few days "cooling off period" to look through the code >>> for anything that doesn't seem right. >>> >>> On 27/04/07, Karol Langner <kar...@kn...> wrote: >>>> I changed all references to NumPy, but left the Numeric imports >>>> (when >>>> importing numpy fails). Some method names had to be changed. All >>>> the >>>> tests and regressions go fine, although I'm worried we don't >>>> have tests >>>> for all the methods, since that's where the most Numeric >>>> functions are >>>> used. >>>> >>>> -- >>>> written by Karol Langner >>>> Fri Apr 27 17:36:53 CEST 2007 >> >> -- >> written by Karol Langner >> Sat Apr 28 11:36:59 CEST 2007 >> > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel |
|
From: Karol L. <kar...@kn...> - 2007-05-10 18:29:42
|
On Monday 07 May 2007 20:44, Adam Tenderholt wrote: > So does this mean that Numeric will no longer work and NumPy is now > required? Just curious... > > Adam As fas as I can tell, everything in cclib still works with Numeric. I haven't actaully run the tests until now (just commited a little hack to get the test code working, though), but they do finish fine. The regression tests are also OK. It is wise, however, to drop Numeric at some point, since it is not supported anymore. - Karol -- written by Karol Langner Thu May 10 20:25:26 CEST 2007 |
|
From: Adam T. <a-t...@st...> - 2007-05-15 20:37:34
|
> As fas as I can tell, everything in cclib still works with Numeric. > I haven't > actaully run the tests until now (just commited a little hack to > get the test > code working, though), but they do finish fine. The regression > tests are also > OK. It is wise, however, to drop Numeric at some point, since it is > not > supported anymore. The Mulliken and C-squared population analysis are broken with revision 624. I haven't really explored it other than noticing that the numbers are way off and that it looks like every aoresult for a given MO have the same number (~1). Adam |
|
From: Noel O'B. <bao...@gm...> - 2007-05-15 22:50:05
|
It's likely that all algorithms have been broken - I assume I'm going to have similar problems with GaussSum. It's best to make a clean break with Numeric as this point though, as it's no longer available for Python 2.5 on windows for example, which about 50% of people are now using. We will fix all these issues before the next release (promise!). Noel On 15/05/07, Adam Tenderholt <a-t...@st...> wrote: > > As fas as I can tell, everything in cclib still works with Numeric. > > I haven't > > actaully run the tests until now (just commited a little hack to > > get the test > > code working, though), but they do finish fine. The regression > > tests are also > > OK. It is wise, however, to drop Numeric at some point, since it is > > not > > supported anymore. > > The Mulliken and C-squared population analysis are broken with > revision 624. I haven't really explored it other than noticing that > the numbers are way off and that it looks like every aoresult for a > given MO have the same number (~1). > > Adam > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Karol L. <kar...@kn...> - 2007-05-15 23:16:19
|
On Wednesday 16 May 2007 00:50, Noel O'Boyle wrote: > It's likely that all algorithms have been broken - I assume I'm going > to have similar problems with GaussSum. It's best to make a clean > break with Numeric as this point though, as it's no longer available > for Python 2.5 on windows for example, which about 50% of people are > now using. > > We will fix all these issues before the next release (promise!). Not all algorithms are broken, the MPA bug is related to me copy-pasting the wrong function name. I'm all for a clean break, although supporting Numeric is not an issue in cclib, since no functionality unique for numpy is used yet. And if it's not a problem, why not keep it for some time? > On 15/05/07, Adam Tenderholt <a-t...@st...> wrote: > > The Mulliken and C-squared population analysis are broken with > > revision 624. I haven't really explored it other than noticing that > > the numbers are way off and that it looks like every aoresult for a > > given MO have the same number (~1). > > > > Adam Thanks for pointing these out... the bug with MPA is obvious to me now that I look at the diff - a misclick. I'm just about to commit the fix, along with a test for MPA (this probably wouldn't have been overlooked if there had been an MPA test before). I'll look at the CSPA problem after that. - Karol -- written by Karol Langner Wed May 16 01:08:30 CEST 2007 |
|
From: Karol L. <kar...@kn...> - 2007-05-16 00:33:49
|
On Tuesday 15 May 2007 22:37, Adam Tenderholt wrote:
> The Mulliken and C-squared population analysis are broken with
> revision 624. I haven't really explored it other than noticing that
> the numbers are way off and that it looks like every aoresult for a
> given MO have the same number (~1).
I can't get bad results from the CSPA method, any way I go, with code before
the NumPy->Numeric transition, using numpy or Numeric. Can you specify which
parsed file breaks the method?
For example, in all the three following cases:
1) before transition
>>> cclib.method.cspa.__revision__
'$Revision: 549 $'
2) after transition, using Numeric
>>> cclib.method.cspa.__revision__
'$Revision: 616 $'
>>> cclib.method.cspa.numpy.__name__
'Numeric'
3) after transition, using NumPy
>>> cclib.method.cspa.__revision__
'$Revision: 616 $'
>>> cclib.method.cspa.numpy.__name__
'numpy'
I get the same output for basicGaussian03/dvb_sp.out:
>>> a = cclib.parser.ccopen("dvb_sp.out")
>>> a.parse()
[Gaussian dvb_sp.out INFO] Creating attribute atomnos[]
[Gaussian dvb_sp.out INFO] Creating attribute natom: 20
[Gaussian dvb_sp.out INFO] Creating attribute atomcoords[]
[Gaussian dvb_sp.out INFO] Creating attribute nbasis: 60
[Gaussian dvb_sp.out INFO] Creating attribute aooverlaps[x, y]
[Gaussian dvb_sp.out INFO] Creating attribute nmo: 60
[Gaussian dvb_sp.out INFO] Creating attribute scftargets[]
[Gaussian dvb_sp.out INFO] Creating attribute scfvalues
[Gaussian dvb_sp.out INFO] Creating attribute scfenergies[]
[Gaussian dvb_sp.out INFO] Creating attribute mosyms[[]]
[Gaussian dvb_sp.out INFO] Creating attribute homos[]
[Gaussian dvb_sp.out INFO] Creating attribute moenergies
[Gaussian dvb_sp.out INFO] Creating attributes aonames[], mocoeffs[]
[Gaussian dvb_sp.out INFO] Creating attribute coreelectrons[]
>>> b = cclib.method.cspa(a)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'module' object is not callable
>>> b = cclib.method.CSPA(a)
>>> b.calculate()
[CSPA Gaussian log file dvb_sp.out INFO] Creating attribute aoresults:
array[3]
[CSPA Gaussian log file dvb_sp.out INFO] Saving partitioned results in
fragresults: array[3]
[CSPA Gaussian log file dvb_sp.out INFO] Creating fragcharges: array[1]
True
>>> b.fragcharges
array([ 6.15511175, 6.17848707, 6.17201986, 6.15511175, 6.17848707,
0.80749953,
0.80896859, 0.80749953, 6.1965754 , 6.20647677, 0.82826582,
0.82550176, 0.82109346, 6.1965754 , 0.82550176, 6.20647677,
0.82826582, 0.82109346, 6.17201986, 0.80896859])
--
written by Karol Langner
Wed May 16 02:17:02 CEST 2007
|
|
From: Adam T. <a-t...@st...> - 2007-05-16 00:43:33
|
> I can't get bad results from the CSPA method, any way I go, with > code before > the NumPy->Numeric transition, using numpy or Numeric. Can you > specify which > parsed file breaks the method? I must have accidently chosen the MPA method (in pymolyze) when I was doing a quick check because I can't reproduce it either. Adam |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X