On Wed, Oct 21, 2009 at 22:32, Mathieu Blondel wrote:
> On Thu, Oct 22, 2009 at 11:31 AM, Sturla Molden wrote:
>> Mathieu Blondel skrev:
>>> Hello,
>>>
>>> About one year ago, a high-level, objected-oriented SIMD API was added
>>> to Mono. For example, there is a class Vector4f for vectors of 4
>
On Thu, Oct 22, 2009 at 11:31 AM, Sturla Molden wrote:
> Mathieu Blondel skrev:
>> Hello,
>>
>> About one year ago, a high-level, objected-oriented SIMD API was added
>> to Mono. For example, there is a class Vector4f for vectors of 4
>> floats and this class implements methods such as basic opera
Mathieu Blondel skrev:
> Hello,
>
> About one year ago, a high-level, objected-oriented SIMD API was added
> to Mono. For example, there is a class Vector4f for vectors of 4
> floats and this class implements methods such as basic operators,
> bitwise operators, comparison operators, min, max, sqrt
On Wed, Oct 21, 2009 at 10:14 PM, Pauli Virtanen wrote:
>
> This type of project could probably also be started outside Numpy, and
> just monkey-patch the Numpy routines on import.
I think I would prefer this approach as a first shot. I will look into
adding a small C library + wrapper in python
On 10/21/2009 3:23 PM, Charles R Harris wrote:
> What exactly *was* the history of that project and what can we learn
> from it?
Imo, what really drove this project forward, is that Skipper
was able to interact regularly with someone else who was actively
using and developing on the code base (i.e
On Wed, Oct 21, 2009 at 12:02 PM, Charles R Harris
wrote:
> I don't feel that numpy/scipy did as well in GSOC 2009 as it could have.
I'd be curious to hear why you felt that numpy/scipy didn't do as well
this year. We had more projects than any other year and I think that
most of the code ended
sigh; yet another email dropped by the list.
David Warde-Farley wrote:
> On 21-Oct-09, at 9:14 AM, Pauli Virtanen wrote:
>
>> Since these are ufuncs, I suppose the SSE implementations could just
>> be
>> put in a separate module, which is always compiled. Before importing
>> the
>> module, we
On Wed, Oct 21, 2009 at 3:23 PM, Charles R Harris
wrote:
>
>
> On Wed, Oct 21, 2009 at 1:11 PM, wrote:
>>
>> On Wed, Oct 21, 2009 at 3:02 PM, Charles R Harris
>> wrote:
>> > Hi All,
>> >
>> > I don't feel that numpy/scipy did as well in GSOC 2009 as it could
>> > have. I
>> > think this was mos
On Wed, Oct 21, 2009 at 3:23 PM, Charles R Harris
wrote:
>
>
> On Wed, Oct 21, 2009 at 1:11 PM, wrote:
>>
>> On Wed, Oct 21, 2009 at 3:02 PM, Charles R Harris
>> wrote:
>> > Hi All,
>> >
>> > I don't feel that numpy/scipy did as well in GSOC 2009 as it could
>> > have. I
>> > think this was mos
On 21-Oct-09, at 9:14 AM, Pauli Virtanen wrote:
> Since these are ufuncs, I suppose the SSE implementations could just
> be
> put in a separate module, which is always compiled. Before importing
> the
> module, we could simply check from Python side that the CPU supports
> the
> necessary i
On 21-Oct-09, at 3:02 PM, Charles R Harris wrote:
> • Best of breed special functions in cython. These could be part of
> a separate numpy extras package where code is restricted to C,
> Cython, and Python.
I think a lot of SciPy could be usefully brought over to Cython, as
well (not
On Wed, Oct 21, 2009 at 1:11 PM, wrote:
> On Wed, Oct 21, 2009 at 3:02 PM, Charles R Harris
> wrote:
> > Hi All,
> >
> > I don't feel that numpy/scipy did as well in GSOC 2009 as it could have.
> I
> > think this was mostly due to lack of preparation on our part, we weren't
> > ready when the st
On Wed, Oct 21, 2009 at 3:02 PM, Charles R Harris
wrote:
> Hi All,
>
> I don't feel that numpy/scipy did as well in GSOC 2009 as it could have. I
> think this was mostly due to lack of preparation on our part, we weren't
> ready when the students started showing up on the lists. So I would like t
Hi All,
I don't feel that numpy/scipy did as well in GSOC 2009 as it could have. I
think this was mostly due to lack of preparation on our part, we weren't
ready when the students started showing up on the lists. So I would like to
put together a selection of suitable projects and corresponding m
...
> I once wrote a module that replaces the built in transcendental
> functions of numpy by optimized versions from Intels vector math
> library. If someone is interested, I can publish it. In my experience it
> was of little use since real world problems are limited by memory
> bandwidth. Theref
On Wed, Oct 21, 2009 at 1:23 PM, Ryan May wrote:
> On Wed, Oct 21, 2009 at 11:38 AM, Gregor Thalhammer
> wrote:
>> I once wrote a module that replaces the built in transcendental
>> functions of numpy by optimized versions from Intels vector math
>> library. If someone is interested, I can publis
On Wed, Oct 21, 2009 at 11:38 AM, Gregor Thalhammer
wrote:
> I once wrote a module that replaces the built in transcendental
> functions of numpy by optimized versions from Intels vector math
> library. If someone is interested, I can publish it. In my experience it
> was of little use since real
On Wed, Oct 21, 2009 at 11:28, Charles R Harris
wrote:
> As an aside, would it be
> appropriate to have some of the more common Bessel functions as ufuncs?
I'd prefer that we stick to the policy of including special functions
that are part of the C99 standard (or another appropriate one) and no
m
Pauli Virtanen schrieb:
> Wed, 21 Oct 2009 14:47:02 +0200, Francesc Alted wrote:
> [clip]
>
>>> Do you have any interest in adding SIMD to some core numpy
>>> (transcendental functions). If so, I would try to go back to the
>>> problem of runtime SSE detection and loading of optimized shared
>>> li
On Wed, Oct 21, 2009 at 9:18 AM, wrote:
> On Sun, Oct 18, 2009 at 3:11 PM, Jeffrey McGee
> wrote:
> > Howdy,
> > I'm having trouble getting the kaiser window to work. Anytime I try
> > to call numpy.kaiser(), it throws an exception. Here's the output when
> > I run the example code from
> > ht
On Wed, Oct 21, 2009 at 2:14 PM, Pauli Virtanen
> wrote:
> Wed, 21 Oct 2009 14:47:02 +0200, Francesc Alted wrote:
> [clip]
> >> Do you have any interest in adding SIMD to some core numpy
> >> (transcendental functions). If so, I would try to go back to the
> >> problem of runtime SSE detection an
On Sun, Oct 18, 2009 at 3:11 PM, Jeffrey McGee wrote:
> Howdy,
> I'm having trouble getting the kaiser window to work. Anytime I try
> to call numpy.kaiser(), it throws an exception. Here's the output when
> I run the example code from
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.
Sorry for the noise. Found the instructions in HOWTO_BUILD_DOCS.txt .
Mike
Michael Droettboom wrote:
> I'm in the process of converting a project to use Sphinx for
> documentation, and would like to use the Numpy docstring standard with
> its sections etc. It appears, however, that the numpyd
On Wed, Oct 21, 2009 at 9:09 AM, Zachary Pincus wrote:
>> Wow. Once again, Apple makes using python unnecessarily difficult.
>> Someone needs a whack with a clue bat.
>
> Well, some tools from the operating system use numpy and other python
> modules. And upgrading one of these modules might conc
I'm in the process of converting a project to use Sphinx for
documentation, and would like to use the Numpy docstring standard with
its sections etc. It appears, however, that the numpydoc sphinxext is
not installed but merely sits in doc/sphinxext. I see that scipy uses
an SVN external to ge
> Wow. Once again, Apple makes using python unnecessarily difficult.
> Someone needs a whack with a clue bat.
Well, some tools from the operating system use numpy and other python
modules. And upgrading one of these modules might conceivably break
that dependency, leading to breakage in the O
On Wed, Oct 21, 2009 at 2:54 PM, Ryan May wrote:
> Wow. Once again, Apple makes using python unnecessarily difficult.
> Someone needs a whack with a clue bat.
Right - I think in the end I decided I will try and use macports
python with virtualenv for svn numpy/scipy and leave system python
well
> It seems it does... the built in numpy which is in
> '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python',
> comes before $HOME/.local in sys.path so I think system numpy will
> always be picked up over my own installed version.
>
> robin-mbp:~ robince$ /usr/bin/python2.6
Wed, 21 Oct 2009 14:47:02 +0200, Francesc Alted wrote:
[clip]
>> Do you have any interest in adding SIMD to some core numpy
>> (transcendental functions). If so, I would try to go back to the
>> problem of runtime SSE detection and loading of optimized shared
>> library in a cross-platform way - th
A Wednesday 21 October 2009 14:27:46 David Cournapeau escrigué:
> > This is because numpy is a package that works mainly with arrays in an
> > element-wise way, and in this scenario, the time to transmit data to CPU
> > dominates, by and large, over the time to perform operations.
>
> Is it general
> Is it general, or just for simple operations in numpy and ufunc ? I
> remember that for music softwares, SIMD used to matter a lot, even for
> simple bus mixing (which is basically a ax+by with a, b scalars and x
> y the input arrays).
Indeed, it shouldn't :| I think the main reason might not be
On Wed, Oct 21, 2009 at 6:12 PM, Francesc Alted wrote:
> A Wednesday 21 October 2009 07:44:39 Mathieu Blondel escrigué:
>> Hello,
>>
>> About one year ago, a high-level, objected-oriented SIMD API was added
>> to Mono. For example, there is a class Vector4f for vectors of 4
>> floats and this clas
Thanks...
On Wed, Oct 21, 2009 at 11:41 AM, David Cournapeau
wrote:
> Robin wrote:
>>
>> Thanks - that looks ideal. I take it $HOME/.local is searched first so
>> numpy will be used fromt here in preference to the system numpy.
>>
>
> Yes, unless framework-enabled python does something 'fishy' (I
Robin wrote:
>
> Thanks - that looks ideal. I take it $HOME/.local is searched first so
> numpy will be used fromt here in preference to the system numpy.
>
Yes, unless framework-enabled python does something 'fishy' (I think
framework vs convention python have different rules w.r.t. sys.path).
On Wed, Oct 21, 2009 at 10:28 AM, David Cournapeau
wrote:
> Robin wrote:
>> Hi,
>>
>> I was wondering what the recommended way to run numpy/scipy on mac os
>> x 10.6 is. I understood previously it was recommended to use
>> python.org python and keep everything seperate from the system python,
>> w
Robin wrote:
> Hi,
>
> I was wondering what the recommended way to run numpy/scipy on mac os
> x 10.6 is. I understood previously it was recommended to use
> python.org python and keep everything seperate from the system python,
> which worked well.
You can simply use the --user option to the ins
Hi,
I was wondering what the recommended way to run numpy/scipy on mac os
x 10.6 is. I understood previously it was recommended to use
python.org python and keep everything seperate from the system python,
which worked well. But now I would like to have a 64 bit python and
numpy, and there isn't o
A Wednesday 21 October 2009 07:44:39 Mathieu Blondel escrigué:
> Hello,
>
> About one year ago, a high-level, objected-oriented SIMD API was added
> to Mono. For example, there is a class Vector4f for vectors of 4
> floats and this class implements methods such as basic operators,
> bitwise operato
On Wed, Oct 21, 2009 at 5:23 PM, David Cournapeau
wrote:
> Ah, I think you are mistaken, then - he referred to merging numpy and
> scipy into python during his talk, not cython.
Oh, I meant to say CPython (the default implementation of Python), not
Cython. I didn't realize that they were differe
Mathieu Blondel wrote:
> He went on to say that he talked about
> it with Guido and apparently the main barrier was the release cycle.
> Please check the video as I'm telling you that from memory.
>
Ah, I think you are mistaken, then - he referred to merging numpy and
scipy into python during h
On Wed, Oct 21, 2009 at 5:05 PM, David Cournapeau
wrote:
> Mathieu Blondel wrote:
>> I saw the video of Peter Norvig at the last Scipy conference who was
>> suggesting to merge Numpy into Cython. The SIMD API would be an
>> argument in favor of this too because of the possible interactions
>> betw
Mathieu Blondel wrote:
> I saw the video of Peter Norvig at the last Scipy conference who was
> suggesting to merge Numpy into Cython. The SIMD API would be an
> argument in favor of this too because of the possible interactions
> between such a SIMD API and an array API.
>
Hm, I don't remember
Wed, 21 Oct 2009 16:48:22 +0900, Mathieu Blondel wrote:
[clip]
> My original idea was to write the code in C with Intel/Alvitec/Neon
> intrinsics and have this code binded to be able to call it from Python.
> So the SIMD code would be compiled already, ready to be called from
> Python. Like you sai
Hi David,
On Wed, Oct 21, 2009 at 3:56 PM, David Cournapeau
wrote:
> I am not sure how this could be applied to numpy case ? From what I can
> understand, this cannot be directly applied to python: the described
> changes are vm changes, and we cannot do anything at python vm level (I
> would gue
> The licenses look all hodge-podge:
[...]
> However, if the good stuff is in the class libraries, that looks OK. But
> that still leaves it in C#, no?
I was mentioning Mono just to show that "this has been done" and also
their API reference can serve as inspiration to design Numpy's own
API.
Hi Mathieu,
Mathieu Blondel wrote:
> Hello,
>
> About one year ago, a high-level, objected-oriented SIMD API was added
> to Mono. For example, there is a class Vector4f for vectors of 4
> floats and this class implements methods such as basic operators,
> bitwise operators, comparison operators, m
On Tue, Oct 20, 2009 at 11:44 PM, Mathieu Blondel wrote:
> Hello,
>
> About one year ago, a high-level, objected-oriented SIMD API was added
> to Mono. For example, there is a class Vector4f for vectors of 4
> floats and this class implements methods such as basic operators,
> bitwise operators, c
47 matches
Mail list logo
