Re: [Numpy-discussion] Support of '@='?

[Hans Larsen]

I thank you for the answer!!!

Bu this with "temp" is also in core-Python bihind the scene!;-)



Den 22-06-2016 kl. 21:39 skrev Nathaniel Smith:


To repeat and (hopefully) clarify/summarize the other answers:

It's been left out on purpose so far.

Why was it left out? A few reasons:

- Usually in-place operations like "a += b" are preferred over the 
out-of-place equivalents like "a[...] = a + b" because they avoid some 
copies and potentially large temporary arrays. But for @= this is 
impossible -- you have to make a temporary copy of the whole matrix, 
because otherwise you find yourself writing output elements on top of 
input elements that you're still using. So it's probably better style 
to write this as "a[...] = a @ b": this makes it more clear to the 
reader that a potentially large temporary array is being allocated.


- The one place where this doesn't apply, and where "a @= b" really 
could be a performance win, is when working with higher dimensional 
stacks of matrices. In this case we still have to make a temporary 
copy of each matrix, but only of one matrix at a time, not the whole 
stack together.


- But, not that many people are using matrix stacks yet, and in any 
case "a @= b" is limited to cases where both matrices are square. And 
making it efficient in the stacked case may require some non-trivial 
surgery on the internals. So there hasn't been much urgency to fix this.


My guess is that eventually it will be supported because the stacked 
matrix use case is somewhat compelling, but it will take a bit until 
someone (maybe you!) decides they care enough and have the time/energy 
to fix it.


-n

On Jun 21, 2016 17:39, "Hans Larsen" > wrote:


