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

On 19.09.2006, at 18:48, Christopher Barker wrote: > 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. Obviously. It also depends on the context in which o

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

On 19.09.2006, at 20:42, Travis Oliphant wrote: > Well, I got both ScientificPython and MMTK to compile and import > using > the steps outlined on http://www.scipy.org/Porting_to_NumPy in > about 1 > hour (including time to fix alter_code1 to make the process even > easier). Could you ple

[Numpy-discussion] Possible inconsisteny in enumerated type mapping

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 that a numpy.int32 is being mapped in N

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

Sebastian Haase wrote: > 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 insulti

Re: [Numpy-discussion] max argmax combo

A Dimarts 19 Setembre 2006 21:41, Bill Baxter va escriure: > I think he meant do an argsort first, then use fancy indexing to get > the sorted array. > For a 1-d array that's just > > ind = A.argsort() > Asorted = A[ind] > > That should be O(N lg N + N), aka O(N lg N) I see. Thanks. OTOH, may

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

On Sep 19, 2006, at 9:45 PM, Tim Hochberg wrote: > Perhaps there's some use for the sort to end behaviour that I'm > missing, > but the raise an exception behaviour sure looks a lot more > appealing to me. FYI, in IDL the NaN values wind up at the end of the sorted array. That's true despi

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

IMHO, the only correct way to handle this case is to raise an exception. It does not make sense to compare NaN and "real" numbers. It could be very confusing not to raise an exception. Xavier. > On 19/09/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > >> A. M. Archibald wrote: >> >>> Mmm. S

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

A Dimecres 20 Setembre 2006 12:48, Travis Oliphant va escriure: > Making sure you get the correct data-type is why there are NPY_INT32 and > NPY_INT64 enumerated types. You can't code using NPY_LONG and expect > it will give you the same sizes when moving from 32-bit and 64-bit > platforms. Tha

[Numpy-discussion] immutable arrays

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. Thanks, Martin. - Take Surveys. Earn Cash. Influence the Future of

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

Robert Kern wrote: >> This was not supposed to be a scientific statement -- I'm (again) >> thinking of our students that not always appreciate the full >> complexity >> of computational numerics and data types and such. > > They need to appreciate the complexity of computational numerics if

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

Robert Kern wrote: > Sebastian Haase wrote: > >> 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 acc

[Numpy-discussion] ANN: Job postings -- Enthought, Inc.

Hey group, We are growing again and have multiple positions open here at Enthought. I'd love to recruit more people out of the Scipy/numpy community. I think many of you would find the work interesting. You can look at our career page for more info: http://www.enthought.com/careers.htm

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

On Wed, Sep 20, 2006 at 03:01:18AM -0500, Robert Kern wrote: > Let me offer a third path: the algorithms used for .mean() and .var() are > substandard. There are much better incremental algorithms that entirely avoid > the need to accumulate such large (and therefore precision-losing) > intermed

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

Sebastian Haase wrote: > The best I can hope for is a "sound" default for most (practical) cases... > I still think that 80bit vs. 128bit vs 96bit is rather academic for most > people ... most people seem to only use float64 and then there are some > that use float32 (like us) ... I fully agree

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

On 9/20/06, David M. Cooke <[EMAIL PROTECTED]> wrote: On Wed, Sep 20, 2006 at 03:01:18AM -0500, Robert Kern wrote:> Let me offer a third path: the algorithms used for .mean() and .var() are> substandard. There are much better incremental algorithms that entirely avoid > the need to accumulate such

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

David M. Cooke wrote: > On Wed, Sep 20, 2006 at 03:01:18AM -0500, Robert Kern wrote: >> Let me offer a third path: the algorithms used for .mean() and .var() are >> substandard. There are much better incremental algorithms that entirely >> avoid >> the need to accumulate such large (and therefor

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

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

Robert Kern wrote: > David M. Cooke wrote: > >> On Wed, Sep 20, 2006 at 03:01:18AM -0500, Robert Kern wrote: >> >>> Let me offer a third path: the algorithms used for .mean() and .var() are >>> substandard. There are much better incremental algorithms that entirely >>> avoid >>> the need

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

[Sorry, this version should have less munged formatting since I clipped the comments. Oh, and the Kahan sum algorithm was grabbed from wikipedia, not mathworld] Tim Hochberg wrote: > Robert Kern wrote: > >> David M. Cooke wrote: >> >> >>> On Wed, Sep 20, 2006 at 03:01:18AM -0500, Robe

[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] please change mean to use dtype=float

Robert Kern wrote: > David M. Cooke wrote: > >> On Wed, Sep 20, 2006 at 03:01:18AM -0500, Robert Kern wrote: >> >>> Let me offer a third path: the algorithms used for .mean() and .var() are >>> substandard. There are much better incremental algorithms that entirely >>> avoid >>> the need

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

I don't see a windows binary. Will this be added? Mathew Travis Oliphant wrote: > 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 > > > ---

[Numpy-discussion] If you don't want to receive $5000 per month then don't open that letter

Please read this letter attentively! Financial company is in search of representatives in the US. - Age: from 18 till 60 years - Have a skill to communicate and access to the Internet. - You can speak english language above average - You need to know how to use excel and word. You will earn fr

Re: [Numpy-discussion] If you don't want to receive $5000 per month then don't open that letter

I like the salutation of the letter below: "Please read this letter attentively!" Why does so much spam make it through the sourceforge filters? Or maybe they only let through the very good deals. "You will earn from 1500 up to 3000 USD per week, working only some hours per day." On Wed, 20 Sep

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

Travis Oliphant wrote: >> In [77]: arange(5, dtype=int)/0 >> Out[77]: array([0, 0, 0, 0, 0]) > It is deliberate. Numarray introduced it (the only difference being > that by default NumPy has division-by-zero erros turned off). It's tied > to the way floating-point division-by zero is handled.

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

Charles R Harris wrote: > Thinking a bit, keeping the values in place isn't easy. Why the heck would "in place" be desirable for sorted data anyway? I understand that it means that if there is a NaN in the nth position before sorting, there will be one in the nth position after sorting. However

[Numpy-discussion] change of default dtype

I noticed that the default dtype for the "ones" and "zeros" functions is now float, whereas it used to be int. Should this be noted at http://www.scipy.org/ReleaseNotes/NumPy_1.0 since it does break code (if you are using the array you creating with ones or zeros as indices into another array).--

Re: [Numpy-discussion] change of default dtype

I think that's supposed to be covered by this line: "The default array data-type is now float64 (c double precision) instead of c integer." But yeh, I agree. It's definitely not obvious what that means in terms of concrete API changes. --bb On 9/21/06, David Grant <[EMAIL PROTECTED]> wrote: > I

Re: [Numpy-discussion] change of default dtype

It is a wiki, and contributions are absolutely welcome, so please go ahead and change it to be more clear. Bill Baxter wrote: >I think that's supposed to be covered by this line: >"The default array data-type is now float64 (c double precision) >instead of c integer." > >But yeh, I agree. It's d

[Numpy-discussion] nan adds lots of whitespace

NaN adds a lot of whitespace in the representation of a matrix. Without NaN: matrix([[1, 2], [3, 4]]) With NaN: matrix([[ nan,2.], [ 3.,4.]]) There's enough room for the wikipedia entry for nan. ---

Re: [Numpy-discussion] change of default dtype

Hey Andrew, point taken, but I think it would be better if someone who actually knows the full extent of the change made the edit. I know zeros and ones changed. Did anything else? Anyway, I'm surprised the release notes page is publicly editable. --bb On 9/21/06, Andrew Straw <[EMAIL PROTECTE