Re: [Numpy-discussion] record descriptors: trailing unused bytes

Martin Wiechert wrote: > Hi list, > > does anybody know, if in C in the PyArray_Descr struct it is safe to manually > change descr->elsize and descr->alignment as long as these are compatible and > descr->elsize is large enough to hold all fields? Of course I mean before any > array is construct

Re: [Numpy-discussion] buggy buggy bugyy: format and casting ==> BUG in numpy.sum?

Eric Emsellem wrote: > Hi again > > after some hours of debugging I finally (I think) found the problem: > > numpy.sum([[0,1,2],[2,3,4]]) > 24 > > numpy.sum([[0,1,2],[2,3,4]],axis=0) > array([2, 4, 6]) > > numpy.sum([[0,1,2],[2,3,4]],axis=1) > array([3, 9]) > > > Isn't the first line supposed to ac

Re: [Numpy-discussion] feasability study to migrate from numarray to numpy

mg wrote: > Hi all, > > I am doing a feseability study to migrate our Python based FEM > applications from Numarray to Numpy. > > First, I tried to install Numpy from Python-2.4 on linux-x86, > linux-86-64bit. So, all work fine. Great! Moreover, I change easily the > BLAS linked libraries. I tri

Re: [Numpy-discussion] Changing byte ordering with astype fails with 0d arrays

