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

Robert Kern wrote: > Sebastian Haase wrote: >> I know that having too much knowledge of the details often makes one >> forget what the "newcomers" will do and expect. > > Please be more careful with such accusations. Repeated frequently, they can > become quite insulting. > I did not mean to in

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

On 9/19/06, Charles R Harris <[EMAIL PROTECTED]> wrote: On 9/19/06, Charles R Harris < [EMAIL PROTECTED]> wrote: On 9/19/06, Sebastian Haase < [EMAIL PROTECTED]> wrote: Travis Oliphant wrote:> Sebastian Haase wrote:>> I still would argue that getting a "good" (smaller rounding errors) answer>> sho

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

Sebastian Haase wrote: > I know that having too much knowledge of the details often makes one > forget what the "newcomers" will do and expect. Please be more careful with such accusations. Repeated frequently, they can become quite insulting. > We are only talking > about people that will a)

[Numpy-discussion] ufunc.reduce and conversion

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)? I ask because I was startled by the following behaviour: >>> a = array([1,1],uint8); print a.dtype; print maximum

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

On 9/19/06, Charles R Harris <[EMAIL PROTECTED]> wrote: On 9/19/06, Sebastian Haase < [EMAIL PROTECTED]> wrote: Travis Oliphant wrote:> 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* coul

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

Charles R Harris wrote: > > > On 9/19/06, *Sebastian Haase* <[EMAIL PROTECTED] > > wrote: > > Travis Oliphant wrote: > > Sebastian Haase wrote: > >> I still would argue that getting a "good" (smaller rounding > errors) answer > >> should be the d

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

On 9/20/06, Charles R Harris <[EMAIL PROTECTED]> wrote: > > I guess I'm not really aware of the float96 type ... > > Is that a "machine type" on any system ? I always thought that -- e.g . > > coming from C -- double is "as good as it gets"... > > Who uses float96 ? I heard somewhere that (some)

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

On 9/19/06, Sebastian Haase <[EMAIL PROTECTED]> wrote: Travis Oliphant wrote:> 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

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

Travis Oliphant wrote: > 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 i

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

On 9/19/06, A. M. Archibald <[EMAIL PROTECTED]> wrote: On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:> I'm still somewhat mystified by the desire to move the nans to one end> of the sorted object. I see two scenarios: It's mostly to have something to do with them other than throw anexception.

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] 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] sorting -inf, nan, inf

On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > I'm still somewhat mystified by the desire to move the nans to one end > of the sorted object. I see two scenarios: It's mostly to have something to do with them other than throw an exception. Leaving them in place while the rest of the array

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

Charles R Harris wrote: > > > On 9/19/06, *A. M. Archibald* <[EMAIL PROTECTED] > > wrote: > > On 19/09/06, Charles R Harris <[EMAIL PROTECTED] > > wrote: > > > > > > > > For floats we could use something like: > > >

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

On 9/19/06, A. M. Archibald <[EMAIL PROTECTED]> wrote: On 19/09/06, Charles R Harris <[EMAIL PROTECTED]> wrote: For floats we could use something like:>> lessthan(a,b) := a < b || (a == nan && b != nan) >> Which would put all the nans at one end and might not add too much overhead.You could put

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

