On Monday 11 May 2009 23:52:29 Christopher Barker wrote:
> Wei Su wrote:
> > The codes do not work. Guess you forgot something there.
>
> l wasn't defined:
>
> In [16]: a = np.arange(10)
>
> In [17]: b = np.arange(5)
>
> In [20]: l = [a,b]
>
> In [21]: l
> Out[21]: [array([0, 1, 2, 3, 4, 5, 6, 7, 8
[crossposted to numpy-discussion and mlabwrap-user]
Hi,
I wrote a little utility class in Matlab that inherits from double and
overloads the display function so you can easily print matlab arrays
of arbitrary dimension in Numpy format for easy copy and pasting.
I have to work a lot with other pe
I am very new to Numpy and relatively new to Python. I have used Matlab for
15+ years now. But, I am starting to lean toward using Numpy for all my
work.
One thing that I am not understanding is the order of data when read in from
a file. Let's say I have a 256x256x150 uint16 dataset (MRI, 150
On Tue, May 12, 2009 at 2:51 PM, brechmos wrote:
> So, in Numpy I have to reshape it so the "slices" are in the first
> dimension. Obviously, I can do a b.transpose( (1,2,0) ) to get it to look
> like Matlab, but...
>
> I don't understand why the index ordering is different between Matlab and
>
Ah, hah.
In [3]: c = b.reshape((256,256,150), order='F')
Ok, I needed more coffee.
If I do it this way (without the transpose), it should be as fast as
c=b.reshape((150,256,256)), right? It is just changing the stride (or
something like that)? Or is it going to be faster without changing th
On Tue, May 12, 2009 at 14:55, Ryan May wrote:
> On Tue, May 12, 2009 at 2:51 PM, brechmos wrote:
>>
>> So, in Numpy I have to reshape it so the "slices" are in the first
>> dimension. Obviously, I can do a b.transpose( (1,2,0) ) to get it to look
>> like Matlab, but...
>>
>> I don't understand
On 12-May-09, at 3:55 PM, Ryan May wrote:
>
> It's going to be faster to do it without the transpose. Besides,
> for numpy,
> that imshow becomes:
>
>imshow(b[0])
>
> Which, IMHO, looks better than Matlab.
You're right, that is better, odd how I never thought of doing it like
that. I've
This is interesting.
I have always done RGB imaging with numpy using arrays of shape (height,
width, 3). In fact, this is the form that PIL gives when calling
np.asarray() on a PIL image.
It does seem more efficient to be able to do a[0],a[1],a[2] to get the R, G,
and B channels respectively. Thi
On Tue, May 12, 2009 at 15:32, Chris Colbert wrote:
> This is interesting.
>
> I have always done RGB imaging with numpy using arrays of shape (height,
> width, 3). In fact, this is the form that PIL gives when calling
> np.asarray() on a PIL image.
>
> It does seem more efficient to be able to do
Hi,
I am attempting (and failing...) to build numpy on a Scientific Linux
4.6 x86_64 (essentially RHEL I believe) with Python 2.4 (i386). The
machine has the following Python RPM installed:
python2.4-2.4-1pydotorg.i386
python2.4-tools-2.4-1pydotorg.i386
python2.4-devel-2.4-1pydotorg.i386
And
Hi Ian,
Sorry for responding so late. I've been traveling and I'm just
catching up on my e-mail now. This is easily accomplished with the
cdist function, which computes the pairwise distances between two sets
of vectors. In your case, one of the sets contains only a single
vector.
In [6]: scipy.s
Thanks, but I don't want to make SciPy a dependency. NumPy is ok though.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
If you want the distance functionality without the rest of SciPy, you
can download the scipy-cluster package
(http://scipy-cluster.googlecode.com), which I still maintain. It does
not depend on any other libraries except NumPy and is very easy to
build. I understand if that's not an option for you.
Hey, this looks cool! I may use it in the future. The problem has already
been solved, though, and I don't think changing it is necessary. I'd also
like to keep the dependencies (even packaged ones) to a minimum.
___
Numpy-discussion mailing list
Numpy
On Wed, May 13, 2009 at 6:14 AM, James Jackson wrote:
>
>
> I note that the distribution directory being created is build/
> src.linux-x86_64-2.4 - not i386. Can I force the architecture in the
> configure step, as it appears this would be the problem (hinted at by
> LONG_BIG wrong for platform er
2009/5/10 Stéfan van der Walt :
>
> I think the message "ABI version %%x of C-API" is unclear, maybe
> simply use "ABI version %%x" on its own.
>
> The hash file can be loaded in one line with
>
> np.loadtxt('/tmp/dat.dat', usecols=(0, 2), dtype=[('api', 'S10'),
> ('hash', 'S32')])
>
> The rest lo
16 matches
Mail list logo
