[Numpy-discussion] Proceedings of EuroSciPy 2014
On Tue, Dec 23, 2014 at 7:06 PM, pdeb...@ulb.ac.be wrote: Dear scientist using Python, We are glad to announce the publication of the proceedings of the 7th European Conference on Python in Science, EuroSciPy 2014, still in 2014! The proceedings cover various scientific fields in which Python and its scientific libraries are used. You may obtain the table of contents and all the articles on the arXiv at http://arxiv.org/abs/1412.7030 For convenience, the articles' titles are listed below. It is a useful reference to have as the publication of software-related scientific work is not always straightforward. Thanks go to all authors and reviewers for their contributions. The reviews were conducted publicly at https://github.com/euroscipy/euroscipy_proceedings Pierre de Buyl Nelle Varoquaux, editors PS: there was no large announcement of the proceedings of EuroSciPy 2013. In the hope that this can increase their visibility, here is the URL Proceedings of EuroSciPy 2013: http://arxiv.org/abs/1405.0166 Pierre de Buyl, Nelle Varoquaux: Preface Jérôme Kieffer, Giannis Ashiotis: PyFAI: a Python library for high performance azimuthal integration on GPU Andrew Leonard, Huw Morgan: Temperature diagnostics of the solar atmosphere using SunPy Bastian Venthur, Benjamin Blankertz: Wyrm, A Pythonic Toolbox for Brain-Computer Interfacing Christophe Pouzat, Georgios Is. Detorakis: SPySort: Neuronal Spike Sorting with Python Thomas Cokelaer, Julio Saez-Rodriguez: Using Python to Dive into Signalling Data with CellNOpt and BioServices Davide Monari, Francesco Cenni, Erwin Aertbeliën, Kaat Desloovere: Py3DFreeHandUS: a library for voxel-array reconstruction using Ultrasonography and attitude sensors Esteban Fuentes, Hector E. Martinez: SClib, a hack for straightforward embedded C functions in Python Jamie A Dean, Liam C Welsh, Kevin J Harrington, Christopher M Nutting, Sarah L Gulliford: Predictive Modelling of Toxicity Resulting from Radiotherapy Treatments of Head and Neck Cancer Rebecca R. Murphy, Sophie E. Jackson, David Klenerman: pyFRET: A Python Library for Single Molecule Fluorescence Data Analysis Robert Cimrman: Enhancing SfePy with Isogeometric Analysis Steve Brasier, Fred Pollard: A Python-based Post-processing Toolset For Seismic Analyses Vladimír Lukeš, Miroslav Jiřík, Alena Jonášová, Eduard Rohan, Ondřej Bublík, Robert Cimrman: Numerical simulation of liver perfusion: from CT scans to FE model ___ euroscipy-org mailing list euroscipy-...@python.org https://mail.python.org/mailman/listinfo/euroscipy-org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] edge-cases of ellipsis indexing
On Mo, 2015-01-05 at 14:13 +0530, Maniteja Nandana wrote: Hi Anthony, I am not sure whether the following section in documentation is relevant to the behavior you were referring to. When an ellipsis (...) is present but has no size (i.e. replaces zero :) the result will still always be an array. A view if no advanced index is present, otherwise a copy. Exactly. There are actually three forms of indexing to distinguish. 1. Indexing with integers (also scalar arrays) matching the number of dimensions. This will return a *scalar*. 2. Slicing, etc. which returns a view. This also occurs as soon there is an ellipsis in there (even if it replaces 0 `:`). You should see it as a feature to get a view if the result might be a scalar otherwise ;)! 3. Advanced indexing which cannot be view based and returns a copy. - Sebastian Here, ...replaces zero : Advanced indexing always returns a copy of the data (contrast with basic slicing that returns a view). And I think it is a view that is returned in this case. a = array([1]) a array([1]) a[:,0] # zero : are present Traceback (most recent call last): File stdin, line 1, in module IndexError: too many indices for array a[...,0]=2 a array([2]) a[0] = 3 a array([3]) a[(0,)] = 4 a array([4]) a[: array([1]) Hope I helped. Cheers, N.Maniteja. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] edge-cases of ellipsis indexing
Hi Anthony, I am not sure whether the following section in documentation is relevant to the behavior you were referring to. When an ellipsis (...) is present but has no size (i.e. replaces zero :) the result will still always be an array. A view if no advanced index is present, otherwise a copy. Here, ...replaces zero : Advanced indexing always returns a *copy* of the data (contrast with basic slicing that returns a *view* http://docs.scipy.org/doc/numpy/glossary.html#term-view). And I think it is a view that is returned in this case. a = array([1]) a array([1]) a[:,0] # zero : are present Traceback (most recent call last): File stdin, line 1, in module IndexError: too many indices for array a[...,0]=2 a array([2]) a[0] = 3 a array([3]) a[(0,)] = 4 a array([4]) a[: array([1]) Hope I helped. Cheers, N.Maniteja. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] The future of ndarray.diagonal()
Konrad Hinsen konrad.hin...@fastmail.net wrote: Scientific communication depends more and more on scripts as the only precise documentation of a computational method. Our programming languages are becoming a major form of scientific notation, alongside traditional mathematics. To me it seems that algorithms in scientific papers and books are described in various forms of pseudo-code. Perhaps we need a notation which is universal and ethernal like the language mathematics. But I am not sure Python could or should try to be that scripting language. I also think it is reasonable to ask if journals should require code as algorithmic documentation to be written in some ISO standard language like C or Fortran 90. The behavior of Python and NumPy are not dictated by standards, and as such is not better than pseudo-code. Sturla ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] The future of ndarray.diagonal()
--On 5 janvier 2015 08:43:45 + Sturla Molden sturla.mol...@gmail.com 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 science are never published in a specific article. Very often, a scientific article gives only an outline of a method in plain English. The only full documentation of the method is the implementation. Perhaps we need a notation which is universal and ethernal like the language mathematics. But I am not sure Python could or should try to be that scripting language. Neither Python nor any other programming was designed for that task, and none of them is really a good fit. But today's de facto situation is that programming languages fulfill the role of algorithmic specification languages in computational science. And I don't expect this to change rapidly, in particular because to the best of my knowledge there is no better choice available at the moment. I wrote an article on this topic that will appear in the March 2015 issue of Computing in Science and Engineering. It concludes that for now, a simple Python script is probably the best you can do for an executable specification of an algorithm. However, I also recommend not using big libraries such as NumPy in such scripts. I also think it is reasonable to ask if journals should require code as algorithmic documentation to be written in some ISO standard language like C or Fortran 90. The behavior of Python and NumPy are not dictated by standards, and as such is not better than pseudo-code. True, but the ISO specifications of C and Fortran have so many holes (undefined behavior) that they are not really much better for the job. And again, we can't ignore the reality of the de facto use today: there are no such requirements or even guidelines, so Python scripts are often the best we have as algorithmic documentation. Konrad. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] The future of ndarray.diagonal()
On 1/5/2015 10:48 AM, josef.p...@gmail.com wrote: Dtypes are a mess (in terms of code compatibility). Matlab is much nicer, it's all just doubles. 1. Thank goodness for dtypes. 2. http://www.mathworks.com/help/matlab/numeric-types.html 3. After translating Matlab code to much nicer NumPy, I cannot find any way to say MATLAB is nicer. Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] The future of ndarray.diagonal()
On Mon, Jan 5, 2015 at 11:13 AM, Alan G Isaac alan.is...@gmail.com wrote: On 1/5/2015 10:48 AM, josef.p...@gmail.com wrote: Dtypes are a mess (in terms of code compatibility). Matlab is much nicer, it's all just doubles. 1. Thank goodness for dtypes. 2. http://www.mathworks.com/help/matlab/numeric-types.html 3. After translating Matlab code to much nicer NumPy, I cannot find any way to say MATLAB is nicer. Maybe it's my selection bias in matlab, I only wrote or read code in matlab that used exclusively double. Of course they are a necessary and great feature. However, life and code would be simpler if we could just do x = np.asarray(x, float) or even x = np.array(x, float) at the beginning of every function, instead of worrying why a user doesn't have float and trying to accommodate that choice. https://github.com/statsmodels/statsmodels/search?q=dtypetype=Issuesutf8=%E2%9C%93 AFAIK, matlab and R still have copy on write, so they don't have to worry about inplace modifications. 5 lines of code to implement an algorithm, and 50 lines of code for input checking. My response was to the issue of code as algorithmic documentation: There are packages or code supplements to books that come with the disclaimer that the code is written for educational purposes, to help understand the algorithm, but is not designed for efficiency or performance or generality. The more powerful the language and the fancier the code, the larger is the maintenance and wrapping work. another example: a dot product of a float/double 2d array is independent of any numpy version, and it will produce the same result in numpy 19.0 (except for different machine precision rounding errors) a dot product of an array (without dtype and shape restriction) might be anything and change within a few numpy versions. Josef Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Characteristic of a Matrix.
On 05-Jan-15 1:56 PM, Davidid wrote: On 5 January 2015 at 20:40, Colin J. Williams cjwilliam...@gmail.com wrote: This illustrates a failure, which is reported later in the calculation: A2= np.matrix([[1, 2, -2], [-3, -1, 4], [4, 2 -6]]) Here 2 - 6 is treated as an expression. There should be a comma between 2 and -6. The rectangularity is checked, and in this case, it is not fulfilled. As such, NumPy creates a square matrix of size 1x1 of dtype object. If you want to make sure what you have manually inputed is correct, you should include a couple of assertions afterwards. /David. David, Thanks. My suggestion was that numpy should do that checking, Colin W. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] edge-cases of ellipsis indexing
I see, thanks! 2015-01-05 2:14 GMT-07:00 Sebastian Berg sebast...@sipsolutions.net: On Mo, 2015-01-05 at 14:13 +0530, Maniteja Nandana wrote: Hi Anthony, I am not sure whether the following section in documentation is relevant to the behavior you were referring to. When an ellipsis (...) is present but has no size (i.e. replaces zero :) the result will still always be an array. A view if no advanced index is present, otherwise a copy. Exactly. There are actually three forms of indexing to distinguish. 1. Indexing with integers (also scalar arrays) matching the number of dimensions. This will return a *scalar*. 2. Slicing, etc. which returns a view. This also occurs as soon there is an ellipsis in there (even if it replaces 0 `:`). You should see it as a feature to get a view if the result might be a scalar otherwise ;)! 3. Advanced indexing which cannot be view based and returns a copy. - Sebastian Here, ...replaces zero : Advanced indexing always returns a copy of the data (contrast with basic slicing that returns a view). And I think it is a view that is returned in this case. a = array([1]) a array([1]) a[:,0] # zero : are present Traceback (most recent call last): File stdin, line 1, in module IndexError: too many indices for array a[...,0]=2 a array([2]) a[0] = 3 a array([3]) a[(0,)] = 4 a array([4]) a[: array([1]) Hope I helped. Cheers, N.Maniteja. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Characteristic of a Matrix.
Nathaniel,
This is not a comment on any present matrix support, but deals with
the matrix class, which existed back when Todd Miller of the Space
Telescope Group supported numpy.
Matrix is a sub-class of ndarray.
I'm suggesting that anything which is produced by this class should
be checked for the Characteristics of a Matrix. These
characteristics include:
a rectangular array; and
all numeric values.
Others might suggest other characteristics.
I suggest that any matrix which is returned should check the
characteristics and reject any incompatible cases.
An example of a failure was given:
A1= np.matrix([[1, 2, -2], [-3, -1, 4], [4, 2 -6]])
A comma was missing
Subsequent statements might have been shown:
print('A1=', A1)
print ('Identity: A1 * A1.I: ', A1 * A1.I) ## Grief here numpy
# Reported in a misleading way:
# Traceback (most
recent call last):
# File
"string", line 254, in run_nodebug
# File
"C:\Users\cjw_2\Documents \stephanie.py", line 31, in
module
# print
('Identity: A1 * A1.I: ', A1 * A1.I) ## Grief here numpy
# File
"C:\Python27\lib\site-packages\numpy\matrixlib\defmatrix.py", line
870, in getI
# return
asmatrix(func(self))
# File
"C:\Python27\lib\site-packages\numpy\linalg\linalg.py", line 1584,
in pinv
# a =
a.conjugate()
# AttributeError:
'list' object has no attribute 'conjugate'
#
A check up front would have been more helpful, especially for a user
who is not familiar with Numpy.
I hope that this is clearer.
Colin W.
On 05-Jan-15 1:58 PM, Nathaniel Smith
wrote:
I'm afraid that I really don't understand what you're trying to say. Is
there something that you think numpy should be doing differently?
On Mon, Jan 5, 2015 at 6:40 PM, Colin J. Williams cjwilliam...@gmail.com
wrote:
One of the essential characteristics of a matrix is that it be rectangular.
This is neither spelt out or checked currently.
The Doc description refers to a class:
- *class *numpy.matrix[source]
http://github.com/numpy/numpy/blob/v1.9.1/numpy/matrixlib/defmatrix.py#L206
Returns a matrix from an array-like object, or from a string of data. A
matrix is aspecialized 2-D array that retains its 2-D
nature through operations. It has certain special operators, such as *
(matrix multiplication) and ** (matrix power).
This illustrates a failure, which is reported later in the calculation:
A2= np.matrix([[1, 2, -2], [-3, -1, 4], [4, 2 -6]])
Here 2 - 6 is treated as an _expression_.
Wikipedia offers:
In mathematics http://en.wikipedia.org/wiki/Mathematics, a *matrix*
(plural *matrices*) is a rectangular
http://en.wikipedia.org/wiki/Rectangle *array
http://en.wiktionary.org/wiki/array*[1]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-1 of
numbers http://en.wikipedia.org/wiki/Number, symbols
http://en.wikipedia.org/wiki/Symbol_%28formal%29, or expressions
http://en.wikipedia.org/wiki/Expression_%28mathematics%29, arranged in *rows
http://en.wiktionary.org/wiki/row* and *columns
http://en.wiktionary.org/wiki/column*.[2]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-2[3]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-3 The
individual items in a matrix are called its *elements* or *entries*. An
example of a matrix with 2 rows and 3 columns is
[image: \begin{bmatrix}1 9 -13 \\20 5 -6 \end{bmatrix}.]In the
Numpy context, the symbols or expressions need to be evaluable.
Colin W.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Characteristic of a Matrix.
One of the essential characteristics of a matrix is that it be rectangular.
This is neither spelt out or checked currently.
The Doc description refers to a class:
- *class *numpy.matrix[source]
http://github.com/numpy/numpy/blob/v1.9.1/numpy/matrixlib/defmatrix.py#L206
Returns a matrix from an array-like object, or from a string of data. A
matrix is aspecialized 2-D array that retains its 2-D
nature through operations. It has certain special operators, such as *
(matrix multiplication) and ** (matrix power).
This illustrates a failure, which is reported later in the calculation:
A2= np.matrix([[1, 2, -2], [-3, -1, 4], [4, 2 -6]])
Here 2 - 6 is treated as an expression.
Wikipedia offers:
In mathematics http://en.wikipedia.org/wiki/Mathematics, a *matrix*
(plural *matrices*) is a rectangular
http://en.wikipedia.org/wiki/Rectangle *array
http://en.wiktionary.org/wiki/array*[1]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-1 of
numbers http://en.wikipedia.org/wiki/Number, symbols
http://en.wikipedia.org/wiki/Symbol_%28formal%29, or expressions
http://en.wikipedia.org/wiki/Expression_%28mathematics%29, arranged in *rows
http://en.wiktionary.org/wiki/row* and *columns
http://en.wiktionary.org/wiki/column*.[2]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-2[3]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-3 The
individual items in a matrix are called its *elements* or *entries*. An
example of a matrix with 2 rows and 3 columns is
[image: \begin{bmatrix}1 9 -13 \\20 5 -6 \end{bmatrix}.]In the
Numpy context, the symbols or expressions need to be evaluable.
Colin W.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Characteristic of a Matrix.
On 5 January 2015 at 20:40, Colin J. Williams cjwilliam...@gmail.com wrote: This illustrates a failure, which is reported later in the calculation: A2= np.matrix([[1, 2, -2], [-3, -1, 4], [4, 2 -6]]) Here 2 - 6 is treated as an expression. There should be a comma between 2 and -6. The rectangularity is checked, and in this case, it is not fulfilled. As such, NumPy creates a square matrix of size 1x1 of dtype object. If you want to make sure what you have manually inputed is correct, you should include a couple of assertions afterwards. /David. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Characteristic of a Matrix.
Hi,
On Mon, Jan 5, 2015 at 8:40 PM, Colin J. Williams cjwilliam...@gmail.com
wrote:
One of the essential characteristics of a matrix is that it be rectangular.
This is neither spelt out or checked currently.
The Doc description refers to a class:
- *class *numpy.matrix[source]
http://github.com/numpy/numpy/blob/v1.9.1/numpy/matrixlib/defmatrix.py#L206
Returns a matrix from an array-like object, or from a string of data. A
matrix is aspecialized 2-D array that retains its 2-D
nature through operations. It has certain special operators, such as *
(matrix multiplication) and ** (matrix power).
This illustrates a failure, which is reported later in the calculation:
A2= np.matrix([[1, 2, -2], [-3, -1, 4], [4, 2 -6]])
Here 2 - 6 is treated as an expression.
FWIW, here A2 is definitely rectangular, with shape== (1, 3) and dtype==
object, i.e elements are just python lists.
Wikipedia offers:
In mathematics http://en.wikipedia.org/wiki/Mathematics, a *matrix*
(plural *matrices*) is a rectangular
http://en.wikipedia.org/wiki/Rectangle *array
http://en.wiktionary.org/wiki/array*[1]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-1 of
numbers http://en.wikipedia.org/wiki/Number, symbols
http://en.wikipedia.org/wiki/Symbol_%28formal%29, or expressions
http://en.wikipedia.org/wiki/Expression_%28mathematics%29, arranged in *rows
http://en.wiktionary.org/wiki/row* and *columns
http://en.wiktionary.org/wiki/column*.[2]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-2[3]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-3
(and in this context also python objects).
-eat
The individual items in a matrix are called its *elements* or *entries*.
An example of a matrix with 2 rows and 3 columns is
[image: \begin{bmatrix}1 9 -13 \\20 5 -6 \end{bmatrix}.]In the
Numpy context, the symbols or expressions need to be evaluable.
Colin W.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Characteristic of a Matrix.
I'm afraid that I really don't understand what you're trying to say. Is
there something that you think numpy should be doing differently?
On Mon, Jan 5, 2015 at 6:40 PM, Colin J. Williams cjwilliam...@gmail.com
wrote:
One of the essential characteristics of a matrix is that it be rectangular.
This is neither spelt out or checked currently.
The Doc description refers to a class:
- *class *numpy.matrix[source]
http://github.com/numpy/numpy/blob/v1.9.1/numpy/matrixlib/defmatrix.py#L206
Returns a matrix from an array-like object, or from a string of data. A
matrix is aspecialized 2-D array that retains its 2-D
nature through operations. It has certain special operators, such as *
(matrix multiplication) and ** (matrix power).
This illustrates a failure, which is reported later in the calculation:
A2= np.matrix([[1, 2, -2], [-3, -1, 4], [4, 2 -6]])
Here 2 - 6 is treated as an expression.
Wikipedia offers:
In mathematics http://en.wikipedia.org/wiki/Mathematics, a *matrix*
(plural *matrices*) is a rectangular
http://en.wikipedia.org/wiki/Rectangle *array
http://en.wiktionary.org/wiki/array*[1]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-1 of
numbers http://en.wikipedia.org/wiki/Number, symbols
http://en.wikipedia.org/wiki/Symbol_%28formal%29, or expressions
http://en.wikipedia.org/wiki/Expression_%28mathematics%29, arranged in *rows
http://en.wiktionary.org/wiki/row* and *columns
http://en.wiktionary.org/wiki/column*.[2]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-2[3]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-3 The
individual items in a matrix are called its *elements* or *entries*. An
example of a matrix with 2 rows and 3 columns is
[image: \begin{bmatrix}1 9 -13 \\20 5 -6 \end{bmatrix}.]In the
Numpy context, the symbols or expressions need to be evaluable.
Colin W.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Characteristic of a Matrix.
On Mon, Jan 5, 2015 at 1:58 PM, Nathaniel Smith n...@pobox.com wrote:
I'm afraid that I really don't understand what you're trying to say. Is
there something that you think numpy should be doing differently?
This is a case similar to the issue discussed in
https://github.com/numpy/numpy/issues/5303. Instead of getting an error
(because the arguments don't create the expected 2-d matrix), a matrix with
dtype object and shape (1, 3) is created.
Warren
On Mon, Jan 5, 2015 at 6:40 PM, Colin J. Williams cjwilliam...@gmail.com
wrote:
One of the essential characteristics of a matrix is that it be
rectangular.
This is neither spelt out or checked currently.
The Doc description refers to a class:
- *class *numpy.matrix[source]
http://github.com/numpy/numpy/blob/v1.9.1/numpy/matrixlib/defmatrix.py#L206
Returns a matrix from an array-like object, or from a string of data. A
matrix is aspecialized 2-D array that retains its 2-D
nature through operations. It has certain special operators, such as *
(matrix multiplication) and ** (matrix power).
This illustrates a failure, which is reported later in the calculation:
A2= np.matrix([[1, 2, -2], [-3, -1, 4], [4, 2 -6]])
Here 2 - 6 is treated as an expression.
Wikipedia offers:
In mathematics http://en.wikipedia.org/wiki/Mathematics, a *matrix*
(plural *matrices*) is a rectangular
http://en.wikipedia.org/wiki/Rectangle *array
http://en.wiktionary.org/wiki/array*[1]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-1 of
numbers http://en.wikipedia.org/wiki/Number, symbols
http://en.wikipedia.org/wiki/Symbol_%28formal%29, or expressions
http://en.wikipedia.org/wiki/Expression_%28mathematics%29, arranged in
*rows
http://en.wiktionary.org/wiki/row* and *columns
http://en.wiktionary.org/wiki/column*.[2]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-2[3]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-3 The
individual items in a matrix are called its *elements* or *entries*. An
example of a matrix with 2 rows and 3 columns is
[image: \begin{bmatrix}1 9 -13 \\20 5 -6 \end{bmatrix}.]In the
Numpy context, the symbols or expressions need to be evaluable.
Colin W.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Characteristic of a Matrix.
On Mon, Jan 5, 2015 at 1:58 PM, Nathaniel Smith n...@pobox.com wrote:
I'm afraid that I really don't understand what you're trying to say. Is
there something that you think numpy should be doing differently?
I liked it better when this raised an exception, instead of creating a
rectangular object array.
Josef
On Mon, Jan 5, 2015 at 6:40 PM, Colin J. Williams cjwilliam...@gmail.com
wrote:
One of the essential characteristics of a matrix is that it be
rectangular.
This is neither spelt out or checked currently.
The Doc description refers to a class:
- *class *numpy.matrix[source]
http://github.com/numpy/numpy/blob/v1.9.1/numpy/matrixlib/defmatrix.py#L206
Returns a matrix from an array-like object, or from a string of data. A
matrix is aspecialized 2-D array that retains its 2-D
nature through operations. It has certain special operators, such as *
(matrix multiplication) and ** (matrix power).
This illustrates a failure, which is reported later in the calculation:
A2= np.matrix([[1, 2, -2], [-3, -1, 4], [4, 2 -6]])
Here 2 - 6 is treated as an expression.
Wikipedia offers:
In mathematics http://en.wikipedia.org/wiki/Mathematics, a *matrix*
(plural *matrices*) is a rectangular
http://en.wikipedia.org/wiki/Rectangle *array
http://en.wiktionary.org/wiki/array*[1]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-1 of
numbers http://en.wikipedia.org/wiki/Number, symbols
http://en.wikipedia.org/wiki/Symbol_%28formal%29, or expressions
http://en.wikipedia.org/wiki/Expression_%28mathematics%29, arranged in
*rows
http://en.wiktionary.org/wiki/row* and *columns
http://en.wiktionary.org/wiki/column*.[2]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-2[3]
http://en.wikipedia.org/wiki/Matrix_%28mathematics%29#cite_note-3 The
individual items in a matrix are called its *elements* or *entries*. An
example of a matrix with 2 rows and 3 columns is
[image: \begin{bmatrix}1 9 -13 \\20 5 -6 \end{bmatrix}.]In the
Numpy context, the symbols or expressions need to be evaluable.
Colin W.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Characteristic of a Matrix.
On Mon, Jan 5, 2015 at 7:18 PM, josef.p...@gmail.com wrote: On Mon, Jan 5, 2015 at 1:58 PM, Nathaniel Smith n...@pobox.com wrote: I'm afraid that I really don't understand what you're trying to say. Is there something that you think numpy should be doing differently? I liked it better when this raised an exception, instead of creating a rectangular object array. Did it really used to raise an exception? Patches accepted :-) (#5303 is the relevant bug, like Warren points out. From the discussion there it doesn't look like np.array's handling of non-conformable lists has any defenders.) -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Characteristic of a Matrix.
On Mon, Jan 5, 2015 at 2:36 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Jan 5, 2015 at 7:18 PM, josef.p...@gmail.com wrote: On Mon, Jan 5, 2015 at 1:58 PM, Nathaniel Smith n...@pobox.com wrote: I'm afraid that I really don't understand what you're trying to say. Is there something that you think numpy should be doing differently? I liked it better when this raised an exception, instead of creating a rectangular object array. Did it really used to raise an exception? Patches accepted :-) (#5303 is the relevant bug, like Warren points out. From the discussion there it doesn't look like np.array's handling of non-conformable lists has any defenders.) Since I'm usually late in updating numpy, I was for a long time very familiar with the frequent occurence of `ValueError: setting an array element with a sequence.` based on this, it was up to numpy 1.5 https://github.com/scipy/scipy/pull/2631#issuecomment-20898809 ugly but backwards compatible :) Josef -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Characteristic of a Matrix.
On Mon, Jan 5, 2015 at 9:36 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Jan 5, 2015 at 7:18 PM, josef.p...@gmail.com wrote: On Mon, Jan 5, 2015 at 1:58 PM, Nathaniel Smith n...@pobox.com wrote: I'm afraid that I really don't understand what you're trying to say. Is there something that you think numpy should be doing differently? I liked it better when this raised an exception, instead of creating a rectangular object array. Did it really used to raise an exception? Patches accepted :-) (#5303 is the relevant bug, like Warren points out. From the discussion there it doesn't look like np.array's handling of non-conformable lists has any defenders.) +1 for 'object array [and matrix] construction should require explicitly specifying dtype= object' -eat -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] The future of ndarray.diagonal()
On Mon, Jan 5, 2015 at 4:08 AM, Konrad Hinsen konrad.hin...@fastmail.net wrote: --On 5 janvier 2015 08:43:45 + Sturla Molden sturla.mol...@gmail.com 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 science are never published in a specific article. Very often, a scientific article gives only an outline of a method in plain English. The only full documentation of the method is the implementation. Perhaps we need a notation which is universal and ethernal like the language mathematics. But I am not sure Python could or should try to be that scripting language. Neither Python nor any other programming was designed for that task, and none of them is really a good fit. But today's de facto situation is that programming languages fulfill the role of algorithmic specification languages in computational science. And I don't expect this to change rapidly, in particular because to the best of my knowledge there is no better choice available at the moment. I wrote an article on this topic that will appear in the March 2015 issue of Computing in Science and Engineering. It concludes that for now, a simple Python script is probably the best you can do for an executable specification of an algorithm. However, I also recommend not using big libraries such as NumPy in such scripts. I also think it is reasonable to ask if journals should require code as algorithmic documentation to be written in some ISO standard language like C or Fortran 90. The behavior of Python and NumPy are not dictated by standards, and as such is not better than pseudo-code. True, but the ISO specifications of C and Fortran have so many holes (undefined behavior) that they are not really much better for the job. And again, we can't ignore the reality of the de facto use today: there are no such requirements or even guidelines, so Python scripts are often the best we have as algorithmic documentation. Matlab is more well defined than numpy. numpy has too many features. I think, if you want a runnable python script as algorithmic documentation, then it will be necessary and relatively easy in most cases to stick to the stable basic features. The same for a library, if we want to minimize compatibility problems, then we shouldn't use features that are most likely a moving target. One of the issues is whether we want to write safe or fancy code. (Fancy code might or will be faster, with a specific version.) For example in most of my use cases having a view or copy of an array makes a difference to the performance but not the results. I didn't participate in the `diagonal` debate because I don't have a strong opinion and don't use it with an assignment. There is an explicit np.fill_diagonal that is inplace. Having views or copies of arrays never sounded like having a clear cut answer, there are too many functions that return views if possible. When our (statsmodels) code correctness depends on whether it's a view or copy, then we usually make sure and write the matching unit tests. Other cases, the behavior of numpy in edge cases like empty arrays is still in flux. We usually try to avoid relying on implicit behavior. Dtypes are a mess (in terms of code compatibility). Matlab is much nicer, it's all just doubles. Now pandas and numpy are making object arrays popular and introduce strange things like datetime dtypes, and users think a program written a while ago can handle them. Related compatibility issue python 2 and python 3: For non-string manipulation scientific code the main limitation is to avoid version specific features, and decide when to use lists versus iterators for range, zip, map. Other than that, it looks much simpler to me than expected. Overall I think the current policy of incremental changes in numpy works very well. Statsmodels needs a few minor adjustments in each version. But most of those are for cases where numpy became more strict or where we used a specific behavior in edge cases, AFAIR. One problem with accumulating changes for a larger version change like numpy 2 or 3 or 4 is to decide what changes would require this. Most changes will break some code, if the code requires or uses some exotic or internal behavior. If we want to be strict, then we don't change the policy but change the version numbers, instead of 1.8, 1.9 we have numpy 18 and numpy 19. However, from my perspective none of the recent changes were fundamental enough. BTW: Stata is versioning scripts. Each script can define for which version of Stata it was written, but I have no idea how they handle the compatibility issues. It looks to me that it would be way too much work to do something like this in an open source project. Legacy cleanups like removal of numeric compatibility in numpy or weave (and
