René Dudfield wrote:
On Wed, Dec 30, 2009 at 2:26 PM, Ravi lists_r...@lavabit.com wrote:
On Wednesday 30 December 2009 06:15:45 René Dudfield wrote:
I agree with many things in that post. Except your conclusion on
multiple versions of packages in isolation. Package isolation is like
David wrote:
Repository
The goal here is to have something like CRAN
(http://cran.r-project.org/web/views/), ideally with a build farm so
that whenever anyone submits a package to our repository, it would
automatically be checked, and built for windows/mac os x and maybe a
few
On Tue, Dec 29, 2009 at 3:49 AM, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
Do you here mean automatic generation of Ubuntu debs, Debian debs,
Windows
MSI installer, Windows EXE installer, and so on? (If so then great!)
Yes (although this is not yet implemented
Christopher Barker wrote:
Dag Sverre Seljebotn wrote:
This is readily done -- there is no computational portion except for
what is in NumPy/Scipy or scikits, and I intend for it to remain that
way. It's just another interface, really.
(What kind of computations were you thinking about
Christopher Barker wrote:
Dag Sverre Seljebotn wrote:
I recently got motivated to get better linear algebra for Python;
wonderful!
To me that seems like the ideal way to split up code -- let NumPy/SciPy
deal with the array-oriented world and Sage the closer-to-mathematics
notation
Christopher Barker wrote:
Dag Sverre Seljebotn wrote:
I recently got motivated to get better linear algebra for Python;
wonderful!
To me that seems like the ideal way to split up code -- let NumPy/SciPy
deal with the array-oriented world and Sage the closer-to-mathematics
notation
Wayne Watson wrote:
I'm trying to compute the angle between two vectors in three dimensional
space. For that, I need to use the scalar (dot) product , according to
a calculus book (quoting the book) I'm holding in my hands right now.
I've used dot() successfully to produce the necessary
Christopher Barker wrote:
Wayne Watson wrote:
Yes, flat sounds useful here. However, numpy isn't bending over
backwards to tie in conventional mathematical language into it.
exactly -- it isn't bending over at all! (well a little -- see below).
numpy was designed for general
Jasper van de Gronde wrote:
(Resending without attachment as I don't think my previous message arrived.)
I just started using numpy and am very, very pleased with the
functionality and cleanness so far. However, I tried what I though would
be a simple optimization and found that the opposite
Jasper van de Gronde wrote:
Dag Sverre Seljebotn wrote:
Jasper van de Gronde wrote:
I've attached a test file which shows the problem. It also tries adding
columns instead of rows (in case the memory layout is playing tricks),
but this seems to make no difference. This is the output
Anne Archibald wrote:
2009/12/9 Dr. Phillip M. Feldman pfeld...@verizon.net:
When I recently tried to validate a code, the answers were wrong, and it
took two full days to track down the cause. I am now forced to reconsider
carefully whether Python/NumPy is a suitable platform for
Pauli Virtanen wrote:
ti, 2009-12-08 kello 22:26 -0800, Dr. Phillip M. Feldman kirjoitti:
Darren Dale wrote:
On Sat, Mar 7, 2009 at 5:18 AM, Robert Kern robert.k...@gmail.com wrote:
On Sat, Mar 7, 2009 at 04:10, Stéfan van der Walt ste...@sun.ac.za
wrote:
2009/3/7
Ruben Salvador wrote:
Hello everybody.
I've seen this question arise sometimes on the list, but don't know if
something has happened yet or not. I mean, any solution feasible to
use more or less right out of the box?
I'm just a hardware engineer, so it would be difficult for me to
Pauli Virtanen wrote:
2) Figure out how to test the PEP 3118 buffer interface on Python 2.6
and Python 3.1
Write unit tests for it.
On that note, I gave that a very small start in August. The two files
are here -- one is a Cython file wrapping the part of the PyBuffer API
that one
Francesc Alted wrote:
A Thursday 03 December 2009 14:56:16 Dag Sverre Seljebotn escrigué:
Pauli Virtanen wrote:
Thu, 03 Dec 2009 14:03:13 +0100, Dag Sverre Seljebotn wrote:
[clip]
Great! Are you storing the format string in the dtype types as well? (So
that no release is needed
Dag Sverre Seljebotn wrote:
Dag Sverre Seljebotn wrote:
Pauli Virtanen wrote:
Fri, 27 Nov 2009 23:19:58 +0100, Dag Sverre Seljebotn wrote:
[clip]
One thing to keep in mind here is that PEP 3118 actually defines a
standard dtype format string, which is (mostly
Pauli Virtanen wrote:
Thu, 03 Dec 2009 14:03:13 +0100, Dag Sverre Seljebotn wrote:
[clip]
Great! Are you storing the format string in the dtype types as well? (So
that no release is needed and acquisitions are cheap...)
I regenerate it on each buffer acquisition. It's simple low
Anne Archibald wrote:
2009/11/30 James Bergstra bergs...@iro.umontreal.ca:
Your question involves a few concepts:
- an integer vector describing the position of an element
- the logical shape (another int vector)
- the physical strides (another int vector)
Ignoring the case of
Dag Sverre Seljebotn wrote:
Anne Archibald wrote:
2009/11/30 James Bergstra bergs...@iro.umontreal.ca:
Your question involves a few concepts:
- an integer vector describing the position of an element
- the logical shape (another int vector)
- the physical strides (another
Francesc Alted wrote:
A Friday 27 November 2009 16:41:04 Pauli Virtanen escrigué:
I think so. However, I think S is probably closest to bytes... and
maybe S can be reused for bytes... I'm not sure though.
That could be a good idea because that would ensure compatibility with
existing NumPy
Pauli Virtanen wrote:
Mon, 23 Nov 2009 08:58:47 +0100, Sturla Molden wrote:
Pauli Virtanen skrev:
XXX: 3K: numpy.random is disabled for now, uses PyString_* XXX: 3K:
numpy.ma is disabled for now -- some issues
I thought numpy.random uses Cython? Is it just a matter of
Dag Sverre Seljebotn:
Hi,
Is anyone working on alternative storage options for numpy arrays, and
specifically recarrays? My main application involves processing series
of large recarrays (say 1000 recarrays, each with 5M rows having 50
fields). Existing options meet some but not all of my
Stephen Simmons wrote:
P.S. Maybe this will be too much work, and I'd be better off sticking
with Pytables.
I can't judge that, but I want to share some thoughts (rant?):
- Are you ready to not only write the code, but maintain it over years to
come, and work through nasty bugs, and think
I'm getting (to me( very mysterious NaNs when doing matrix
multiplication with certain (randomly generated) data:
In [52]: a.shape, b.shape, i, j
Out[52]: ((22, 1000), (1000, 22), 0, 16)
In [53]: np.dot(a, b)[i,j]
Out[53]: (31.322778824758661+nan*j)
In [54]: np.dot(a[i,:], b[:,j])
Out[54]:
David Cournapeau wrote:
On Thu, Oct 29, 2009 at 10:26 PM, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
I'm getting (to me( very mysterious NaNs when doing matrix
multiplication with certain (randomly generated) data:
In [52]: a.shape, b.shape, i, j
Out[52]: ((22, 1000), (1000
Darren Dale wrote:
On Fri, Oct 23, 2009 at 9:29 AM, Pauli Virtanen pav...@iki.fi wrote:
Fri, 23 Oct 2009 09:21:17 -0400, Darren Dale wrote:
Can we use features of C99 in numpy? For example, can we use // style
comments, and C99 for statements for (int i=0, ...) ?
It would be
Robert Kern wrote:
On Wed, Oct 21, 2009 at 22:32, Mathieu Blondel math...@mblondel.org wrote:
On Thu, Oct 22, 2009 at 11:31 AM, Sturla Molden stu...@molden.no wrote:
Mathieu Blondel skrev:
Hello,
About one year ago, a high-level, objected-oriented SIMD API was added
to
Adam Ginsburg wrote:
Hi folks,
I'm trying to write a ray-tracing code for which high precision is
required. I also need to use square roots. However, math.sqrt and
numpy.sqrt seem to only use single-precision floats. Is there a
simple way to make sqrt use higher precision? Alternately,
Robert Kern wrote:
On Wed, Sep 30, 2009 at 09:34, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
I looked and looked in the docs, but couldn't find an answer to this:
When writing a ufunc, is it possible somehow to raise a Python exception
(by acquiring the GIL first to raise it, set
Christopher Barker wrote:
OK -- this one I'm intending to send!
Hi all,
This idea was inspired by a discussion at the SciPy conference, in which
we spent a LOT of time during the numpy tutorial talking about how to
accumulate values in an array when you don't know how big the array
needs
I looked and looked in the docs, but couldn't find an answer to this:
When writing a ufunc, is it possible somehow to raise a Python exception
(by acquiring the GIL first to raise it, set a flag and a callback which
will be called with the GIL, or otherwise?). Or should one always use
NaN even
Robert Kern wrote:
On Tue, Sep 22, 2009 at 01:33, Sebastian Haase seb.ha...@gmail.com wrote:
Hi,
I'm not subscribed to the cython list - hoping enough people would
care to justify my post here:
The post might be justified, but it is a question of available knowledge
as well. I
Francesc Alted wrote:
A Thursday 10 September 2009 13:45:10 Dag Sverre Seljebotn escrigué:
Do you see any issues with this approach: Add a flag timeit to provide
two modes:
a) Do an initial run which is always not included in timings (in fact,
as it gets min and not mean, I
Christopher Barker wrote:
George Dahl wrote:
Sturla Molden sturla at molden.no writes:
Teraflops peak performance of modern GPUs is impressive. But NumPy
cannot easily benefit from that.
I know that for my work, I can get around an order of a 50-fold speedup over
numpy using a python
Darren Dale wrote:
On Tue, Sep 8, 2009 at 9:02 PM, David Cournapeaucourn...@gmail.com wrote:
On Wed, Sep 9, 2009 at 9:37 AM, Darren Daledsdal...@gmail.com wrote:
Hi David,
I already gave my own opinion on py3k, which can be summarized as:
- it is a huge effort, and no core numpy/scipy
Dag Sverre Seljebotn wrote:
Darren Dale wrote:
On Tue, Sep 8, 2009 at 9:02 PM, David Cournapeaucourn...@gmail.com wrote:
On Wed, Sep 9, 2009 at 9:37 AM, Darren Daledsdal...@gmail.com wrote:
Hi David,
I already gave my own opinion on py3k, which can be summarized as:
- it is a huge effort
Sturla Molden wrote:
Dag Sverre Seljebotn skrev:
Nitpick: This will fail on large arrays. I guess numpy.npy_intp is the
right type to use in this case?
By the way, here is a more polished version, does it look ok?
http://projects.scipy.org/numpy/attachment/ticket/1213
Fons Adriaensen wrote:
Some weeks ago there was a post on this list requesting feedback
on possible future directions for numpy. As I was quite busy at that
time I'll reply to it now.
My POV is that of a novice user, who at the same time wants quite
badly to use the numpy framework for his
There's been some discussion earlier about how starting to write bigger
parts of the NumPy/SciPy codebase in Cython could potentially lower the
barrier of entry.
Some topics:
* Move towards PEP3118 as the primary scientific data container
rather than ndarray?
* Cython templates?
* Native
Hello all,
(resending for the Nth time, as the previous attempts
didn't make it to the list)
I'm new to this list (and numpy is mostly new to me :-).
Using python 2.6 and numpy 1.3.
My plan is to write some C extensions that will perform
rather specialised processing on multichannel
Hello all,
(resending for the Nth time, as the previous attempts
didn't make it to the list)
I'm new to this list (and numpy is mostly new to me :-).
Using python 2.6 and numpy 1.3.
My plan is to write some C extensions that will perform
rather specialised processing on multichannel
I'm trying to fledge out Cython's numpy.pxd, and have a question:
Is there documentation anywhere, or a simple-to-remember rule, on
whether the return value of a NumPy C API is incref-ed or not?
E.g. PyArray_BASE, PyArray_DESCR obviously does not incref; while I'm
assuming that PyArray_New*
Fabrice Silva wrote:
Le vendredi 03 juillet 2009 à 11:52 +0200, Nils Wagner a écrit :
You will need multiprecision arithmetic in that case.
It's an ill-conditioned problem.
I may have said that the solution are of the same order of magnitude, so
that the ratio between the lowest and the
Dan Goodman wrote:
Robert Kern wrote:
On Fri, Jun 26, 2009 at 03:39, Christian K.ckk...@hoc.net wrote:
John Schulman joschu at caltech.edu writes:
I'm trying to reduce the memory used in a calculation, so I'd like to
switch my program to float32 instead of float64. Is it possible to
change
Bryan Cole wrote:
I'm starting work on an application involving cpu-intensive data
processing using a quad-core PC. I've not worked with multi-core systems
previously and I'm wondering what is the best way to utilise the
hardware when working with numpy arrays. I think I'm going to use the
cp wrote:
I don't know anything about PIL and its implementation, but I would not
be surprised if the cost is mostly accessing items which are not
contiguous in memory and bounds checking ( to check where you are in the
subimage). Conditional inside loops often kills performances, and the
Where can I find release notes? (It would be helpful if I can point to a
URL as part of the fedora release)
OK, I put my email announcement up here:
http://wiki.cython.org/ReleaseNotes-0.11.2
Tell me if you need something else (different format or level of detail --
the list of tickets on
Dag Sverre Seljebotn wrote:
albert.thuswald...@gmail.com wrote:
Dear list,
I'm writing this because i have developed a small python module that
might be of interest to you the readers of this list:
http://code.google.com/p/pyhdf5io/
It basically implements load/save functions that mimic
now generate a main()-method for embedding of the Python
interpreter into an executable (see #289) [Robert Bradshaw]
* @wraparound directive (another way to disable arr[idx] for negative
idx) [Dag Sverre Seljebotn]
* Correct support for NumPy record dtypes with different alignments,
and cdef
Charles R Harris wrote:
Hi Dag,
Numpy can now do separate compilations with controlled export of symbols
when the object files are linked together to make a module. Does Cython
have
anyway of controlling the visibility of symbols or should we just include
the right files in Numpy to get the
Dag Sverre Seljebotn wrote:
Stéfan van der Walt wrote:
2009/5/7 Chris Colbert sccolb...@gmail.com:
This was really my first attempt at doing anything constructive with Cython.
It was actually unbelievably easy to work with. I think i spent less time
working on this, than I did trying to find
David Cournapeau wrote:
On Mon, May 4, 2009 at 1:24 AM, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
David Cournapeau wrote:
On Fri, Apr 24, 2009 at 4:49 PM, Dag Sverre Seljebotn
One thing somebody *could* work on rather independently for some hours
is proper PEP
David Cournapeau wrote:
On Fri, Apr 24, 2009 at 4:49 PM, Dag Sverre Seljebotn
One thing somebody *could* work on rather independently for some hours
is proper PEP 3118 support, as that is available in Python 2.6+ as well
and could be conditionally used on those systems.
Yes, this could
David Cournapeau wrote:
Christopher Barker wrote:
Though I'm a bit surprised that that's not how the print function is
written in the first place (maybe it is in py3k -- I'm testing on 2.5)
That's actually how it works as far as I can tell. The thing with
removing those print is that
I'm looking at fixing up support for NumPy record arrays in Cython, and
realize my knowledge of NumPy is a bit too limited. Searching the docs
didn't enlighten me, so:
Does NumPy always use packed alignment for nested dtypes?
In [35]: T
Out[35]: dtype([('f0', 'f4'), ('f1', '|i1'), ('f2',
Robert Kern wrote:
On Thu, Mar 12, 2009 at 17:45, Sturla Molden stu...@molden.no wrote:
2009/3/13 Charles R Harris charlesr.har...@gmail.com:
That said, I think it best to leave '%' with its C default and add a
special
modulus function for the python version. Changing its meaning in C-like
Fernando Perez wrote:
On Thu, Mar 12, 2009 at 11:34 PM, Robert Kern robert.k...@gmail.com wrote:
One possibility (that may be opening a can of worms) is to have two
sets of operators, one that does native semantics (C for cdef longs,
Python for Python ints) and one that does Python
Sturla Molden wrote:
On Fri, Mar 13, 2009 at 01:41, Dag Sverre Seljebotn
# Explicitly declared C types?
cdef long i, j, k
i = -1
j = 5
k = i % j
This one is what I'm really asking about.
My opinion on this is that C semantics have been explicitly
(First off, is it OK to continue polling the NumPy list now and then on
Cython language decisions? Or should I expect that any interested Cython
users follow the Cython list?)
In Python, if I write -1 % 5, I get 4. However, in C if I write -1 %
5 I get -1. The question is, what should I get in
Francesc Alted wrote:
A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué:
But yes, to implement that one would need to reimplement parts of
NumPy to get it working. But because code would be generated
specifically for the situation inline, I think it would be more like
reimplementing
Francesc Alted wrote:
A Thursday 05 March 2009, Francesc Alted escrigué:
Well, I suppose that, provided that Cython could perform the for-loop
transformation, giving support for strided arrays would be relatively
trivial, and the performance would be similar than numexpr in this
case.
Sturla Molden wrote:
Introducing this syntax would actually mean less time to focus on real
usability issues like that. OTOH, if the syntax I propose is superior,
it's better to introduce it early in a long-term perspective.
There is not much difference between
cdef int[:,:]
Francesc Alted wrote:
A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué:
No, one could do the same thing that NumPy does (I think, never
looked into it in detail), i.e:
decide on dimension to do innermost dynamically from strides and
sizes save the stride in that dimension for each
Wes McKinney wrote:
This still doesn't explain why the buffer interface was slow.
I finally remembered to look at this; there seems to be a problem in
your code:
def reindexObject(ndarray[object, ndim=1] index,
ndarray[object, ndim=1] arr,
dict idxMap):
This is NOT yet discussed on the Cython list; I wanted to check with
more numerical users to see if the issue should even be brought up there.
The idea behind the current syntax was to keep things as close as
possible to Python/NumPy, and only provide some hints to Cython for
optimization. My
Stéfan van der Walt wrote:
Hi Dag
2009/3/5 Dag Sverre Seljebotn da...@student.matnat.uio.no:
More details: http://wiki.cython.org/enhancements/buffersyntax
Interesting proposal! Am I correct in thinking that you'd have to
re-implement a lot of NumPy yourself to get this working
Sturla Molden wrote:
arr = np.zeros(..)
cdef int[:,:] buf = arr # 2D buffer
Here, buf would be something else than arr; it is a seperate view to the
array for low-level purposes.
I like your proposal. The reason we use Fortran for numerical computing is
that Fortran makes it easy to
Andrew Straw wrote:
Dag Sverre Seljebotn wrote:
This is NOT yet discussed on the Cython list; I wanted to check with
more numerical users to see if the issue should even be brought up there.
The idea behind the current syntax was to keep things as close as
possible to Python/NumPy
Wes McKinney wrote:
The general problem here is an indexed array (by dates or strings, for
example), that you want to conform to a new index. The arrays most of
the time contain floats but occasionally PyObjects. For some reason
the access and assignment is slow (this function can be
Francesc Alted wrote:
A Thursday 12 February 2009, Dag Sverre Seljebotn escrigué:
A quick digression:
It would be interesting to see how a spec would look for integrating
OpenMP natively into Cython for these kinds of purposes. Cython is
still flexible as a language after all
Sturla Molden wrote:
On 2/12/2009 1:50 PM, Francesc Alted wrote:
Hey! That's very nice to know. We already have OpenMP support in
Cython for free (or apparently it seems so :-)
Not we don't, as variable names are different in C and Cython. But
adding support for OpenMP would
Sturla Molden wrote:
On 2/12/2009 12:34 PM, Dag Sverre Seljebotn wrote:
FYI, I am one of the core Cython developers and can make such
modifications in Cython itself as long as there's consensus on how it
should look on the Cython mailing list. My problem is that I don't
really know
Dag Sverre Seljebotn wrote:
Hmm... yes. Care would need to be taken though because Cython might in
the future very well generate a while loop instead for such a
statement under some circumstances, and that won't work with OpenMP. One
should be careful with assuming what the C result
Brian Granger wrote:
And a question:
With the new Numpy support in Cython, does Cython release the GIL if
it can when running through through loops over numpy arrays? Does
Cython call into the C API during these sections?
You know, I thought of the exact same thing when reading your post.
Wes McKinney wrote:
I am writing some Cython code and have noted that the buffer interface
offers very little speedup for PyObject arrays. In trying to rewrite the
same code using the C API in Cython, I find I can't get PyArray_SETITEM to
work, in a call like:
PyArray_SETITEM(result, void *
Francesc Alted wrote:
A Friday 16 January 2009, j...@physics.ucf.edu escrigué:
Right
now, I'm not quite sure whether the problem you are solving is merely
the case of expressions-in-strings, and there is no advantage for
expressions-in-code, or whether your expressions-in-strings are
faster
Some of the problems you encounter could probably be remedied by better
support in Cython for some situations. I've filed two feature request
tickets for myself, but I have no idea when or if I'll get around to them.
http://trac.cython.org/cython_trac/ticket/177
For mailing list archival purposes, I'm posting the conclusion of this
story: An update to Cython which also works with NumPy/Python2.4/64-bit
can now be retrieved from http://hg.cython.org/cython
That Mercurial repo contains previous release + bugfixes deemed to be
very safe, so I recommend
Charles R Harris wrote:
On Sun, Nov 9, 2008 at 4:29 PM, Dag Sverre Seljebotn
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
What the Cython numpy.pxd file does is implementing PEP 3118 [1],
which
is supported by Cython in all Python versions (ie backported
Charles R Harris wrote:
On Sun, Nov 9, 2008 at 4:37 PM, Dag Sverre Seljebotn
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Charles R Harris wrote:
But mixing python types and numpy types is not a good idea, they
exist
separately and apply to different software
As the latest Cython 0.10 release has some important news for
Cython/NumPy users, I decided to post an announcement (hope that's ok).
Download at http://cython.org
What's new for NumPy users:
1) Support for access to complex float buffers. Cython does not have
native complex float syntax
Charles R Harris wrote:
On Sun, Nov 9, 2008 at 11:44 AM, David Cournapeau [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Mon, Nov 10, 2008 at 2:40 AM, Charles R Harris
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Let me see if I understand this
Gael Varoquaux wrote:
On Fri, Oct 10, 2008 at 04:02:21AM -0700, Scott Askey wrote:
Subject: matlab ss2tf in python/symbol in linear algebra/transfer functions
To: numpy-discussion@scipy.org
Date: Thursday, October 9, 2008, 5:36 PM
Is there a clever way to do symbolic linear algebra with
Richard Shaw wrote:
Hello,
Forgive me if this is a stupid question, I've been looking around all
the Cython documentation and I can't find out if this is possible.
What I would like to do is generally is wrap a C function that takes a
double array, and be able to pass in a numpy array,
Richard Shaw wrote:
Hello,
Forgive me if this is a stupid question, I've been looking around all
the Cython documentation and I can't find out if this is possible.
What I would like to do is generally is wrap a C function that takes a
double array, and be able to pass in a numpy array,
[EMAIL PROTECTED] wrote:
I'm working on getting the Sage matrices for real/complex doubles to use
numpy as a backend. In this, I'm using the PyArray_SETITEM macro from
within Cython. However, Cython wraps the macro in a function call to
convert the output to a Python value:
__pyx_1 =
Manuel Metz wrote:
Claude Gouedard wrote:
Hi ,
I'm just surprised by the behaviour of numpy.asarray on lists.
Can someone comment this :
=
a=(1)
aa=asarray(a)
print aa.size , aa.shape
1 ( )
=
The shape doesnot reflect the actual size.
Claude Gouedard wrote:
Ok ,
The same for asarray(1) ..
The problem is that
aa=asarray(1) is an numpy.array (right ? ) with a size 1 and a shape ( ) !
No surprising ?
I think it is considered a 0-dimensional array (= a scalar).
--
Dag Sverre
___
Cython just had a release, and amongst the new features are efficient
NumPy array indexing for integers, real floats and Python objects.
You can get it at http://cython.org
For those new to Cython, I've written a tutorial specifically targeted
for NumPy users here:
Ondrej Certik wrote:
Hi Christian,
On Mon, Aug 18, 2008 at 11:22 PM, Christian Heimes [EMAIL PROTECTED]
wrote:
Ondrej Certik wrote:
Ok, in the current state, you don't know either what's going to
happen. If you write
In [1]: x/2*3/4
you have no idea what the result is going to be, you
David Cournapeau wrote:
On Mon, 2008-08-04 at 01:50 +0200, Stéfan van der Walt wrote:
Just to be clear: I meant that I agree with you that we should see
NumPy related warnings that aren't smothered in bogus messages. Is
there no way to do this without compiler-specific hacks?
Yes, there
Travis E. Oliphant wrote:
Dag Sverre Seljebotn wrote:
I'd like some advice for what way people feel would be the best for
supporting complex datatypes in NumPy in Cython; as well as ask in what
way it is likely that NumPy will make use of PEP 3118.
It seems like NumPy defines its complex
I'd like some advice for what way people feel would be the best for
supporting complex datatypes in NumPy in Cython; as well as ask in what
way it is likely that NumPy will make use of PEP 3118.
It seems like NumPy defines its complex data to be a struct of two
doubles, for instance:
typedef
Matthew Brett wrote:
Hi,
The feature of compiling code for multiple types is somewhat orthogonal
to
ndarray support; better treat them seperately and take one at the time.
Well, it's relevant to numpy because if you want to implement - for
example - a numpy sort, then you've got to deal
Dag wrote:
General feedback is welcome; in particular, I need more opinions about
what syntax people would like. We seem unable to find something that we
really like; this is the current best candidate (cdef is the way you
declare types on variables in Cython):
cdef int i = 4, j = 6
cdef
Matthew Brett wrote:
Hi,
Thanks a lot for the email - it's an exciting project.
cdef int i = 4, j = 6
cdef np.ndarray[np.float64, 2] arr = np.zeros((10, 10),
dtype=np.float64)
arr[i, j] = 1
I'm afraid I'm going to pitch into an area I'm ignorant of, and I'm
sorry for that, but do you
Joris De Ridder wrote:
Hi Dag,
General feedback is welcome; in particular, I need more opinions about
what syntax people would like. We seem unable to find something that
we
really like; this is the current best candidate (cdef is the way you
declare types on variables in Cython):
cdef
Fernando Perez wrote:
On Fri, Jun 20, 2008 at 11:50 PM, Dag Sverre Seljebotn
[EMAIL PROTECTED] wrote:
Since there's been a lot of Cython discussion lately I thought I'd speak
up and start a thread specifically for my project.
Thanks for coming over for the discussion!
The code above
Anne Archibald wrote:
2008/6/21 Dag Sverre Seljebotn [EMAIL PROTECTED]:
Dag wrote:
General feedback is welcome; in particular, I need more opinions about
what syntax people would like. We seem unable to find something that we
really like; this is the current best candidate (cdef is the way
Keith Goodman wrote:
I'd rather not pull in a scipy dependency for one function if there is
a numpy alternative. I think it is funny that you picked up on my
brief mention of scipy and called it unreasonable.
(I didn't follow this exact discussion, arguing from general principles
here
301 - 400 of 409 matches
Mail list logo
