Re: [Numpy-discussion] Problem with numpy.linalg.eig?
On Nov 12, 2007 10:26 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Geoffrey Zhu wrote: > > On Nov 12, 2007 12:37 PM, Keith Goodman <[EMAIL PROTECTED]> wrote: > >> On Nov 12, 2007 10:10 AM, Peter Creasey <[EMAIL PROTECTED]> wrote: > >>> The following code calling numpy v1.0.4 fails to terminate on my machine, > >>> which was not the case with v1.0.3.1 > >>> > >>> from numpy import arange, float64 > >>> from numpy.linalg import eig > >>> a = arange(13*13, dtype = float64) > >>> a.shape = (13,13) > >>> a = a%17 > >>> eig(a) > >> It sounds like the same problem that was reported in this thread: > >> > >> http://thread.gmane.org/gmane.comp.python.numeric.general/17456/focus=17465 > > > > The code hangs on my machine too. In the thread you mentioned above, I > > wrote that using the EGG instead of MSI appears to fix the > > numpy.test() problem, but maybe it just somehow hides it. > When you use the MSI, can you always reproduce the problem ? As I said > previously, it is hard to know for sure without being able to reproduce > the bug on our own workstation, but if this is a problem between fortran > and C argument passing, then the result can be pretty random since the > problem reduced to a pointer pointing at a wrong address (crash, wrong > value, etc...). > > cheers, > > David > > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > Yes, with the MSI I can always reproduce the problem with numpy.test(). It always hangs.With the egg it does not hang. Pointer problems are usually random, but not random if we are using the same binaries in EGG and MSI and variables are always initialized to certain value. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] I removed some duplicate code from weave
Hey, I just noticed that dumb_shelve.py and dumbdbm_patched.py were in both scipy.io and scipy.weave. Since I assume that this was just an oversight, I went ahead and cleaned it up. First, I made sure that the newest code was in scipy.io: http://projects.scipy.org/scipy/scipy/changeset/3521 http://projects.scipy.org/scipy/scipy/changeset/3522 And then I removed the version in scipy.weave: http://projects.scipy.org/scipy/scipy/changeset/3524 Please let me know if this change causes any major problems. Cheers, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Merging new (optional) build system in the trunk ?
Travis E. Oliphant wrote: > David Cournapeau wrote: >> Hi, >> >> I would appreciate to get some comment on whether there is any >> chance to get my numpy.scons branch merge into the trunk at some near >> future. I feel to have reached the point where the only big thing >> missing is more testing. I tried to test it on many platforms, but there >> is a limit to what I can test just by myself. The branch has been >> conceived such as by default, the current numpy.distutils is used to >> build, and the scons-based build is used only by explicit request >> (another setup.py), so this does not force any use now: except the work >> related to numpyconfig (which can be tested separately, since it was >> done in a different branch, and is only a few lines of code), everything >> else is exactly the same than before. >> > > I think there is a chance. I'm generally favorable to the idea. I was > mainly waiting for the 1.0.4 release. I think we should be able to > merge it over now if there are no serious objections. Ok, great. Just tell me when you want to merge it, because I did a few things to make testing on the buildbot easier: - I inverted the old and new setup.py (to be able to test my branch on the buildbot). - There is also some debugging on by default, which should be disabled in the trunk. This ia a 2 second change, but just to avoid any surprises for people regularly using the trunk Also, what is the timeline for 1.0.5 ? Ideally, once the scons work is merged into the trunk, I would like to work on a scipy branch which uses scons, so that both numpy and scipy next (1.0.5 and 0.7 ?) releases can both be built using scons. > > I'm also interested in moving scipy.weave into numpy (without the blitz > converters which will stay in scipy). > > For 1.0.5, I would also like to see aligned memory and some steps > towards optimization using intrinsics. Are you speaking about SIMD intrisics ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Merging new (optional) build system in the trunk ?
David Cournapeau wrote: > Hi, > > I would appreciate to get some comment on whether there is any > chance to get my numpy.scons branch merge into the trunk at some near > future. I feel to have reached the point where the only big thing > missing is more testing. I tried to test it on many platforms, but there > is a limit to what I can test just by myself. The branch has been > conceived such as by default, the current numpy.distutils is used to > build, and the scons-based build is used only by explicit request > (another setup.py), so this does not force any use now: except the work > related to numpyconfig (which can be tested separately, since it was > done in a different branch, and is only a few lines of code), everything > else is exactly the same than before. > I think there is a chance. I'm generally favorable to the idea. I was mainly waiting for the 1.0.4 release. I think we should be able to merge it over now if there are no serious objections. I'm also interested in moving scipy.weave into numpy (without the blitz converters which will stay in scipy). For 1.0.5, I would also like to see aligned memory and some steps towards optimization using intrinsics. -Travis O. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] f2py cannot find gfortran compiler on OSX 10.5
I've just upgraded my OSX system to Leopard, and have successfully build numpy from scratch. I am trying to build some code, which includes f2py extensions, that build successfully on 10.4. I have the gfortran compiler installed, and am building my code using: python setup.py config_fc --fcompiler gnu95 build However, when I run this, I get the following error when the Fortran code compiles: AttributeError: 'NoneType' object has no attribute 'compile' Is there any reason that gnu95 no longer would find gfortran? I have confirmed that the compiler is in my path. Thanks. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with numpy.linalg.eig?
Geoffrey Zhu wrote: > On Nov 12, 2007 12:37 PM, Keith Goodman <[EMAIL PROTECTED]> wrote: >> On Nov 12, 2007 10:10 AM, Peter Creasey <[EMAIL PROTECTED]> wrote: >>> The following code calling numpy v1.0.4 fails to terminate on my machine, >>> which was not the case with v1.0.3.1 >>> >>> from numpy import arange, float64 >>> from numpy.linalg import eig >>> a = arange(13*13, dtype = float64) >>> a.shape = (13,13) >>> a = a%17 >>> eig(a) >> It sounds like the same problem that was reported in this thread: >> >> http://thread.gmane.org/gmane.comp.python.numeric.general/17456/focus=17465 > > The code hangs on my machine too. In the thread you mentioned above, I > wrote that using the EGG instead of MSI appears to fix the > numpy.test() problem, but maybe it just somehow hides it. When you use the MSI, can you always reproduce the problem ? As I said previously, it is hard to know for sure without being able to reproduce the bug on our own workstation, but if this is a problem between fortran and C argument passing, then the result can be pretty random since the problem reduced to a pointer pointing at a wrong address (crash, wrong value, etc...). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] how to convert btw rgb and pixel value
Since PIL Images now have array interfaces, it has become a lot
simpler. The following should do the job:
from numpy import array
from PIL import Image
def imread(fname,flatten=False):
"""Return a copy of a PIL image as a numpy array.
*Parameters*:
im : PIL image
Input image.
flatten : bool
If true, convert the output to grey-scale.
*Returns*:
img_array : ndarray
The different colour bands/channels are stored in the
third dimension, such that a grey-image is MxN, an
RGB-image MxNx3 and an RGBA-image MxNx4.
"""
im = Image.open(fname)
if flatten:
im = im.convert('F')
return array(im)
Cheers
Stéfan
On Mon, Nov 05, 2007 at 12:58:45PM +0200, Nadav Horesh wrote:
> If the image is in the form of a standard image format (png, bmp, jpeg...) you
> can use the PIL library. png file can be read by pylab's imread function.
>
>Nadav.
>
> On Sun, 2007-11-04 at 23:37 -0800, [EMAIL PROTECTED] wrote:
>
> hi
> i wish to convert an rgb image into an array of double values..is
> there a method for that in numpy?
> also i want to create an array of doubles into corresponding rgb
> tuples of an image
> can anyone guide me?
> dn
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with numpy.linalg.eig?
On Nov 12, 2007 12:37 PM, Keith Goodman <[EMAIL PROTECTED]> wrote: > > On Nov 12, 2007 10:10 AM, Peter Creasey <[EMAIL PROTECTED]> wrote: > > The following code calling numpy v1.0.4 fails to terminate on my machine, > > which was not the case with v1.0.3.1 > > > > from numpy import arange, float64 > > from numpy.linalg import eig > > a = arange(13*13, dtype = float64) > > a.shape = (13,13) > > a = a%17 > > eig(a) > > It sounds like the same problem that was reported in this thread: > > http://thread.gmane.org/gmane.comp.python.numeric.general/17456/focus=17465 > > A friend of mine says the windows binary of 1.0.4 also hangs on eigh > and lstsq (so linalg in general). I don't have that problem on 1.0.5 > compiled on GNU/Linux. > > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > The code hangs on my machine too. In the thread you mentioned above, I wrote that using the EGG instead of MSI appears to fix the numpy.test() problem, but maybe it just somehow hides it. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.0.5.dev4445.egg-info
It allows the check on egg dependencies IIRC Matthieu 2007/11/12, Keith Goodman <[EMAIL PROTECTED]>: > > I noticed that > > python setup.py install --prefix=/usr/local > > installs a new file called numpy-1.0.5.dev4445.egg-info. It used to be > that files were only installed in > /usr/local/lib/python2.4/site-packages/numpy. > > What is the file used for? > > $ cat /usr/local/lib/python2.4/site-packages/numpy-1.0.5.dev4445.egg-info > Metadata-Version: 1.0 > Name: numpy > Version: 1.0.5.dev4445 > Summary: NumPy: array processing for numbers, strings, records, and > objects. > Home-page: http://numeric.scipy.org > Author: NumPy Developers > Author-email: [EMAIL PROTECTED] > License: BSD > Download-URL: > http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 > Description: NumPy is a general-purpose array-processing package designed > to > efficiently manipulate large multi-dimensional arrays of arbitrary > records without sacrificing too much speed for small > multi-dimensional > arrays. NumPy is built on the Numeric code base and adds features > introduced by numarray as well as an extended C-API and the > ability to > create arrays of arbitrary type which also makes NumPy suitable > for > interfacing with general-purpose data-base applications. > > There are also basic facilities for discrete fourier transform, > basic linear algebra and random number generation. > > Platform: Windows > Platform: Linux > Platform: Solaris > Platform: Mac OS-X > Platform: Unix > Classifier: Development Status :: 4 - Beta > Classifier: Intended Audience :: Science/Research > Classifier: Intended Audience :: Developers > Classifier: License :: OSI Approved > Classifier: Programming Language :: C > Classifier: Programming Language :: Python > Classifier: Topic :: Software Development > Classifier: Topic :: Scientific/Engineering > Classifier: Operating System :: Microsoft :: Windows > Classifier: Operating System :: POSIX > Classifier: Operating System :: Unix > Classifier: Operating System :: MacOS > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > -- French PhD student Website : http://miles.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy-1.0.5.dev4445.egg-info
I noticed that python setup.py install --prefix=/usr/local installs a new file called numpy-1.0.5.dev4445.egg-info. It used to be that files were only installed in /usr/local/lib/python2.4/site-packages/numpy. What is the file used for? $ cat /usr/local/lib/python2.4/site-packages/numpy-1.0.5.dev4445.egg-info Metadata-Version: 1.0 Name: numpy Version: 1.0.5.dev4445 Summary: NumPy: array processing for numbers, strings, records, and objects. Home-page: http://numeric.scipy.org Author: NumPy Developers Author-email: [EMAIL PROTECTED] License: BSD Download-URL: http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 Description: NumPy is a general-purpose array-processing package designed to efficiently manipulate large multi-dimensional arrays of arbitrary records without sacrificing too much speed for small multi-dimensional arrays. NumPy is built on the Numeric code base and adds features introduced by numarray as well as an extended C-API and the ability to create arrays of arbitrary type which also makes NumPy suitable for interfacing with general-purpose data-base applications. There are also basic facilities for discrete fourier transform, basic linear algebra and random number generation. Platform: Windows Platform: Linux Platform: Solaris Platform: Mac OS-X Platform: Unix Classifier: Development Status :: 4 - Beta Classifier: Intended Audience :: Science/Research Classifier: Intended Audience :: Developers Classifier: License :: OSI Approved Classifier: Programming Language :: C Classifier: Programming Language :: Python Classifier: Topic :: Software Development Classifier: Topic :: Scientific/Engineering Classifier: Operating System :: Microsoft :: Windows Classifier: Operating System :: POSIX Classifier: Operating System :: Unix Classifier: Operating System :: MacOS ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Getting an array interface and using it
> > I think numpy.array(object) always makes a copy. > > > > You want numpy.asarray(object) which will make a view if object exposes > > the array interface and matches the type and sizes requested. FYI, numpy.asarray is a shortcut for numpy.array(copy=False), numpy.asanyarray for numpy.array(copy=False, subok=True)... In other terms, you can stick to array, as long as you provide the proper keywords. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Getting an array interface and using it
2007/11/12, Christopher Barker <[EMAIL PROTECTED]>: > > Matthieu Brucher wrote: > > I have an object that exposes an array interface. I want to modify the > > data it contains, but using numpy.array(myObject) seems to copy the data > > and thus my object is not modified. Am I mistaken or did I make a > > mistake in my array interface ? > > I think numpy.array(object) always makes a copy. > > You want numpy.asarray(object) which will make a view if object exposes > the array interface and matches the type and sizes requested. Thank you for the tip, I'll try it this evening. I checked that the data is actually copied, so this should be what I need ;) Matthieu -- French PhD student Website : http://miles.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Getting an array interface and using it
Matthieu Brucher wrote: > I have an object that exposes an array interface. I want to modify the > data it contains, but using numpy.array(myObject) seems to copy the data > and thus my object is not modified. Am I mistaken or did I make a > mistake in my array interface ? I think numpy.array(object) always makes a copy. You want numpy.asarray(object) which will make a view if object exposes the array interface and matches the type and sizes requested. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with numpy.linalg.eig?
On Nov 13, 2007 3:37 AM, Keith Goodman <[EMAIL PROTECTED]> wrote: > > On Nov 12, 2007 10:10 AM, Peter Creasey <[EMAIL PROTECTED]> wrote: > > The following code calling numpy v1.0.4 fails to terminate on my machine, > > which was not the case with v1.0.3.1 > > > > from numpy import arange, float64 > > from numpy.linalg import eig > > a = arange(13*13, dtype = float64) > > a.shape = (13,13) > > a = a%17 > > eig(a) > > It sounds like the same problem that was reported in this thread: > > http://thread.gmane.org/gmane.comp.python.numeric.general/17456/focus=17465 > > A friend of mine says the windows binary of 1.0.4 also hangs on eigh > and lstsq (so linalg in general). I don't have that problem on 1.0.5 > compiled on GNU/Linux. Could you friend try the binaries there: http://projects.scipy.org/pipermail/numpy-discussion/2007-November/029811.html This may be a problem related to the blas/lapack used for the binaries. The binaries posted above use non optimized BLAS/LAPACK (I can update to 1.0.4 if this is a problem). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy book and PyArray_CastToType
2007/11/12, Albert Strasheim <[EMAIL PROTECTED]>: > > Hello, > > Have you considered looking at the source for PyArray_CastToType in > core/src/arrayobject.c? > > Cheers, > > Albert Well no :( I didn't know where to look (and this should be fixed in the book as well...) Matthieu -- French PhD student Website : http://miles.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with numpy.linalg.eig?
Works fine on my computer (Mac OS X 10.4), Python 2.4. Runs in a second or so. -- Lou Pecora ---Peter wrote: Hi all, The following code calling numpy v1.0.4 fails to terminate on my machine, which was not the case with v1.0.3.1 from numpy import arange, float64 from numpy.linalg import eig a = arange(13*13, dtype = float64) a.shape = (13,13) a = a%17 eig(a) Regards, Peter __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with numpy.linalg.eig?
On Nov 12, 2007 10:10 AM, Peter Creasey <[EMAIL PROTECTED]> wrote: > The following code calling numpy v1.0.4 fails to terminate on my machine, > which was not the case with v1.0.3.1 > > from numpy import arange, float64 > from numpy.linalg import eig > a = arange(13*13, dtype = float64) > a.shape = (13,13) > a = a%17 > eig(a) It sounds like the same problem that was reported in this thread: http://thread.gmane.org/gmane.comp.python.numeric.general/17456/focus=17465 A friend of mine says the windows binary of 1.0.4 also hangs on eigh and lstsq (so linalg in general). I don't have that problem on 1.0.5 compiled on GNU/Linux. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Problem with numpy.linalg.eig?
Hi all, The following code calling numpy v1.0.4 fails to terminate on my machine, which was not the case with v1.0.3.1 from numpy import arange, float64 from numpy.linalg import eig a = arange(13*13, dtype = float64) a.shape = (13,13) a = a%17 eig(a) Regards, Peter ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] weibull distribution has only one parameter?
D.Hendriks (Dennis) wrote:
> Alan G Isaac wrote:
>> On Mon, 12 Nov 2007, "D.Hendriks (Dennis)" apparently wrote:
>>
>>> All of this makes me doubt the correctness of the formula
>>> you proposed.
>>>
>> It is always a good idea to hesitate before doubting Robert.
>> http://en.wikipedia.org/wiki/Weibull_distribution#Generating_Weibull-distributed_random_variates>
>>
>> hth,
>> Alan Isaac
>>
> So, you are saying that it was indeed correct? That still leaves the
> question why I can't seem to confirm that in the figure I mentioned (red
> and green lines). Also, if you refer to X = lambda*(-ln(U))^(1/k) as
> 'proof' for the validity of the formula, I have to ask if
> Weibull(a,Size) does actually correspond to (-ln(U))^(1/a)?
double rk_standard_exponential(rk_state *state)
{
/* We use -log(1-U) since U is [0, 1) */
return -log(1.0 - rk_double(state));
}
double rk_weibull(rk_state *state, double a)
{
return pow(rk_standard_exponential(state), 1./a);
}
Like Ryan says, multiplying a random deviate by a number is different from
multiplying the PDF by a number. Multiplying the random deviate by lambda is
equivalent to transforming pdf(x) to pdf(x/lambda) not lambda*pdf(x).
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] weibull distribution has only one parameter?
D.Hendriks (Dennis) wrote: > Alan G Isaac wrote: >> On Mon, 12 Nov 2007, "D.Hendriks (Dennis)" apparently wrote: >> >>> All of this makes me doubt the correctness of the formula >>> you proposed. >>> >> It is always a good idea to hesitate before doubting Robert. >> http://en.wikipedia.org/wiki/Weibull_distribution#Generating_Weibull-distributed_random_variates> >> >> hth, >> Alan Isaac >> > So, you are saying that it was indeed correct? That still leaves the > question why I can't seem to confirm that in the figure I mentioned (red > and green lines). Also, if you refer to X = lambda*(-ln(U))^(1/k) as > 'proof' for the validity of the formula, I have to ask if > Weibull(a,Size) does actually correspond to (-ln(U))^(1/a)? > Have you actually looked at a histogram of the random variates generated this way to see if they are wrong? Multiplying the the individual random values by a number changes the distribution differently than multiplying the distribution/density function by a number. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy book and PyArray_CastToType
Hello, Have you considered looking at the source for PyArray_CastToType in core/src/arrayobject.c? Cheers, Albert On Mon, 12 Nov 2007, Matthieu Brucher wrote: > Nobody can answer this ? > > Matthieu > > 2007/11/4, Matthieu Brucher <[EMAIL PROTECTED]>: > > > > Hi, > > > > I'm trying to use PyArray_CastToType(), but according to the book, there > > are two arguments, a PyArrayObject* and a PyArrayDescr*, but according to > > the header file, there are three arguments, an additional int. Does someone > > know its use ? > > > > Matthieu ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Getting an array interface and using it
Hi, I have an object that exposes an array interface. I want to modify the data it contains, but using numpy.array(myObject) seems to copy the data and thus my object is not modified. Am I mistaken or did I make a mistake in my array interface ? Matthieu -- French PhD student Website : http://miles.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy book and PyArray_CastToType
Nobody can answer this ? Matthieu 2007/11/4, Matthieu Brucher <[EMAIL PROTECTED]>: > > Hi, > > I'm trying to use PyArray_CastToType(), but according to the book, there > are two arguments, a PyArrayObject* and a PyArrayDescr*, but according to > the header file, there are three arguments, an additional int. Does someone > know its use ? > > Matthieu > -- > French PhD student > Website : http://miles.developpez.com/ > Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 > LinkedIn : http://www.linkedin.com/in/matthieubrucher -- French PhD student Website : http://miles.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] weibull distribution has only one parameter?
Alan G Isaac wrote: On Mon, 12 Nov 2007, "D.Hendriks (Dennis)" apparently wrote: All of this makes me doubt the correctness of the formula you proposed. It is always a good idea to hesitate before doubting Robert. http://en.wikipedia.org/wiki/Weibull_distribution#Generating_Weibull-distributed_random_variates> hth, Alan Isaac So, you are saying that it was indeed correct? That still leaves the question why I can't seem to confirm that in the figure I mentioned (red and green lines). Also, if you refer to X = lambda*(-ln(U))^(1/k) as 'proof' for the validity of the formula, I have to ask if Weibull(a,Size) does actually correspond to (-ln(U))^(1/a)? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] weibull distribution has only one parameter?
On Mon, 12 Nov 2007, "D.Hendriks (Dennis)" apparently wrote: > All of this makes me doubt the correctness of the formula > you proposed. It is always a good idea to hesitate before doubting Robert. http://en.wikipedia.org/wiki/Weibull_distribution#Generating_Weibull-distributed_random_variates> hth, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Merging new (optional) build system in the trunk ?
Hi, I would appreciate to get some comment on whether there is any chance to get my numpy.scons branch merge into the trunk at some near future. I feel to have reached the point where the only big thing missing is more testing. I tried to test it on many platforms, but there is a limit to what I can test just by myself. The branch has been conceived such as by default, the current numpy.distutils is used to build, and the scons-based build is used only by explicit request (another setup.py), so this does not force any use now: except the work related to numpyconfig (which can be tested separately, since it was done in a different branch, and is only a few lines of code), everything else is exactly the same than before. Thanks, David P.S: Just as a reminder, here are some of the already implemented goals currently: - all the facilities of scons are available to build extensions (parallel builds, automatic dependency, easy extension through of new builders and configuration checks, etc...) - ability to build shared libraries and Ctypes-based extension in a cross platform way. - optimization flags logic cleanly separated from the other flags: you can now easily replace, add, remove optimization flags without having to handle platform specific flags such as -fPIC, etc... - facility replacing system_info which is easier to use (one function call to support most common cases) - performance library checks are stronger, for more reliable build results. MKL, Sunperf, ATLAS, vecLib and Accelerate are already supported; new libraries can generally be added in a few lines, as they all use the same infrastructure. - the current (successfully) tested platforms are : Mac OS X Intel (gfortran + gcc), Linux (g77 + gcc, gfortran + gcc, intel compilers), MS Windows (mingw, VS 2003 + g77, VS 2005 + g77), Solaris (with sun compilers). - Generally, I tried to follow the autoconf philosophy (do not check for version, check for facilities). The fortran runtime, for example, is found automatically, as is the fortran name mangling. - easier maintenance: no more distutils monkey patching because upstream distutils does not have a clean API, the current codebase is a bit below 3000 lines of code, not counting scons (as a comparison, system_info.py is almost 2000 lines by itself), most of the code is totally cross platform, and platform specific are encapsulated; there are a few hacks, but they are implementation-only hacks. So concretely, I believe that most of the things stated in http://projects.scipy.org/scipy/numpy/wiki/DistutilsRevamp are available *now*. More concrete info here: http://projects.scipy.org/scipy/numpy/wiki/NumpyScons ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] weibull distribution has only one parameter?
Robert Kern wrote: D.Hendriks (Dennis) wrote: According to (for instance) http://en.wikipedia.org/wiki/Weibull_distribution the Weibull distribution has two parameters: lambda > 0 is the scale parameter (real) and k > 0 is the shape parameter (real). However, the numpy.random.weibull function has only a single 'a' parameter (except for the size parameter which indicates the size of the array to fill with values - this is NOT a parameter of the distribution itself). My question is how this 'a' parameter translates to the Weibull distribution as it 'normally' is and how to sample the distribution when I have the lambda and k parameters? lambda * numpy.random.weibull(k) Thanks for the quick replay. However, when I look at the image of the probability density function at http://en.wikipedia.org/wiki/Weibull_distribution I see a red line and a green line, both with k=2. The red line is for lambda=0.5 and the green for lambda=1.0. The green line is not only half the height of the red one (while double the lambda factor!), but also has its mean a bit more to the right. Looking at the formulas on the same page, this makes sense. All of this makes me doubt the correctness of the formula you proposed... ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] weibull distribution has only one parameter?
D.Hendriks (Dennis) wrote: > According to (for instance) > http://en.wikipedia.org/wiki/Weibull_distribution the Weibull > distribution has two parameters: lambda > 0 is the scale parameter > (real) and k > 0 is the shape parameter (real). However, the > numpy.random.weibull function has only a single 'a' parameter (except > for the size parameter which indicates the size of the array to fill > with values - this is NOT a parameter of the distribution itself). My > question is how this 'a' parameter translates to the Weibull > distribution as it 'normally' is and how to sample the distribution when > I have the lambda and k parameters? lambda * numpy.random.weibull(k) -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] weibull distribution has only one parameter?
According to (for instance) http://en.wikipedia.org/wiki/Weibull_distribution the Weibull distribution has two parameters: lambda > 0 is the scale parameter (real) and k > 0 is the shape parameter (real). However, the numpy.random.weibull function has only a single 'a' parameter (except for the size parameter which indicates the size of the array to fill with values - this is NOT a parameter of the distribution itself). My question is how this 'a' parameter translates to the Weibull distribution as it 'normally' is and how to sample the distribution when I have the lambda and k parameters? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
