--On 5 janvier 2015 08:43:45 + Sturla Molden
wrote:
> To me it seems that algorithms in scientific papers and books are
> described in various forms of pseudo-code.
That's indeed what people do when they write a paper about an algorithm.
But many if not most algorithms in computational sci
On 04/01/15 21:28, Sturla Molden wrote:
> A scientific paper or thesis should be written so it is completely
> reproducible. That would include describing the computer, OS, Python
> version and NumPy version, as well as C or Fortran compiler.
I completely agree and we should all work towards this
On 04/01/15 21:55, Sturla Molden wrote:
> On 03/01/15 20:49, Nathaniel Smith wrote:
>
>> OTOH the big problem that motivated his post was that his code is
>> all written against the APIs of the ancient and long-abandoned Numeric
>> project, and he finds the costs of transitioning them to the "new"
On 03/01/15 20:49, Nathaniel Smith wrote:
> The post you cite brings this up explicitly:
>
> > [3] http://khinsen.wordpress.com/2014/09/12/the-state-of-numpy/
>
> I have huge respect for the problems and pain that Konrad describes in
> this blog post, but I really can't agree with the argument or
On 8 oct. 11, at 17:57, Vicente Sole wrote:
> I have never seen myself a NetCDF file but if your NetCDF file is
> using HDF5 as format (possible since NetCDF 4 if I am not mistaken),
> you should be able to use h5py or PyTables to access and or modify it.
I haven't tried this, but I don't think i
On 22 Aug 2011, at 14:50, Travis Oliphant wrote:
> This goes into the category of "feature". Structured arrays use
> tuples to indicate a record. So, (only) when using structured
> arrays as a dtype, there is a difference between lists and
> tuples.In this case, array sees the tuple a
Hi everyone,
I just stumbled on a behavior in NumPy for which I can't find an
explanation in the documentation. I wonder whether this is a bug or an
undocumented (or badly documented) feature:
--
import numpy
On Apr 15, 2008, at 11:41, Gael Varoquaux wrote:
> On Tue, Apr 15, 2008 at 01:38:45AM -0500, Robert Kern wrote:
>>> Given that the next release will be 1.1, I think it is
>>> reasonable to
>>> include a few additional API breaks.
>
>> -lots. I don't want to break API compatibility again no mat
On 07.03.2008, at 09:59, Fernando Perez wrote:
> I doubt it's much better, and that's part of the point of the project:
> to identify the problems and fix them once and for all. Getting
> anything fixed in pyrex was hard due to a very opaque development
> process, but Cython is part of the Sage u
On Feb 22, 2008, at 15:55, Travis E. Oliphant wrote:
>> ColumnVector, and RowVector. It would work like this:
>>
>> m = Matrix([[1, 2], [3, 4]])
>>
>> m[0, :] --> ColumnVector([1, 3])
>> m[:, 0] --> RowVector([1, 2])
>>
> These seem backward to me.I would think that m[0,:] would be the
> RowV
On 22.02.2008, at 01:10, Alan G Isaac wrote:
> Someone once pointed out on this list that one might
> consider a matrix to be a container of 1d vectors. For NumPy,
> however, it is natural that it be a container of 1d arrays.
> (See the discussion for the distinction.)
If I were to design a Pyth
On 21.02.2008, at 18:40, Alan G Isaac wrote:
x = N.array([1,2],dtype='float')
x0 = x[0]
type(x0)
>
>
> So a "float64 value" is whatever a numpy.float64 is,
> and that is part of what is under discussion.
numpy.float64 is a very recent invention. During the first decade of
On Feb 21, 2008, at 18:08, Alan G Isaac wrote:
> I do not think anyone has really defended this behavior,
> *but* the reply to me when I suggested that a matrix
> contains arrays and we should see that in its behavior
> was that, no, a matrix is a container of matrices so this is
> what you get.
On Feb 21, 2008, at 16:03, Travis E. Oliphant wrote:
> However, I think my proposal for limited indexing capabilities
> should be
> considered separately from coercion behavior of NumPy scalars. NumPy
> scalars are intentionally different from Python scalars, and I see
> this
> difference gro
On 21.02.2008, at 08:41, Francesc Altet wrote:
> Well, it seems like a non-intrusive modification, but I like the
> scalars
> to remain un-indexable, mainly because it would be useful to raise an
> error when you are trying to index them. In fact, I thought that when
> you want a kind of scalar
operations.
Konrad.
--
---------
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expériences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mai
Python/ScientificPythonManual/
It probably has a steeper learning curve, but it is suitable for more
complex parallel programs because it permits the construction of
parallel libraries.
Konrad.
--
---------
Konrad Hinsen
Centre de
cdf is not based on the latest release of the
ScientificPython code, which contains various bug fixes. You might be
better off using ScientificPython 2.7, which works pretty well with
NumPy these days.
Konrad.
--
---------
Konrad Hinse
g. those who want an API that resembles the C API for
netCDF. Fortunately, there is something for everybody.
Konrad.
--
---------
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expérienc
guishing Python
2.5 from its predecessors as well? In other words, is that a test
that one could add to every header file to avoid problems? That's
what I am looking for...
Konrad.
--
-----
Konrad Hinsen
Centre de Biophysique
and Python < 2.5, because both NumPy and ScientificPython
define Py_ssize_t. There doesn't seem to be a nice solution for that
problem, unfortunately.
Konrad.
--
---------
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS O
against mistakes: with arrays, additional checks for
shape and element size would be needed to make code robust.
4) Performance (especially memory-wise).
Konrad.
--
---------
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orl
lcome, ideally through the Web site mentioned above.
Konrad.
--
-
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expériences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33
;ll not get it really cheaper
> I think.
What I expect to be costly is the reshape (resize in most
situations), not the multiplication. I didn't do any timings though...
Konrad
--
---------
Konrad Hinsen
Centre de Biophysique
.typecode())
that will *also* (not *only*) work under NumPy (where typecode()
became dtype.char). An obvious idea is reshaping array1 and
multiplying by 0., but that can become quite costly.
Any ideas?
Konrad.
--
-
Konrad
25 matches
Mail list logo
