feed-forward neural network for python
Hi! I released feed-forward neural network for python (ffnet) project at sourceforge. Implementation is extremelly fast (code written mostly in fortran with thin python interface, scipy optimizers involved) and very easy to use. I'm announcing it here because you, folks, are potential users/testers. If anyone is interested please visit http://ffnet.sourceforge.net (and then post comments if any...) Greetings -- Marek Wojciechowski -- http://mail.python.org/mailman/listinfo/python-list
Re: feed-forward neural network for python
Beliavsky napisal(a): > mwojc wrote: > > Hi! > > I released feed-forward neural network for python (ffnet) project at > > sourceforge. Implementation is extremelly fast (code written mostly in > > fortran with thin python interface, scipy optimizers involved) and very > > easy to use. > > I'm announcing it here because you, folks, are potential users/testers. > > > > If anyone is interested please visit http://ffnet.sourceforge.net (and > > then post comments if any...) > > Thanks for making available your code. The Fortran code compiles with > both g95 and gfortran. I looked at the code briefly, and it is > well-documented and clear, but I do wonder why you are writing new code > in Fortran 77. Using free source form instead of fixed source form > would make the code more readable, and using the array operations of > Fortran 90 would make it more concise. Gfortran is a Fortran 95 > compiler and is part of gcc, so using Fortran 95 features should not > inhibit portability. There are three reasons I use Fortran 77: 1. g77 compiler is just everywhere. 2. fortran 77 code compiles with all subsequent fortrans. 3. f2py not necessarily support fortran 90/95 instructions. Portability of Fortran 95 is not so obvious, for example my 2-years old Gentoo Linux has only g77 and I think there are many people like me. > I think using the single letter "o" as a variable name is a bad idea -- > it looks too much like "0". You're right, thanks. > I would like to see a Fortran driver (main program) for the code, so I > could see an example of its use independent from Python and f2py. Yes, this would be nice. The only problem is that all data arrays defining the network are set up in python. The simple case however (like XOR) can be inserted manually (or read from file) and I'll try to include this in the next release. In fact, in my work, I plan to train the networks in python but use them also from fortran. Thanks Marek -- http://mail.python.org/mailman/listinfo/python-list
__getattr__, __setattr__ and pickle
Hi! My class with implemented __getattr__ and __setattr__ methods cannot be pickled because of the Error: == ERROR: testPickle (__main__.TestDeffnet2WithBiases) -- Traceback (most recent call last): File "deffnet.py", line 246, in testPickle cPickle.dump(self.denet, file) TypeError: 'NoneType' object is not callable -- Is there an obvious reason i don't know, which prevents pickling with those methods (if i comment them out the pickling test passes)? I'm using Python 2.4.4 on Gentoo Linux. The mentioned methods goes as follows: def __setattr__(self, name, value): if name == 'weights': j = 0 for net in self.nets: w1 = self.wmarks[j] w2 = self.wmarks[j+1] net.weights = value[w1:w2] j += 1 else: self.__dict__[name] = value def __getattr__(self, name): if name == 'weights': j = 0 for net in self.nets: w1 = self.wmarks[j] w2 = self.wmarks[j+1] self._weights[w1:w2] = net.weights j += 1 return self._weights Greetings, -- Marek -- http://mail.python.org/mailman/listinfo/python-list
Re: __getattr__, __setattr__ and pickle
Bruno Desthuilliers wrote: > mwojc a écrit : >> Hi! >> My class with implemented __getattr__ and __setattr__ methods cannot be >> pickled because of the Error: >> >> == >> ERROR: testPickle (__main__.TestDeffnet2WithBiases) >> -- >> Traceback (most recent call last): >> File "deffnet.py", line 246, in testPickle >> cPickle.dump(self.denet, file) >> TypeError: 'NoneType' object is not callable >> >> -- >> >> Is there an obvious reason i don't know, which prevents pickling with >> those methods (if i comment them out the pickling test passes)? >> >> I'm using Python 2.4.4 on Gentoo Linux. The mentioned methods goes as >> follows: >> >> def __setattr__(self, name, value): >> if name == 'weights': >> j = 0 >> for net in self.nets: >> w1 = self.wmarks[j] >> w2 = self.wmarks[j+1] >> net.weights = value[w1:w2] >> j += 1 >> else: >> self.__dict__[name] = value >> >> def __getattr__(self, name): >> if name == 'weights': >> j = 0 >> for net in self.nets: >> w1 = self.wmarks[j] >> w2 = self.wmarks[j+1] >> self._weights[w1:w2] = net.weights >> j += 1 >> return self._weights > > __getattr__ should raise an AttributeError when name != 'weight' instead > of (implicitely) returning None. pickle looks for a couple special > method in your object[1], and it looks like it doesn't bother to check > if what it found was really callable. Yes, raising AttributeError helped. Thanks! > > FWIW, you'd be better using a property instead of __getattr__ / > __setattr__ if possible. You're probably right again, in this case it's better to use property. > And while we're at it, you dont need to > manually take care of your index in the for loop - you can use > enumerate(iterable) instead: > > for j, net in enumerate(self.nets): > w1 = self.wmarks[j] > w2 = self.wmarks[j+1] > self._weights[w1:w2] = net.weights > return self._weights > Sometimes i use manual handling of index because i'm convinced that enumeration is a bit slower than this. But i'm not really sure about it... Thanks again. Greetings, -- Marek -- http://mail.python.org/mailman/listinfo/python-list
Re: __getattr__, __setattr__ and pickle
Bruno Desthuilliers wrote:
> >>> class Prop(object):
> ... @apply
> ... def prop():
> ... def fget(self): return self._prop
> ... def fset(self, val): self._prop = val
> ... return property(**locals())
> ... def __init__(self, val): self.prop=val
> ...
> >>> class Hook(object):
> ... def __getattr__(self, name):
> ... if name == 'prop':
> ... return self._prop
> ... raise AttributeError("yadda")
> ... def __setattr__(self, name, val):
> ... if name == 'prop':
> ... self.__dict__['_prop'] = val
> ... else:
> ... # XXX : INCORRECT IMPLEMENTATION, DONT DO THIS !
> ... self.__dict__[name] = val
> ... # correct implementation:
> ... # super(Hook, self).__setattr__(name, value)
> ... def __init__(self, val): self.prop=val
Hi!
Finally i ended up with all the suggestions you gave me. The speed is
important to me besause i get/set my attribute a lot... The only doubts i
have are with the @apply decorator, because 'apply' seems to be depreciated
since python 2.3... And another thing: why writing for all
attributes 'self.__dict__[name] = val' in __setattr__ is incorrect?
Thanks a lot!
Greetings,
--
Marek
--
http://mail.python.org/mailman/listinfo/python-list
Re: F2PY changing integers to arrays???
john wrote:
> I have a simple module which performs basic operations on plot3d files
> (below). I wrapped like:
>
> f2py --fcompiler=gfortran -m plot3d -c prec.f90 plot3d.f90
>
> That seems to work fine, but i get some unexpected results...
>
from plot3d import plot3d as p3
dir(p3)
> ['imax', 'jmax', 'kmax', 'mg', 'prc', 'printall', 'readit', 'writeit',
> 'writeit2d']
p3.readit( "mesh.xrtz.dat", "FORMATTED", ".TRUE." )
p3.imax
> array(409)
>
>
> "409" is correct, but "imax" is declared as an INTEGER in fortran and
> now it's an array in python??? Any ideas?
>
>
>
>
>
>
>
>
> # prec.f90
> MODULE prec
> IMPLICIT NONE
> INTEGER, PARAMETER :: single = SELECTED_REAL_KIND(p=6,r=37)
> INTEGER, PARAMETER :: double = SELECTED_REAL_KIND(p=15,r=200)
> END MODULE prec
>
>
>
>
> # plot3d.f90
> MODULE PLOT3D
> USE prec
> IMPLICIT NONE
> INTEGER, PARAMETER :: prc=single
> REAL(prc), ALLOCATABLE, DIMENSION(:,:,:,:) :: x, y, z
> INTEGER :: mg, imax, jmax, kmax
>
> CONTAINS
>
> !--
> SUBROUTINE READIT( fname, ftype, fmg )
> ! reads the plot3d, formatted, mg file in xyz
> IMPLICIT NONE
> CHARACTER(len=20), INTENT(IN) :: fname, ftype
>
> LOGICAL :: fmg
> INTEGER :: i, j, k, n, f=1
>
> SELECT CASE (ftype)
> CASE ('FORMATTED')
> OPEN( UNIT=f, FILE=fname, STATUS='OLD', ACTION='READ',
> FORM=ftype )
> IF (fmg) READ(f,*) mg ! only read if multigrid
> READ(f,*) imax, jmax, kmax
> ALLOCATE( x(mg, imax, jmax, kmax) )
> ALLOCATE( y(mg, imax, jmax, kmax) )
> ALLOCATE( z(mg, imax, jmax, kmax) )
> READ(f,*) x(n,
> i,j,k),i=1,imax),j=1,jmax),k=1,kmax),n=1,mg), &
> y(n,
> i,j,k),i=1,imax),j=1,jmax),k=1,kmax),n=1,mg), &
> z(n,
> i,j,k),i=1,imax),j=1,jmax),k=1,kmax),n=1,mg)
> CASE ('UNFORMATTED')
> OPEN( UNIT=f, FILE=fname, STATUS='OLD', ACTION='READ',
> FORM=ftype )
> IF (fmg) READ(f) mg ! only read if multigrid
> READ(f) imax, jmax, kmax
> ALLOCATE( x(mg, imax, jmax, kmax) )
> ALLOCATE( y(mg, imax, jmax, kmax) )
> ALLOCATE( z(mg, imax, jmax, kmax) )
> READ(f) x(n,
> i,j,k),i=1,imax),j=1,jmax),k=1,kmax),n=1,mg), &
> y(n,
> i,j,k),i=1,imax),j=1,jmax),k=1,kmax),n=1,mg), &
> z(n,
> i,j,k),i=1,imax),j=1,jmax),k=1,kmax),n=1,mg)
> CASE DEFAULT
> WRITE(*,*) 'filetype not supported in '
> STOP
> END SELECT
>
> CLOSE(f)
>
> END SUBROUTINE READIT
>
> END MODULE PLOT3D
I'm not sure why you obtain array(409) instead 409, but you can use this
type in python as normal integer. For example array(409)+409 gives integer
value 818.
Greetings
--
Marek
--
http://mail.python.org/mailman/listinfo/python-list
