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't seem to like
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 you're
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__
method:
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
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! ;)
Well
En/na Pierre Barbier de Reuille ha escrit::
import numpy
numpy.__version__
'0.9.9.2852'
numpy.bool_
type 'boolscalar'
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.
Ivan Vilata i Balaguer wrote:
En/na Pierre Barbier de Reuille ha escrit::
import numpy
numpy.__version__
'0.9.9.2852'
numpy.bool_
type 'boolscalar'
Sorry if I didn't make my question clear. What I find lacking is a
``numpy.boolean`` type which is
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,
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 !)
Thanks,
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 something...
import
Hi,
Are numpy.product() and numpy.prod()
doing the exact same thing ? If yes, why are they pointing to two different
functions ?
N.prod
function prod at 0x43cef56c
N.product
function product at 0x43cef304
Thanks,
Sebastian Haase
Sebastian Haase wrote:
Hi!
I'm trying to convert my numarray records code to numpy.
type(m.hdrArray)
class 'numpy.core.records.recarray'
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
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 turn
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 byteorder
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.dtype
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 were
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 giving access to
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
-
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
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 beta
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 than
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 second
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
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, but if the concern
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 simultaneously.
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 __version__ is
And I think byteorder matters when comparing dtypes:
numpy.dtype('f4') == numpy.dtype('f4')
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 equal to
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
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
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) -- 'i4'
but
str(a.dtype)-- 'int32 (little endian)'
+1
that's the whole point of __str__. It should be human
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 of
:―― INFORMATION ―:
不正・悪質なサイトを一切排除しておりますので
安心してご利用ください。 http://love-match.bz/pc/?02
:――:
*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*
━━━
□■ 不倫・ワリキリ専門の無料出会いサイト『Love☆Match』
:―― INFORMATION ―:
不正・悪質なサイトを一切排除しておりますので
安心してご利用ください。 http://love-match.bz/pc/?010
:――:
*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*
お金と時間を持て余している人妻の間で、噂になってるあのサイト
[登録・利用料全て無料] http://love-match.bz/pc/?010
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
type
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
35 matches
Mail list logo
