On Tuesday 25 July 2006 02:36, Mike Ressler wrote:
> I'm trying to work with memmaps on very large files, i.e. > 2 GB, up to 10
> GB. The files are data cubes of images (my largest is
> 1290(x)x1024(y)x2011(z)) and my immediate task is to strip the data from
> 32-bits down to 16, and to rearrange s
On Tuesday 25 July 2006 01:42, Bill Baxter wrote:
> > > And I think byteorder matters when comparing dtypes:
> > > >>> numpy.dtype('>f4') == numpy.dtype(' > >
> > > False
>
> Oh -- that '<' part is indicating *byte order* ?!
> I thought it was odd that numpy could only tell me the type was "les
Mike Ressler wrote:
> I'm trying to work with memmaps on very large files, i.e. > 2 GB, up
> to 10 GB. The files are data cubes of images (my largest is
> 1290(x)x1024(y)x2011(z)) and my immediate task is to strip the data
> from 32-bits down to 16, and to rearrange some of the data on a
> per-
On Fri, 21 Jul 2006, Travis Oliphant wrote:
>
> I've created the 1.0b1 release tag in SVN and will be uploading files
> shortly to Sourceforge.
FYI numpy-1.0b1 builds fine and passes all its regression tests
on OpenBSD -current.
-d
Hi,
I just ran a simple test which I think would be of general interest.
It's about types and what there names are in the numpy module
(and how many different names there are for a given type !!)
Cheers, Sebastian Haase
(maybe there is a good place in the wiki for this !?)
>>> N.csingle
>
:―― INFORMATION ―:
不正・悪質なサイトを一切排除しておりますので
安心してご利用ください。 http://love-match.bz/pc/?010
:――:
*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*
お金と時間を持て余している人妻の間で、噂になってるあのサイト
[登録・利用料全て無料] http://love-match.bz/pc/?010
━━━
Hi Sebastian,On 7/24/06, Sebastian Haase <[EMAIL PROTECTED]> wrote:
Hi,Essentially I'm looking for the equivalent of what was in numarray:from numarray import random_arrayrandom_array.poisson(arr)That is: if for example arr is a 256x256 array of positive integers, then this
returns a new a
:―― INFORMATION ―:
不正・悪質なサイトを一切排除しておりますので
安心してご利用ください。 http://love-match.bz/pc/?02
:――:
*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*
━━━
□■ 不倫・ワリキリ専門の無料出会いサイト『Love☆Match』
--
Howdy,
Instructions for compiling your own SciPy can be found here.
http://www.scipy.org/Installing_SciPy
I think the 0.4.9 source will probably work. But getting it from SVN
is probably safer.
--bb
On 7/25/06, Mathew Yeates <[EMAIL PROTECTED]> wrote:
> Where is the source? Do I just use the
Where is the source? Do I just use the 0.4.9 source?
Bill Baxter wrote:
> Yep, scipy needs to be recompiled against the 1.0b1 version of numpy.
> I think they should have an updated version on the web site in a few
> days or so if you don't feel like compiling yourself.
>
> --bb
>
> On 7/25/06, M
Yep, scipy needs to be recompiled against the 1.0b1 version of numpy.
I think they should have an updated version on the web site in a few
days or so if you don't feel like compiling yourself.
--bb
On 7/25/06, Mathew Yeates <[EMAIL PROTECTED]> wrote:
> I installed numpy-1.0b1 and now >import nump
On 7/25/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
> 1.0.2881 - This would sort after 1.0 (and 1.0b and 1.0c) and before 1.1
> for most tools out there.
I like that best. Save the 1.1 prefix until it's actually released as such.
The numbering scheme needs to deal with what to call the patch tip
Sebastian Haase wrote:
> Which is why I was trying to change the str() representation of a type to
> something more intuitive.
> If nothing else one could even leave
> repr(a.dtype) --> ' but
> str(a.dtype)--> 'int32 (little endian)'
+1
that's the whole point of __str__. It should be hum
I'm trying to work with memmaps on very large files, i.e. > 2 GB, up to 10 GB. The files are data cubes of images (my largest is 1290(x)x1024(y)x2011(z)) and my immediate task is to strip the data from 32-bits down to 16, and to rearrange some of the data on a per-xy-plane basis. I'm running this o
On Monday 24 July 2006 16:42, Bill Baxter wrote:
> > > And I think byteorder matters when comparing dtypes:
> > > >>> numpy.dtype('>f4') == numpy.dtype(' > >
> > > False
>
> Oh -- that '<' part is indicating *byte order* ?!
> I thought it was odd that numpy could only tell me the type was "less
I installed numpy-1.0b1 and now >import numpy produces a segv. According
to gdb it's happening after a failure to import scipy.optimize.minpack2.
Eventually, Py_FatalError is called followed by abort,raise and
thr_kill. Then the SEGV.
Any ideas? Do I need a different version of scipy? I current
On 7/25/06, Sven Schreiber <[EMAIL PROTECTED]> wrote:
> Travis Oliphant schrieb:
> > Sven Schreiber wrote:
> >>
> > The change was trying to fix up some cases but did break this one. The
> > problem is that figuring out whether or not to transpose the result is a
> > bit tricky. I've obviously st
> > And I think byteorder matters when comparing dtypes:
> > >>> numpy.dtype('>f4') == numpy.dtype(' > False
Oh -- that '<' part is indicating *byte order* ?!
I thought it was odd that numpy could only tell me the type was "less
than f4", which I assumed must be shorthand for "less than or equ
I can't answer why, but in oldnumeric.py, you can see there's two
different fuctions with basically identical code, so yes they are
distinct, but no they are not different. Seems like prod could be
replaced by prod=product.
def product (x, axis=0, dtype=None):
"""Product of the array elements
On Mon, Jul 24, 2006 at 04:03:13PM -0700, Andrew Straw wrote:
> Sasha wrote:
>
> >On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
> >
> >>BTW, Fernando, all this is so that we can still have the svn revision
> >>number in __version__, but so that it doesn't screw up sorting.
> >
> >Sorting __v
On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
> Yes, I only brought up version numbers as strings because you did. I'm
> not proposing we solve that problem. I see setuptools, in particular, as
> the biggest thing to support, because it lets you have multiple versions
> installed simultaneou
Sasha wrote:
>On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
>
>
>
>>BTW, Fernando, all this is so that we can still have the svn revision
>>number in __version__, but so that it doesn't screw up sorting.
>>
>>
>
>Sorting __version__ is screwed up regardless of svn revision number:
>
>
Sasha wrote:
>On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
>[snip]
>
>
>>The concern is that there are a bazillion ways of sorting version
>>numbers but the version numbers from numpy's current svn tree don't sort
>>with (m)any of them. Sorting strings in Python is one way, using
>>setupt
On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
> BTW, Fernando, all this is so that we can still have the svn revision
> number in __version__, but so that it doesn't screw up sorting.
Sorting __version__ is screwed up regardless of svn revision number:
>>> '1.9' < '1.10'
False
---
On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
[snip]
> The concern is that there are a bazillion ways of sorting version
> numbers but the version numbers from numpy's current svn tree don't sort
> with (m)any of them. Sorting strings in Python is one way, using
> setuptools or debian's dpkg
Sasha wrote:
>On 7/24/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>
>>Andrew Straw has emphasized that the current strategy of appending the
>>SVN version number to development versions of the SVN tree makes it hard
>>to do version sorting.
>>
>>
>
>I am not sure what the problem is, bu
On Monday 24 July 2006 14:20, Robert Kern wrote:
> Sebastian Haase wrote:
> > Hi,
> > Essentially I'm looking for the equivalent of what was in numarray:
> > from numarray import random_array
> > random_array.poisson(arr)
> >
> > That is: if for example arr is a 256x256 array of positive i
On 7/24/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Andrew Straw has emphasized that the current strategy of appending the
> SVN version number to development versions of the SVN tree makes it hard
> to do version sorting.
I am not sure what the problem is, but if the concern is that
>>> '0.
On Mon, 24 Jul 2006 15:06:57 -0600
Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Andrew Straw has emphasized that the current strategy of appending the
> SVN version number to development versions of the SVN tree makes it hard
> to do version sorting.
>
> His proposal is to not change the versio
On Sat, 22 Jul 2006 17:50:13 -0400
Steve Lianoglou <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> Since 1.0 release is eminent, I just wanted to draw the attention to
> two failures I get when I run numpy.test(1).
>
> I've never been able to get numpy to pass all test cases, but now it
> fails a
Sebastian Haase wrote:
> Hi,
> Essentially I'm looking for the equivalent of what was in numarray:
> from numarray import random_array
> random_array.poisson(arr)
>
> That is: if for example arr is a 256x256 array of positive integers, then
> this
> returns a new array of random numbers
On 7/24/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Andrew Straw has emphasized that the current strategy of appending the
> SVN version number to development versions of the SVN tree makes it hard
> to do version sorting.
>
> His proposal is to not change the version number until the first be
Andrew Straw has emphasized that the current strategy of appending the
SVN version number to development versions of the SVN tree makes it hard
to do version sorting.
His proposal is to not change the version number until the first beta
comes out.
In other words, the trunk should not be 1.1 b
For the next several months until 1.0 comes out. Please make changes
that go into 1.0 to the ver1.0 branch of the NumPy SVN tree.
Then, periodically, we can merge those changes back to the trunk for ver 1.1
-Travis
-
T
On Monday 24 July 2006 12:23, Travis Oliphant wrote:
> Sebastian Haase wrote:
> > Hi,
> > I have a (medical) image file.
> > I wrote a nice interface based on memmap using numarray.
> > The class design I used was essentially to return a numarray array
> > object with a new "custom" attribute givi
Travis Oliphant schrieb:
> Sven Schreiber wrote:
>>
> The change was trying to fix up some cases but did break this one. The
> problem is that figuring out whether or not to transpose the result is a
> bit tricky. I've obviously still got it wrong.
>
Ok, this is obviously one of the places
Sebastian Haase wrote:
> Hi,
> if I have a numpy array 'a'
> and say:
> a.dtype == numpy.float32
>
> Is the result independent of a's byteorder ?
>
The byteorder is a property of the data-type (not of the array) --- this
is different from numarray where byteorder is a property of the array.
a.
Sebastian Haase wrote:
> Hi,
> if I have a numpy array 'a'
> and say:
> a.dtype == numpy.float32
>
> Is the result independent of a's byteorder ?
> (That's what I would expect ! Just checking !)
>
I think I misread the question and saw "==" as "="
But, the answer I gave should still help: the
Sven Schreiber wrote:
> Thanks for helping out on matrix stuff, Bill!
>
>
> Hm, I don't know -- if you don't mind I'd like to get a second opinion
> before I mess around there. It's funny though that the changeset has the
> title "fixing up matrix slicing" or something like that...
>
The chan
Sebastian Haase wrote:
> Hi,
> I'm converting SWIG typemap'ed C extensions from numarray to numpy.
> I studied (and use parts of) numpy.i from the doc directory.
> I noticed that there is no
> decref for the TYPEMAP_INPLACE2 typemap. This uses a function
> obj_to_array_no_conversion() which in tu
Hi,
Essentially I'm looking for the equivalent of what was in numarray:
from numarray import random_array
random_array.poisson(arr)
That is: if for example arr is a 256x256 array of positive integers, then this
returns a new array of random numbers than are drawn according to the poisson
Sebastian Haase wrote:
> Hi!
> I'm trying to convert my numarray records code to numpy.
> >>> type(m.hdrArray)
>
> >>> m.hdrArray.d
> [(array([ 1., 1., 1.], dtype=float32),)]
>
> but I get:
> >>> m.hdrArray[0].getfield('d')
> 5.43230922614e-312
>
> Am I missing something or is this a bug ?
>
Paul Barrett wrote:
> I'm having a problem converting a C extension module that was
> originally written for numarray to use numpy. I using swig to create
> a wrapper flle for the C code. I have added the
> numpy.get_numarray_include() method to my setup.py file and have
> changed the numarray/li
Hi,
Are numpy.product() and numpy.prod()
doing the exact same thing ? If yes, why are they pointing to two different
functions ?
>>> N.prod
>>> N.product
Thanks,
Sebastian Haase
-
Take Surveys. Earn Cash. Influence the Fut
On Monday 24 July 2006 20:10, Sebastian Haase wrote:
> Hi !
> Thanks for the reply.
> Did you actually run this ? I get:
> #>>> a=N.arange(10, dtype=N.float32)
> #>>> a.dtype == N.float32
> #True
> #>>> N.__version__
> #'0.9.9.2823'
Hi,
Looks like I need to upgrade my working version or somethin
On Monday 24 July 2006 03:18, Karol Langner wrote:
> On Monday 24 July 2006 06:47, Sebastian Haase wrote:
> > Hi,
> > if I have a numpy array 'a'
> > and say:
> > a.dtype == numpy.float32
> >
> > Is the result independent of a's byteorder ?
> > (That's what I would expect ! Just checking !)
> >
> >
Graham Cummins wrote:
> Greetings,
>
> I just downloaded numpy 1.0b1. I see a lot of changes from 0.9.8, and
> I'm curious as to whether these changes will be a lasting property of
> numpy 1.0 and later.
>
> Most of the changes relate to nomenclature for type constants (e.g.
> int32, complex128,
Ivan Vilata i Balaguer wrote:
> En/na Pierre Barbier de Reuille ha escrit::
>
>
> import numpy
> numpy.__version__
>
>> '0.9.9.2852'
>>
> numpy.bool_
>
>>
>>
>
> Sorry if I didn't make my question clear. What I find lacking is a
> ``numpy.boo
En/na Pierre Barbier de Reuille ha escrit::
import numpy
numpy.__version__
>'0.9.9.2852'
numpy.bool_
>
Sorry if I didn't make my question clear. What I find lacking is a
``numpy.boolean`` type which is to ``numpy.bool_`` the same as
``numpy.string`` is now to ``numpy.str_`` (i.e. a p
Ivan Vilata i Balaguer wrote:
> Hi all,
>
> Since there is a "string" type which is the same as "str_", how come
> there is no "boolean" type which is the same as "bool_"? Did I miss
> some design decision about naming? You know, just for completeness, not
> that it is some kind of problem at all
Hi All,
I'm finding myself dealing with n-dimensional grids quite a lot, and
trying to do some 'tricky' index manipulation. The main problem is
manipulating arrays when I don't know a priori the number of dimensions;
in essence I need to be able to iterate across dimensions.
first, I've got th
Hi all,
Since there is a "string" type which is the same as "str_", how come
there is no "boolean" type which is the same as "bool_"? Did I miss
some design decision about naming? You know, just for completeness, not
that it is some kind of problem at all! ;)
Cheers,
::
Ivan Vilata i
2006/7/24, PGM <[EMAIL PROTECTED]>:
Folks ,I'm still using numpy 0.9.8 and just ran into this problem on my machine(AMD64):>>> import numpy as N>>> x = N.array([1.23456])>>> print divmod(x,1)(array([ 1.]), array([
0.23456]))>>> print divmod(x[0],1)()>>> print divmod(x.tolist()[0],1)(1.0, 0.2345600
Thanks for helping out on matrix stuff, Bill!
Bill Baxter schrieb:
> On 7/22/06, Sven Schreiber <[EMAIL PROTECTED]> wrote:
>>
>> Note the array slicing works correct, but the equivalent thing with the
>> matrix does not.
>
> Looks like it happened in rev 2698 of defmatrix.py, matrix.__getitem__
On Monday 24 July 2006 06:47, Sebastian Haase wrote:
> Hi,
> if I have a numpy array 'a'
> and say:
> a.dtype == numpy.float32
>
> Is the result independent of a's byteorder ?
> (That's what I would expect ! Just checking !)
>
> Thanks,
> Sebastian Haase
The condition will always be False, because
Folks ,
I'm still using numpy 0.9.8 and just ran into this problem on my machine
(AMD64):
>>> import numpy as N
>>> x = N.array([1.23456])
>>> print divmod(x,1)
(array([ 1.]), array([ 0.23456]))
>>> print divmod(x[0],1)
()
>>> print divmod(x.tolist()[0],1)
(1.0, 0.23456001)
divmod doesn'
56 matches
Mail list logo
