Re: [Numpy-discussion] edge-cases of ellipsis indexing

[Maniteja Nandana]

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*
).
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 "", line 1, in 
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()

[Sturla Molden]

Konrad Hinsen  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()

[Konrad Hinsen]

--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 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] edge-cases of ellipsis indexing

[Sebastian Berg]

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 "", line 1, in 
> 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] The future of ndarray.diagonal()

[josef.pktd]

On Mon, Jan 5, 2015 at 4:08 AM, Konrad Hinsen 
wrote:

> --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 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 we

Re: [Numpy-discussion] The future of ndarray.diagonal()

[Alan G Isaac]

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()

[josef.pktd]

On Mon, Jan 5, 2015 at 11:13 AM, Alan G Isaac  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=dtype&type=Issues&utf8=%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

[Numpy-discussion] Characteristic of a Matrix.

[Colin J. Williams]

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]
   

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 , a *matrix*
(plural *matrices*) is a rectangular
 *array
*[1]
 of
numbers , symbols
, or expressions
, arranged in *rows
* and *columns
*.[2]
[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.

[Daπid]

On 5 January 2015 at 20:40, Colin J. Williams 
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.

[eat]

Hi,


On Mon, Jan 5, 2015 at 8:40 PM, Colin J. Williams 
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]
>
> 
>
> 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 , a *matrix*
> (plural *matrices*) is a rectangular
>  *array
> *[1]
>  of
> numbers , symbols
> , or expressions
> , arranged in *rows
> * and *columns
> *.[2]
> [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.

[Nathaniel Smith]

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 
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]
>
> 
>
> 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 , a *matrix*
> (plural *matrices*) is a rectangular
>  *array
> *[1]
>  of
> numbers , symbols
> , or expressions
> , arranged in *rows
> * and *columns
> *.[2]
> [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.

[Warren Weckesser]

On Mon, Jan 5, 2015 at 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?
>
>

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 
> 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]
>>
>> 
>>
>> 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 , a *matrix*
>> (plural *matrices*) is a rectangular
>>  *array
>> *[1]
>>  of
>> numbers , symbols
>> , or expressions
>> , arranged in 
>> *rows
>> * and *columns
>> *.[2]
>> [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.

[josef.pktd]

On Mon, Jan 5, 2015 at 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?
>


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 
> 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]
>>
>> 
>>
>> 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 , a *matrix*
>> (plural *matrices*) is a rectangular
>>  *array
>> *[1]
>>  of
>> numbers , symbols
>> , or expressions
>> , arranged in 
>> *rows
>> * and *columns
>> *.[2]
>> [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.

[Nathaniel Smith]

On Mon, Jan 5, 2015 at 7:18 PM,  wrote:
>
>
>
> On Mon, Jan 5, 2015 at 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?
>
>
> 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.

[josef.pktd]

On Mon, Jan 5, 2015 at 2:36 PM, Nathaniel Smith  wrote:

> On Mon, Jan 5, 2015 at 7:18 PM,  wrote:
> >
> >
> >
> > On Mon, Jan 5, 2015 at 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?
> >
> >
> > 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.

[eat]

On Mon, Jan 5, 2015 at 9:36 PM, Nathaniel Smith  wrote:

> On Mon, Jan 5, 2015 at 7:18 PM,  wrote:
> >
> >
> >
> > On Mon, Jan 5, 2015 at 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?
> >
> >
> > 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] Characteristic of a Matrix.

[cjw]

On 05-Jan-15 1:56 PM, David€id wrote:
> On 5 January 2015 at 20:40, Colin J. Williams 
> 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] Characteristic of a Matrix.

[cjw]

  
  
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
  "", line 254, in run_nodebug
      #  File
  "C:\Users\cjw_2\Documents       \stephanie.py", line 31, in
  
      #    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 
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]
   

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 , a *matrix*
(plural *matrices*) is a rectangular
 *array
*[1]
 of
numbers , symbols
, or expressions
, arranged in *rows
* and *columns
*.[2]
[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

Re: [Numpy-discussion] edge-cases of ellipsis indexing

[Antony Lee]

I see, thanks!

2015-01-05 2:14 GMT-07:00 Sebastian Berg :

> 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 "", line 1, in 
> > 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

[Numpy-discussion] Proceedings of EuroSciPy 2014

[Ralf Gommers]

On Tue, Dec 23, 2014 at 7:06 PM,  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