On Mon, Nov 24, 2008 at 12:46 AM, Jarrod Millman <[EMAIL PROTECTED]>wrote:
> On Sun, Nov 23, 2008 at 11:41 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > I'd like to do a 1.1.2 release for the Python 2.3 user(s) to get out some
> > fixes for Python 2.3 that went in after the last release. I
2008/11/21 Sébastien Barthélemy <[EMAIL PROTECTED]>:
> In this spirit, in numpy a set of rotation matrices could be built in
> the following way:
>
> def rotx(theta):
>"""
>SE(3) matrices corresponding to a rotation around x-axis. Theta is
> a 1-d array
>"""
>costheta = np.cos(theta
Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for
the NumPy 1.3.0:
http://projects.scipy.org/scipy/numpy/milestone/1.3.0
The original plan was to release 1.3 at the end of November. At this
point, we are going to have to push back the release date a bit. I
would like to get
Jarrod Millman wrote:
> Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for
> the NumPy 1.3.0:
> http://projects.scipy.org/scipy/numpy/milestone/1.3.0
>
>
For completeness, we were wondering with Jarrod if the main focus of
1.3 could be python 2.6 compatibility (plus what is
A Monday 24 November 2008, David Cournapeau escrigué:
> Jarrod Millman wrote:
> > Now that scipy 0.7.0b1 has been tagged, I wanted to start planning
> > for the NumPy 1.3.0:
> > http://projects.scipy.org/scipy/numpy/milestone/1.3.0
>
> For completeness, we were wondering with Jarrod if the main fo
Hello,
While using the PIL interface to numpy, I rediscovered a logic error in
the PIL.Image.fromarray() procedure. The problem (and a solution) was
mentioned earlier at:
*
http://projects.scipy.org/pipermail/numpy-discussion/2006-December/024903.html
There does not seem to be a formal
Well, talking about support to 2.6:
When using explicit outputs for some functions (eg, ma.max,
ma.min...), a value that should be masked is transformed into np.nan
when the explicit output is not a ma.MaskedArray. That worked great in
2.5, with np.nan automatically transformed when the expl
On Mon, Nov 24, 2008 at 4:34 AM, Jarrod Millman <[EMAIL PROTECTED]>wrote:
> Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for
> the NumPy 1.3.0:
> http://projects.scipy.org/scipy/numpy/milestone/1.3.0
>
> The original plan was to release 1.3 at the end of November. At this
>
I am currently working on the Ironclad project porting numpy to Ironpython.
It would be quite useful for me if HermitianTestCase in test_linalg.py
was a new style-class instead of an old-style class - since Ironpython
has a bug where dir operations do not work for classes inheriting from
both o
>> def rotx(theta):
>>"""
>>SE(3) matrices corresponding to a rotation around x-axis. Theta is
>> a 1-d array
>>"""
>>costheta = np.cos(theta)
>>sintheta = np.sin(theta)
>>H = np.zeros((theta.size,4,4))
>>H[:,0,0] = 1
>>H[:,3,3] = 1
>>H[:,1,1] = costheta
>>H[
Jim Vickroy wrote:
> Hello,
>
> While using the PIL interface to numpy, I rediscovered a logic error
> in the PIL.Image.fromarray() procedure. The problem (and a solution)
> was mentioned earlier at:
>
> *
> http://projects.scipy.org/pipermail/numpy-discussion/2006-December/024903.html
>
>
Tom Wright wrote:
> I am currently working on the Ironclad project porting numpy to Ironpython.
>
> It would be quite useful for me if HermitianTestCase in test_linalg.py
> was a new style-class instead of an old-style class - since Ironpython
> has a bug where dir operations do not work for clas
Hello,
Using numpy 1.2.1 on a mac os 10.5
I admit the user was sort of stretching the limits but (on his machine)
import numpy
a=numpy.ones((16800,60,96),'f')
numpy.sort(a,axis=0)
works
import numpy.ma
a=numpy.ma.sort((16800,60,96),'f')
numpy.ma.sort(a,axis=0)
failed with some malloc error:
i mistyped the second line of the sample failing script
it should obviously read:
a=numpy.ma.ones((16800,60,96),'f')
not numpy.ma.sort((16800,60,96),'f')
C.
On Nov 24, 2008, at 8:40 AM, Charles سمير Doutriaux wrote:
> Hello,
>
> Using numpy 1.2.1 on a mac os 10.5
>
>
> I admit the user was sort
Travis E. Oliphant wrote:
Jim Vickroy wrote:
Hello,
While using the PIL interface to numpy, I rediscovered a logic error
in the PIL.Image.fromarray() procedure. The problem (and a solution)
was mentioned earlier at:
*
http://projects.scipy.org/pipermail/numpy-discussion/2006-Decemb
On Mon, Nov 24, 2008 at 11:26, Jim Vickroy <[EMAIL PROTECTED]> wrote:
> Travis E. Oliphant wrote:
>
> Jim Vickroy wrote:
>
>
> Hello,
>
> While using the PIL interface to numpy, I rediscovered a logic error
> in the PIL.Image.fromarray() procedure. The problem (and a solution)
> was mentioned earl
Robert Kern wrote:
On Mon, Nov 24, 2008 at 11:26, Jim Vickroy <[EMAIL PROTECTED]> wrote:
Travis E. Oliphant wrote:
Jim Vickroy wrote:
Hello,
While using the PIL interface to numpy, I rediscovered a logic error
in the PIL.Image.fromarray() procedure. The problem (and a solution)
was menti
David Cournapeau wrote:
> Windows 64 is a PITA,
...
> I don:t see much hope to see more than a simple numpy built with
> lapack-lite. This could be useful for people who use numpy for
> matplotlib, for example; not sure if it worths the trouble.
I think there is a great deal of use for it beyond s
Robert Kern wrote:
>> Jim Vickroy wrote:
>> While using the PIL interface to numpy, I rediscovered a logic error
>> in the PIL.Image.fromarray() procedure. The problem (and a solution)
>> was mentioned earlier at:
> Tell them that we approve of the change. We don't have commit access
> to PIL, so
A Monday 24 November 2008, Jarrod Millman escrigué:
> Now that scipy 0.7.0b1 has been tagged, I wanted to start planning
> for the NumPy 1.3.0:
> http://projects.scipy.org/scipy/numpy/milestone/1.3.0
>
> The original plan was to release 1.3 at the end of November. At this
> point, we are going to
Hi,
After dealing with another issue, I realized that the names of inverse
trigonometrical/hyperbolic functions in NumPy don't follow the main
standards in computer science. For example, where Python writes:
asin, acos, atan, asinh, acosh, atanh
NumPy choose:
arcsin, arccos, arctan, arcsinh,
Robert Kern wrote:
> matrix objects are a bit weird. Most operations on them always return
> a 2D matrix, even if the same operation on a regular ndarray would
> return a 1D array.
Whatever happened to the proposals to improve this? I think there were
some good ideas floated.
-Chris
--
Chris
Francesc Alted wrote:
> Hi,
>
> After dealing with another issue, I realized that the names of inverse
> trigonometrical/hyperbolic functions in NumPy don't follow the main
> standards in computer science. For example, where Python writes:
>
> asin, acos, atan, asinh, acosh, atanh
>
> NumPy c
On Mon, Nov 24, 2008 at 07:45:56PM +0100, Francesc Alted wrote:
> Hi,
>
> After dealing with another issue, I realized that the names of inverse
> trigonometrical/hyperbolic functions in NumPy don't follow the main
> standards in computer science. For example, where Python writes:
>
> asin, ac
Charles,
Confirmed on my machine...
I gonna have to clean ma.sort, as there are indeed some temporaries
that probably don't need to be created. I must warn you however that I
won;t have a lot of time to spend on that in the next few days. In any
case, of course, I'll keep you posted.
Thx for
Francesc Alted wrote:
> So, IMHO, I think it would be better to rename the inverse trigonometric
> functions from ``arc*`` to ``a*`` prefix. Of course, in order to do
> that correctly, one should add the new names and add a
> ``DeprecationWarning`` informing that people should start to use the
Eric Firing wrote:
> Francesc Alted wrote:
>
>> So, IMHO, I think it would be better to rename the inverse trigonometric
>> functions from ``arc*`` to ``a*`` prefix.
>
> +1
> I have stumbled over this myself. If there is resistance to removing
-1
There is resistance. Please don't remove the o
On Mon, Nov 24, 2008 at 14:00, Jon Wright <[EMAIL PROTECTED]> wrote:
> I have the feeling the only times I ever write to this list is to say
> "please don't change the API". So, here I am again, "please don't change
> the API". This is a cosmetic change whose only effect seems to be to
> have every
> There is resistance. Please don't remove the old names. Also note that
> your proposed change will alter people's code in subtle, but potentially
> very "interesting" ways:
>
> >>> from math import *
> >>> from numpy import *
> >>> type(arcsin(1)) is type(asin(1))
> False
> >>> from numpy impo
On Mon, Nov 24, 2008 at 09:00:48PM +0100, Jon Wright wrote:
> There is resistance. Please don't remove the old names. Also note that
> your proposed change will alter people's code in subtle, but potentially
> very "interesting" ways:
> >>> from math import *
> >>> from numpy import *
> >>> type
On 24-Nov-08, at 4:22 PM, Gabriel Gellner wrote:
>> asin(1j) raises an exception, arcsin doesn't. They are *different*
>> functions, hence the names.
>>
> Yet:
>
type(np.sin(1)) == type(math.sin(1))
> False
In fact, this goes for every single function listed in the math
module's docs, exc
On Mon, Nov 24, 2008 at 3:00 PM, David Warde-Farley <[EMAIL PROTECTED]>wrote:
>
> On 24-Nov-08, at 4:22 PM, Gabriel Gellner wrote:
>
> >> asin(1j) raises an exception, arcsin doesn't. They are *different*
> >> functions, hence the names.
> >>
> > Yet:
> >
> type(np.sin(1)) == type(math.sin(1)
On Mon, Nov 24, 2008 at 10:45 AM, Francesc Alted <[EMAIL PROTECTED]> wrote:
> So, IMHO, I think it would be better to rename the inverse trigonometric
> functions from ``arc*`` to ``a*`` prefix. Of course, in order to do
> that correctly, one should add the new names and add a
> ``DeprecationWarni
On Mon, Nov 24, 2008 at 3:55 PM, Jarrod Millman <[EMAIL PROTECTED]>wrote:
> On Mon, Nov 24, 2008 at 10:45 AM, Francesc Alted <[EMAIL PROTECTED]>
> wrote:
> > So, IMHO, I think it would be better to rename the inverse trigonometric
> > functions from ``arc*`` to ``a*`` prefix. Of course, in order
I agree with Jon here. I can see plenty of motivation for adding the
names asin, etc., but there really isn't a need to remove the current
versions, and it will just introduce compatibility issues when someone
tries to run code written with NumPy 1.x using a NumPy 2.x
installation for even the simp
On Mon, Nov 24, 2008 at 4:09 PM, Charles R Harris <[EMAIL PROTECTED]
> wrote:
>
>
> On Mon, Nov 24, 2008 at 3:55 PM, Jarrod Millman <[EMAIL PROTECTED]>wrote:
>
>> On Mon, Nov 24, 2008 at 10:45 AM, Francesc Alted <[EMAIL PROTECTED]>
>> wrote:
>> > So, IMHO, I think it would be better to rename the
Hi,
I think this change could be confusing.
numpy.asum numpy.arange numpy.amax etc all have the intended meaning
of 'a-for-array-version-of-function'. This obviously isn't the case
for 'acos'. Explaining the difference could be painful.
Best,
Matthew
_
On Mon, Nov 24, 2008 at 17:13, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Maybe we could push all the changes off to a Numpy release compatible with
> Python 3.0. Folks will expect a certain amount of hassle when making that
> switch.
Guido, et al., have specifically asked that projects not do
Matthew Brett wrote:
> numpy.asum numpy.arange numpy.amax etc all have the intended meaning
> of 'a-for-array-version-of-function'. This obviously isn't the case
> for 'acos'.
actually, it is, isn't it? a version of math.cos that works for arrays?
But anyway, if we had it to do all over again,
On Mon, Nov 24, 2008 at 18:40, Chris Barker <[EMAIL PROTECTED]> wrote:
> Matthew Brett wrote:
>> numpy.asum numpy.arange numpy.amax etc all have the intended meaning
>> of 'a-for-array-version-of-function'. This obviously isn't the case
>> for 'acos'.
>
> actually, it is, isn't it? a version of m
Robert Kern wrote:
> On Mon, Nov 24, 2008 at 18:40, Chris Barker <[EMAIL PROTECTED]> wrote:
>> actually, it is, isn't it? a version of math.cos that works for arrays?
>
> No. Not at all. acos() and arccos() are the inverse functions of cos().
argg!! total brain freeze there. Can I pretend I never
On Mon, Nov 24, 2008 at 19:29, Christopher Barker <[EMAIL PROTECTED]> wrote:
> Robert Kern wrote:
>> On Mon, Nov 24, 2008 at 18:40, Chris Barker <[EMAIL PROTECTED]> wrote:
>>> actually, it is, isn't it? a version of math.cos that works for arrays?
>>
>> No. Not at all. acos() and arccos() are the i
Hi,
Following the discussion on python 2.6 support for numpy, I tried last
svn on mac os X, and I get a number of failures which I don't
understand, which seem to be linked to dtype code, more exactly to
endianness:
==
FAIL: tes
On Mon, Nov 24, 2008 at 8:18 PM, David Cournapeau <[EMAIL PROTECTED]>wrote:
> Hi,
>
> Following the discussion on python 2.6 support for numpy, I tried last
> svn on mac os X, and I get a number of failures which I don't
> understand, which seem to be linked to dtype code, more exactly to
> endian
Announcing CorePy 1.0 - http://www.corepy.org
We are pleased to announce the latest release of CorePy. CorePy is a
complete system for developing machine-level programs in Python.
CorePy lets developers build and execute assembly-level programs
interactively from the Python command prompt, embed
On Tue, Nov 25, 2008 at 12:41 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> 1) This problem is specific to 2.6 and 2.5 works.
Yes
> 2) It's on Intel hardware?
Yes.
Here is a minimal test which shows the problem:
import numpy as np
assert np.dtype('http://projects.scipy.org/mailman/listi
On Mon, Nov 24, 2008 at 9:02 PM, David Cournapeau <[EMAIL PROTECTED]>wrote:
> On Tue, Nov 25, 2008 at 12:41 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
>
> > 1) This problem is specific to 2.6 and 2.5 works.
>
> Yes
>
> > 2) It's on Intel hardware?
>
> Yes.
>
> Here is a minimal test whi
On Mon, Nov 24, 2008 at 9:38 PM, Charles R Harris <[EMAIL PROTECTED]
> wrote:
>
>
> On Mon, Nov 24, 2008 at 9:02 PM, David Cournapeau <[EMAIL PROTECTED]>wrote:
>
>> On Tue, Nov 25, 2008 at 12:41 PM, Charles R Harris
>> <[EMAIL PROTECTED]> wrote:
>> >
>>
>> > 1) This problem is specific to 2.6 and
On Mon, Nov 24, 2008 at 9:58 PM, Charles R Harris <[EMAIL PROTECTED]
> wrote:
>
>
> On Mon, Nov 24, 2008 at 9:38 PM, Charles R Harris <
> [EMAIL PROTECTED]> wrote:
>
>>
>>
>> On Mon, Nov 24, 2008 at 9:02 PM, David Cournapeau <[EMAIL PROTECTED]>wrote:
>>
>>> On Tue, Nov 25, 2008 at 12:41 PM, Charle
Chris,
Wow, this is fantastic...both the BSD license and the x86 support. I
look forward to playing with this!
Cheers,
Brian
On Mon, Nov 24, 2008 at 7:49 PM, Chris Mueller <[EMAIL PROTECTED]> wrote:
> Announcing CorePy 1.0 - http://www.corepy.org
>
> We are pleased to announce the latest relea
On Mon, 2008-11-24 at 21:38 -0700, Charles R Harris wrote:
>
>
> On Mon, Nov 24, 2008 at 9:02 PM, David Cournapeau <[EMAIL PROTECTED]>
> wrote:
> On Tue, Nov 25, 2008 at 12:41 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
>
> > 1) This problem is s
On Mon, 2008-11-24 at 22:06 -0700, Charles R Harris wrote:
>
>
> Well, it may not be that easy to figure. The (generated)
> pyconfig-32.h has
>
> /* Define to 1 if your processor stores words with the most
> significant byte
> first (like Motorola and SPARC, unlike Intel and VAX).
52 matches
Mail list logo
