I'd like to tag the tree and make a NumPy 1.0.4 release tomorrow. Is
there anything that needs to be done before that can happen?
I'd also like to get another release of SciPy out the door as soon as
possible. At the end of this week or early next week.
I've added a bunch of 1-d classic
Thanks for your hint! My numpy version is 1.0.2. compiled by myself a
bit ago. I have however not fully understood your reply. Is the issue,
that caused problems in your code in the numpy svn version resolved now?
I read something in the thread about forcefully unloading certain
DLLs, I am on a
Hello all
Consider the following example:
In [43]: x = N.zeros((3,2))
In [44]: x.flags
Out[44]:
C_CONTIGUOUS : True
F_CONTIGUOUS : False
OWNDATA : True
WRITEABLE : True
ALIGNED : True
UPDATEIFCOPY : False
In [45]: x[:,[1,0]].flags
Out[45]:
C_CONTIGUOUS : False
F_CONTIGUOUS :
On 23/05/07, Albert Strasheim [EMAIL PROTECTED] wrote:
Consider the following example:
First a comment: almost nobody needs to care how the data is stored
internally. Try to avoid looking at the flags unless you're
interfacing with a C library. The nice feature of numpy is that it
hides all
Hello all
On Wed, 23 May 2007, Anne Archibald wrote:
On 23/05/07, Albert Strasheim [EMAIL PROTECTED] wrote:
Consider the following example:
First a comment: almost nobody needs to care how the data is stored
internally. Try to avoid looking at the flags unless you're
interfacing with a
On Wed, May 23, 2007 at 09:49:08AM -0400, Anne Archibald wrote:
On 23/05/07, Albert Strasheim [EMAIL PROTECTED] wrote:
Is it correct that the F_CONTIGUOUS flag is set in the case of the fancy
indexed x? I'm running NumPy 1.0.3.dev3792 here.
Numpy arrays are always stored in contiguous
On 23/05/07, Albert Strasheim [EMAIL PROTECTED] wrote:
If you are correct that this is in fact a fresh new array, I really
don't understand where the values of these flags. To recap:
In [19]: x = N.zeros((3,2))
In [20]: x.flags
Out[20]:
C_CONTIGUOUS : True
F_CONTIGUOUS : False
On 5/23/07, Albert Strasheim [EMAIL PROTECTED] wrote:
Hello all
On Wed, 23 May 2007, Anne Archibald wrote:
On 23/05/07, Albert Strasheim [EMAIL PROTECTED] wrote:
Consider the following example:
First a comment: almost nobody needs to care how the data is stored
internally. Try to avoid
dmitrey wrote:
hi all,
I was very surprised that norm() is present in scipy.linalg but absent
in numpy.
Don't you think it's better to add the one to numpy?
In [237]: import numpy
In [238]: numpy.linalg.norm?
Type: function
Base Class: type 'function'
Namespace:
Ok, then appropriate changes in
http://www.scipy.org/NumPy_for_Matlab_Users should be made
D.
Robert Kern wrote:
dmitrey wrote:
hi all,
I was very surprised that norm() is present in scipy.linalg but absent
in numpy.
Don't you think it's better to add the one to numpy?
In
dmitrey wrote:
Ok, then appropriate changes in
http://www.scipy.org/NumPy_for_Matlab_Users should be made
Go for it.
--
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
On 5/23/07, Robert Kern [EMAIL PROTECTED] wrote:
dmitrey wrote:
hi all,
I was very surprised that norm() is present in scipy.linalg but absent
in numpy.
Don't you think it's better to add the one to numpy?
In [237]: import numpy
In [238]: numpy.linalg.norm?
Type: function
Base
Hi Robert and list,
My colleague said that it certainly looks like a missing thread library.
It looks like the problem is that lapack_lite was compiled
multi-threaded and can't find the thread library.
Any solution to that?
BTW, I tried 1.0.2 and got the same error.
Thanks,
Shawn
Albert Strasheim wrote:
Hello all
Consider the following example:
In [43]: x = N.zeros((3,2))
In [44]: x.flags
Out[44]:
C_CONTIGUOUS : True
F_CONTIGUOUS : False
OWNDATA : True
WRITEABLE : True
ALIGNED : True
UPDATEIFCOPY : False
In [45]: x[:,[1,0]].flags
Out[45]:
Hi all-
The types of objects are not preserved through mathematical operations
when numpy scalars are involved. This has been discussed on this list
before. I think the following error is problematic, however.
x=N.array(0.1)
type(x)
type 'numpy.ndarray'
y = N.cos(x)
# the type has changed
Erin Sheldon wrote:
y=x.copy()
N.cos(x,y)
but wouldn't it be better to just preserve the type through functions
like cos? Or does this cause repercussions in other places?
This causes repercussions in other places. This can be re-visited for
1.1, but for now, all ufuncs that
Robert Kern wrote:
Go for it.
I'm sorry, I don't know how to edit the page and I guess I haven't
enough permissions.
D.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
dmitrey wrote:
Robert Kern wrote:
Go for it.
I'm sorry, I don't know how to edit the page and I guess I haven't
enough permissions.
Create an account here:
http://www.scipy.org/UserPreferences
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless enigma
Ok, I have made the changes.
Robert Kern wrote:
dmitrey wrote:
Robert Kern wrote:
Go for it.
I'm sorry, I don't know how to edit the page and I guess I haven't
enough permissions.
Create an account here:
http://www.scipy.org/UserPreferences
Hanno Klemm wrote:
Hi,
I want to use freeze.py on code that heavily relies on numpy. If I
just try
python2.5 /scratch/src/Python-2.5/Tools/freeze/freeze.py pylay.py
I've seen people use NumPy with programs like freeze before. You have
to take into account that multiarray is a compiled
I'm pleased to announce the release of NumPy 1.0.3
Hopefully, this release will work better with multiple interpreters as
well as having some significant bugs fixed.
Other changes include
* x/y follows Python standard on mixed-sign division
* iinfo added to provide information on integer
Bumped into the following in numpy-1.0.2 and 1.0.3 (of course :-) on
both 32-bit and 64-bit linux boxes:
import numpy as nm
a=nm.zeros(100,dtype='Int32')-3
nm.median(a)
-3.0
a=nm.zeros(100,dtype='Int16')-3
nm.median(a)
Warning: overflow encountered in short_scalars
2768.0
22 matches
Mail list logo
