On Fri, Jan 30, 2009 at 5:18 AM, Neal Becker <ndbecker2 <at> gmail.com> wrote: > A nit, but it would be nice if 'ones' could fill with a value other than 1. > > Maybe an optional val= keyword? You can use the "tile" function for this. "tile(3,3)" creates an array of 3 3's. Geoffrey
Beautiful! That should do the trick. Now let's see how this performs against the list comprehension... Thanks a lot! Raik Rick White wrote: > Here's a technique that works: > > Python 2.4.2 (#5, Nov 21 2005, 23:08:11) > [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import numpy as np > >>> a = np.array([0,4,0,11]) > >>> b = np.array([-1,11,4,15]) > >>> rangelen = b-a+1 > >>> cumlen = rangelen.cumsum() > >>> c = np.arange(cumlen[-1],dtype=np.int32) > >>> c += np.repeat(a[1:]-c[cumlen[0:-1]], rangelen[1:]) > >>> print c > [ 4 5 6 7 8 9 10 11 0 1 2 3 4 11 12 13 14 15] > > The basic idea is that the difference of your desired output from a > simple range is an array with a bunch of constant values appended > together, and that is what repeat() does. I'm assuming that you'll > never have b < a. Notice the slight ugliness of prepending the > elements at the beginning so that the cumsum starts with zero. > (Maybe there is a cleaner way to do that.) > > This does create a second array (via the repeat) that is the same(Continue reading)
On Sun, Feb 1, 2009 at 12:24 AM, Robert Kern <robert.kern <at> gmail.com> wrote: > On Sat, Jan 31, 2009 at 10:30, Sebastian Walter > <sebastian.walter <at> gmail.com> wrote: >> Wouldn't it be nice to have numpy a little more generic? >> All that would be needed was a little check of the arguments. >> >> If I do: >> numpy.trace(4) >> shouldn't numpy be smart enough to regard the 4 as a 1x1 array? > > Why? It's not a 1x1 array. It's a scalar. If you want a 1x1 array, > give it a 1x1 array. > >> numpy.sin(4) works! > > Yes, numpy.sin() operates on scalars in addition to arrays. > >> and if >> x = my_class(4) >> >> wouldn't it be nice if >> >> numpy.trace(x) >> would call >> x.trace() ? >> >> numpy.sin(my_class(4)) works! >> >> Wouldn't it be nice if numpy worked a little more consistent. >> Is this worth a ticket? Or am I missing something here?(Continue reading)
David Froger <david.froger.info <at> gmail.com> writes: > Hy,My question is about reading Fortran binary file (oh no this question > again...) I've posted this before, but I finally got it cleaned up for the Cookbook. For this purpose I use a subclass of file that has methods for reading unformatted Fortran data. See http://www.scipy.org/Cookbook/FortranIO/FortranFile. I'd gladly see this in numpy or scipy somewhere, but I'm not sure where it belongs. > program makeArray > implicit none > integer,parameter:: nx=10,ny=20 > real(4),dimension(nx,ny):: ux,uy,p > integer :: i,j > open(11,file='uxuyp.bin',form='unformatted') > do i = 1,nx > do j = 1,ny > ux(i,j) = real(i*j) > uy(i,j) = real(i)/real(j) > p (i,j) = real(i) + real(j) > enddo > enddo > write(11) ux,uy > write(11) p > close(11) > end program makeArray(Continue reading)
I've been playing with __array_wrap__ to make quantities with units play well with numpy's ufuncs. For example, __array_wrap__ makes it is possible to do the following:
>>> numpy.sqrt([1.,4.,9.]*m**2)
array([1.,2.,3.])*m
Is there an analog to __array_wrap__ for preprocessing arrays on their way *into* a ufunc? For example, it would be nice if one could do something like:
numpy.sin([1,2,3]*arcseconds)
where we have the opportunity to inspect the context, convert the Quantity to units of radians, and then actually call the ufunc. Is this possible, or does one have to reimplement such functions?
Thanks,
Darren
_______________________________________________ Numpy-discussion mailing list Numpy-discussion <at> scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Feb 1, 2009, at 6:32 PM, Darren Dale wrote: > > > Is there an analog to __array_wrap__ for preprocessing arrays on > their way *into* a ufunc? For example, it would be nice if one could > do something like: > > numpy.sin([1,2,3]*arcseconds) > > where we have the opportunity to inspect the context, convert the > Quantity to units of radians, and then actually call the ufunc. Is > this possible, or does one have to reimplement such functions? Just an idea: look at the code for numpy.ma ufuncs (in numpy.ma.core). By defining a few classes for unary, binary and domained functions, you could probably do what you want, without having to recode all the functions by hand. Another idea would be to define some specific __mul__ or __rmul__ rules for your units, so that the list would be transformed into a UnitArray...
Just an idea: look at the code for numpy.ma ufuncs (in numpy.ma.core).
On Feb 1, 2009, at 6:32 PM, Darren Dale wrote:
>
>
> Is there an analog to __array_wrap__ for preprocessing arrays on
> their way *into* a ufunc? For example, it would be nice if one could
> do something like:
>
> numpy.sin([1,2,3]*arcseconds)
>
> where we have the opportunity to inspect the context, convert the
> Quantity to units of radians, and then actually call the ufunc. Is
> this possible, or does one have to reimplement such functions?
By defining a few classes for unary, binary and domained functions,
you could probably do what you want, without having to recode all the
functions by hand.
Another idea would be to define some specific __mul__ or __rmul__
rules for your units, so that the list would be transformed into a
UnitArray...
_______________________________________________ Numpy-discussion mailing list Numpy-discussion <at> scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Hi everyone.
I'd like to log the state of my program as it progresses. Using the
numpy.save / numpy.load functions on the same filehandle repeatedly works
very well for this -- but ends up making a file which very quickly grows to
gigabytes. The data compresses well, though, so I thought I'd use Python's
built-in gzip module underneath. This works great for saving -- but when it
comes time to play back, there's an issue:
>>> import numpy
>>> import gzip
>>> f=open("test.gz")
>>> g=gzip.GzipFile(None,"rb",9,f)
>>> g
<gzip open file 'test.gz', mode 'r' at 0xbaad50 0xc0ab90>
>>> numpy.load(g)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.5/site-packages/numpy/lib/io.py", line 133, in load
fid.seek(-N,1) # back-up
TypeError: seek() takes exactly 2 arguments (3 given)
Turns out you can't rewind gzip file handles in Python. Oops. The offending
code is that which distinguishes between npy and npz files. Could there
maybe be something added to just trust me that it's an npy?
Or better yet, is there something I'm doing wrong / overlooking?
Thanks!
--
--
Matthew Miller mattdm <at> mattdm.org <http://mattdm.org/>
2009/2/2 Matthew Miller <mattdm <at> mattdm.org>:
> I'd like to log the state of my program as it progresses. Using the
> numpy.save / numpy.load functions on the same filehandle repeatedly works
> very well for this -- but ends up making a file which very quickly grows to
> gigabytes. The data compresses well, though, so I thought I'd use Python's
> built-in gzip module underneath. This works great for saving -- but when it
> comes time to play back, there's an issue:
>
> >>> import numpy
> >>> import gzip
> >>> f=open("test.gz")
> >>> g=gzip.GzipFile(None,"rb",9,f)
> >>> g
> <gzip open file 'test.gz', mode 'r' at 0xbaad50 0xc0ab90>
> >>> numpy.load(g)
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/usr/lib64/python2.5/site-packages/numpy/lib/io.py", line 133, in load
> fid.seek(-N,1) # back-up
> TypeError: seek() takes exactly 2 arguments (3 given)
The GzipFile in Python 2.5 does not support the 2nd ("whence")
argument. The solution may be to use this wrapper from the EffBot:
http://effbot.org/librarybook/gzip-example-2.py
In order to "back-port" that functionality.
Regards
Stéfan
On Mon, Feb 02, 2009 at 08:01:54AM +0200, Stéfan van der Walt wrote:
> The GzipFile in Python 2.5 does not support the 2nd ("whence")
> argument. The solution may be to use this wrapper from the EffBot:
> http://effbot.org/librarybook/gzip-example-2.py
> In order to "back-port" that functionality.
Unless I'm misunderstanding, even with the wrapper one can't actually seek
backwards, which is what the numpy code wants to do.
In the meantime, I'm just using numpy.lib.format.read_array() directly.
--
--
Matthew Miller mattdm <at> mattdm.org <http://mattdm.org/>
RSS Feed242 | |
|---|---|
366 | |
397 | |
259 | |
475 | |
280 | |
413 | |
536 | |
833 | |
369 | |
340 | |
729 | |
328 | |
359 | |
259 | |
463 | |
623 | |
503 | |
488 | |
787 | |
576 | |
440 | |
502 | |
641 | |
848 | |
441 | |
655 | |
735 | |
497 | |
911 | |
608 | |
594 | |
842 | |
590 | |
665 | |
897 | |
681 | |
587 | |
504 | |
532 | |
557 | |
778 | |
758 | |
1019 | |
620 | |
1244 | |
1110 | |
620 | |
551 | |
672 | |
317 | |
398 | |
391 | |
293 | |
319 | |
351 | |
282 | |
504 | |
617 | |
720 | |
435 | |
594 | |
361 | |
500 | |
873 | |
530 | |
636 | |
803 | |
664 | |
436 | |
543 | |
584 | |
673 | |
439 | |
61 | |
118 | |
145 | |
65 | |
56 | |
120 | |
58 | |
78 | |
205 | |
295 | |
318 | |
185 | |
60 | |
55 | |
131 | |
75 | |
84 | |
150 | |
149 | |
72 | |
49 | |
70 | |
75 | |
110 | |
71 | |
83 | |
61 | |
107 | |
24 | |
48 | |
12 | |
76 | |
6 | |
42 | |
72 | |
110 | |
104 | |
23 | |
36 | |
59 | |
34 | |
36 | |
123 | |
34 | |
62 | |
126 | |
37 | |
72 | |
54 | |
81 | |
33 | |
56 | |
92 | |
52 | |
33 | |
50 | |
67 | |
42 | |
54 | |
56 | |
24 | |
32 | |
60 | |
44 | |
16 | |
16 | |
28 | |
37 | |
28 | |
48 | |
49 | |
8 |
