Re: [Numpy-discussion] Proposed Roadmap Overview

+1 on the NEP guideline As part of a team building a scientific analysis library, I'm attempting to understand the current state of NumPy development and its likely future (with a view to contributing if appropriate). The proposed NEP process would make that a whole lot easier. And if nothing else

Re: [Numpy-discussion] Proposed Roadmap Overview

I Would like to hear the opinions of others on that point, but yes, I think that is an appropriate procedure. Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Feb 29, 2012, at 10:54 AM, Matthew Brett wrote: > Hi, > > On Wed, Feb 29, 2012 at 1:46 AM, Travis Oliphant wrote: >> We

Re: [Numpy-discussion] Proposed Roadmap Overview

On Wed, Feb 29, 2012 at 1:20 PM, Neal Becker wrote: > > Much of Linus's complaints have to do with the use of c++ in the _kernel_. > These objections are quite different for an _application_. For example, > there > are issues with the need for support libraries for exception handling. > Not an

Re: [Numpy-discussion] Proposed Roadmap Overview

Charles R Harris wrote: > On Tue, Feb 28, 2012 at 12:05 PM, John Hunter wrote: > >> On Sat, Feb 18, 2012 at 5:09 PM, David Cournapeau wrote: >> >>> >>> There are better languages than C++ that has most of the technical >>> >>> benefits stated in this discussion (rust and D being the most >>> "ob

Re: [Numpy-discussion] Proposed Roadmap Overview

Hi, On Wed, Feb 29, 2012 at 1:46 AM, Travis Oliphant wrote: > We already use the NEP process for such decisions.   This discussion came > from simply from the *idea* of writing such a NEP. > > Nothing has been decided.  Only opinions have been shared that might > influence the NEP.  This is all

Re: [Numpy-discussion] Proposed Roadmap Overview

On Tue, Feb 28, 2012 at 11:28 PM, Mark Wiebe wrote: > The development approach I really like is to start with a relatively rough > NEP, then cycle through feedback, updating the NEP, and implementation. > Organizing ones thoughts to describe them in a design document can often > clarify things tha

Re: [Numpy-discussion] Proposed Roadmap Overview

On Tue, Feb 28, 2012 at 11:03 PM, Fernando Perez wrote: > On Tue, Feb 28, 2012 at 10:46 PM, Travis Oliphant > wrote: > > We already use the NEP process for such decisions. This discussion > came from simply from the *idea* of writing such a NEP. > > > > Nothing has been decided. Only opinions

Re: [Numpy-discussion] Proposed Roadmap Overview

On Tue, Feb 28, 2012 at 10:46 PM, Travis Oliphant wrote: > We already use the NEP process for such decisions.   This discussion came > from simply from the *idea* of writing such a NEP. > > Nothing has been decided.  Only opinions have been shared that might > influence the NEP.  This is all pre

Re: [Numpy-discussion] Proposed Roadmap Overview

We already use the NEP process for such decisions. This discussion came from simply from the *idea* of writing such a NEP. Nothing has been decided. Only opinions have been shared that might influence the NEP. This is all pretty premature, though --- migration to C++ features on a trial br

Re: [Numpy-discussion] Proposed Roadmap Overview

On Tue, Feb 28, 2012 at 4:49 PM, Bryan Van de Ven wrote: > Just my own $0.02 regarding this issue: I am in favor of using C++ for > numpy, I think it could confer various benefits. However, I am also in > favor of explicitly deciding and documenting what subset of C++ features > are acceptable for

Re: [Numpy-discussion] Proposed Roadmap Overview

On 2/28/12 4:09 PM, Russell E. Owen wrote: > I can't imagine working in C anymore and doing without exception > handling and namespaces. So I'm sorry to hear that C++ is not being > considered for a numpy rewrite. -- Russell AFAIK C++ is still being considered for numpy in the future, and I think

Re: [Numpy-discussion] Proposed Roadmap Overview

In article , David Cournapeau wrote: > On Sat, Feb 18, 2012 at 10:50 PM, Sturla Molden wrote: > > >  > In an ideal world, we would have a better language than C++ that can > > be spit out as > C for portability. > > > > What about a statically typed Python? (That is, not Cython.) We just > >

Re: [Numpy-discussion] Proposed Roadmap Overview

On Tue, Feb 28, 2012 at 2:34 PM, Dag Sverre Seljebotn < d.s.seljeb...@astro.uio.no> wrote: > On 02/28/2012 11:05 AM, John Hunter wrote: > > On Sat, Feb 18, 2012 at 5:09 PM, David Cournapeau > > wrote: > > > > > > There are better languages than C++ that has most of

Re: [Numpy-discussion] Proposed Roadmap Overview

On 02/28/2012 11:05 AM, John Hunter wrote: > On Sat, Feb 18, 2012 at 5:09 PM, David Cournapeau > wrote: > > > There are better languages than C++ that has most of the technical > benefits stated in this discussion (rust and D being the most > "obvious" ones),

Re: [Numpy-discussion] Proposed Roadmap Overview

On Tue, Feb 28, 2012 at 12:05 PM, John Hunter wrote: > On Sat, Feb 18, 2012 at 5:09 PM, David Cournapeau wrote: > >> >> There are better languages than C++ that has most of the technical >> >> benefits stated in this discussion (rust and D being the most >> "obvious" ones), but whose usage is unr

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sat, Feb 18, 2012 at 5:09 PM, David Cournapeau wrote: > > There are better languages than C++ that has most of the technical > benefits stated in this discussion (rust and D being the most > "obvious" ones), but whose usage is unrealistic today for various > reasons: knowledge, availability on

Re: [Numpy-discussion] Proposed Roadmap Overview

> > Sure. This list actually deserves a long writeup about that. First, > there wasn't a "Cython-refactor" of NumPy. There was a Cython-refactor of > SciPy. I'm not sure of it's current status. I'm still very supportive > of that sort of thing. > > > I think I missed that - is it on git so

Re: [Numpy-discussion] Proposed Roadmap Overview

Hi Perry, On Wed, Feb 22, 2012 at 6:44 AM, Perry Greenfield wrote: > I, like Travis, have my worries about C++. But if those actually doing > the work (and particularly the subsequent support) feel it is the best > language for implementation, I can live with that. > > I particularly like the in

Re: [Numpy-discussion] Proposed Roadmap Overview

I, like Travis, have my worries about C++. But if those actually doing the work (and particularly the subsequent support) feel it is the best language for implementation, I can live with that. I particularly like the incremental and conservative approach to introducing C++ that was proposed

Re: [Numpy-discussion] Proposed Roadmap Overview

It's great advice to say avoid using new instead rely on scope and classes such as std::vector. I just want to point out, that sometimes objects must outlive scope. For those cases, std::shared_ptr can be helpful. ___ NumPy-Discussion mailing list N

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 05:44:27AM -0500, David Warde-Farley wrote: > I think the comments about the developer audience NumPy will attract are > important. There may be lots of C++ developers out there, but the > intersection of (truly competent in C++) and (likely to involve oneself in > NumPy

Re: [Numpy-discussion] Proposed Roadmap Overview

On Tue, Feb 21, 2012 at 4:04 AM, Travis Oliphant wrote: > It uses llvm-py (modified to work with LLVM 3.0) and code I wrote to do the > translation from Python byte-code to LLVM.   This LLVM can then be "JIT"ed. >   I have several applications that I would like to use this for.   It would > be pos

Re: [Numpy-discussion] Proposed Roadmap Overview

Interesting you bring this up. I actually have a working prototype of using Python to emit LLVM. I will be showing it at the HPC tutorial that I am giving at PyCon.I will be making this available after PyCon to a wider audience as open source. It uses llvm-py (modified to work with LL

Re: [Numpy-discussion] Proposed Roadmap Overview

On Mon, Feb 20, 2012 at 19:55, Paul Anton Letnes wrote: > > On 20. feb. 2012, at 16:29, Sturla Molden wrote: >>> - in newer standards it has some nontrivial mathematical functions: gamma, >>> bessel, etc. that numpy lacks right now >> >> That belongs to SciPy. > > I don't see exactly why. Why sh

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 20.02.2012 21:12, skrev Sturla Molden: > > If you need to control the lifetime of an object, make an inner block > with curly brackets, and declare it on top of the block. Don't call new > and delete to control where you want it to be allocated and deallocated. > Nothing goes on the heap unless

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 20.02.2012 20:14, skrev Daniele Nicolodi: > Hello Sturla, unrelated to the numpy tewrite debate, can you please > suggest some resources you think can be used to learn how to program > C++ "the proper way"? Thank you. Cheers, This is totally OT on this list, however ... Scott Meyer's book

Re: [Numpy-discussion] Proposed Roadmap Overview

Looks like Dag forked the discussion of lazy evaluation to a new thread ([Numpy-discussion] ndarray and lazy evaluation). There are actually several projects inspired by this sort of design: off the top of my head I can think of Theano, copperhead, numexpr, arguably sympy, and some non-public cod

Re: [Numpy-discussion] Proposed Roadmap Overview

On 20. feb. 2012, at 16:29, Sturla Molden wrote: > Den 20.02.2012 08:35, skrev Paul Anton Letnes: >> In the language wars, I have one question. Why is Fortran not being >> considered? Fortran already implements many of the features that we want in >> NumPy: > > Yes ... but it does not make For

Re: [Numpy-discussion] Proposed Roadmap Overview

Lluís writes: > Francesc Alted writes: >> On Feb 20, 2012, at 6:18 PM, Dag Sverre Seljebotn wrote: >>> You need at least a slightly different Python API to get anywhere, so >>> numexpr/Theano is the right place to work on an implementation of this >>> idea. Of course it would be nice if numexpr

Re: [Numpy-discussion] Proposed Roadmap Overview

Charles R Harris wrote: > On Fri, Feb 17, 2012 at 12:09 PM, Benjamin Root wrote: > >> >> >> On Fri, Feb 17, 2012 at 1:00 PM, Christopher Jordan-Squire < >> cjord...@uw.edu> wrote: >> >>> On Fri, Feb 17, 2012 at 10:21 AM, Mark Wiebe wrote: >>> > On Fri, Feb 17, 2012 at 11:52 AM, Eric Firing >>>

Re: [Numpy-discussion] Proposed Roadmap Overview

Francesc Alted writes: > On Feb 20, 2012, at 6:18 PM, Dag Sverre Seljebotn wrote: >> You need at least a slightly different Python API to get anywhere, so >> numexpr/Theano is the right place to work on an implementation of this >> idea. Of course it would be nice if numexpr/Theano offered somet

Re: [Numpy-discussion] Proposed Roadmap Overview

2012/2/20 Daniele Nicolodi > On 18/02/12 04:54, Sturla Molden wrote: > > This is not true. C++ can be much easier, particularly for those who > > already know Python. The problem: C++ textbooks teach C++ as a subset > > of C. Writing C in C++ just adds the complexity of C++ on top of C, > > for n

Re: [Numpy-discussion] Proposed Roadmap Overview

On 18/02/12 04:54, Sturla Molden wrote: > This is not true. C++ can be much easier, particularly for those who > already know Python. The problem: C++ textbooks teach C++ as a subset > of C. Writing C in C++ just adds the complexity of C++ on top of C, > for no good reason. I can write FORTRAN in a

Re: [Numpy-discussion] Proposed Roadmap Overview

On Feb 20, 2012, at 7:08 PM, Dag Sverre Seljebotn wrote: > On 02/20/2012 09:34 AM, Christopher Jordan-Squire wrote: >> On Mon, Feb 20, 2012 at 9:18 AM, Dag Sverre Seljebotn >> wrote: >>> On 02/20/2012 08:55 AM, Sturla Molden wrote: Den 20.02.2012 17:42, skrev Sturla Molden: > There are

Re: [Numpy-discussion] Proposed Roadmap Overview

On 02/20/2012 09:34 AM, Christopher Jordan-Squire wrote: > On Mon, Feb 20, 2012 at 9:18 AM, Dag Sverre Seljebotn > wrote: >> On 02/20/2012 08:55 AM, Sturla Molden wrote: >>> Den 20.02.2012 17:42, skrev Sturla Molden: There are still other options than C or C++ that are worth considering. >>>

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 20.02.2012 18:34, skrev Christopher Jordan-Squire: > I don't follow this. Could you expand a bit more? (Specifically, I > wasn't aware that numpy could be 10-20x slower than a cython loop, if > we're talking about the base numpy library--so core operations. I'm > also not totally sure why a

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 20.02.2012 18:18, skrev Dag Sverre Seljebotn: > > I think it is moot to focus on improving NumPy performance as long as in > practice all NumPy operations are memory bound due to the need to take a > trip through system memory for almost any operation. C/C++ is simply > "good enough". JIT is wh

Re: [Numpy-discussion] Proposed Roadmap Overview

On Mon, Feb 20, 2012 at 9:18 AM, Dag Sverre Seljebotn wrote: > On 02/20/2012 08:55 AM, Sturla Molden wrote: >> Den 20.02.2012 17:42, skrev Sturla Molden: >>> There are still other options than C or C++ that are worth considering. >>> One would be to write NumPy in Python. E.g. we could use LLVM as

Re: [Numpy-discussion] Proposed Roadmap Overview

2012/2/19 Sturla Molden > Den 19.02.2012 10:28, skrev Mark Wiebe: > > > > Particular styles of using templates can cause this, yes. To properly > > do this kind of advanced C++ library work, it's important to think > > about the big-O notation behavior of your template instantiations, not > > jus

Re: [Numpy-discussion] Proposed Roadmap Overview

On Feb 20, 2012, at 6:18 PM, Dag Sverre Seljebotn wrote: > You need at least a slightly different Python API to get anywhere, so > numexpr/Theano is the right place to work on an implementation of this > idea. Of course it would be nice if numexpr/Theano offered something as > convenient as > >

Re: [Numpy-discussion] Proposed Roadmap Overview

2012/2/19 Nathaniel Smith > On Sun, Feb 19, 2012 at 9:16 AM, David Cournapeau > wrote: > > On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe wrote: > >> Is there a specific > >> target platform/compiler combination you're thinking of where we can do > >> tests on this? I don't believe the compile tim

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 20.02.2012 18:14, skrev Charles R Harris: > > Would that work for Ruby also? One of the advantages of C++ is that > the code doesn't need to be refactored to start with, just modified > step by step going into the future. I think PyPy is close to what you > are talking about. > If we plant

Re: [Numpy-discussion] Proposed Roadmap Overview

2012/2/19 Matthew Brett > Hi, > > On Sat, Feb 18, 2012 at 8:38 PM, Travis Oliphant > wrote: > > > We will need to see examples of what Mark is talking about and clarify > some > > of the compiler issues. Certainly there is some risk that once code is > > written that it will be tempting to jus

Re: [Numpy-discussion] Proposed Roadmap Overview

> Would it be fair to say then, that you are expecting the discussion > about C++ will mainly arise after the Mark has written the code? I > can see that it will be easier to specific at that point, but there > must be a serious risk that it will be too late to seriously consider > an alternative

Re: [Numpy-discussion] Proposed Roadmap Overview

> C++11 has this option: > > for (auto& item : container) { > // iterate over the container object, > // get a reference to each item > // > // "container" can be an STL class or > // A C-style array with known size. > } > > Which does this: > > for item in container: > pass

Re: [Numpy-discussion] Proposed Roadmap Overview

On 02/20/2012 08:55 AM, Sturla Molden wrote: > Den 20.02.2012 17:42, skrev Sturla Molden: >> There are still other options than C or C++ that are worth considering. >> One would be to write NumPy in Python. E.g. we could use LLVM as a >> JIT-compiler and produce the performance critical code we nee

Re: [Numpy-discussion] Proposed Roadmap Overview

On Mon, Feb 20, 2012 at 9:55 AM, Sturla Molden wrote: > Den 20.02.2012 17:42, skrev Sturla Molden: > > There are still other options than C or C++ that are worth considering. > > One would be to write NumPy in Python. E.g. we could use LLVM as a > > JIT-compiler and produce the performance critic

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 20.02.2012 17:42, skrev Sturla Molden: > There are still other options than C or C++ that are worth considering. > One would be to write NumPy in Python. E.g. we could use LLVM as a > JIT-compiler and produce the performance critical code we need on the fly. > > LLVM and its C/C++ frontend Cla

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 19.02.2012 00:09, skrev David Cournapeau: > There are better languages than C++ that has most of the technical > benefits stated in this discussion (rust and D being the most > "obvious" ones), but whose usage is unrealistic today for various > reasons: knowledge, availability on "esoteric"

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 20.02.2012 08:35, skrev Paul Anton Letnes: > As far as I can understand, implementing element-wise operations, slicing, > and a host of other NumPy features is in some sense pointless - the Fortran > compiler authors have already done it for us. Only if you know the array dimensions in advan

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 20.02.2012 08:35, skrev Paul Anton Letnes: > In the language wars, I have one question. Why is Fortran not being > considered? Fortran already implements many of the features that we want in > NumPy: Yes ... but it does not make Fortran a systems programming language. Making NumPy is differ

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 20.02.2012 10:54, skrev Pauli Virtanen: > Fortran is OK for simple numerical algorithms, but starts to suck > heavily if you need to do any string handling, I/O, complicated logic, > or data structures For string handling, C is actually worse than Fortran. In Fortran a string can be sliced

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 20.02.2012 12:43, skrev Charles R Harris: > > > There also used to be a problem with unsigned types not being > available. I don't know if that is still the case. > Fortran -- like Python and Java -- does not have built-in unsigned integer types. It is never really a problem though. One can

Re: [Numpy-discussion] Proposed Roadmap Overview

On Mon, Feb 20, 2012 at 2:54 AM, Pauli Virtanen wrote: > 20.02.2012 08:35, Paul Anton Letnes kirjoitti: > > In the language wars, I have one question. > > Why is Fortran not being considered? > > Fortran is OK for simple numerical algorithms, but starts to suck > heavily if you need to do any str

Re: [Numpy-discussion] Proposed Roadmap Overview

On Mon, Feb 20, 2012 at 1:54 AM, Pauli Virtanen wrote: > 20.02.2012 08:35, Paul Anton Letnes kirjoitti: >> In the language wars, I have one question. >> Why is Fortran not being considered? > > Fortran is OK for simple numerical algorithms, but starts to suck > heavily if you need to do any string

Re: [Numpy-discussion] Proposed Roadmap Overview

20.02.2012 08:35, Paul Anton Letnes kirjoitti: > In the language wars, I have one question. > Why is Fortran not being considered? Fortran is OK for simple numerical algorithms, but starts to suck heavily if you need to do any string handling, I/O, complicated logic, or data structures. Most of

Re: [Numpy-discussion] Proposed Roadmap Overview

On 17.02.2012, at 21:46, Ralf Gommers wrote: > [...] > So far no one has managed to build the numpy/scipy combo with the LLVM-based > compilers, so if you were willing to have a go at fixing that it would be > hugely appreciated. See http://projects.scipy.org/scipy/ticket/1500 for > details. >

Re: [Numpy-discussion] Proposed Roadmap Overview

In the language wars, I have one question. Why is Fortran not being considered? Fortran already implements many of the features that we want in NumPy: - slicing and similar operations, at least some of the fancy indexing kind - element-wise array operations and function calls - array bounds-checki

Re: [Numpy-discussion] Proposed Roadmap Overview

On Feb 19, 2012 4:14 PM, "Sturla Molden" wrote: > > Den 20.02.2012 00:39, skrev Nathaniel Smith: > > But there's an order-of-magnitude difference in compile times between > > most real-world C projects and most real-world C++ projects. It might > > not be a deal-breaker and it might not apply for

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 20.02.2012 00:39, skrev Nathaniel Smith: > But there's an order-of-magnitude difference in compile times between > most real-world C projects and most real-world C++ projects. It might > not be a deal-breaker and it might not apply for subset of C++ you're > planning to use, but AFAICT that'

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 4:42 PM, Nathaniel Smith wrote: > On Sun, Feb 19, 2012 at 1:42 PM, Neal Becker wrote: > > On Fedora linux I use ccache, which is completely transparant and makes > a huge > > difference in build times. > > ccache is fabulous (and it's fabulous for C too), but it only help

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 1:42 PM, Neal Becker wrote: > On Fedora linux I use ccache, which is completely transparant and makes a huge > difference in build times. ccache is fabulous (and it's fabulous for C too), but it only helps when 'make' has screwed up and decided to rebuild some file that di

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 7:13 PM, Mark Wiebe wrote: > On Sun, Feb 19, 2012 at 5:25 AM, Nathaniel Smith wrote: >> Precompiled headers can help some, but require complex and highly >> non-portable build-system support. (E.g., gcc's precompiled header >> constraints are here: >> http://gcc.gnu.org/on

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 4:03 AM, David Cournapeau wrote: > On Sun, Feb 19, 2012 at 9:28 AM, Mark Wiebe wrote: > > > Is there anyone who uses a blue gene or small device which needs > up-to-date > > numpy support, that I could talk to directly? We really need a list of > > supported platforms on t

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 5:25 AM, Nathaniel Smith wrote: > On Sun, Feb 19, 2012 at 9:16 AM, David Cournapeau > wrote: > > On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe wrote: > >> Is there a specific > >> target platform/compiler combination you're thinking of where we can do > >> tests on this? I

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 4:13 PM, xavier.gn...@gmail.com wrote: > I'm no sure. If you want to be able to write A=B+C+D; with decent > performances, I think you have to use a lib based on expression templates. > It would be great if C++ compilers could automatically optimize out > spurious copies in

Re: [Numpy-discussion] Proposed Roadmap Overview

On 02/19/2012 04:48 PM, Sturla Molden wrote: > Den 19.02.2012 10:28, skrev Mark Wiebe: >> Particular styles of using templates can cause this, yes. To properly >> do this kind of advanced C++ library work, it's important to think >> about the big-O notation behavior of your template instantiations,

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 19.02.2012 10:28, skrev Mark Wiebe: > > Particular styles of using templates can cause this, yes. To properly > do this kind of advanced C++ library work, it's important to think > about the big-O notation behavior of your template instantiations, not > just the big-O notation of run-time. C

Re: [Numpy-discussion] Proposed Roadmap Overview

Sturla Molden wrote: > > Den 18. feb. 2012 kl. 01:58 skrev Charles R Harris > : > >> >> >> On Fri, Feb 17, 2012 at 4:44 PM, David Cournapeau wrote: >> I don't think c++ has any significant advantage over c for high performance >> libraries. I am not convinced by the number of people argument

Re: [Numpy-discussion] Proposed Roadmap Overview

Nathaniel Smith wrote: > On Sun, Feb 19, 2012 at 9:16 AM, David Cournapeau wrote: >> On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe wrote: >>> Is there a specific >>> target platform/compiler combination you're thinking of where we can do >>> tests on this? I don't believe the compile times are as

Re: [Numpy-discussion] Proposed Roadmap Overview

Sturla Molden wrote: > Den 19.02.2012 01:12, skrev Nathaniel Smith: >> >> I don't oppose it, but I admit I'm not really clear on what the >> supposed advantages would be. Everyone seems to agree that >>-- Only a carefully-chosen subset of C++ features should be used >>-- But this subset wo

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 9:16 AM, David Cournapeau wrote: > On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe wrote: >> Is there a specific >> target platform/compiler combination you're thinking of where we can do >> tests on this? I don't believe the compile times are as bad as many people >> suspect,

Re: [Numpy-discussion] Proposed Roadmap Overview

On 2012-02-19, at 12:47 AM, Benjamin Root wrote: > Dude, have you seen the .c files in numpy/core? They are already read-only > for pretty much everybody but Mark. I've managed to patch several of them without incident, and I do not do a lot of programming in C. It could be simpler, but it's no

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 10:28 AM, Mark Wiebe wrote: > On Sun, Feb 19, 2012 at 3:16 AM, David Cournapeau wrote: > >> On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe wrote: >> > On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau >> > wrote: >> >> >> >> On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 9:28 AM, Mark Wiebe wrote: > Is there anyone who uses a blue gene or small device which needs up-to-date > numpy support, that I could talk to directly? We really need a list of > supported platforms on the numpy wiki we can refer to when discussing this > stuff, it all se

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 3:16 AM, David Cournapeau wrote: > On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe wrote: > > On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau > > wrote: > >> > >> On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris > >> wrote: > >> > >> > > >> > Well, we already have code ob

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe wrote: > On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau > wrote: >> >> On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris >> wrote: >> >> > >> > Well, we already have code obfuscation (DOUBLE_your_pleasure, >> > FLOAT_your_boat), so we might as well

Re: [Numpy-discussion] Proposed Roadmap Overview

On Feb 19, 2012 12:09 AM, "Mark Wiebe" wrote: > > These standard library issues were definitely valid 10 years ago, but all the major C++ compilers have great C++98 support now. Is there a specific target platform/compiler combination you're thinking of where we can do tests on this? I don't belie

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sun, Feb 19, 2012 at 6:47 AM, Benjamin Root wrote: > > All kidding aside, is your concern that when Mark starts this that no one > will be able to contribute until he is done? I can tell you right now that > won't be the case as I will be trying to flesh out issues with datetime64 > with him.

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau wrote: > On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris > wrote: > > > > > Well, we already have code obfuscation (DOUBLE_your_pleasure, > > FLOAT_your_boat), so we might as well let the compiler handle it. > > Yes, those are not great, but on

Re: [Numpy-discussion] Proposed Roadmap Overview

Hi, On Sat, Feb 18, 2012 at 10:09 PM, Charles R Harris wrote: > > > On Sat, Feb 18, 2012 at 9:38 PM, Travis Oliphant > wrote: >> >> Sure.  This list actually deserves a long writeup about that.   First, >> there wasn't a "Cython-refactor" of NumPy.   There was a Cython-refactor of >> SciPy.   I

Re: [Numpy-discussion] Proposed Roadmap Overview

Hi, On Sat, Feb 18, 2012 at 9:47 PM, Benjamin Root wrote: > > > On Saturday, February 18, 2012, Matthew Brett wrote: >> >> Hi, >> >> On Sat, Feb 18, 2012 at 8:38 PM, Travis Oliphant >> wrote: >> >> > We will need to see examples of what Mark is talking about and clarify >> > some >> > of the com

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sat, Feb 18, 2012 at 9:38 PM, Travis Oliphant wrote: > > The decision will not be made until NumPy 2.0 work is farther along. > The most likely outcome is that Mark will develop something quite nice in > C++ which he is already toying with, and we will either choose to use it in > NumPy to buil

Re: [Numpy-discussion] Proposed Roadmap Overview

On Saturday, February 18, 2012, Matthew Brett wrote: > Hi, > > On Sat, Feb 18, 2012 at 8:38 PM, Travis Oliphant > > > wrote: > > > We will need to see examples of what Mark is talking about and clarify > some > > of the compiler issues. Certainly there is some risk that once code is > > written

Re: [Numpy-discussion] Proposed Roadmap Overview

Hi, On Sat, Feb 18, 2012 at 8:38 PM, Travis Oliphant wrote: > We will need to see examples of what Mark is talking about and clarify some > of the compiler issues.   Certainly there is some risk that once code is > written that it will be tempting to just use it.   Other approaches are > certain

Re: [Numpy-discussion] Proposed Roadmap Overview

>> >> The decision will not be made until NumPy 2.0 work is farther along. The >> most likely outcome is that Mark will develop something quite nice in C++ >> which he is already toying with, and we will either choose to use it in >> NumPy to build 2.0 on --- or not. I'm interested in spo

Re: [Numpy-discussion] Proposed Roadmap Overview

On 2012-02-18, at 2:47 AM, Matthew Brett wrote: > Of course it might be that so-far undiscovered C++ developers are > drawn to a C++ rewrite of Numpy. But it that really likely? If we can trick them into thinking the GIL doesn't exist, then maybe... David ___

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sat, Feb 18, 2012 at 5:18 PM, Matthew Brett wrote: > Hi, > > On Sat, Feb 18, 2012 at 2:54 PM, Travis Oliphant wrote: >> >> On Feb 18, 2012, at 4:03 PM, Matthew Brett wrote: >> >>> Hi, >>> >>> On Sat, Feb 18, 2012 at 1:57 PM, Travis Oliphant >>> wrote: The C/C++ discussion is just gettin

Re: [Numpy-discussion] Proposed Roadmap Overview

Hi, On Sat, Feb 18, 2012 at 2:54 PM, Travis Oliphant wrote: > > On Feb 18, 2012, at 4:03 PM, Matthew Brett wrote: > >> Hi, >> >> On Sat, Feb 18, 2012 at 1:57 PM, Travis Oliphant wrote: >>> The C/C++ discussion is just getting started.  Everyone should keep in mind >>> that this is not something

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 19.02.2012 01:12, skrev Nathaniel Smith: > > I don't oppose it, but I admit I'm not really clear on what the > supposed advantages would be. Everyone seems to agree that >-- Only a carefully-chosen subset of C++ features should be used >-- But this subset would be pretty useful > I wond

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sat, Feb 18, 2012 at 5:12 PM, Nathaniel Smith wrote: > On Sat, Feb 18, 2012 at 10:54 PM, Travis Oliphant > wrote: > > I'm reading very carefully any arguments against using C++ because I've > actually pushed back on Mark pretty hard as we've discussed these things > over the past months. I a

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sat, Feb 18, 2012 at 11:09 PM, David Cournapeau wrote: > On Sat, Feb 18, 2012 at 10:50 PM, Sturla Molden wrote: > >>  > In an ideal world, we would have a better language than C++ that can >> be spit out as > C for portability. >> >> What about a statically typed Python? (That is, not Cython.)

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sat, Feb 18, 2012 at 10:54 PM, Travis Oliphant wrote: > I'm reading very carefully any arguments against using C++ because I've > actually pushed back on Mark pretty hard as we've discussed these things over > the past months.  I am nervous about corner use-cases that will be unpleasant > fo

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 18.02.2012 23:54, skrev Travis Oliphant: > Another factor. the decision to make an extra layer of indirection makes > small arrays that much slower. I agree with Mark that in a core library we > need to go the other way with small arrays being completely allocated in the > data-structure

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sat, Feb 18, 2012 at 3:24 PM, David Cournapeau wrote: > On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris > wrote: > > > > > Well, we already have code obfuscation (DOUBLE_your_pleasure, > > FLOAT_your_boat), so we might as well let the compiler handle it. > > Yes, those are not great, but on

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 19.02.2012 00:33, skrev Sturla Molden: > Or just write everything in Cython, even the core? That is, use memory view syntax and fused types for generics, and hope it is stable before we are done ;-) Sturla ___ NumPy-Discussion mailing list NumPy-D

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 19.02.2012 00:09, skrev David Cournapeau: > There are better languages than C++ that has most of the technical > benefits stated in this discussion (rust and D being the most > "obvious" ones), What about Java? (compile with GJC for CPython) Or just write everything in Cython, even the core

Re: [Numpy-discussion] Proposed Roadmap Overview

Den 19.02.2012 00:09, skrev David Cournapeau: > reasons: knowledge, availability on "esoteric" platforms, etc… A new > language is completely ridiculous. Yes, that is why I argued against Cython as well. Personally I prefer C++ to C, but only if it is written in a readable way. And if the purpos

Re: [Numpy-discussion] Proposed Roadmap Overview

On Sat, Feb 18, 2012 at 10:50 PM, Sturla Molden wrote: >  > In an ideal world, we would have a better language than C++ that can > be spit out as > C for portability. > > What about a statically typed Python? (That is, not Cython.) We just > need to make the compiler :-) There are better languag

Re: [Numpy-discussion] Proposed Roadmap Overview

Hi, On Sat, Feb 18, 2012 at 2:51 PM, Robert Kern wrote: > On Sat, Feb 18, 2012 at 22:29, Matthew Brett wrote: >> Hi, >> >> On Sat, Feb 18, 2012 at 2:20 PM, Robert Kern wrote: >>> On Sat, Feb 18, 2012 at 22:06, Matthew Brett >>> wrote: Hi, On Sat, Feb 18, 2012 at 2:03 PM, Robert

  1   2   >