I have Python 3-5-1 and NumPy 1-11! windows 64bits!
When will by side 'M=M@P' be supported with 'M@=P'???:-(

-- 
Hans Larsen Galgebakken Sønder 4-11A 2620 Albertslund Danmark/Danio

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org 
https://mail.scipy.org/mailman/listinfo/numpy-discussion



___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion


--
Hans Larsen Galgebakken Sønder 4-11A 2620 Albertslund Danmark/Danio
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support of '@='?

[Nathaniel Smith]

To repeat and (hopefully) clarify/summarize the other answers:

It's been left out on purpose so far.

Why was it left out? A few reasons:

- Usually in-place operations like "a += b" are preferred over the
out-of-place equivalents like "a[...] = a + b" because they avoid some
copies and potentially large temporary arrays. But for @= this is
impossible -- you have to make a temporary copy of the whole matrix,
because otherwise you find yourself writing output elements on top of input
elements that you're still using. So it's probably better style to write
this as "a[...] = a @ b": this makes it more clear to the reader that a
potentially large temporary array is being allocated.

- The one place where this doesn't apply, and where "a @= b" really could
be a performance win, is when working with higher dimensional stacks of
matrices. In this case we still have to make a temporary copy of each
matrix, but only of one matrix at a time, not the whole stack together.

- But, not that many people are using matrix stacks yet, and in any case "a
@= b" is limited to cases where both matrices are square. And making it
efficient in the stacked case may require some non-trivial surgery on the
internals. So there hasn't been much urgency to fix this.

My guess is that eventually it will be supported because the stacked matrix
use case is somewhat compelling, but it will take a bit until someone
(maybe you!) decides they care enough and have the time/energy to fix it.

-n
On Jun 21, 2016 17:39, "Hans Larsen"  wrote:

> I have Python 3-5-1 and NumPy 1-11! windows 64bits!
> When will by side 'M=M@P' be supported with 'M@=P'???:-(
>
> --
> Hans Larsen Galgebakken Sønder 4-11A 2620 Albertslund Danmark/Danio
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support of '@='?

[Marten van Kerkwijk]

>
> Just if you are curious why it is an error at the moment. We can't have
> it be filled in by python to be not in-place (`M = M @ P` meaning), but
> copying over the result is a bit annoying and nobody was quite sure
> about it, so it was delayed.


The problem with using out in-place is clear from trying `np.matmul(a, a,
out=a)`:
```
In [487]: a
array([[ 1.   ,  0.   ,  0.   ],
   [ 0.   ,  0.8660254,  0.5  ],
   [ 0.   , -0.5  ,  0.8660254]])

In [488]: np.matmul(a, a)
Out[488]:
array([[ 1.   ,  0.   ,  0.   ],
   [ 0.   ,  0.5  ,  0.8660254],
   [ 0.   , -0.8660254,  0.5  ]])

In [489]: np.matmul(a, a, out=a)
Out[489]:
array([[ 0.,  0.,  0.],
   [ 0.,  0.,  0.],
   [ 0.,  0.,  0.]])
```

It would seem hard to avoid doing the copying (though obviously one should
iterate over higher dimensiones, ie., temp.shape = M.shape[-2:]). Not
dissimilar from cumsum etc which are also not true ufuncs (but where things
can be made to work by ensuring operations are doing in the right order).

-- Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support of '@='?

[Sebastian Berg]

On Mi, 2016-06-22 at 02:38 +0200, Hans Larsen wrote:
> I have Python 3-5-1 and NumPy 1-11! windows 64bits!
> When will by side 'M=M@P' be supported with 'M@=P'???:-(
> 

When someone gets around to making it a well defined operation? ;) Just
to be clear, `M = M @ P` is probably not what `M @= P` is, because the
result of that should probably be `temp = M @ P; M[...] = temp`.
Now this operation needs copy back to the original array from a
temporary array (you can't do it in-place, because you still need the
values in M after overwriting them if you would).

Just if you are curious why it is an error at the moment. We can't have
it be filled in by python to be not in-place (`M = M @ P` meaning), but
copying over the result is a bit annoying and nobody was quite sure
about it, so it was delayed.

- Sebastian

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Support of '@='?

[Hans Larsen]

I have Python 3-5-1 and NumPy 1-11! windows 64bits!
When will by side 'M=M@P' be supported with 'M@=P'???:-(

--
Hans Larsen Galgebakken Sønder 4-11A 2620 Albertslund Danmark/Danio
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support of @= in numpy?

[Sturla Molden]

Charles R Harris  wrote:

> In any case, we support the `@` operator in 1.10, but not the `@=`
> operator. The `@=` operator is tricky to have true inplace matrix
> multiplication, as not only are elements on the left overwritten, but the
> dimensions need to be preserved.

As long as we use BLAS, we can never have true inplace matrix
multiplication because Fortran prohibits pointer aliasing. We therefore
need to make a temporary copy before we call BLAS.

But as for preserving dimensions: This should be allowed if the array is
square. 

Sturla

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Support of @= in numpy?

[Hans Larsen]

I have a Python3.5.1 64bits on Windows 10 same bit-length!
I want to knowing when and what version of numpy, that support @= ?
I have a functional numpy-1-10-1!=-O

--
Hans Larsen Galgebakken Sønder 4-11A 2620 Albertslund Danmark/Danio
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support of @= in numpy?

[Hans Larsen]

Den 26-12-2015 kl. 17:26 skrev Charles R Harris:

I just haven get NumPy ver. 1-10-2: Also in this @= is'n supported!:-(




On Sat, Dec 26, 2015 at 9:06 AM, Hans Larsen > wrote:


I have a Python3.5.1 64bits on Windows 10 same bit-length!
I want to knowing when and what version of numpy, that support @= ?
I have a functional numpy-1-10-1!=-O


May I suggest numpy 1.10.2? Numpy 1.10.1 has some nasty bugs.

In any case, we support the `@` operator in 1.10, but not the `@=` 
operator. The `@=` operator is tricky to have true inplace matrix 
multiplication, as not only are elements on the left overwritten, but 
the dimensions need to be preserved.


Chuck


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion


--
Hans Larsen Galgebakken Sønder 4-11A 2620 Albertslund Danmark/Danio
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?

[Charles R Harris]

On Thu, Dec 13, 2012 at 10:38 AM, Charles R Harris 
charlesr.har...@gmail.com wrote:

 The previous proposal to drop python 2.4 support garnered no opposition.
 How about dropping support for python 2.5 also?


The proposal to drop support for python 2.5 and 2.4 in numpy 1.8 has
carried. It is now a todo issue on
githubhttps://github.com/numpy/numpy/issues/2830
.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?

[Christopher Hanley]

We (STScI) are ending support for Python 2.5 in our stsci_python project
and told our users as much last July.  I have no objections to ending
support for Python 2.5.


Chris


On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris 
charlesr.har...@gmail.com wrote:

 The previous proposal to drop python 2.4 support garnered no opposition.
 How about dropping support for python 2.5 also?

 Chuck

 ___
 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] Support for python 2.4 dropped. Should we drop 2.5 also?

[Olivier Delalleau]

I'd say it's a good idea, although I hope 1.7.x will still be maintained
for a while for those who are still stuck with Python 2.4-5 (sometimes you
don't have a choice).

-=- Olivier

2012/12/13 Charles R Harris charlesr.har...@gmail.com

 The previous proposal to drop python 2.4 support garnered no opposition.
 How about dropping support for python 2.5 also?

 Chuck

 ___
 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] Support for python 2.4 dropped. Should we drop 2.5 also?

[Benjamin Root]

On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris 
charlesr.har...@gmail.com wrote:

 The previous proposal to drop python 2.4 support garnered no opposition.
 How about dropping support for python 2.5 also?

 Chuck


matplotlib 1.2 supports py2.5.  I haven't seen any plan to move off of that
for 1.3.  Is there a compelling reason for dropping 2.5?

Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?

[Benjamin Root]

My apologies... we support 2.6 and above.  +1 on dropping 2.5 support.

Ben

On Thu, Dec 13, 2012 at 1:12 PM, Benjamin Root ben.r...@ou.edu wrote:

 On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris 
 charlesr.har...@gmail.com wrote:

 The previous proposal to drop python 2.4 support garnered no opposition.
 How about dropping support for python 2.5 also?

 Chuck


 matplotlib 1.2 supports py2.5.  I haven't seen any plan to move off of
 that for 1.3.  Is there a compelling reason for dropping 2.5?

 Ben Root


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?

[David Cournapeau]

On Thu, Dec 13, 2012 at 7:12 PM, Benjamin Root ben.r...@ou.edu wrote:
 On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris
 charlesr.har...@gmail.com wrote:

 The previous proposal to drop python 2.4 support garnered no opposition.
 How about dropping support for python 2.5 also?

 Chuck


 matplotlib 1.2 supports py2.5.  I haven't seen any plan to move off of that
 for 1.3.  Is there a compelling reason for dropping 2.5?

A rationale for the record: I don't think people who don't care about
2.4 care about 2.5, and 2.6 is a significant improvement compared to
2.5:

  - context manager
  - python 3-compatible exception syntax (writing code that works with
2 and 3 without any change is significantly easier if your baseline in
2.6 instead of 2.4/2.5)
  - json, ast, multiprocessing are available and potentially quite
useful for NumPy itself.

cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?

[Chris Barker - NOAA Federal]

 How about dropping support for python 2.5 also?

Im still dumfounded that people are working on projects where they
are free to use the latest an greatest numpy, but *have* to use a
more-than-four-year-old-python:


Python 2.6 (final) was released on October 1st, 2008.


so +1 on moving forward!

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?

[David Cournapeau]

On Thu, Dec 13, 2012 at 10:07 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
 How about dropping support for python 2.5 also?

 Im still dumfounded that people are working on projects where they
 are free to use the latest an greatest numpy, but *have* to use a
 more-than-four-year-old-python:

It happens very easily in corporate environments. Compiling python it
a major headache compared to numpy, not because of python itself, but
because you need to recompile every single extension you're gonna use.

Compiling numpy + its dependencies is at least feasable, but building
things like pygtk when you don't have X11 headers installed is more or
less impossible.

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?

[Bradley M. Froehle]

Yes, but the point was that since you can live with an older version on
Python you can probably live with an older version of NumPy.

On Thursday, December 13, 2012, David Cournapeau wrote:

  Im still dumfounded that people are working on projects where they
  are free to use the latest an greatest numpy, but *have* to use a
  more-than-four-year-old-python:

 It happens very easily in corporate environments. Compiling python it
 a major headache compared to numpy, not because of python itself, but
 because you need to recompile every single extension you're gonna use.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?

[Chris Barker - NOAA Federal]

On Thu, Dec 13, 2012 at 3:01 PM, Bradley M. Froehle
brad.froe...@gmail.com wrote:
 Yes, but the point was that since you can live with an older version on
 Python you can probably live with an older version of NumPy.

exactly -- also:

How likely are you to nee the latest and greatest numpy but not a new
PyGTK, or a new name_your_package_here. And, in fact, other packages
drop support for older Python's too.

However, what I can imagine is pretty irrelevant -- sorry I brought it
up -- either there are a significant number of folks for whom support
for old Pythons in important, or there aren't.

-Chris



 On Thursday, December 13, 2012, David Cournapeau wrote:

  Im still dumfounded that people are working on projects where they
  are free to use the latest an greatest numpy, but *have* to use a
  more-than-four-year-old-python:

 It happens very easily in corporate environments. Compiling python it
 a major headache compared to numpy, not because of python itself, but
 because you need to recompile every single extension you're gonna use.


 ___
 NumPy-Discussion mailing list
 NumPy-Discussion@scipy.org
 http://mail.scipy.org/mailman/listinfo/numpy-discussion




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?

[Olivier Delalleau]

2012/12/13 Chris Barker - NOAA Federal chris.bar...@noaa.gov

 On Thu, Dec 13, 2012 at 3:01 PM, Bradley M. Froehle
 brad.froe...@gmail.com wrote:
  Yes, but the point was that since you can live with an older version on
  Python you can probably live with an older version of NumPy.

 exactly -- also:

 How likely are you to nee the latest and greatest numpy but not a new
 PyGTK, or a new name_your_package_here. And, in fact, other packages
 drop support for older Python's too.

 However, what I can imagine is pretty irrelevant -- sorry I brought it
 up -- either there are a significant number of folks for whom support
 for old Pythons in important, or there aren't.


I doubt it's a common situation, but just to give an example: I am
developing some machine learning code that heavily relies on Numpy, and it
is meant to run into a large Python 2.4 software environment, which can't
easily be upgraded because it contains lots of libraries that have been
built against Python 2.4. And even if I could rebuild it, they wouldn't let
me ;) This Python code is mostly proprietary and doesn't require external
dependencies to be upgraded... except my little module that may take
advantage of Numpy improvements.

-=- Olivier
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Support for sparse matrix in Distance function (and clustering)?

[Bab Tei]

Damian Eads eads at soe.ucsc.edu writes:

 
 Hi,
 
 Can you be more specific? Do you need sparse matrices to represent
 observation vectors because they are sparse? Or do you need sparse
 matrices to represent distance matrices because most vectors you are
 clustering are similar while a few are dissimilar?
 Damian
 
 On Tue, Dec 9, 2008 at 1:28 PM, Bab Tei babaktei at yahoo.com wrote:
  Hi
  Does the distance function in spatial package support sparse matrix?
  regards
Hi
I need sparse matrices to represent observation vectors because they are sparse.
I have a large sparse matrix. I also use kmeans (Besides hierarchical
clustering) which can directly work with very large data.
Teimourpour


  
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Support for sparse matrix in Distance function (and clustering)?

[Bab Tei]

Hi
Does the distance function in spatial package support sparse matrix?
regards


  
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Support for sparse matrix in Distance function (and clustering)?

[Damian Eads]

Hi,

Can you be more specific? Do you need sparse matrices to represent
observation vectors because they are sparse? Or do you need sparse
matrices to represent distance matrices because most vectors you are
clustering are similar while a few are dissimilar?

The clustering code is written mostly in C and does not support sparse
matrices. However, this should not matter because most of the
clustering code does not look at the raw observation vectors
themselves, just the distances passed as a distance matrix.

Damian

On Tue, Dec 9, 2008 at 1:28 PM, Bab Tei [EMAIL PROTECTED] wrote:
 Hi
 Does the distance function in spatial package support sparse matrix?
 regards



 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://projects.scipy.org/mailman/listinfo/numpy-discussion




-- 
-
Damian Eads Ph.D. Student
Jack Baskin School of Engineering, UCSCE2-489
1156 High Street Machine Learning Lab
Santa Cruz, CA 95064http://www.soe.ucsc.edu/~eads
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Support universal gfortran compiler on OS X

[Jarrod Millman]

Hello,

Could someone confirm whether this ticket can be closed:
http://projects.scipy.org/scipy/numpy/ticket/571

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion