cclib-devel — Developer's mailing list

Re: [cclib-devel] Jaguar basis sets

[Noel O'B. <bao...@gm...>]

Yes, there are problems with gbasis for Jaguar. First I want to finish
volume.py, though. I'll come back to this though and we can talk it
through. If you have any ideas in the meantime I'd be happy to hear
them.

On 31/01/07, Karol Langner <kar...@kn...> wrote:
> Hi,
>
>  I'm wondering about the basis sets output by Jaguar... they have me stumped,
> since the contraction coefficients for the SP gaussian primitives are totally
> different than those given by GAMESS and Gaussian.
>
>  Compare the STO-3G function for carbon that I found in the cclib test
> logfiles.
>
> Gaussian:
>  S   3 1.00       0.000000000000
>       0.7161683735D+02  0.1543289673D+00
>       0.1304509632D+02  0.5353281423D+00
>       0.3530512160D+01  0.4446345422D+00
>  SP   3 1.00       0.000000000000
>       0.2941249355D+01 -0.9996722919D-01  0.1559162750D+00
>       0.6834830964D+00  0.3995128261D+00  0.6076837186D+00
>       0.2222899159D+00  0.7001154689D+00  0.3919573931D+00
>
> Jaguar:
>              s    j
>              h    c  i       n
>              e    o  s       f
>              l    n  h       s
>   atom       l    t  l  l    h          z              coef            rcoef
> --------    ---  --- -- --  ---     ----------      ----------       ---------
>  C1          1    3  0  1    0      71.6168373       0.1543290       2.7078144
>  C1          2   -1  0  1    0      13.0450963       0.5353281       2.6188802
>  C1          3   -1  0  1    0       3.5305122       0.4446345       0.8161906
>  C1          4    2  2  1    1       2.9412494      -0.2956454      -0.4732386
>  C1          5   -4  2  1    1       0.6834831       1.1815287       0.6329949
>  C1          6    2 -1  2    2       2.9412494       0.2213487       1.2152952
>  C1          7   -6 -1  2    2       0.6834831       0.8627064       0.7642102
>  C1          8    1  1  1    1       0.2222899       1.0000000       0.2307278
>  C1          9    1 -1  2    2       0.2222899       1.0000000       0.2175654
>
> The coefficient for the S shells are the same, but the ones for SP are not.
> Does anybody know how to explain this, and eventually how to interconvert? I
> assume that the STO-3G functions used in both programs are identical, so it
> should be possible. Or, where should I ask about this? Maybe this is the
> reason why there's no gbasis attribute for the Jaguar parser yet?
>
> Karol
>
> --
> written by Karol Langner
> Wed Jan 31 14:00:32 CET 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] Jaguar basis sets

[Karol L. <kar...@kn...>]

Hi,

 I'm wondering about the basis sets output by Jaguar... they have me stumped, 
since the contraction coefficients for the SP gaussian primitives are totally 
different than those given by GAMESS and Gaussian.

 Compare the STO-3G function for carbon that I found in the cclib test 
logfiles.

Gaussian:
 S   3 1.00       0.000000000000
      0.7161683735D+02  0.1543289673D+00
      0.1304509632D+02  0.5353281423D+00
      0.3530512160D+01  0.4446345422D+00
 SP   3 1.00       0.000000000000
      0.2941249355D+01 -0.9996722919D-01  0.1559162750D+00
      0.6834830964D+00  0.3995128261D+00  0.6076837186D+00
      0.2222899159D+00  0.7001154689D+00  0.3919573931D+00

Jaguar:
             s    j
             h    c  i       n
             e    o  s       f
             l    n  h       s
  atom       l    t  l  l    h          z              coef            rcoef
--------    ---  --- -- --  ---     ----------      ----------       ---------
 C1          1    3  0  1    0      71.6168373       0.1543290       2.7078144
 C1          2   -1  0  1    0      13.0450963       0.5353281       2.6188802
 C1          3   -1  0  1    0       3.5305122       0.4446345       0.8161906
 C1          4    2  2  1    1       2.9412494      -0.2956454      -0.4732386
 C1          5   -4  2  1    1       0.6834831       1.1815287       0.6329949
 C1          6    2 -1  2    2       2.9412494       0.2213487       1.2152952
 C1          7   -6 -1  2    2       0.6834831       0.8627064       0.7642102
 C1          8    1  1  1    1       0.2222899       1.0000000       0.2307278
 C1          9    1 -1  2    2       0.2222899       1.0000000       0.2175654

The coefficient for the S shells are the same, but the ones for SP are not. 
Does anybody know how to explain this, and eventually how to interconvert? I 
assume that the STO-3G functions used in both programs are identical, so it 
should be possible. Or, where should I ask about this? Maybe this is the 
reason why there's no gbasis attribute for the Jaguar parser yet?

Karol

-- 
written by Karol Langner
Wed Jan 31 14:00:32 CET 2007

Re: [cclib-devel] pre/post-parsing function for LogFile

[Karol L. <kar...@kn...>]

On Tuesday 30 of January 2007 17:39, Adam Tenderholt wrote:
> >> I have however, a different idea. What if .parse() were defined
> >> for the
> >> generic class LogFile, and it did all the "generic" things, and
> >> also called
> >> self.extract(), which would contain the "for line in
> >> self.inputfile" loop
> >> that is specific to each parser (effectively replacing the
> >> current.parse()).
> >> This way, we would have only one function more and all the
> >> benifits, and
> >> again no change for the user.
> >
> > Indeed, I prefer this too.
>
> I agree that this is a good idea. I also think ccopen and others
> should check to see if the logfile exists, and if not, print an error/
> warning about it.
>
> Adam

Well, to start this I added a parse() method to the LogFile class and renamed 
parse() to extract() in the parsers. Take a look if the general idea is 
suitable. If so, we can start moving things to the generic method.

I checked all the tests and regression tests - nothing broken.

Karol

-- 
written by Karol Langner
Wed Jan 31 00:38:48 CET 2007

[cclib-devel] Regarding recent email on OpenBabel list

[Noel O'B. <bao...@gm...>]

This sounds very interesting. I am involved in a Python project called
cclib, http://cclib.sf.net, which sounds like it has several of the
same aims, although it currently does not parse Gaussian formatted
checkpoint files.

I would be interested in knowing exactly what the aims of your project
are, and whether there is some way we could work together.

Noel

>   I have seen recently that the Gaussian formatted checkpoint file
> format is not (yet) supported by OpenBabel. I have already programmed a
> parser (in Python), which can extract the following data :

>  1) geometry
>  2) Hessian
>  3) Raman / Raman optical activity data :
>   a) derivatives of the polarizability tensor (alpha)
>    b) derivatives of the optical rotation tensor (G')
>    c) derivatives of the D-Q polarizability tensor (A)

>  4) Infrared / vibrational circular dichroism data :
>   a) Derivatives of the electric dipole moment (APT)
>    b) Derivatives of the magnetic dipole moment (AAT)

>  It would be not a big problem to contribute a C++ code for OpenBabel. Tell me if someone still needs the support
> for the format and what exactly is desired. The Python code will be published (under GNU GPL) soon on sourceforge.net
> as a part of a library for visualizing vibrational Raman optical activity (VROA) data.


>  With best regards,
>  Maxim Fedorovsky.

Re: [cclib-devel] pre/post-parsing function for LogFile

[Adam T. <a-t...@st...>]

>> I have however, a different idea. What if .parse() were defined  
>> for the
>> generic class LogFile, and it did all the "generic" things, and  
>> also called
>> self.extract(), which would contain the "for line in  
>> self.inputfile" loop
>> that is specific to each parser (effectively replacing the  
>> current.parse()).
>> This way, we would have only one function more and all the  
>> benifits, and
>> again no change for the user.
>
> Indeed, I prefer this too.

I agree that this is a good idea. I also think ccopen and others  
should check to see if the logfile exists, and if not, print an error/ 
warning about it.

Adam

Re: [cclib-devel] CDA!

[Noel O'B. <bao...@gm...>]

Was this issue resolved in the end?

On 23/01/07, Adam Tenderholt <a-t...@st...> wrote:
> I have added some more code for the CDA method. It now reproduces the
> numbers (well, still off by a factor of two and am hopefully going to
> hear back from Frenking about this soon) that the C++ version of CDA
> gives. I have also created a wiki page on how to use it: http://
> cclib.sourceforge.net/wiki/index.php/Charge_Decomposition_Analysis
>
> I haven't tested my implementation against a "real" molecule with an
> appreciable number of basis functions, nor I have tested it against
> unrestricted S > 0 systems or fragments.
>
> Adam
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] pre/post-parsing function for LogFile

