Re: [Numpy-discussion] ** On entry to ILAENV parameter numb er 2 had an illegal value
Steven Coutts stevec at couttsnet.com writes: I am getting this error when trying to run a script using scipy. Python 2.5 atlas-3.9.0 lapack-3.2 numpy-1.3.0 scipy-0.7.1 Anyone any ideas how I can fix this? Regards Also tried Atlas 3.9.11 and 3.8.3 with no luck. Anyone got any ideas? Regards ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
Steven Coutts wrote: Steven Coutts stevec at couttsnet.com writes: I am getting this error when trying to run a script using scipy. Python 2.5 atlas-3.9.0 lapack-3.2 numpy-1.3.0 scipy-0.7.1 Anyone any ideas how I can fix this? Lapack 3.2 is problematic, so I would try to downgrade to 3.1.1 first. Which OS are you on ? The exact core you are running, as well as the output of the test suite (numpy.test()) would be helpful, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
David Cournapeau wrote: Lapack 3.2 is problematic, so I would try to downgrade to 3.1.1 first. Which OS are you on ? The exact core you are running, as well as the output of the test suite (numpy.test()) would be helpful, cheers, David Ok, I have downgraded to lapack 3.1.1 and re-compiled and re-installed everything. Numpy test seg faults :( http://pastebin.com/d56fd6e44 This is on Linux (CentOS) and a Quad-Core AMD Opteron(tm) Processor 2350 HE Regards ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
Steven Coutts wrote: David Cournapeau wrote: Lapack 3.2 is problematic, so I would try to downgrade to 3.1.1 first. Which OS are you on ? The exact core you are running, as well as the output of the test suite (numpy.test()) would be helpful, cheers, David Ok, I have downgraded to lapack 3.1.1 and re-compiled and re-installed everything. Numpy test seg faults :( http://pastebin.com/d56fd6e44 Not sure it can be considered as progress :) Could you run the test suite with verbosity set to ten (numpy.test(verbose=10)) ? Also, which fortran compiler are you using ? g77 or gfortran ? cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
David Cournapeau wrote: Not sure it can be considered as progress :) Could you run the test suite with verbosity set to ten (numpy.test(verbose=10)) ? Also, which fortran compiler are you using ? g77 or gfortran ? cheers, David Ok, http://pastebin.com/ddaae526 Seg faults here -: test_cdouble (test_linalg.TestEigh) I am using gfortran. Regards ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
Steven Coutts wrote: Ok, http://pastebin.com/ddaae526 Seg faults here -: test_cdouble (test_linalg.TestEigh) I am using gfortran. Regards Ok, downgraded numpy to 1.2.1 and all the tests pass now! Regards ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter numb er 2 had an illegal value
Steven Coutts stevec at couttsnet.com writes: Ok, downgraded numpy to 1.2.1 and all the tests pass now! Regards But now scipy seg faults straight away http://pastebin.com/de13dd62 Downgraded scipy to 0.7.0 and still the same seg fault :( ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter numb er 2 had an illegal value
Steven Coutts stevec at couttsnet.com writes: But now scipy seg faults straight away http://pastebin.com/de13dd62 Downgraded scipy to 0.7.0 and still the same seg fault :( Downgrading all the way back to scipy-0.6.0 makes scipy work. Any ideas why no newer version work? Regards ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
Steven Coutts wrote: Ok, downgraded numpy to 1.2.1 and all the tests pass now! That's really strange - Linux is the most tested configuration, numpy 1.3.0 should run without problems. There is something unusual with your configuration that I am missing. Could you build numpy 1.3.0 from scratch and paste the output (rm -rf build python setup.py build build.log) ? If you are willing to do it, I would also be interested whether numpy works ok if linked against BLAS/LAPACK instead of atlas (i.e. build numpy, again from scratch, with ATLAS=None python setup.py build, and then run the test suite). cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
Steven Coutts wrote: Steven Coutts stevec at couttsnet.com writes: Ok, downgraded numpy to 1.2.1 and all the tests pass now! Regards But now scipy seg faults straight away http://pastebin.com/de13dd62 Downgraded scipy to 0.7.0 and still the same seg fault :( Make sure your scipy is built against numpy 1.2.1. You cannot build scipy against numpy 1.3.0, and then use scipy with numpy 1.2.1 (but you can build against numpy 1.2.1 and use scipy with numpy 1.3.0). cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
David Cournapeau david at ar.media.kyoto-u.ac.jp writes: Make sure your scipy is built against numpy 1.2.1. You cannot build scipy against numpy 1.3.0, and then use scipy with numpy 1.2.1 (but you can build against numpy 1.2.1 and use scipy with numpy 1.3.0). cheers, David Yes it was built against the correct version of Numpy (I triple checked this!) Regards ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Timeline for 1.4.0 and installer for Windows64bit ?
A suggestion: How about releasing Numpy for the AMD64 version first (without Scipy) and then follow up with a later release with Scipy support? This would satisfy Numpy-only users which can't be a bad thing rather than having a version that is not usable (I believe) by either Numpy or Scipy users. Dinesh From: David Cournapeau Sent: Thursday, July 30, 2009 8:15 PM To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Timeline for 1.4.0 and installer for Windows64bit ? Hi Klaus, Klaus Noekel wrote: Dear folks, just over a month ago there was a thread about plans for numpy, and IIRC somebody had volunteered to try and put together a working AMD64 version with an installer. Since then I have not heard about the issue again - but I may have missed part of the discussion. Have the plans firmed up by now? Is there a tentative date for a beta or RC? In particular: how much hope is there for a reasonably usable AMD64 numpy under Windows? There were some discussion about pushing 1.4.0 'early', but instead, I think we let it slipped - one consequence is that there will be enough time for 1.4.0 to be released with proper AMD64 support on windows. The real issue is not numpy per-se, but making scipy work on top of numpy in 64 bits mode. It is hard to give an exact date as to when those issues will be fixed, but it is being worked on. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
David Cournapeau david at ar.media.kyoto-u.ac.jp writes: That's really strange - Linux is the most tested configuration, numpy 1.3.0 should run without problems. There is something unusual with your configuration that I am missing. Could you build numpy 1.3.0 from scratch and paste the output (rm -rf build python setup.py build build.log) ? If you are willing to do it, I would also be interested whether numpy works ok if linked against BLAS/LAPACK instead of atlas (i.e. build numpy, again from scratch, with ATLAS=None python setup.py build, and then run the test suite). Ok build.log is here http://pastebin.com/d5eb5dc20 I'll try building against BLAS/LAPACK after lunch. Regards ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Timeline for 1.4.0 and installer for Windows64bit ?
Dinesh B Vadhia wrote: A suggestion: How about releasing Numpy for the AMD64 version first (without Scipy) and then follow up with a later release with Scipy support? This would satisfy Numpy-only users which can't be a bad thing rather than having a version that is not usable (I believe) by either Numpy or Scipy users. Because scipy needs code I would pull out from numpy. You can build numpy for amd64 by yourself at the moment, BTW. I am afraid that distributing one numpy binary now would only makes things more confusing when scipy for amd64 will be out, as it will not work with this numpy, but only with a later one. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
David Cournapeau david at ar.media.kyoto-u.ac.jp writes: If you are willing to do it, I would also be interested whether numpy works ok if linked against BLAS/LAPACK instead of atlas (i.e. build numpy, again from scratch, with ATLAS=None python setup.py build, and then run the test suite). Yes that appears to work fine, all tests run. Regards ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
Steven Coutts wrote: David Cournapeau david at ar.media.kyoto-u.ac.jp writes: If you are willing to do it, I would also be interested whether numpy works ok if linked against BLAS/LAPACK instead of atlas (i.e. build numpy, again from scratch, with ATLAS=None python setup.py build, and then run the test suite). Yes that appears to work fine, all tests run. So that's a problem with ATLAS. Maybe a gcc bug ? Another user contacted me privately for my rpm repository, and got exactly the same problem with the rpms, on CENTOS 5.3 as well. I will try to look at it on a centos VM if I have time this WE, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
David Cournapeau david at ar.media.kyoto-u.ac.jp writes: So that's a problem with ATLAS. Maybe a gcc bug ? Another user contacted me privately for my rpm repository, and got exactly the same problem with the rpms, on CENTOS 5.3 as well. I will try to look at it on a centos VM if I have time this WE, I think the user who contacted you is the person I am installing this for, he said he had mailed you:) As I said I'm back on numpy 1.2.1 and scipy-0.6.0, anything above that just seg faults or gets the ILAENV error. Think I must have tried nearly every possible combination of versions of packages (including atlas and lapack)! But it's running so it's not a biggy for now. If this were my box I'd give you access to have a bit of a look at, but unfortunately it's not mine. :) Regards ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] (newbie) How can I use NumPy to wrap my C++ class with 2-dimensional arrays?
Hi Matthieu, Thanks for the explanation. After having looked at the documentation, I decided to do my own plain Python c-api implementation. Thanks for your time Raymond Matthieu Brucher wrote: 2009/7/30 Raymond de Vries ree...@zonnet.nl: Hi Indeed, the solution is as simple as this ;) The trouble is to find the information! Yes, there is so much information everywhere. And it's hard to make the first steps. For the std::vector[], I suggest you convert it to a single vector, as the data inside this array is not contiguous and it can thus be cumbersome to create a Numpy array from that. I am now ready to do this. To be certain, 'contiguous' means that the std::vector's are not the same length, right? Would that mean that I'd better use a tuple of lists or so? (or list of lists or so). thanks for your time Raymond Contiguous means that the whole data is in one big chunk. If it is not, you have to rely on other Numpy functions (I don't know all of them, perhaps you will find one that satisfies your need), and the data may then be copied (not sure though). Matthieu ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Memory layout of record arrays
I've cooked a very rudimentary implementation of what I would like to
have, however I've got a small problem concerning array shape. The idea
is to have a parent array (a group) that can be instantiated like a
regular array and that build internally all the relevant contiguous
child arrays. I would like those child arrays to not be reshapable (at
least not without telling their parent first) and I naively overloaded
the shape property but got a lot of problems with infinite recursion. Is
there a way to do that ?
Nicolas
I put the code below (around 100 lines):
class array(np.ndarray):
def __new__(subtype, shape=(1,1), dtype=np.float32, order=None,
group=None):
obj = np.ndarray.__new__(subtype, shape=shape, dtype=dtype,
order=order)
obj._group = group
return obj
def _get_group(self):
return self._group or self
def _set_group(self, group):
if self.size == group.size:
self.shape = group.shape
self._group = group
else:
raise ValueError, \
'shape mismatch: objects cannot be broadcast to a single
shape'
group = property(_get_group, _set_group,
doc = '''Group to which this array belongs to''')
def _get_shape(self):
return self.ctypes.shape
def _set_shape(self, shape):
if self.group == None:
self.ctypes.shape = shape
else:
raise AttributeError, \
'''Cannot reshape a child array (''group'' is not
None)'''
#shape = property(_get_shape, _set_shape, doc='''c-types shape''')
class group(object):
def __init__(self, shape, dtype=None, order=None):
object.__setattr__(self,'_arrays', {})
self._shape = shape
self._dtype = dtype
if len(dtype) == 0:
self._dtype = np.dtype('f0',dtype)
for i in range(len(self._dtype)):
name, dtype = self._dtype[i]
self._arrays[name] =
array(shape=shape,dtype=dtype,order=order)
def __getattr__(self, key):
if key in self._arrays.keys():
return self._arrays[key]
else:
return object.__getattribute__(self, key)
def __setattr__(self, key, value):
if key in self._arrays.keys():
self._arrays[key][...] = value
else:
object.__setattr__(self, key, value)
def __getitem__(self, key):
return self._arrays[key]
def __setitem__(self, key, value):
self._arrays[key][...] = value
def __len__(self):
return len(self._arrays[self._arrays.keys()[0]])
def _get_shape(self):
return self._shape
def _set_shape(self, shape):
for key in self._arrays.keys():
self._arrays[key].shape = shape
self._shape = shape
shape = property(_get_shape, _set_shape)
def _get_dtype(self):
return self._dtype
def _set_dtype(self):
raise AttributeError, \
'''attribute 'dtype' of 'group' objects is not writable'''
dtype = property(_get_dtype, _set_dtype)
def _get_size(self):
return self._arrays[self._arrays.keys()[0]].size
def _set_size(self):
raise AttributeError, \
'''attribute 'size' of 'group' objects is not writable'''
size = property(_get_size, _set_size)
def __repr__(self):
s = 'group(\n'
for i in range(len(self._dtype)):
name,dtype = self._dtype[i]
t = '%s': % name
a = repr(self._arrays[name]).replace('\n', '\n' +' '*len(t))
s += t+a+'\n'
s += ')'
return s
if __name__ == '__main__':
G = group((3,3), dtype =
[('r',np.float32),('g',np.int32),('b',np.bool)])
G['r'] = G.g = G.b = 0
print G
print
G.r.shape = (9,1)
print G.r.shape
print G.shape
On Thu, 2009-07-30 at 20:01 +0200, Nicolas Rougier wrote:
Thanks for the quick answer. It makes sense.
I will have to find some other way to do it then.
Nicolas
On 30 Jul, 2009, at 18:52 , David Cournapeau wrote:
On Fri, Jul 31, 2009 at 12:53 AM, Nicolas
Rougiernicolas.roug...@loria.fr wrote:
Hello,
I've been using record arrays to create arrays with different types
and since I'm doing a lot of computation on each of the different
fields, the default memory layout does not serve my computations.
Ideally, I would like to have record arrays where each field is a
contiguous block of memory.
I don't think you can do it with record arrays: one of the fundamental
design choice of numpy array layout is that the data pointer points to
one block of N items, where each item is described by the dtype. To
have contiguous layout for each member of the structured dtype, you
need two arrays with the corresponding dtype.
cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
On Fri, Jul 31, 2009 at 5:48 AM, Steven Coutts ste...@couttsnet.com wrote: David Cournapeau david at ar.media.kyoto-u.ac.jp writes: So that's a problem with ATLAS. Maybe a gcc bug ? Another user contacted me privately for my rpm repository, and got exactly the same problem with the rpms, on CENTOS 5.3 as well. I will try to look at it on a centos VM if I have time this WE, I think the user who contacted you is the person I am installing this for, he said he had mailed you:) As I said I'm back on numpy 1.2.1 and scipy-0.6.0, anything above that just seg faults or gets the ILAENV error. Think I must have tried nearly every possible combination of versions of packages (including atlas and lapack)! But it's running so it's not a biggy for now. If this were my box I'd give you access to have a bit of a look at, but unfortunately it's not mine. :) Sounds like this problem might depend on the specific combination of compiler, hardware, and Atlas. Could you tell us which amd chip and compiler versions you are using? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ** On entry to ILAENV parameter number 2 had an illegal value
Charles R Harris wrote: Sounds like this problem might depend on the specific combination of compiler, hardware, and Atlas. Could you tell us which amd chip and compiler versions you are using? Chuck processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : Quad-Core AMD Opteron(tm) Processor 2350 HE stepping: 3 cpu MHz : 1994.999 cache size : 512 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu de tsc msr pae cx8 apic cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc rep_good pni cx16 popcnt lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch bogomips: 3999.28 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) GNU Fortran (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python 3.n and Scipy Numpy
A short field report. Python 2.6.2 installed and working with the latest versions of: numpy scipy MySQLdb gnuplot.py and gnuplot rpy and R 2.9.1 PyScripter PyWin32 Rpyc 2.6 The little bit of 3.n syntax I have tried works. So far, this seems like a stable and trouble-free stack. Thanks for the fine work, jab -- John Bollinger, CFA, CMT www.BollingerBands.com If you advance far enough, you arrive at the beginning. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] SciPy Foundation
About sixteen months ago, I launched the SciPy Documentation Project and its Marathon. Dozens pitched in and now numpy docs are rapidly approaching a professional level. The pink wave (Needs Review status) is at 56% today! There is consensus among doc writers that much of the rest can be labeled in the unimportant category, so we're close to starting the review push (hold your fire, there is a web site mod to be done first). We're also nearing the end of the summer, and it's time to look ahead. The path for docs is clear, but the path for SciPy is not. I think our weakest area right now is organization of the project. There is no consensus-based plan for improvement of the whole toward a stated goal, no centralized coordination of work, and no funded work focused on many of our weaknesses, notwithstanding my doc effort and what Enthought does for code. I define success as popular adoption in preference to commercial packages. I believe in vote-with-your-feet: this goal will not be reached until all aspects of the package and its presentation to the world exceed those of our commercial competition. Scipy is now a grass roots effort, but that takes it only so far. Other projects, such as OpenOffice and Sage, don't follow this model and do produce quality products that compete with commercial offerings, at least on open-source platforms. Before we can even hope for that, we have to do the following: - Docs - Rest of numpy reference pages reviewed and proofed or marked unimportant - Scipy reference pages - User manual for the whole toolstack - Multiple commercial books - Packaging - Personal Package Archive or equivalent for every release of every OS for the full toolstack (There are tools that do this but we don't use them. NSF requires Metronome - http://nmi.cs.wisc.edu/ - for funding most development grants, so right now we're not even on NSF's radar.) - Track record of having the whole toolstack installation just work in a few command lines or clicks for *everyone* - Regular, scheduled releases of numpy and scipy - Coordinated releases of numpy, scipy, and stable scikits into PPA system - Public communication - A real marketing plan - Executing on that plan - Web site geared toward multiple audiences, run by experts at that kind of communication - More webinars, conference booths, training, aimed at all levels - Demos, testimonials, topical forums, all showcased - Code - A full design review for numpy 2.0 - No more inconsistencies like median(), lacking out, degrees option for angle functions? - Trimming of financial functions, maybe others, from numpy? - Package structure review (eliminate fromnumeric?) - Goal that this be the last breakage for numpy API (the real 1.0) - Scipy - Is it maintainable? should it be broken up? - Clear code addition path (or decide never to add more) - Docs (see above) - Add-on packages - Both existence of and good indexing/integration/support for field-specific packages - Clearer development path for new packages - Central hosting system for packages (svn, mailing lists, web, build integration, etc.) - Simultaneous releases of stable packages along with numpy/scipy I posted a basic improvement plan some years back. The core ideas have not changed; it is linked from the bottom of http://scipy.org/Developer_Zone. I chose our major weakness to begin with and started the doc project, using some money I could justify spending simply for the utility of docs for my own research. I funded the work of two doc coordinators, one each this summer and last. Looking at http://docs.scipy.org/numpy/stats/, you can see that when a doc coordinator was being paid (summers), work got done. When not, then not. Without publicly announcing what these guys made, I'll be the first to admit that it wasn't a lot. Yet, those small sums bought a huge contribution to numpy through the work of several dozen volunteers and the major contributions of a few. My conclusion is that active and constant coordination is central to motivating volunteer work, and that without a salary we cannot depend on coordination remaining active. On the other hand, I have heard Enthought's leaders bemoan the high cost of devoting employee time to this project, and the low returns available from selling support to universities and non-profit research institutes. Their leadership has moved us forward, particularly in the area of code, but has not provided the momentum necessary to carry us forward on all fronts. It is time for the public and education sectors to kick in some resources and organizational leadership. We are, after all, benefitting immensely. Since the cost of employee time is not so high for us in the public and education sectors, I propose to continue hiring people like Stefan and David as UCF employees or contractors, and to expand to hiring others in areas like
Re: [Numpy-discussion] Functions to pack/unpack bytes?
Travis Oliphant wrote:
Doesn't .view work for that?
Travis
Sent from my iPhone
On Jul 29, 2009, at 6:57 AM, Neal Becker ndbeck...@gmail.com wrote:
Neal Becker wrote:
Does numpy have functions to convert between e.g. an array of
uint32 and
uint8, where the uint32 array is a packed version of the uint8 array
(selecting little/big endian)?
I've been thinking about making a ufunc (in python) to do this, but
have no
idea how to make a ufunc for a function that consumes 4 consecutive
values
of it's input and produces an output array of 1/4 the size of the
input. Is
that possible?
Can 'view' switch byteorder? Doesn't seem to work:
import numpy as np
a = np.arange(10, dtype=np.uint32)
b1 = a.view (np.dtype(np.uint32).newbyteorder(''))
c1 = b1.view(np.uint8)
b2 = a.view (np.dtype(np.uint32).newbyteorder(''))
c2 = b2.view(np.uint8)
print c1
print c2
[0 0 0 0 1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9
0 0 0]
[0 0 0 0 1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9
0 0 0]
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Is this a bug?
Numpy 1.3 In [1]: import numpy as np In [2]: a = np.zeros(5).fill(5) In [3]: a In [4]: type(a) Out[4]: type 'NoneType' In [5]: a = np.zeros(5) In [6]: a.fill(5) In [7]: a Out[7]: array([ 5., 5., 5., 5., 5.]) What i'm trying to do may not be the best way, but I think it should still have worked. Thoughts? Cheers, Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Is this a bug?
On Fri, Jul 31, 2009 at 17:15, Chris Colbertsccolb...@gmail.com wrote: Numpy 1.3 In [1]: import numpy as np In [2]: a = np.zeros(5).fill(5) In [3]: a In [4]: type(a) Out[4]: type 'NoneType' In [5]: a = np.zeros(5) In [6]: a.fill(5) In [7]: a Out[7]: array([ 5., 5., 5., 5., 5.]) What i'm trying to do may not be the best way, but I think it should still have worked. Thoughts? Not a bug. As you can see from In[6], .fill() does not return anything (except the obligatory None). This is just like how list.sort() returns None. -- 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://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Is this a bug?
ahh, yeah I see now. Thanks! nothing like making myself look the fool on a friday! Cheers! On Fri, Jul 31, 2009 at 6:20 PM, Robert Kernrobert.k...@gmail.com wrote: On Fri, Jul 31, 2009 at 17:15, Chris Colbertsccolb...@gmail.com wrote: Numpy 1.3 In [1]: import numpy as np In [2]: a = np.zeros(5).fill(5) In [3]: a In [4]: type(a) Out[4]: type 'NoneType' In [5]: a = np.zeros(5) In [6]: a.fill(5) In [7]: a Out[7]: array([ 5., 5., 5., 5., 5.]) What i'm trying to do may not be the best way, but I think it should still have worked. Thoughts? Not a bug. As you can see from In[6], .fill() does not return anything (except the obligatory None). This is just like how list.sort() returns None. -- 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://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Is this a bug?
On Fri, Jul 31, 2009 at 4:30 PM, Chris Colbert sccolb...@gmail.com wrote: ahh, yeah I see now. Thanks! nothing like making myself look the fool on a friday! If you have to choose a day, Friday is the day of choice. Or a least it supposedly works that way for bad news and politics. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Is this a bug?
Awww, it's fun to be foolish on Fridays! ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
