To use quaternions I find I often need conversion to/from matrices and to/from
Euler angles. Will you add that functionality? Will you handle the left
versor and right versor versions?
I have a set of pure python code I've sketched out for my needs (aerospace) but
would be happy to have an in
Hi Travis, hi Olivier,
Thanks for your replies last month about the choose() issue.
I did some further investigation into this. I ran out of time in that
project to come up with a patch, but here's what I found, which may be of
interest:
The compile-time constant NPY_MAXARGS is indeed limiting c
On Wed, Jul 27, 2011 at 05:25:20PM -0600, Charles R Harris wrote:
>Well, doc tests are just a losing proposition, no one should be using them
>for writing tests. It's not like this is a new discovery, doc tests have
>been known to be unstable for years.
Untested documentation is broken
On Wed, Jul 27, 2011 at 4:07 PM, Gael Varoquaux <
gael.varoqu...@normalesup.org> wrote:
> On Wed, Jul 27, 2011 at 04:59:17PM -0500, Mark Wiebe wrote:
> >but ultimately NumPy needs the ability to change its repr and other
> >details like it in order to progress as a software project.
>
> Yo
On Wed, Jul 27, 2011 at 5:47 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Jul 27, 2011 at 3:23 PM, Mark Wiebe wrote:
> > On Wed, Jul 27, 2011 at 5:07 PM, Gael Varoquaux
> > wrote:
> >>
> >> On Wed, Jul 27, 2011 at 04:59:17PM -0500, Mark Wiebe wrote:
> >> >but ultimately NumPy needs the ability
Thanks, Mark! Problem solved.
Johann
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
On Wed, Jul 27, 2011 at 3:40 PM, Mark Wiebe wrote:
> On Wed, Jul 27, 2011 at 5:35 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> I was trying to compile matplotlib against current trunk, and hit an
>> error with this line:
>>
>> char* row0 = PyArray_BYTES(matrix);
>>
>>
>> https://git
Hi,
On Wed, Jul 27, 2011 at 3:23 PM, Mark Wiebe wrote:
> On Wed, Jul 27, 2011 at 5:07 PM, Gael Varoquaux
> wrote:
>>
>> On Wed, Jul 27, 2011 at 04:59:17PM -0500, Mark Wiebe wrote:
>> > but ultimately NumPy needs the ability to change its repr and other
>> > details like it in order to prog
On Wed, Jul 27, 2011 at 5:35 PM, Matthew Brett wrote:
> Hi,
>
> I was trying to compile matplotlib against current trunk, and hit an
> error with this line:
>
>char* row0 = PyArray_BYTES(matrix);
>
>
> https://github.com/matplotlib/matplotlib/blob/master/src/agg_py_transforms.cpp
>
> T
Hi,
I was trying to compile matplotlib against current trunk, and hit an
error with this line:
char* row0 = PyArray_BYTES(matrix);
https://github.com/matplotlib/matplotlib/blob/master/src/agg_py_transforms.cpp
The error is:
src/agg_py_transforms.cpp:30:26: error: invalid conversion
Probably the easiest way is to emulate what Python is doing in M[i,:] and
M[:,i]. You can create the : with PySlice_New(NULL, NULL, NULL), and the i
with PyInt_FromLong. Then create a tuple with Py_BuildValue and use
PyObject_GetItem to do the slicing.
It is possible to do the same thing directly
On Wed, Jul 27, 2011 at 5:07 PM, Gael Varoquaux <
gael.varoqu...@normalesup.org> wrote:
> On Wed, Jul 27, 2011 at 04:59:17PM -0500, Mark Wiebe wrote:
> >but ultimately NumPy needs the ability to change its repr and other
> >details like it in order to progress as a software project.
>
> Yo
On Wed, Jul 27, 2011 at 04:59:17PM -0500, Mark Wiebe wrote:
>but ultimately NumPy needs the ability to change its repr and other
>details like it in order to progress as a software project.
You have to understand that numpy is the core layer on which people have
build pretty huge scientifi
On Wed, Jul 27, 2011 at 4:32 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Jul 27, 2011 at 1:12 PM, Mark Wiebe wrote:
> > On Wed, Jul 27, 2011 at 3:09 PM, Robert Kern
> wrote:
> >>
> >> On Wed, Jul 27, 2011 at 14:47, Mark Wiebe wrote:
> >> > On Wed, Jul 27, 2011 at 2:44 PM, Matthew Brett <
> matth
On Wed, Jul 27, 2011 at 5:36 PM, Alex Flint wrote:
> When applying two different slicing operations in succession (e.g. select a
> sub-range, then select using a binary mask) it seems that numpy arrays can
> be inconsistent with respect to assignment:
> For example, in this case an array is modifi
On Wed, Jul 27, 2011 at 3:09 PM, Robert Kern wrote:
> On Wed, Jul 27, 2011 at 14:47, Mark Wiebe wrote:
> > On Wed, Jul 27, 2011 at 2:44 PM, Matthew Brett
> > wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Jul 27, 2011 at 12:25 PM, Mark Wiebe wrote:
> >> > On Wed, Jul 27, 2011 at 1:01 PM, Matthew Brett
Dear experts,
is there a C-API function for numpy which implements Python's
multidimensional indexing? Say, I have a 2d-array
PyArrayObject * M;
and an index
int i;
how do I extract the i-th row or column M[i,:] respectively M[:,i]?
I am looking for a function which gives again a PyArr
When applying two different slicing operations in succession (e.g. select a
sub-range, then select using a binary mask) it seems that numpy arrays can
be inconsistent with respect to assignment:
For example, in this case an array is modified:
In [6]: *A = np.arange(5)*
In [8]: *A[:][A>2] = 0*
In [
Hi,
On Wed, Jul 27, 2011 at 1:12 PM, Mark Wiebe wrote:
> On Wed, Jul 27, 2011 at 3:09 PM, Robert Kern wrote:
>>
>> On Wed, Jul 27, 2011 at 14:47, Mark Wiebe wrote:
>> > On Wed, Jul 27, 2011 at 2:44 PM, Matthew Brett
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Wed, Jul 27, 2011 at 12:25 PM, Mark
> Please don't distribute a different numpy binary for each version of
> MacOS X.
+1
Maybe I should mention that I just finished testing all Python
packages in EPD under 10.7, and everything (execpt numpy.sqr
for weird complex values such as inf/nan) works fine!
In particular building C an
On 7/27/11 12:35 PM, Ralf Gommers wrote:
> Please don't distribute a different numpy binary for each version of
> MacOS X.
+1 !
> If 10.6-built binaries are going to work without problems on 10.7 - also
> for scipy - then two versions is enough. I'm not yet confident this will
> be the ca
On Wed, Jul 27, 2011 at 3:09 PM, Robert Kern wrote:
> On Wed, Jul 27, 2011 at 14:47, Mark Wiebe wrote:
> > On Wed, Jul 27, 2011 at 2:44 PM, Matthew Brett
> > wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Jul 27, 2011 at 12:25 PM, Mark Wiebe wrote:
> >> > On Wed, Jul 27, 2011 at 1:01 PM, Matthew Brett
On Wed, Jul 27, 2011 at 14:47, Mark Wiebe wrote:
> On Wed, Jul 27, 2011 at 2:44 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Wed, Jul 27, 2011 at 12:25 PM, Mark Wiebe wrote:
>> > On Wed, Jul 27, 2011 at 1:01 PM, Matthew Brett
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Wed, Jul 27, 2011 at 6:54
On Wed, Jul 27, 2011 at 2:44 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Jul 27, 2011 at 12:25 PM, Mark Wiebe wrote:
> > On Wed, Jul 27, 2011 at 1:01 PM, Matthew Brett
> > wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Jul 27, 2011 at 6:54 PM, Mark Wiebe wrote:
> >> > This was the most consistent way to
Hi,
On Wed, Jul 27, 2011 at 12:25 PM, Mark Wiebe wrote:
> On Wed, Jul 27, 2011 at 1:01 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Wed, Jul 27, 2011 at 6:54 PM, Mark Wiebe wrote:
>> > This was the most consistent way to deal with the parameterized dtype in
>> > the
>> > repr, making it more f
On Wed, Jul 27, 2011 at 9:00 PM, Russell E. Owen wrote:
> In article
> ,
> Ralf Gommers wrote:
>
> > On Wed, Jul 27, 2011 at 7:17 PM, Ilan Schnell >wrote:
> >
> > > MacOS Lion:
> > > >>> numpy.sqrt([complex(numpy.nan, numpy.inf)])
> > > array([ nan+infj])
> > >
> > > Other all system:
> > > ar
On Wed, Jul 27, 2011 at 2:20 PM, Charles R Harris wrote:
>
>
> On Wed, Jul 27, 2011 at 6:58 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Wed, Jul 27, 2011 at 2:49 AM, Mark Dickinson > > wrote:
>>
>>> In NumPy 1.6.0, I get the following behaviour:
>>>
>>>
>>> Python 2.7
On Wed, Jul 27, 2011 at 1:01 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Jul 27, 2011 at 6:54 PM, Mark Wiebe wrote:
> > This was the most consistent way to deal with the parameterized dtype in
> the
> > repr, making it more future-proof at the same time. It was producing
> reprs
> > like "array(['
On Wed, Jul 27, 2011 at 6:58 AM, Charles R Harris wrote:
>
>
> On Wed, Jul 27, 2011 at 2:49 AM, Mark Dickinson
> wrote:
>
>> In NumPy 1.6.0, I get the following behaviour:
>>
>>
>> Python 2.7.2 |EPD 7.1-1 (32-bit)| (default, Jul 3 2011, 15:40:35)
>> [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
In article
,
Ralf Gommers wrote:
> On Wed, Jul 27, 2011 at 7:17 PM, Ilan Schnell wrote:
>
> > MacOS Lion:
> > >>> numpy.sqrt([complex(numpy.nan, numpy.inf)])
> > array([ nan+infj])
> >
> > Other all system:
> > array([ inf+infj])
> >
> > This causes a few numpy tests to fail on Lion. The nump
On Wed, Jul 27, 2011 at 8:18 PM, Ilan Schnell wrote:
> Thanks for you quick response Ralf. Regarding binaries, we are
> trying to avoid to different EPD binaries for different versions of OSX,
> as maintaining/distributing/testing more binaries is quite expensive.
>
> Agreed, it can be expensive.
Thanks for you quick response Ralf. Regarding binaries, we are
trying to avoid to different EPD binaries for different versions of OSX,
as maintaining/distributing/testing more binaries is quite expensive.
- Ilan
On Wed, Jul 27, 2011 at 12:58 PM, Ralf Gommers
wrote:
>
>
> On Wed, Jul 27, 2011
Hi,
On Wed, Jul 27, 2011 at 6:54 PM, Mark Wiebe wrote:
> This was the most consistent way to deal with the parameterized dtype in the
> repr, making it more future-proof at the same time. It was producing reprs
> like "array(['2011-01-01'], dtype=datetime64[D])", which is clearly wrong,
> and put
On Wed, Jul 27, 2011 at 7:17 PM, Ilan Schnell wrote:
> MacOS Lion:
> >>> numpy.sqrt([complex(numpy.nan, numpy.inf)])
> array([ nan+infj])
>
> Other all system:
> array([ inf+infj])
>
> This causes a few numpy tests to fail on Lion. The numpy
> was not compiled using the new LLVM based gcc, it is
This was the most consistent way to deal with the parameterized dtype in the
repr, making it more future-proof at the same time. It was producing reprs
like "array(['2011-01-01'], dtype=datetime64[D])", which is clearly wrong,
and putting quotes around it makes it work in general for all possible
d
Hi,
I see that (current trunk):
In [9]: np.ones((1,), dtype=bool)
Out[9]: array([ True], dtype='bool')
- whereas (1.5.1):
In [2]: np.ones((1,), dtype=bool)
Out[2]: array([ True], dtype=bool)
That is breaking quite a few doctests. What is the reason for the
change? Something to do with more
MacOS Lion:
>>> numpy.sqrt([complex(numpy.nan, numpy.inf)])
array([ nan+infj])
Other all system:
array([ inf+infj])
This causes a few numpy tests to fail on Lion. The numpy
was not compiled using the new LLVM based gcc, it is the
same numpy binary I used on other MacOS systems, which
was compile
Looks good. It might be good to change it back to (void *) for the
PyArray_DATA inline function as well, I changed that during lots of tweaking
to get things to build properly.
-Mark
On Wed, Jul 27, 2011 at 11:46 AM, Michael Droettboom wrote:
> The return type of PyArray_BYTES in the old API com
The return type of PyArray_BYTES in the old API compatibility code seems
to have changed recently to (void *) which breaks matplotlib builds.
This pull request changes it back. Is this correct?
https://github.com/numpy/numpy/pull/121
Mike
___
NumPy-
On Wed, Jul 27, 2011 at 2:49 AM, Mark Dickinson wrote:
> In NumPy 1.6.0, I get the following behaviour:
>
>
> Python 2.7.2 |EPD 7.1-1 (32-bit)| (default, Jul 3 2011, 15:40:35)
> [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
> Type "packages", "demo" or "enthought" for more information.
> >>> impo
In NumPy 1.6.0, I get the following behaviour:
Python 2.7.2 |EPD 7.1-1 (32-bit)| (default, Jul 3 2011, 15:40:35)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "packages", "demo" or "enthought" for more information.
>>> import numpy
>>> numpy.nanmin(numpy.ma.masked_array([1,2,3,4]))
Tracebac
41 matches
Mail list logo