On Tuesday 19 September 2006 17:17, Travis Oliphant wrote: > 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 now (as long as you are n

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

On 19/09/06, Charles R Harris <[EMAIL PROTECTED]> wrote: > > > > For floats we could use something like: > > lessthan(a,b) := a < b || (a == nan && b != nan) > > Which would put all the nans at one end and might not add too much overhead. You could put an any(isnan()) out front and run this slower

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

On 9/19/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: 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 now (as long as you are not using>>numpy.old

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

Sebastian Haase wrote: > (don't know how to say this for complex types !? Are here real and imag > treated separately / independently ?) Yes. For mean(), there's really no alternative. Scalar variance is not a well-defined concept for complex numbers, but treating the real and imaginary parts s

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 now (as long as you are not using >>numpy.oldnumeric). >> >>I suppose mo

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

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 now (as long as you are not using > numpy.oldnumeric). > > I suppose more appropriately, we could reduce over float for integer > da

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] 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. It is deliberate. Numarray introduced it (the only diffe

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

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.Chuck - Take Surveys. Earn Cash. Inf

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

On Tuesday 19 September 2006 20:37, Travis Oliphant wrote: > 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?". >

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

On 9/19/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: Travis Oliphant wrote:> 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 w

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] 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 --

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

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 dtype int32 and had many large value

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

OK - I'm really sorry !! I also get 'u' -- I had a typo there ... But what is the complete list of kind values ? -Sebastian On Tuesday 19 September 2006 11:54, Scott Ransom wrote: > > > Can anybody on a 64-bit system confirm? > > > > I'm on 64-bit Debian: > > > > In [11]: arr=N.arange(10,dtype

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

Travis Oliphant wrote: > 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 a

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

On 9/19/06, A. M. Archibald <[EMAIL PROTECTED]> wrote: On 19/09/06, Charles R Harris <[EMAIL PROTECTED]> wrote:> If this sort of thing can cause unexpected errors I wonder if it would be> worth it to have a global debugging flag that essentially causes  isnan to > be called before any function appl

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Straw wrote: > William Grant wrote: > >> Hi, >> >> I'm currently attempting to get scipy 0.5.1 into Ubuntu, however it >> currently cannot happen as numpy doesn't build with Python 2.5. I note >> that changeset 3109 >> (http://projects.scipy.or

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] Numpy fails to build with Python 2.5

William Grant wrote: >Hi, > >I'm currently attempting to get scipy 0.5.1 into Ubuntu, however it >currently cannot happen as numpy doesn't build with Python 2.5. I note >that changeset 3109 >(http://projects.scipy.org/scipy/numpy/changeset/3109#file1) is meant to >give 2.5 compatibility, but it is

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

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 NaNs. I further suspect you'd need s

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

A. M. Archibald wrote: > On 19/09/06, Charles R Harris <[EMAIL PROTECTED]> wrote: > > >> If this sort of thing can cause unexpected errors I wonder if it would be >> worth it to have a global debugging flag that essentially causes isnan to >> be called before any function applications. >>

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

On 19/09/06, Charles R Harris <[EMAIL PROTECTED]> wrote: > If this sort of thing can cause unexpected errors I wonder if it would be > worth it to have a global debugging flag that essentially causes isnan to > be called before any function applications. That sounds very like the IEEE floating-p

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

On 9/19/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: Charles R Harris wrote:>>> On 9/19/06, *Tim Hochberg* <[EMAIL PROTECTED]> [EMAIL PROTECTED] >> wrote:>> A. M. Archibald wrote:> > On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:> >> >> Keith Goodman wr

Re: [Numpy-discussion] Resolution of tickets.

Matthew Brett wrote: > Hi, > >>> 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 "resolution" section at >>> the very bottom. >> Ah, that works. I orignally tried to register and discovered that charris >> was already tak

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

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 NaNs. I further suspect you'd need some > punishingly slow n**2 algori

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

On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > A. M. Archibald wrote: > > Mmm. Somebody who's working with NaNs has more or less already decided > > they don't want to be pestered with exceptions for invalid data. > Do you really think so? In my experience NaNs are nearly always just an > i

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

Charles R Harris wrote: > > > On 9/19/06, *Tim Hochberg* <[EMAIL PROTECTED] > > wrote: > > A. M. Archibald wrote: > > On 19/09/06, Tim Hochberg <[EMAIL PROTECTED] > > wrote: > > > >> Keith Goodman wrote: > >> > >>> In

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

On 9/19/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: A. M. Archibald wrote:> On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:>>> Keith Goodman wrote:> In what order would you like argsort to sort the values -inf, nan, inf? Ideally, -inf should sort first, inf should sort last and na

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

A. M. Archibald wrote: > On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > >> Keith Goodman wrote: >> >>> In what order would you like argsort to sort the values -inf, nan, inf? >>> >>> >> Ideally, -inf should sort first, inf should sort last and nan should >> raise an exception

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

On 9/19/06, Keith Goodman <[EMAIL PROTECTED]> wrote: > Is there an easy way to use isnan to pull out the nans if the matrix I > am sorting has more than one column? > There seems to be a "nan_to_num" function that converts nans to zeros, but I would suggest just using fancy indexing to fill the nan

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

On 9/19/06, A. M. Archibald <[EMAIL PROTECTED]> wrote: > On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > > Keith Goodman wrote: > > > In what order would you like argsort to sort the values -inf, nan, inf? > > > > > Ideally, -inf should sort first, inf should sort last and nan should > > rai

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

On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > Keith Goodman wrote: > > In what order would you like argsort to sort the values -inf, nan, inf? > > > Ideally, -inf should sort first, inf should sort last and nan should > raise an exception if present. > > -tim Mmm. Somebody who's working w

Re: [Numpy-discussion] max argmax combo

On 9/19/06, Bill Baxter <[EMAIL PROTECTED]> wrote: On 9/20/06, Francesc Altet <[EMAIL PROTECTED]> wrote:> A Dimarts 19 Setembre 2006 19:21, Charles R Harris va escriure:> >> > Do you want both the indexes and index sorted array returned, or just sort > > the array using indexes, i.e., something lik

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

On 9/19/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > Ideally, -inf should sort first, inf should sort last and nan should > raise an exception if present. I disagree. NumPy sort leaving nan's where they are is probably just a side-effect of nans unusual properties (both nanx is always false), but

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

On 9/19/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: Keith Goodman wrote:> In what order would you like argsort to sort the values -inf, nan, inf?>Ideally, -inf should sort first, inf should sort last and nan shouldraise an exception if present. -timThat sounds right. Nan can't be compared because,

Re: [Numpy-discussion] max argmax combo

On 9/20/06, Francesc Altet <[EMAIL PROTECTED]> wrote: > A Dimarts 19 Setembre 2006 19:21, Charles R Harris va escriure: > > > > Do you want both the indexes and index sorted array returned, or just sort > > the array using indexes, i.e., something like > > > > a.sort(kind="quicksort", method="indir

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

Keith Goodman wrote: > In what order would you like argsort to sort the values -inf, nan, inf? > Ideally, -inf should sort first, inf should sort last and nan should raise an exception if present. -tim > In numpy 1.0b1 nan is always left where it began: > > EXAMPLE 1 > > >>> x >>>

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

In what order would you like argsort to sort the values -inf, nan, inf? In numpy 1.0b1 nan is always left where it began: EXAMPLE 1 >> x matrix([[ inf], [ -inf], [ nan]]) >> x[x.argsort(0),:] matrix([[ -inf], [

Re: [Numpy-discussion] Resolution of tickets.

Hi, > > 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 "resolution" section at > > the very bottom. > > Ah, that works. I orignally tried to register and discovered that charris > was already taken and I didn't know what

Re: [Numpy-discussion] Resolution of tickets.

On 9/19/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: 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

Re: [Numpy-discussion] 1.0b5 Installation on OS X

In article <[EMAIL PROTECTED]>, Christopher Barker <[EMAIL PROTECTED]> wrote: > David Andrews wrote: > > > I'm unable to install the 1.0b5 release from the .mpkg on OS X - when > > it comes to the two checkboxes to select the platlib and the scripts, > > both are greyed out. The installer then

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

> > Can anybody on a 64-bit system confirm? > > I'm on 64-bit Debian: > > In [11]: arr=N.arange(10,dtype=N.uint) > > In [12]: arr.dtype.kind > Out[12]: 'u' > > In [13]: arr.dtype.itemsize > Out[13]: 4 > > In [14]: arr=N.arange(10,dtype=N.long) > > In [15]: arr.dtype.kind > Out[15]: 'i' > > In [16]:

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

On Tuesday 19 September 2006 14:46, Travis Oliphant wrote: > 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 > >

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] 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] [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] max argmax combo

On 9/19/06, Francesc Altet <[EMAIL PROTECTED]> wrote: A Dimarts 19 Setembre 2006 19:21, Charles R Harris va escriure:> On 9/19/06, Francesc Altet <[EMAIL PROTECTED]> wrote:> > A Dimarts 19 Setembre 2006 07:18, Charles R Harris va escriure: > > > I note that argsort also produces indexes that are ha

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] 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] 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? Indeed there is. charris is on that list. charris208 is not. Forget your password? :-) Talk to me offlist about which username y

Re: [Numpy-discussion] max argmax combo

A Dimarts 19 Setembre 2006 19:21, Charles R Harris va escriure: > On 9/19/06, Francesc Altet <[EMAIL PROTECTED]> wrote: > > A Dimarts 19 Setembre 2006 07:18, Charles R Harris va escriure: > > > I note that argsort also produces indexes that are hard to use in the > > > ndim>1 case. > > > > Perhaps

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

Hello all > -Original Message- > From: [EMAIL PROTECTED] [mailto:numpy- > [EMAIL PROTECTED] On Behalf Of Sebastian Haase > Sent: 19 September 2006 19:24 > To: Discussion of Numerical Python > Subject: [Numpy-discussion] arr.dtype.kind is 'i' for dtype=unit !? > > Hi, > What are the possib

[Numpy-discussion] Resolution of tickets.

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?Chuck - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel

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

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 is just showing off our amd64 linux ;-) ) How can I distinguish signed from un

Re: [Numpy-discussion] max argmax combo

On 9/19/06, Francesc Altet <[EMAIL PROTECTED]> wrote: A Dimarts 19 Setembre 2006 07:18, Charles R Harris va escriure:> I note that argsort also produces indexes that are hard to use in the> ndim>1 case.Perhaps it is worth to mention here that I've always liked to have a sort() and argsort() functio

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

Konrad Hinsen wrote: > MMTK works fine with Numeric 23.x (and probably many other versions), > so I don't see a pressing need to change to NumPy. Pressing is in the eye of the beholder. However: I don't think we should underestimate the negative impact of the Numeric/numarray split on the usab

Re: [Numpy-discussion] max argmax combo

A Dimarts 19 Setembre 2006 07:18, Charles R Harris va escriure: > I note that argsort also produces indexes that are hard to use in the > ndim>1 case. Perhaps it is worth to mention here that I've always liked to have a sort() and argsort() functionality merged in one shot function (or method). H

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

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 MMTK without changing some of th

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

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?". Thanks, Martin. - Take Survey

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

Seth, this problem is most likely related to LAPACK's SLAMCH and DLAMCH routines. If these routines get translated with f2c the compiler can optimize things away and create infinite loops. This functions get called when you start using singular and eigenvalue routines. It's because Fortran 77 did

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

On 9/19/06, William Grant <[EMAIL PROTECTED]> wrote: > 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 posted my problem yes

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

-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 posted my problem yesterday. The answe

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

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 posted my problem yesterday. The answer from Travis was it will be corrected in Numpy-1.0rc1 which will co

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

Hi, I'm currently attempting to get scipy 0.5.1 into Ubuntu, however it currently cannot happen as numpy doesn't build with Python 2.5. I note that changeset 3109 (http://projects.scipy.org/scipy/numpy/changeset/3109#file1) is meant to give 2.5 compatibility, but it is those bits which seem to bre

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

mg wrote: > I forget a last question, > > We currently advise a High Performance Platform for our customers > (Opteron cluster) where our applications are linked with GOTO blas library. > > I found in the Numpy distribution the file site.cfg, used to specify the > BLAS to used at the link time. (

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

I forget a last question, We currently advise a High Performance Platform for our customers (Opteron cluster) where our applications are linked with GOTO blas library. I found in the Numpy distribution the file site.cfg, used to specify the BLAS to used at the link time. (It could be an interes

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

Hi Travis, First, thanks for your answer. I just download the source of Numpy from the SVN and recompile the package from Python-2.5 and 2.6a (from svn)... and it still crashes. So I do not investigate the compilation on Windows. So, may I have to wait the release 1.0rc0 of Numpy? About the m

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] Fwd: Collection.findTransformation() never stops

Hi Travis,I would very happily accept the Scientific and MMTK patches.  Thank you very much for the offer.I hadn't thought much about it until very recently, when the advent of a new IT structure in our laboratory forced me to upgrade my existing software.  It was then that it became obvious that t