+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
On Tue, Feb 28, 2012 at 11:28 PM, Mark Wiebe mwwi...@gmail.com 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
Hi,
On Wed, Feb 29, 2012 at 1:46 AM, Travis Oliphant tra...@continuum.io 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
Charles R Harris wrote:
On Tue, Feb 28, 2012 at 12:05 PM, John Hunter jdh2...@gmail.com wrote:
On Sat, Feb 18, 2012 at 5:09 PM, David Cournapeau courn...@gmail.comwrote:
There are better languages than C++ that has most of the technical
benefits stated in this discussion (rust and D
On Wed, Feb 29, 2012 at 1:20 PM, Neal Becker ndbeck...@gmail.com 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
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 matthew.br...@gmail.com wrote:
Hi,
On Wed, Feb 29, 2012 at 1:46 AM, Travis
On Sat, Feb 18, 2012 at 5:09 PM, David Cournapeau courn...@gmail.comwrote:
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,
On Tue, Feb 28, 2012 at 12:05 PM, John Hunter jdh2...@gmail.com wrote:
On Sat, Feb 18, 2012 at 5:09 PM, David Cournapeau courn...@gmail.comwrote:
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),
On 02/28/2012 11:05 AM, John Hunter wrote:
On Sat, Feb 18, 2012 at 5:09 PM, David Cournapeau courn...@gmail.com
mailto:courn...@gmail.com wrote:
There are better languages than C++ that has most of the technical
benefits stated in this discussion (rust and D being the most
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 courn...@gmail.com
mailto:courn...@gmail.com wrote:
There are better languages than C++ that has
In article
cagy4rcxxl8pos5zcwa4thcg0dhkyesoepjso4z05sz_pqjv...@mail.gmail.com,
David Cournapeau courn...@gmail.com wrote:
On Sat, Feb 18, 2012 at 10:50 PM, Sturla Molden stu...@molden.no wrote:
 In an ideal world, we would have a better language than C++ that can
be spit out as C for
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
On Tue, Feb 28, 2012 at 4:49 PM, Bryan Van de Ven bry...@continuum.io 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
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
On Tue, Feb 28, 2012 at 10:46 PM, Travis Oliphant tra...@continuum.io 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.
On Tue, Feb 28, 2012 at 11:03 PM, Fernando Perez fperez@gmail.comwrote:
On Tue, Feb 28, 2012 at 10:46 PM, Travis Oliphant tra...@continuum.io
wrote:
We already use the NEP process for such decisions. This discussion
came from simply from the *idea* of writing such a NEP.
Nothing
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 somewhere?
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
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
Hi Perry,
On Wed, Feb 22, 2012 at 6:44 AM, Perry Greenfield pe...@stsci.edu 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
On Tue, Feb 21, 2012 at 4:04 AM, Travis Oliphant tra...@continuum.io 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 JITed.
I have several applications that I would like to use this for. It
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
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.
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
On Mon, Feb 20, 2012 at 1:54 AM, Pauli Virtanen p...@iki.fi 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
On Mon, Feb 20, 2012 at 2:54 AM, Pauli Virtanen p...@iki.fi 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
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 e.g.
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
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
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
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
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 Clang
On Mon, Feb 20, 2012 at 9:55 AM, Sturla Molden stu...@molden.no 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
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 need on
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
It is even
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
2012/2/19 Matthew Brett matthew.br...@gmail.com
Hi,
On Sat, Feb 18, 2012 at 8:38 PM, Travis Oliphant tra...@continuum.io
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
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 to
2012/2/19 Nathaniel Smith n...@pobox.com
On Sun, Feb 19, 2012 at 9:16 AM, David Cournapeau courn...@gmail.com
wrote:
On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe mwwi...@gmail.com wrote:
Is there a specific
target platform/compiler combination you're thinking of where we can do
tests on
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
with
2012/2/19 Sturla Molden stu...@molden.no
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
On Mon, Feb 20, 2012 at 9:18 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no 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
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 when
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 JIT
On 02/20/2012 09:34 AM, Christopher Jordan-Squire wrote:
On Mon, Feb 20, 2012 at 9:18 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no 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
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
d.s.seljeb...@astro.uio.no wrote:
On 02/20/2012 08:55 AM, Sturla Molden wrote:
Den 20.02.2012 17:42, skrev Sturla Molden:
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 any
2012/2/20 Daniele Nicolodi dani...@grinta.net
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
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 something
Charles R Harris wrote:
On Fri, Feb 17, 2012 at 12:09 PM, Benjamin Root ben.r...@ou.edu 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 mwwi...@gmail.com wrote:
On Fri, Feb 17, 2012 at 11:52 AM, Eric
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/Theano
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 Fortran a
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
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 books
On Mon, Feb 20, 2012 at 19:55, Paul Anton Letnes
paul.anton.let...@gmail.com 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
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
On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau courn...@gmail.comwrote:
On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Well, we already have code obfuscation (DOUBLE_your_pleasure,
FLOAT_your_boat), so we might as well let the compiler handle it.
On Sun, Feb 19, 2012 at 6:47 AM, Benjamin Root ben.r...@ou.edu 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
On Feb 19, 2012 12:09 AM, Mark Wiebe mwwi...@gmail.com 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?
On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau courn...@gmail.com
wrote:
On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Well, we already have code obfuscation
On Sun, Feb 19, 2012 at 3:16 AM, David Cournapeau courn...@gmail.comwrote:
On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau courn...@gmail.com
wrote:
On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris
On Sun, Feb 19, 2012 at 9:28 AM, Mark Wiebe mwwi...@gmail.com 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
On Sun, Feb 19, 2012 at 10:28 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Feb 19, 2012 at 3:16 AM, David Cournapeau courn...@gmail.comwrote:
On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau courn...@gmail.com
wrote:
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 not
On Sun, Feb 19, 2012 at 9:16 AM, David Cournapeau courn...@gmail.com wrote:
On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe mwwi...@gmail.com 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
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 would be
Nathaniel Smith wrote:
On Sun, Feb 19, 2012 at 9:16 AM, David Cournapeau courn...@gmail.com wrote:
On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe mwwi...@gmail.com wrote:
Is there a specific
target platform/compiler combination you're thinking of where we can do
tests on this? I don't believe
Sturla Molden wrote:
Den 18. feb. 2012 kl. 01:58 skrev Charles R Harris
charlesr.har...@gmail.com:
On Fri, Feb 17, 2012 at 4:44 PM, David Cournapeau courn...@gmail.com wrote:
I don't think c++ has any significant advantage over c for high performance
libraries. I am not convinced by
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++
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, not
On Sun, Feb 19, 2012 at 4:13 PM, xavier.gn...@gmail.com
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
On Sun, Feb 19, 2012 at 5:25 AM, Nathaniel Smith n...@pobox.com wrote:
On Sun, Feb 19, 2012 at 9:16 AM, David Cournapeau courn...@gmail.com
wrote:
On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe mwwi...@gmail.com wrote:
Is there a specific
target platform/compiler combination you're thinking
On Sun, Feb 19, 2012 at 4:03 AM, David Cournapeau courn...@gmail.comwrote:
On Sun, Feb 19, 2012 at 9:28 AM, Mark Wiebe mwwi...@gmail.com 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
On Sun, Feb 19, 2012 at 7:13 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Feb 19, 2012 at 5:25 AM, Nathaniel Smith n...@pobox.com 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:
On Sun, Feb 19, 2012 at 1:42 PM, Neal Becker ndbeck...@gmail.com 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
On Sun, Feb 19, 2012 at 4:42 PM, Nathaniel Smith n...@pobox.com wrote:
On Sun, Feb 19, 2012 at 1:42 PM, Neal Becker ndbeck...@gmail.com 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
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's
On Feb 19, 2012 4:14 PM, Sturla Molden stu...@molden.no 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
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
On 02/17/2012 09:55 PM, David Cournapeau wrote:
I may not have explained it very well: my whole point is that we don't
recruite people, where I understand recruit as hiring full time,
profesional programmers.We need more people who can casually spend a few
hours - typically grad students,
On Fri, Feb 17, 2012 at 11:55 PM, David Cournapeau courn...@gmail.com wrote:
Le 18 févr. 2012 06:18, Christopher Jordan-Squire cjord...@uw.edu a
écrit :
On Fri, Feb 17, 2012 at 8:30 PM, Sturla Molden stu...@molden.no wrote:
Den 18. feb. 2012 kl. 05:01 skrev Jason Grout
On Fri, Feb 17, 2012 at 11:31 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Fri, Feb 17, 2012 at 10:18 PM, Christopher Jordan-Squire
cjord...@uw.edu wrote:
On Fri, Feb 17, 2012 at 8:30 PM, Sturla Molden stu...@molden.no wrote:
Den 18. feb. 2012 kl. 05:01 skrev Jason Grout
On Thu, Feb 16, 2012 at 11:39 PM, Travis Oliphant tra...@continuum.iowrote:
Mark Wiebe and I have been discussing off and on (as well as talking with
Charles) a good way forward to balance two competing desires:
* addition of new features that are needed in NumPy
* improving
On Sat, Feb 18, 2012 at 04:54, Charles R Harris
charlesr.har...@gmail.com wrote:
I found this , which references 0mq (used by ipython) as an example of a C++
library with a C interface. It seems enums can have different sizes in
C/C++, so that is something to watch.
One of the ways they
Le 18 févr. 2012 11:25, Robert Kern robert.k...@gmail.com a écrit :
On Sat, Feb 18, 2012 at 04:54, Charles R Harris
charlesr.har...@gmail.com wrote:
I found this , which references 0mq (used by ipython) as an example of
a C++
library with a C interface. It seems enums can have different
Den 18. feb. 2012 kl. 14:38 skrev David Cournapeau courn...@gmail.com:
I took a superficial look at zeromq 2.x sources: it looks like they don't use
much of the stl (beyond vector and some trivial usages of algorithm). I
wonder if this is linked ?
FWIW, I would be fine with using such a
I just meant what Sturla said, nothing more:
Cython is still 0.16, it is still unfinished. We cannot base NumPy on
an unfinished compiler.
Albeit Cython has a special syntax for NumPy arrays, we are talking about
implementation of NumPy, not using it. I would not consider Cython for
Albeit Cython has a special syntax for NumPy arrays, we are talking about
implementation of NumPy, not using it. I would not consider Cython for this
before e.g. memoryviews have been stable for a long period. The subset of
Cython we could safely use is not better than plain C.
If
Yes. Basically, one NEP per feature. Some of them might be merged. The NEP
will be an outline and overview and then fleshed out as the code is developed
in a branch. Some of the NEPs will be more detailed than others a first of
course.
I just wanted to provide a preview about the kind of
18.02.2012 17:24, Sturla Molden kirjoitti:
[clip]
If we want something more readable than C or C++, that looks like Python,
Cython is not the only option. Another is RPython, which is the subset
[clip]
Except that AFAIK integrating it with CPython efficiently or providing C
APIs with it is not
Hi.
On Sat, Feb 18, 2012 at 12:18 AM, Christopher Jordan-Squire
cjord...@uw.edu wrote:
On Fri, Feb 17, 2012 at 11:31 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Fri, Feb 17, 2012 at 10:18 PM, Christopher Jordan-Squire
cjord...@uw.edu wrote:
On Fri, Feb 17, 2012 at 8:30 PM,
On Fri, Feb 17, 2012 at 10:16 PM, Sturla Molden stu...@molden.no wrote:
Den 18. feb. 2012 kl. 05:56 skrev Charles R Harris
charlesr.har...@gmail.com:
But won't a C++ wrapper catch that?
A try-catch block with MSVC will register an SEH with the operating
system. GCC (g++) implements
On Sat, Feb 18, 2012 at 12:21 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi.
On Sat, Feb 18, 2012 at 12:18 AM, Christopher Jordan-Squire
cjord...@uw.edu wrote:
On Fri, Feb 17, 2012 at 11:31 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Fri, Feb 17, 2012 at 10:18 PM,
Hi,
On Sat, Feb 18, 2012 at 12:35 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, Feb 18, 2012 at 12:21 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi.
On Sat, Feb 18, 2012 at 12:18 AM, Christopher Jordan-Squire
cjord...@uw.edu wrote:
On Fri, Feb 17, 2012 at 11:31
On Sat, Feb 18, 2012 at 1:39 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Sat, Feb 18, 2012 at 12:35 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, Feb 18, 2012 at 12:21 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi.
On Sat, Feb 18, 2012 at
Hi,
On Sat, Feb 18, 2012 at 12:45 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, Feb 18, 2012 at 1:39 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Sat, Feb 18, 2012 at 12:35 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, Feb 18, 2012 at
On Sat, Feb 18, 2012 at 8:45 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, Feb 18, 2012 at 1:39 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Sat, Feb 18, 2012 at 12:35 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, Feb 18, 2012 at 12:21 PM,
On Sat, Feb 18, 2012 at 2:45 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Sat, Feb 18, 2012 at 1:39 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Sat, Feb 18, 2012 at 12:35 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, Feb 18, 2012 at 12:21 PM,
On Sat, Feb 18, 2012 at 2:17 PM, David Cournapeau courn...@gmail.comwrote:
On Sat, Feb 18, 2012 at 8:45 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, Feb 18, 2012 at 1:39 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Sat, Feb 18, 2012 at 12:35 PM,
On Sat, Feb 18, 2012 at 1:40 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, Feb 18, 2012 at 2:17 PM, David Cournapeau courn...@gmail.com
wrote:
On Sat, Feb 18, 2012 at 8:45 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, Feb 18, 2012 at 1:39 PM, Matthew
1 - 100 of 189 matches
Mail list logo