Matthew Brett wrote: > Hi, > > As expected: > > In [67]:a = array([1], dtype=' > In [68]:a.astype('>i4').dtype > Out[68]:dtype('>i4') > > I was also expecting this to work for 0d arrays, but it doesn't: > > In [69]:a = array(1, dtype=' > In [70]:a.astype('>i4').dtype > Out[70]:dtype(' > The prob

Re: [Numpy-discussion] Segfault on byteswap() on recarrays

Matthew Brett wrote: > Hi, > > I noticed this works: > > In [5]:a = array((1,), dtype=[('one', ' > In [6]:a.byteswap() > Out[6]: > array((16777216,), > dtype=[('one', ' > But, extending the recarray leads to a segfault on byteswapping: > > In [8]:a = array((1, 2), dtype=[('one', ' > In [9]:a.

Re: [Numpy-discussion] ***[Possible UCE]*** Re: Fwd: Collection.findTransformation() never stops

Dr. Seth Olsen wrote: > > Hi MMTKers and NUMPYers, > > Bill's answer to my inquiry about the problem I'm having with > Collection.findTransformation() (and also, incidentally, with the > dgesvd call in Subspace.getBasis(), has convinced me that I can no > long use MMTK without changing some of t

Re: [Numpy-discussion] Fwd: Collection.findTransformation() never stops

Dr. Seth Olsen wrote: > > Hi Bill, > > MMTK has not made the conversion over to the new numpy module. It is > built against the old Numeric code, and the word from its developers > is that changing to numpy cannot be a priority now. > My suggestion is to *kindly* put pressure on them. I've spe

Re: [Numpy-discussion] Fwd: Collection.findTransformation() never stops

Dr. Seth Olsen wrote: > > Hi Travis, > > I would very happily accept the Scientific and MMTK patches. Thank > you very much for the offer. Look at http://www.scipy.org/Porting_to_NumPy for information (and patches) on how to convert ScientificPython and MMTK to use NumPy. I managed to get the

Re: [Numpy-discussion] Numpy fails to build with Python 2.5

William Grant wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > mg wrote: > >> Hi, >> >> I have the same problem with Python-2.5 and Python-2.6a with which i can >> not compile Numpy-1.0b5 and Numpy from svn. (I suppose your version of >> Scipy is based on one of these Numpy.) >> I

Re: [Numpy-discussion] what's the difference between npy_intp and size_t?

Martin Wiechert wrote: > Hi list, > > Please forgive my ignorance: Is there any difference between npy_intp and > size_t. Aren't both "ints just big enough to be safe with pointer arithmetics > even on 64 bit architectures?". > size_t is unsigned npy_intp is signed It is basically the same a

Re: [Numpy-discussion] [MMTK] Re: Fwd: Collection.findTransformation() never stops

Konrad Hinsen wrote: > On Sep 19, 2006, at 5:11, Dr. Seth Olsen wrote: > > >> Bill's answer to my inquiry about the problem I'm having with >> Collection.findTransformation() (and also, incidentally, with the >> dgesvd call in Subspace.getBasis(), has convinced me that I can no >> long use

Re: [Numpy-discussion] arr.dtype.kind is 'i' for dtype=unit !?

Sebastian Haase wrote: > Hi, > What are the possible values of > arr.dtype.kind ? > > It seems that signed and unsigned are considered to be the same "kind" > arr=N.arange(10,dtype=N.uint) arr.dtype.kind > 'i' > arr.dtype.itemsize > 8 > (OK - this

Re: [Numpy-discussion] Resolution of tickets.

Charles R Harris wrote: > Question, > > How does one mark a ticket as fixed? I don't see this field in the > ticket views I get, is there a list of accepted fixers? > You have to be logged in to the Trac site. If you have SVN write access you should be able to log in. Then there is a "resolutio

Re: [Numpy-discussion] sorting -inf, nan, inf

Tim Hochberg wrote: >A. M. Archibald wrote: > > >>On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: >> >> >> >> >>>I'm not sure where the breakpoint is, but I was seeing failures for all >>>three sort types with N as high as 1. I suspect that they're all >>>broken in the presence of

Re: [Numpy-discussion] arr.dtype.kind is 'i' for dtype=unit !?

Sebastian Haase wrote: >OK - I'm really sorry !! >I also get 'u' -- I had a typo there ... > >But what is the complete list of kind values ? > > It's in the array interface specification: http://numpy.scipy.org/array_interface.shtml -Travis --

Re: [Numpy-discussion] please change mean to use dtype=float

Sebastian Haase wrote: >Hello all, >I just had someone from my lab coming to my desk saying: >"My god - SciPy is really stupid >An array with only positive numbers claims to have a negative mean !! "? > > > >I was asking about this before ... the reason was of course that her array was >of

Re: [Numpy-discussion] Division by zero doesn't raise exception in the integer case.

Charles R Harris wrote: > Travis, > > Is this intentional? > > In [77]: arange(5, dtype=int)/0 > Out[77]: array([0, 0, 0, 0, 0]) > > It looks deliberate because all zeros are returned, but it might be > better if it raised an exception. It is deliberate. Numarray introduced it (the only diffe

Re: [Numpy-discussion] max argmax combo

Charles R Harris wrote: > > > On 9/18/06, *Bill Baxter* <[EMAIL PROTECTED] > > wrote: > > On 9/19/06, Charles R Harris <[EMAIL PROTECTED] > > wrote: > > On 9/18/06, Bill Baxter <[EMAIL PROTECTED] > > wro

Re: [Numpy-discussion] Division by zero doesn't raise exception in the integer case.

Charles R Harris wrote: > Travis, > > Is this intentional? > > In [77]: arange(5, dtype=int)/0 > Out[77]: array([0, 0, 0, 0, 0]) > > It looks deliberate because all zeros are returned, but it might be > better if it raised an exception. As mentioned before we translate integer division errors i

Re: [Numpy-discussion] please change mean to use dtype=float

Sebastian Haase wrote: >On Tuesday 19 September 2006 15:48, Travis Oliphant wrote: > > >>Sebastian Haase wrote: >> >> > > > >>>can we please change dtype to default to float64 !? >>> >>> >>The default is float64

Re: [Numpy-discussion] please change mean to use dtype=float

Charles R Harris wrote: > > Speed depends on the achitecture. Float is a trifle slower than double > on my Athlon64, but faster on PPC750. I don't know about other > machines. I think there is a good argument for accumlating in double > and converting to float for output if required. Yes there

Re: [Numpy-discussion] please change mean to use dtype=float

Sebastian Haase wrote: > I still would argue that getting a "good" (smaller rounding errors) answer > should be the default -- if speed is wanted, then *that* could be still > specified by explicitly using dtype=float32 (which would also be a possible > choice for int32 input) . > So you ar

Re: [Numpy-discussion] Possible inconsisteny in enumerated type mapping

Francesc Altet wrote: > Hi, > > I'm sending a message here because discussing about this in the bug tracker > is > not very comfortable. This my last try before giving up, so don't be > afraid ;-) > > In bug #283 (http://projects.scipy.org/scipy/numpy/ticket/283) I complained > about the fact

Re: [Numpy-discussion] ufunc.reduce and conversion

A. M. Archibald wrote: > Hi, > > What are the rules for datatype conversion in ufuncs? Does ufunc(a,b) > always yield the smallest type big enough to represent both a and b? > What is the datatype of ufunc.reduce(a)? > This is an unintended consequence of making add.reduce() reduce over at leas

Re: [Numpy-discussion] immutable arrays

Martin Wiechert wrote: > Hi list, > > I just stumbled accross NPY_WRITEABLE flag. > Now I'd like to know if there are ways either from Python or C to make an > array temporarily immutable. > Just setting the flag Python: make immutable: a.flags.writeable = False make mutable again: a

[Numpy-discussion] I've just tagged the tree for 1.0rc1

There is now a 1.0rc1 tag on the NumPy SVN tree. I've confirmed it builds and passes all tests on my Linux box for Python2.3-Python2.5 -Travis - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's T

Re: [Numpy-discussion] immutable arrays

Martin Wiechert wrote: > Thanks Travis. > > Do I understand correctly that the only way to be really safe is to make a > copy and not to export a reference to it? > Because anybody having a reference to the owner of the data can override the > flag? > No, that's not quite correct. Of course

Re: [Numpy-discussion] Tests and code documentation

Charles R Harris wrote: > Travis, > > A few questions. > > 1) I can't find any systematic code testing units, although there seem > to be tests for regressions and such. Is there a place we should be > putting such tests? All tests are placed under the tests directory of the corresponding sub-pa

Re: [Numpy-discussion] Question about recarray

Lionel Roubeyrie wrote: > Hi all, > Is it possible to put masked values into recarrays, I need a array with > heterogenous types of datas (datetime objects in the first col, all others > are float) but with missing values in some records. For the moment, I don't > find any solution for that. Ei

Re: [Numpy-discussion] arr.dtype.kind is 'i' for dtype=unit !?

Matthew Brett wrote: > Hi, > > >> It's in the array interface specification: >> >> http://numpy.scipy.org/array_interface.shtml >> > > I was interested in the 't' (bitfield) type - is there an example of > usage somewhere? > No, It's not implemented in NumPy. It's just part of the arra

Re: [Numpy-discussion] Question about recarray

Lionel Roubeyrie wrote: > find any solution for that. I have tried with arrays of dtype=object, but I > have problem when I want to compute min, max, ... with an error like: > TypeError: function not supported for these types, and can't coerce safely to > supported types. > I just added suppor

Re: [Numpy-discussion] please change mean to use dtype=float

David M. Cooke wrote: > >Conclusions: > >- If you're going to calculate everything in single precision, use Kahan >summation. Using it in double-precision also helps. >- If you can use a double-precision accumulator, it's much better than any of >the techniques in single-precision only. > >- for s

Re: [Numpy-discussion] take behaviour has changed

Christian Kristukat wrote: > Bill Baxter gmail.com> writes: > > >> Yep, check the release notes: >> http://www.scipy.org/ReleaseNotes/NumPy_1.0 >> search for 'take' on that page to find out what others have changed as well. >> --bb >> > > Ok. Does axis=None then mean, that take(a, ind) ope

Re: [Numpy-discussion] Putmask/take ?

Stefan van der Walt wrote: > On Fri, Sep 22, 2006 at 02:17:57AM -0500, Robert Kern wrote: > >>> According to the putmask docstring: >>> >>> a.putmask(values, mask) sets a.flat[n] = v[n] for each n where >>> mask.flat[n] is true. v can be scalar. >>> >>> This would mean that 'w' is not of

Re: [Numpy-discussion] Always using scientific notation to print

Brian Granger wrote: >>You can write a function that formats arrays how you like them and then tell >>ndarray to use it for __str__ or __repr__ using numpy.set_string_function(). >> >> > >That seems to be a little low level for most users. Would it be hard >to have the possibility of specifyi

Re: [Numpy-discussion] Putmask/take ?

Travis Oliphant wrote: >Yes, this does explain what you are seeing.It is the behavior of >Numeric's putmask (where this method came from). It does seem >counter-intuitive, and I'm not sure what to do with it. In some sense >putmask should behave the same as x[m] =

Re: [Numpy-discussion] Rationale for atleast_3d

Bill Baxter wrote: >26 weeks, 4 days, 2 hours and 9 minutes ago, Zdeněk Hurák asked why >atleast_3d acts the way it does: >http://article.gmane.org/gmane.comp.python.numeric.general/4382/match=atleast+3d > >He doesn't seem to have gotten any answers. And now I'm wondering the >same thing. Anyone

Re: [Numpy-discussion] take behaviour has changed

Christian Kristukat wrote: >>> Ok. Does axis=None then mean, that take(a, ind) operates on the >>> flattened array? >>> Yes, that is correct. > Sorry, I never really read about what are ufuncs. I thought those are class > methods of the ndarray objects... Anyway, I was refering to the follo

Re: [Numpy-discussion] dtype truth value

Matthew Brett wrote: > Hi, > > Forgive my ignorance, but why is this? > > In [1]:from numpy import * > > In [2]:if not dtype('...:print 'Truth value is no' >...: >...: > Truth value is no > Truth value of user-built Python objects is tested by looking at: 1) __nonzero__ method

Re: [Numpy-discussion] please restore the way dtype prints to original version

Christopher Hanley wrote: > Hi, > > Change set 3213 changed the data type printing with an array from > something like dtype=int64 to dtype='int64'. Although this is a small > cosmetic change it has broken all of the doctests I have written for > numpy code. I was changing the way dtypes print

Re: [Numpy-discussion] NumPy types --> Numeric typecodes map?

Francesc Altet wrote: >Hi, > >Anybody know if there is a map between NumPy types and Numeric >typecodes? Something like 'typecodes' for numarray: > > How about dtype(obj).char? -Travis - Take Surveys. Earn Cash. Influenc

Re: [Numpy-discussion] NumPy types --> Numeric typecodes map?

Francesc Altet wrote: >El dl 25 de 09 del 2006 a les 11:08 -0600, en/na Travis Oliphant va >escriure: > > >>Francesc Altet wrote: >> >> >> >>>Hi, >>> >>>Anybody know if there is a map between NumPy types and Numeric >>&

Re: [Numpy-discussion] typeDict vs sctypeDict

Francesc Altet wrote: >Hi, > >I've just noted this: > >In [12]: numpy.typeNA is numpy.sctypeNA >Out[12]: True > >In [13]: numpy.typeDict is numpy.sctypeDict >Out[13]: True > >Why these aliases? Ara sc* replacing its not-sc-prefix counterparts? >I'd like to know this so that I can avoid names that

Re: [Numpy-discussion] Default values in scalar constructors

Francesc Altet wrote: >Hi, > >Is there any reason why the next works for some types: > >In [26]: numpy.int32() >Out[26]: 0 > >In [27]: numpy.float64() >Out[27]: 0.0 > >but don't for the next others? > >In [28]: numpy.int16() >

Re: [Numpy-discussion] reload and f2py

Fernando Perez wrote: >On 9/26/06, George Nurser <[EMAIL PROTECTED]> wrote: > > >>I'm running Python 2.3.5 with recent SVN f2py. >> >>Suppose I import an extension I have built with f2py. Then, if I edit >>the fortran and recompile the extension, I cannot use reload to use >>the modified version

Re: [Numpy-discussion] More about data types in NumPy

Francesc Altet wrote: > Hello, > > Sorry for being insistent, but I recognize that I'm having a bad time > with NumPy data type rational. Is there an explanation for this?: > > numpy.dtype('i4').type > > numpy.dtype('int32').type > > numpy.dtype

Re: [Numpy-discussion] More about data types in NumPy

Francesc Altet wrote: > Hello, > > Sorry for being insistent, but I recognize that I'm having a bad time > with NumPy data type rational. Is there an explanation for this?: > > Your actually talking about the array scalar types not the data-type objects. But, more to the point numpy

Re: [Numpy-discussion] should I replace asarray with asanyarray in my code ?

Sebastian Haase wrote: > Hi, > This is a vaguely formulated question ... > When I work with memmap'ed files/arrays I have a derived class > that adds special attributes to the array class (referring to the MRC image > file format used in medical / microscopy imaging) > > What are the pros and con

[Numpy-discussion] Question answered incorrectly at NumPy Tutorial

During my NumPy Tutorial at the SciPy conference last month, somebody asked the question about the memory requirements of index arrays that I gave the wrong impression about. Here is the context and the correct response that should alleviate concerns about large cross-product index arrays. I

[Numpy-discussion] Release candidate 2.0 will come out mid-week next week

Hi all, I'd like to release numpy 1.0rc2 on about October 5 of next week. Then, the release of numpy 1.0 official should happen on Monday, October 17. Please try and get all fixes and improvements in before then. Backward-incompatible changes are not acceptable at this point (unless they

Re: [Numpy-discussion] how to compile numpy with visual-studio-2003?

mg wrote: > Hello, > > I just download the newly Python-2.5 and Numpy-1.0rc1 and all work fine > on Linux-x86 32 and 64bit platforms. > Now, I try to compile the both distributions on WindowsXP with > VisualStudio2003. No problem to compile Python-2.5, but i have some > troubles with Numpy-1.0rc

Re: [Numpy-discussion] storage order and concatenate

David Cournapeau wrote: > Hi, > > > What are the rules concerning storage with numpy ? The rule is that a numpy array has "strides" which specify how many bytes to skip to get to the next element in the array. That's the internal model. There are no hard and fast rules about storage order.

Re: [Numpy-discussion] 32/64-bit machines, integer arrays and python ints

Bill Spotz wrote: > I am wrapping code using swig and extending it to use numpy. > > One class method I wrap (let's call it myElements()) returns an array > of ints, and I convert it to a numpy array with > > PyArray_SimpleNew(1,n,'i'); > You should probably use NPY_INT instead of 'i' fo

Re: [Numpy-discussion] 32/64-bit machines, integer arrays and python ints

Bill Spotz wrote: >On Sep 28, 2006, at 12:03 PM, Travis Oliphant wrote: > > > >>The other option is to improve your converter in setElements so >>that it >>can understand any of the array scalar integers and not just the >>default >>Python integer.

Re: [Numpy-discussion] Non-writeable default for numpy.ndarray

Tim Hochberg wrote: > Francesc Altet wrote: > > It's not that the it's being built from ndarray, it's that the buffer > that you are passing it is read only. This is correct. > In fact, I'd argue that allowing > the writeable flag to be set to True in this case is actually a bug. > It's a

Re: [Numpy-discussion] Incorrect removal of NULL char in buffers

Francesc Altet wrote: > Hi, > > > However, for string values, numpy seems to work in a strange way. > The numarray have an expected behaviour, IMO: > > In [100]: numarray.strings.array(buffer="a\x00b"*4, itemsize=4, shape=3) > Out[100]: CharArray(['a', '', 'ba']) > > I'm not sure why you thin

Re: [Numpy-discussion] Non-writeable default for numpy.ndarray

Francesc Altet wrote: >I see. Thanks for the explanation. > > You deserve the thanks for the great testing of less-traveled corners of NumPy. It's exactly the kind of thing needed to get NumPy ready for release. -Travis ---

Re: [Numpy-discussion] return type diffences of indexed arrays with Intel C++ compiler (Python 2.5)

Lars Bittrich wrote: >Hi all, > >recently I tried to compile numpy/scipy with Python 2.5 and Intel C++ compiler >9.1. At first everything was fine, but the scipy test produced a few errors. >The reason was a little difference: > >numpy svn(1.0.dev3233) with Intel C compiler (Python 2.5): >--

Re: [Numpy-discussion] Vectorizing code, for loops, and all that

Albert Strasheim wrote: >In [571]: x1 = N.random.randn(2000,39) > >In [572]: y1 = N.random.randn(64,39) > >In [574]: %timeit z1=x1[...,N.newaxis,...]-y1 10 loops, best of 3: 703 ms >per loop > >In [575]: z1.shape >Out[575]: (2000, 64, 39) > >As far as I can figure, this operation is doing 2000*64*

Re: [Numpy-discussion] Vectorizing code, for loops, and all that

Travis Oliphant wrote: > >I suspect I know why, although the difference seems rather large. > [snip] >I'm surprised the overhead of adjusting pointers is so high, but then >again you are probably getting a lot of cache misses in the first case >so there is more to it t

Re: [Numpy-discussion] ***[Possible UCE]*** Re: Vectorizing code, for loops, and all that

Albert Strasheim wrote: >Hello all > > > >>-Original Message- >>From: [EMAIL PROTECTED] [mailto:numpy- >>[EMAIL PROTECTED] On Behalf Of Travis Oliphant >>Sent: 03 October 2006 02:32 >>To: Discussion of Numerical Python >>Subject: Re: [Nu

Re: [Numpy-discussion] Vectorizing code, for loops, and all that

Albert Strasheim wrote: >>> [1] 12.97% of function time >>> [2] 8.65% of functiont ime >>> [3] 62.14% of function time >>> >>> If statistics from elsewhere in the code would be helpful, let me >>> know, >>> >> and >> >>> I'll see if I can convince Quantify to cough it up. >>> >>>

[Numpy-discussion] RC2 to be released Friday

I'm going to have to put off release of rc2 for Friday. I'm just too busy right now. That might help us get some speed-ups into the NOBUFFER_UFUNCLOOP code as well. My speed-up ideas are: 1) Only keep track of 1 set of coordinates instead of self->nargs sets (1 for each iterator). 2) Keep t

Re: [Numpy-discussion] ValueError: object too deep for desired array

[EMAIL PROTECTED] wrote: >Microsoft Windows XP [Version 5.1.2600] >(C) Copyright 1985-2001 Microsoft Corp. > >C:\Documents and Settings\kenny>cd c:\lameness > >C:\lameness>c:\Python24\python.exe templatewindow.py >a = [[ 1.00013175e+00 2.63483019e-05 1.6740e+00 5.22246363e-05 >1.000

Re: [Numpy-discussion] Fastest way of distinguish a numpy scalar of a python scalar?

Sebastian Haase wrote: >Hi, >a noticed the underscore in "numpy.string_" ... >I thought the underscores were removed in favour of handling the >"from numpy import *" separately via the __all__ variable. >Is this done only for *some* members of numpy ? > > Yeah. The underscores are still on th

Re: [Numpy-discussion] Fastest way of distinguish a numpy scalar of a python scalar?

Tim Hochberg wrote: >Francesc Altet wrote: > > >>Hi, >> >>I thought that numpy.isscalar was a good way of distinguising a numpy scalar >>from a python scalar, but it seems not: >> >> >> >> >numpy.isscalar(numpy.string_('3')) > > > >>True >> >> >> >>

Re: [Numpy-discussion] Problems with Numexpr and discontiguous arrays

Tim Hochberg wrote: >David M. Cooke wrote: > > >>On Wed, 04 Oct 2006 10:19:08 -0700 >>Tim Hochberg <[EMAIL PROTECTED]> wrote: >> >> >> >> >>>Ivan Vilata i Balaguer wrote: >>> >>> >>> It seemed that discontiguous arrays worked OK in Numexpr since r1977 or so, but I have co

Re: [Numpy-discussion] Hello and my first patch

Greg Willden wrote: > Hello All, > I introduced myself on the Scipy list and I have a feeling that most > of the subscribers here are also on Scipy-devel. Anyway I just > submitted my first patch to numpy (ticket #316). I added the > blackman-harris, Nuttall and Flat Top windowing functions a

Re: [Numpy-discussion] Hello and my first patch

Sebastian Haase wrote: >If scipy is going to be installable as separate sub-packages maybe >all window functions can be moved to scipy ;-) > >In other words, if the ones in numpy are there only for "historical >reasons" maybe they should be cleaned out before the 1.0 release. >All arguments seem

Re: [Numpy-discussion] Vectorizing code, for loops, and all that

Travis Oliphant wrote: >Albert Strasheim wrote: > > >>>>[1] 12.97% of function time >>>>[2] 8.65% of functiont ime >>>>[3] 62.14% of function time >>>> >>>>If statistics from elsewhere in the code wo

Re: [Numpy-discussion] On loop and broadcasting (again)

David Cournapeau wrote: >Hi, > > The email from Albert made me look again on some surprising results I >got a few months ago when starting my first "serious" numpy project. I >noticed that when computing multivariate gaussian densities, centering >the data was more expensive than everything e

Re: [Numpy-discussion] Problems with Numexpr and discontiguous arrays

Tim Hochberg wrote: >>> >>> >>> >>That would be easy to do. Right now the opcodes should work correctly >>on data that is spaced in multiples of the itemsize on the last axis. >>Other arrays are copied (no opcode required, it's embedded at the top >>of interp_body lines 64-80). The reco

Re: [Numpy-discussion] Hello and my first patch

John Hunter wrote: >>"Robert" == Robert Kern <[EMAIL PROTECTED]> writes: >> >> > >Robert> IMO, I'd rather see this and similar functions go into >Robert> scipy. New functions that apply semantics to arrays (in >Robert> this case, treating them as time series), I

Re: [Numpy-discussion] flat indexing of object arrays

Martin Wiechert wrote: >Hi list, > >when I try to assign a sequence as an element of an object array via flat >indexing only the first element of the sequence is assigned: > > > import numpy numpy.version.version >'1.0rc1.dev3171' > > from numpy import * a =

Re: [Numpy-discussion] Hello and my first patch

A. M. Archibald wrote: >On 05/10/06, Greg Willden <[EMAIL PROTECTED]> wrote: > > >>On 10/5/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: >> >> >>>Perhaps that is the best way to move forward along with the work on a >>>"pyl

Re: [Numpy-discussion] flat indexing of object arrays

Matthew Brett wrote: >Hi, > >On 10/5/06, Martin Wiechert <[EMAIL PROTECTED]> wrote: > > >>Hi list, >> >>when I try to assign a sequence as an element of an object array via flat >>indexing only the first element of the sequence is assigned: >> >> > >I've also been having trouble with flat on

Re: [Numpy-discussion] Memory errors

Vikalpa Jetly wrote: >I am reading a very large array (~9000,11000) of 1 byte image values. I need >to change values in the array that meet a certain condition so I am running >something like: > >b = numpy.where(a>200,0,1) > >to create a new array with the changed values. However, I get a >"Memory

Re: [Numpy-discussion] repmat

Bill Baxter wrote: >[There seem to have been some gmail delivery problems that prevented >my previous mail on this subject from being delivered] > >I've proposed that we fix repmat handle arbitrary dimensions before 1.0. > > http://projects.scipy.org/scipy/numpy/ticket/292 > >I don't think this

Re: [Numpy-discussion] ***[Possible UCE]*** user-defined type example

Matt Knox wrote: > Could someone please point me to/provide me with a basic example of > creating a user defined type? > > Here is my completely naive attempt which obviously doesn't work... > > import numpy > > class myType(numpy.void): > def __init__(self,val): > self.val = val >

Re: [Numpy-discussion] tensor product

Charles R Harris wrote: > Hmmm, > > I notice that there is no longer a tensor product. As it was the only > one of the outer, kron bunch that I really wanted, l miss it. In fact, > I always thought outer should act like the tensor product for the > other binary operators too. Anyway, mind if I p

Re: [Numpy-discussion] tensor product

Charles R Harris wrote: > > > On 10/9/06, *Tim Hochberg* <[EMAIL PROTECTED] > > wrote: > > > > Is this not the same things as numpy.multiply.outer(a, b)? (as > opposed > to outer(a, b), which appears to pretend that everything is a > vector -- > I

[Numpy-discussion] Numpy rc2 is out

Release Candidate 2.0 is now out. Thanks to all the great testing and fixes that were done between 1.0rc1 and 1.0rc2 The release date for NumPy 1.0 is Oct. 17. There will be a freeze on the trunk starting Monday Oct. 16 so any changes should be in by then. If significant changes are made t

Re: [Numpy-discussion] suggestions for slices of matrices

JJ wrote: > Hello. > I haven't been following development too closely > lately, but I did just download and reinstall the > current svn version. For what its worth, I would like > to again suggest two changes: > Suggestions are nice. Working code is better. Many ideas are just too difficult

Re: [Numpy-discussion] 1.0rc2: imag attribute of numpy.float64 causes segfault

Peter Bienstman wrote: > This is on an AMD64 platform: > > Python 2.4.3 (#1, Sep 27 2006, 14:14:48) > [GCC 4.1.1 (Gentoo 4.1.1)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > import numpy print numpy.__version__ > 1.0rc2 > a

Re: [Numpy-discussion] Constructing an array from memory address

Daniel Drake wrote: >Hi, > >I have an area of memory which is shared between processes (it is >actually a shared memory segment). The address of this memory is stored >in a python long variable, which I pass to various custom C/C++ python >modules. > >I would like to construct a numpy array in thi

Re: [Numpy-discussion] asmatrix and asarray exception

Keith Goodman wrote: >On 10/11/06, Keith Goodman <[EMAIL PROTECTED]> wrote: > > >>This works: >> >> >> M.asmatrix(['a', 'b', None]) >>matrix([[a, b, None]], dtype=object) >> >>But this doesn't: >> >> >> M.asmatrix(['a', 'b', None, 'c']) >>TypeE

Re: [Numpy-discussion] Compile with atlas 3.7.17 fails

Hanno Klemm wrote: >Hi, > >I don't know if this is a bug or just me doing something wrong (I >suspect the latter). I try to compile numpy-1.0rc1 with python2.5 and >atlas 3.7.17. > >I have build the atlas library myself, it doesn't give any errors >under make test or make pttest, so it seems to b

Re: [Numpy-discussion] asmatrix and asarray exception

Charles R Harris wrote: > > > On 10/11/06, *Keith Goodman* <[EMAIL PROTECTED] > > wrote: > > On 10/11/06, Keith Goodman <[EMAIL PROTECTED] > > wrote: > > This works: > > > > >> M.asmatrix(['a', 'b', None]) > > matrix([[a,

Re: [Numpy-discussion] cannot import Numeric

Carl Wenrich wrote: > thanks, but actually it's the other applications i want to use that > have the 'import Numeric' line in them. i'm sure others have noted > this before. what's the normal procedure? You must install Numeric if a package needs Numeric. As far as Python is concerned NumPy

[Numpy-discussion] Things to address for Py3K

Hi all, Py3K is undergoing active development. This gives us an opportunity to discuss more significant changes to the language that might improve the experience of NumPy users. We should form a list and start commenting on the py3k mailing lists about what changes would be most helpful fo

Re: [Numpy-discussion] Things to address for Py3K

Christopher Barker wrote: >Travis Oliphant wrote: > > >>A couple on my short list >> >>1) Adding a *few* new infix operators. >> >> a) an extra multiplication operator to distinguish between >>element-by-element and dot >> b) extending

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[EMAIL PROTECTED] wrote: >Hi, > >I have recieved the following note from a user: > >""" >In SciPy 0.3.x the ufuncs were overloaded by more "intelligent" versions. >A very attractive feature was that sqrt(-1) would yield 1j as in Matlab. >Then you can program formulas directly (e.g., roots of a 2nd

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

Sven Schreiber wrote: >>This is user adjustable. You change the error mode to raise on >>'invalid' instead of pass silently which is now the default. >> >>-Travis >> >> >> > >Could you please explain how this adjustment is done, or point to the >relevant documentation. > > numpy.sqrt(-1)

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

Fernando Perez wrote: >On 10/11/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > > >>[EMAIL PROTECTED] wrote: >> >> >>>Could sqrt(-1) made to return 1j again? >>> >>> >>> >>Not in NumPy. But, in scipy

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

Stefan van der Walt wrote: >I agree with Fernando on this one. > >Further, if I understand correctly, changing sqrt and power to give >the right answer by default will slow things down somewhat. But is it >worth sacrificing intuitive usage for speed? > > For NumPy, yes. This is one reason tha

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[EMAIL PROTECTED] wrote: > >On Wed, 11 Oct 2006, Travis Oliphant wrote: > > > >>On the other hand requiring all calls to numpy.sqrt to go through an >>"argument-checking" wrapper is a bad idea as it will slow down other uses. >> >&g

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

Tim Hochberg wrote: >With python 2.5 out now, perhaps it's time to come up with a with >statement context manager. Something like: > >from __future__ import with_statement >import numpy > >class errstate(object): >def __init__(self, **kwargs): >self.kwargs = kwargs

Re: [Numpy-discussion] incrementing along a diagonal

David Novakovic wrote: > Hi, > > i'm moving some old perl PDL code to python. I've come across a line > which changes values in a diagonal line accross a matrix. > > matrix.diagonal() returns a list of values, but making changes to these > does not reflect in the original (naturally). > > I'm just

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

Greg Willden wrote: > On 10/11/06, *Travis Oliphant* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Stefan van der Walt wrote: > >Further, if I understand correctly, changing sqrt and power to give > >the right answer by default

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

David Goldsmith wrote: > Travis Oliphant wrote: > >> [EMAIL PROTECTED] wrote: >> >> >> >>> Could sqrt(-1) made to return 1j again? >>> >>> >>> >> Not in NumPy. But, in scipy it could. >>

  1   2   3   4   5   6   >