[Noel O'B. <bao...@gm...>]

On 30/01/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 30 of January 2007 09:04, Noel O'Boyle wrote:
> > Some thoughts: The final conversion of attributes to arrays may be
> > different in each case, and so cannot be shared across parsers. Any
> > additional shared code, e.g. final progress update, should be called
> > from the end of the .parse(), rather than having the user call it.
>
> Can you give an example of when the conversion of attributes to arrays would
> be different between two parsers? I thought the idea was for attributes to be
> the same for all parsers.

The net effect is the same, but in some cases the attribute is created
as an array in the main loop, in others it is built up incremently as
a list of lists, and then converted afterwards, outside the loop. Also
found outside the loop are instances where if a particular attribute
has not been set, it is set to a default value.

But after thinking a bit, I guess you're right, the conversion code at
least can be moved into a common function. If moenergies is already an
array, and you try to convert it, it doesn't cause any harm.

> As to calling the function(s) I'm proposing, I wasn't thinking exactly what
> you said - calling them from the beginning/end of .parse(). The user sees no
> changes here.
>
> I have however, a different idea. What if .parse() were defined for the
> generic class LogFile, and it did all the "generic" things, and also called
> self.extract(), which would contain the "for line in self.inputfile" loop
> that is specific to each parser (effectively replacing the current.parse()).
> This way, we would have only one function more and all the benifits, and
> again no change for the user.

Indeed, I prefer this too.

Noel

Re: [cclib-devel] pre/post-parsing function for LogFile

[Karol L. <kar...@kn...>]

On Tuesday 30 of January 2007 09:04, Noel O'Boyle wrote:
> Some thoughts: The final conversion of attributes to arrays may be
> different in each case, and so cannot be shared across parsers. Any
> additional shared code, e.g. final progress update, should be called
> from the end of the .parse(), rather than having the user call it.

Can you give an example of when the conversion of attributes to arrays would 
be different between two parsers? I thought the idea was for attributes to be 
the same for all parsers.

As to calling the function(s) I'm proposing, I wasn't thinking exactly what 
you said - calling them from the beginning/end of .parse(). The user sees no 
changes here.

I have however, a different idea. What if .parse() were defined for the 
generic class LogFile, and it did all the "generic" things, and also called 
self.extract(), which would contain the "for line in self.inputfile" loop 
that is specific to each parser (effectively replacing the current.parse()). 
This way, we would have only one function more and all the benifits, and 
again no change for the user.

Karol

Karol

-- 
written by Karol Langner
Tue Jan 30 09:43:45 CET 2007

Re: [cclib-devel] Molpro

[Noel O'B. <bao...@gm...>]

I would now modify my earlier quote slightly...if you are working on a
new parser just create a new branch of the trunk and start hacking -
don't worry about removing the bridges, and other modules, which is
what I suggest below.

On 29/01/07, Karol Langner <kar...@kn...> wrote:
> On Monday 29 of January 2007 23:14, you wrote:
> > Hi Karol,
> >
> > Noel and I decided it made sense to move Molpro (and any new parsers)
> > to their own branch for development until they are stable and ready
> > for inclusion in a release. We discussed it on a previous thread
> > awhile back, but under a different name. Here is the relevant text
> > from Noel:
> >
> > "...I was suggesting that development for new parsers should be done
> > on a branch, e.g. the molpro parser branch. This would only have
> > tests and data files for
> > molpro, for instance, and wouldn't contain the bridges, methods, etc.
> > modules, so that development would be more focused (and the only
> > changes would be parser related). Since Jaguar is slated for
> > inclusion in the next release, I think it'd be easier at this stage
> > to leave it on the trunk and do the final development there."
>
> OK - I'll dig into the archives when needed.
>
> > Out of curiosity, what parser are you thinking of adding?
> >
> > Adam
>
> I was thinking about Molcas. Maybe also mpqc when I have more time, for fun.
>
> Karol
>
> --
> written by Karol Langner
> Mon Jan 29 23:39:46 CET 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] pre/post-parsing function for LogFile

[Noel O'B. <bao...@gm...>]

Some thoughts: The final conversion of attributes to arrays may be
different in each case, and so cannot be shared across parsers. Any
additional shared code, e.g. final progress update, should be called
from the end of the .parse(), rather than having the user call it.

On 29/01/07, Karol Langner <kar...@kn...> wrote:
> It occurred to me that it might be beneficial to have two functions in the
> LogFile class that should be called before and after logfiles of any type are
> parsed. For instance, when working the GAMESS parser, I saw there was no
> final progress update and conversion of attributes to arrays. With these
> functions, that won't happen for any new parsers, changes can be made for all
> of them in one place, and the code will be clearer.
>
> Basically, everything in the parse() function of a parser before the "for line
> in inputfile" loop would go i nthe first function, and everything after in
> the second. As far as I can tell, there are no differences here between
> parsers, so is there a reason not to do this?
>
> To do this, however, inputfile, nstep, and oldstep (maybe something else,
> also?) need to be parser attributes.
>
> If this seems like a good idea, I'd be happy to do the necessary changes in a
> few days.
>
> Karol
>
> --
> written by Karol Langner
> Tue Jan 30 00:26:31 CET 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] pre/post-parsing function for LogFile

[Karol L. <kar...@kn...>]

It occurred to me that it might be beneficial to have two functions in the 
LogFile class that should be called before and after logfiles of any type are 
parsed. For instance, when working the GAMESS parser, I saw there was no 
final progress update and conversion of attributes to arrays. With these 
functions, that won't happen for any new parsers, changes can be made for all 
of them in one place, and the code will be clearer.

Basically, everything in the parse() function of a parser before the "for line 
in inputfile" loop would go i nthe first function, and everything after in 
the second. As far as I can tell, there are no differences here between 
parsers, so is there a reason not to do this?

To do this, however, inputfile, nstep, and oldstep (maybe something else, 
also?) need to be parser attributes.

If this seems like a good idea, I'd be happy to do the necessary changes in a 
few days.

Karol

-- 
written by Karol Langner
Tue Jan 30 00:26:31 CET 2007

Re: [cclib-devel] Categories on the wiki

[Adam T. <a-t...@st...>]

I think it's a good idea. :o)

On Jan 29, 2007, at 3:12 PM, Karol Langner wrote:

> Hi all,
>
>  I started placing pages in categories on the wiki, as I go along  
> reading, for
> example:
> http://cclib.sourceforge.net/wiki/index.php/Category:Parsed_data
>
>  Hope that's OK.
>
> Karol
>
> -- 
> written by Karol Langner
> Tue Jan 30 00:10:19 CET 2007
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

[cclib-devel] cclib on wikipedia

[Karol L. <kar...@kn...>]

I just noticed there was no page describing cclib on Wikipedia, so I started 
one:
http://en.wikipedia.org/wiki/Cclib

-- 
written by Karol Langner
Tue Jan 30 00:22:19 CET 2007

[cclib-devel] Categories on the wiki

[Karol L. <kar...@kn...>]

Hi all,

 I started placing pages in categories on the wiki, as I go along reading, for 
example:
http://cclib.sourceforge.net/wiki/index.php/Category:Parsed_data

 Hope that's OK.

Karol

-- 
written by Karol Langner
Tue Jan 30 00:10:19 CET 2007

Re: [cclib-devel] Molpro

[Karol L. <kar...@kn...>]

On Monday 29 of January 2007 23:14, you wrote:
> Hi Karol,
>
> Noel and I decided it made sense to move Molpro (and any new parsers)
> to their own branch for development until they are stable and ready
> for inclusion in a release. We discussed it on a previous thread
> awhile back, but under a different name. Here is the relevant text
> from Noel:
>
> "...I was suggesting that development for new parsers should be done
> on a branch, e.g. the molpro parser branch. This would only have
> tests and data files for
> molpro, for instance, and wouldn't contain the bridges, methods, etc.
> modules, so that development would be more focused (and the only
> changes would be parser related). Since Jaguar is slated for
> inclusion in the next release, I think it'd be easier at this stage
> to leave it on the trunk and do the final development there."

OK - I'll dig into the archives when needed.

> Out of curiosity, what parser are you thinking of adding?
>
> Adam

I was thinking about Molcas. Maybe also mpqc when I have more time, for fun.

Karol

-- 
written by Karol Langner
Mon Jan 29 23:39:46 CET 2007

Re: [cclib-devel] Molpro

[Adam T. <a-t...@st...>]

Hi Karol,

Noel and I decided it made sense to move Molpro (and any new parsers)  
to their own branch for development until they are stable and ready  
for inclusion in a release. We discussed it on a previous thread  
awhile back, but under a different name. Here is the relevant text  
from Noel:

"...I was suggesting that development for new parsers should be done  
on a branch, e.g. the molpro parser branch. This would only have  
tests and data files for
molpro, for instance, and wouldn't contain the bridges, methods, etc.  
modules, so that development would be more focused (and the only  
changes would be parser related). Since Jaguar is slated for  
inclusion in the next release, I think it'd be easier at this stage  
to leave it on the trunk and do the final development there."

Out of curiosity, what parser are you thinking of adding?

Adam

[cclib-devel] Molpro

[Karol L. <kar...@kn...>]

Hi all,

I'm wondering - why is there a separate branch for developing the Molpro 
parser? And also, if I'd want to add a parser for another program, would the 
procedure be to do it first in a new branch?

Karol

-- 
written by Karol Langner
Mon Jan 29 23:05:04 CET 2007

Re: [cclib-devel] tests for parsed MP2 data

[Noel O'B. <bao...@gm...>]

testMP.py is a better idea

...please find attached some code I threw together yesterday...you
don't have to use it, of course.

On 29/01/07, Karol Langner <kar...@kn...> wrote:
> Hi again,
>
>  I'd like to add appropriate tests for the MP2 data that is parsed. Should I
> place that in testSP.py or should make a new module testMP.py?
>
> Karol
>
> --
> written by Karol Langner
> Mon Jan 29 06:41:42 CET 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] tests for parsed MP2 data

[Karol L. <kar...@kn...>]

Hi again,

 I'd like to add appropriate tests for the MP2 data that is parsed. Should I 
place that in testSP.py or should make a new module testMP.py?

Karol

-- 
written by Karol Langner
Mon Jan 29 06:41:42 CET 2007

[cclib-devel] Proposed release date (Was Re: Numeric --> numpy)

[Noel O'B. <bao...@gm...>]

Well, ah, you know...how about "when it's ready"? :-)

I'd like to see a working CDA and electron density in the next
release, as I think it's about time we had a good portfolio of
algorithms.

I'd estimate the next release will take place at the end of March.
However, the point of cclib is not to create more deadlines and
pressure on us, so this date can move in any direction.

Let's put up on the wiki a list of things to do for the next release,
and things to do after that. The following page seems like a good
place to put stuff and should probably be updated in any case:
    http://cclib.sourceforge.net/wiki/index.php/Progress

> > What this adds up to is that if nobody disagrees, this will be the
> > first thing we'll do after the next release.
>
> Incidentally, is there a planned release date?
>
> Karol
>
> --
> written by Karol Langner
> Fri Jan 26 13:35:42 CET 2007
>

Re: [cclib-devel] Numeric --> numpy

[Karol L. <kar...@kn...>]

On Friday 26 of January 2007 09:00, Noel O'Boyle wrote:
> Both myself and Adam are also thinking of our own programs, which will
> also need to be adjusted. They will already have to be changed
> slightly to deal with the redefinition of mocoeffs and a couple of
> other attributes.

Didn't think about that.

> What this adds up to is that if nobody disagrees, this will be the
> first thing we'll do after the next release.

Incidentally, is there a planned release date?

Karol

-- 
written by Karol Langner
Fri Jan 26 13:35:42 CET 2007

Re: [cclib-devel] Numeric --> numpy

[Noel O'B. <bao...@gm...>]

Both myself and Adam are also thinking of our own programs, which will
also need to be adjusted. They will already have to be changed
slightly to deal with the redefinition of mocoeffs and a couple of
other attributes.

What this adds up to is that if nobody disagrees, this will be the
first thing we'll do after the next release.

Noel

On 26/01/07, Karol Langner <kar...@kn...> wrote:
> On Thursday 25 of January 2007 20:25, Adam Tenderholt wrote:
> > I briefly looked into the conversion from Numeric to numpy, and it
> > looks like there is a script that does all of the conversion for you
> > since there is an oldnumeric module of numpy. Granted, the script
> > probably isn't flawless. Also, it may be that we can detect whether
> > numpy is available and if so, import the numpy.oldnumeric interface
> > as Numeric (that's actually what the aforementioned script does);
> > otherwise, just import Numeric.
>
> Yes, there is a script, but I've read some people complaining about it (don't
> know if justified).
>
> > I do agree that we should wait until after the next release as this
> > release already had numerous changes. I don't know if numpy compiles
> > on Gentoo---since I bought my mac, I don't develop on Gentoo much
> > these days.
>
> I checked on a machine that runs an up-to-date Gentoo system, and numpy is
> installed system-wide there from portage, version 0.9.8 with python 2.4.3.
> Seems to work fine when played with, but running numpy.test() ends in a
> segmentation fault. That's probably caused by a problem with system
> libraries, becasue I also have a local install of numpy 1.0 with python 2.5
> on that machine, and the tests finish fine in that case - the local
> installation uses my local ATLAS compilation.
>
> Here is a list of attributes cclib uses in Numeric:
>
> ['Numeric.matrixmultiply', 'Numeric.resize', 'Numeric.multiply',
> 'Numeric.divide', 'Numeric.array', 'Numeric.swapaxes',
> 'Numeric.innerproduct', 'Numeric.alltrue', 'Numeric.transpose',
> 'Numeric.arange', 'Numeric.add', 'Numeric.__version__', 'Numeric.reshape',
> 'Numeric.zeros']
>
> As you can see, it isn't much, so there really shouldn't be much work in this
> regard. There's also the slicing and other references to arrays, but that
> hasn't really changed in numpy.
>
> What has changed in the above functions:
> 1. matrixmultiply is no more (use numpy.dot)
> 2. innerproduct is no more (I don't know what to use instead)
>
> Also, there is a new matrix object (matrix multiplication for a*b), but that's
> not too useful for cclib.
>
> Karol
>
> --
> written by Karol Langner
> Fri Jan 26 07:51:39 CET 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] Numeric --> numpy

[Karol L. <kar...@kn...>]

On Thursday 25 of January 2007 20:25, Adam Tenderholt wrote:
> I briefly looked into the conversion from Numeric to numpy, and it
> looks like there is a script that does all of the conversion for you
> since there is an oldnumeric module of numpy. Granted, the script
> probably isn't flawless. Also, it may be that we can detect whether
> numpy is available and if so, import the numpy.oldnumeric interface
> as Numeric (that's actually what the aforementioned script does);
> otherwise, just import Numeric.

Yes, there is a script, but I've read some people complaining about it (don't 
know if justified).

> I do agree that we should wait until after the next release as this
> release already had numerous changes. I don't know if numpy compiles
> on Gentoo---since I bought my mac, I don't develop on Gentoo much
> these days.

I checked on a machine that runs an up-to-date Gentoo system, and numpy is 
installed system-wide there from portage, version 0.9.8 with python 2.4.3. 
Seems to work fine when played with, but running numpy.test() ends in a 
segmentation fault. That's probably caused by a problem with system 
libraries, becasue I also have a local install of numpy 1.0 with python 2.5 
on that machine, and the tests finish fine in that case - the local 
installation uses my local ATLAS compilation.

Here is a list of attributes cclib uses in Numeric:

['Numeric.matrixmultiply', 'Numeric.resize', 'Numeric.multiply', 
'Numeric.divide', 'Numeric.array', 'Numeric.swapaxes', 
'Numeric.innerproduct', 'Numeric.alltrue', 'Numeric.transpose', 
'Numeric.arange', 'Numeric.add', 'Numeric.__version__', 'Numeric.reshape', 
'Numeric.zeros']

As you can see, it isn't much, so there really shouldn't be much work in this 
regard. There's also the slicing and other references to arrays, but that 
hasn't really changed in numpy.

What has changed in the above functions:
1. matrixmultiply is no more (use numpy.dot)
2. innerproduct is no more (I don't know what to use instead)

Also, there is a new matrix object (matrix multiplication for a*b), but that's 
not too useful for cclib.

Karol

-- 
written by Karol Langner
Fri Jan 26 07:51:39 CET 2007

Re: [cclib-devel] Numeric --> numpy

[Adam T. <a-t...@st...>]

I briefly looked into the conversion from Numeric to numpy, and it  
looks like there is a script that does all of the conversion for you  
since there is an oldnumeric module of numpy. Granted, the script  
probably isn't flawless. Also, it may be that we can detect whether  
numpy is available and if so, import the numpy.oldnumeric interface  
as Numeric (that's actually what the aforementioned script does);  
otherwise, just import Numeric.

I do agree that we should wait until after the next release as this  
release already had numerous changes. I don't know if numpy compiles  
on Gentoo---since I bought my mac, I don't develop on Gentoo much  
these days.

Adam

On Jan 25, 2007, at 11:12 AM, Noel O'Boyle wrote:

> I don't know much about the differences, but I'd be hoping they are
> minor. But it might be a better idea to do this immediately *after*
> the next release, rather than before - we have enough to go into it at
> the moment. But I recall that one of the original reasons we didn't
> move to numpy this time last year was that it didn't compile easily on
> Gentoo. Has this situation improved?
>
> On 25/01/07, Adam Tenderholt <a-t...@st...> wrote:
>> I agree that we should move to numpy soon as Numeric is old. Are
>> there major differences between the two? Hopefully the conversion
>> won't be too difficult or time consuming...
>>
>> Adam
>>
>> On Jan 25, 2007, at 7:24 AM, Karol Langner wrote:
>>
>>> On Thursday 25 of January 2007 13:17, Noel O'Boyle wrote:
>>>> Hello all,
>>>>
>>>> We're going to have to start thinking about transitioning to  
>>>> numpy at
>>>> some point this year. Numeric is not available for Python 2.5 on
>>>> Windows, for example, and there is a big push for users to move to
>>>> numpy.
>>>>
>>>> How are things on Gentoo at this stage?
>>>>
>>>> Regards,
>>>>   Noel
>>>
>>> I was actually going to ask about this soon, and will certainly
>>> help when the
>>> time comes if I'm not loaded with work. I guess you're thinking
>>> about making
>>> the transition quickly?
>>>
>>> Karol
>>>
>>> --
>>> written by Karol Langner
>>> Thu Jan 25 16:23:06 CET 2007
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> ---
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>> share your
>>> opinions on IT & business topics through brief surveys - and earn  
>>> cash
>>> http://www.techsay.com/default.php?
>>> page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> cclib-devel mailing list
>>> ccl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share your
>> opinions on IT & business topics through brief surveys - and earn  
>> cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> cclib-devel mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] Numeric --> numpy

[Noel O'B. <bao...@gm...>]

I don't know much about the differences, but I'd be hoping they are
minor. But it might be a better idea to do this immediately *after*
the next release, rather than before - we have enough to go into it at
the moment. But I recall that one of the original reasons we didn't
move to numpy this time last year was that it didn't compile easily on
Gentoo. Has this situation improved?

On 25/01/07, Adam Tenderholt <a-t...@st...> wrote:
> I agree that we should move to numpy soon as Numeric is old. Are
> there major differences between the two? Hopefully the conversion
> won't be too difficult or time consuming...
>
> Adam
>
> On Jan 25, 2007, at 7:24 AM, Karol Langner wrote:
>
> > On Thursday 25 of January 2007 13:17, Noel O'Boyle wrote:
> >> Hello all,
> >>
> >> We're going to have to start thinking about transitioning to numpy at
> >> some point this year. Numeric is not available for Python 2.5 on
> >> Windows, for example, and there is a big push for users to move to
> >> numpy.
> >>
> >> How are things on Gentoo at this stage?
> >>
> >> Regards,
> >>   Noel
> >
> > I was actually going to ask about this soon, and will certainly
> > help when the
> > time comes if I'm not loaded with work. I guess you're thinking
> > about making
> > the transition quickly?
> >
> > Karol
> >
> > --
> > written by Karol Langner
> > Thu Jan 25 16:23:06 CET 2007
> >
> > ----------------------------------------------------------------------
> > ---
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?
> > page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>