**Background**

My question is motivated by simple observations, which somewhat undermine the beliefs/assumptions often held/made by experienced MATLAB users:

 - MATLAB is very well optimized when it comes to the built-in functions and the fundamental language features, such as indexing vectors and matrices.
 - Loops in MATLAB are slow (despite the JIT) and should generally be avoided if the algorithm can be expressed in a native, &#39;vectorized&#39; manner. 

The bottom line: core MATLAB functionality is efficient and trying to outperform it using MATLAB code is hard, if not impossible.


**Investigating performance of vector indexing**

The example codes shown below are as fundamental as it gets: I assign a scalar value to all vector entries. First, I allocate an empty vector `x`:

    tic; x = zeros(1e8,1); toc
    Elapsed time is 0.260525 seconds.

Having `x` I would like to set all its entries to the same value. In practice you would do it differently, e.g., `x = value*ones(1e8,1)`, but the point here is to investigate the performance of vector indexing. The simplest way is to write:

    tic; x(:) = 1; toc
    Elapsed time is 0.094316 seconds.

Let&#39;s call it method 1 (from the value assigned to `x`). It seems to be very fast (faster at least than memory allocation). Because the only thing I do here is operate on memory, I can estimate the efficiency of this code by calculating the obtained *effective memory bandwidth* and comparing it to the *hardware memory bandwidth* of my computer:

    eff_bandwidth = numel(x) * 8 bytes per double * 2 / time

In the above, I multiply by `2` because unless SSE streaming is used, setting values in memory requires that the vector is both read from and written to the memory. In the above example:

    eff_bandwidth(1) = 1e8*8*2/0.094316 = 17 Gb/s

[STREAM-benchmarked memory bandwidth](https://www.cs.virginia.edu/stream/) of my computer is around 17.9 Gb/s, so indeed - MATLAB delivers close to peak performance in this case! So far, so good.

Method 1 is suitable if you want to set *all* vector elements to some value. But if you want to access elements every `step` entries, you need to substitute the `:` with e.g., `1:step:end`. Below is a direct speed comparison with method 1:

    tic; x(1:end) = 2; toc
    Elapsed time is 0.496476 seconds.

While you would not expect it to perform any different, method 2 is clearly big trouble: factor 5 slowdown for no reason. My suspicion is that in this case MATLAB explicitly allocates the index vector (`1:end`). This is somewhat confirmed by using explicit vector size instead of `end`:

    tic; x(1:1e8) = 3; toc
    Elapsed time is 0.482083 seconds.

Methods 2 and 3 perform equally bad.

Another possibility is to explicitly create an index vector `id` and use it to index `x`. This gives you the most flexible indexing capabilities. In our case:

    tic;
    id = 1:1e8; % colon(1,1e8);
    x(id) = 4;
    toc
    Elapsed time is 1.208419 seconds.

Now that is really something - 12 times slowdown compared to method 1! I understand it should perform worse than method 1 because of the additional memory used for `id`, but why is it so much worse than methods 2 and 3?

Let&#39;s try to give the loops a try - as hopeless as it may sound.

    tic;
    for i=1:numel(x)
        x(i) = 5;
    end
    toc
    Elapsed time is 0.788944 seconds.

A big surprise - a loop beats a `vectorized` method 4, but is still slower than methods 1, 2 and 3. It turns out that in this particular case you can do it better:

    tic;
    for i=1:1e8
        x(i) = 6;
    end
    toc
    Elapsed time is 0.321246 seconds.

And that is the probably the most bizarre outcome of this study - **a MATLAB-written loop significantly outperforms native vector indexing**. That should certainly not be so. Note that the JIT&#39;ed loop is still 3 times slower than the theoretical peak almost obtained by method 1. So there is still plenty of room for improvement. It is just surprising (a stronger word would be more suitable) that usual &#39;vectorized&#39; indexing (`1:end`) is even slower.

**Questions**

 - is simple indexing in MATLAB **very** inefficient (methods 2, 3, and 4 are slower than method 1), or did I miss something?
 - why is method 4 **(so much) slower** than methods 2 and 3?
 - why does using `1e8` instead of `numel(x)` as a loop bound speed up the code by factor 2?

**Edit**
After reading Jonas&#39;s comment, here is another way to do that using logical indices:

    tic;
    id = logical(ones(1, 1e8));
    x(id) = 7;
    toc
    Elapsed time is 0.613363 seconds.

Much better than method 4.

For convenience:

    function test

    tic; x = zeros(1,1e8); toc

    tic; x(:) = 1; toc
    tic; x(1:end) = 2; toc
    tic; x(1:1e8) = 3; toc

    tic;
    id = 1:1e8; % colon(1,1e8);
    x(id) = 4;
    toc

    tic;
    for i=1:numel(x)
        x(i) = 5;
    end
    toc

    tic;
    for i=1:1e8
        x(i) = 6;
    end
    toc

    end

Is indexing vectors in MATLAB inefficient?

`numpy.vectorize` takes a function f:a-&gt;b and turns it into g:a[]-&gt;b[].

This works fine when `a` and `b` are scalars, but I can&#39;t think of a reason why it wouldn&#39;t work with b as an `ndarray` or list, i.e. f:a-&gt;b[] and g:a[]-&gt;b[][]

For example:

    import numpy as np
    def f(x):
        return x * np.array([1,1,1,1,1], dtype=np.float32)
    g = np.vectorize(f, otypes=[np.ndarray])
    a = np.arange(4)
    print(g(a))
This yields:
    
    array([[ 0.  0.  0.  0.  0.],
           [ 1.  1.  1.  1.  1.],
           [ 2.  2.  2.  2.  2.],
           [ 3.  3.  3.  3.  3.]], dtype=object)

Ok, so that gives the right values, but the wrong dtype.  And even worse:

    g(a).shape

yields:

    (4,)

So this array is pretty much useless.  I know I can convert it doing:

    np.array(map(list, a), dtype=np.float32)


to give me what I want:

    array([[ 0.,  0.,  0.,  0.,  0.],
           [ 1.,  1.,  1.,  1.,  1.],
           [ 2.,  2.,  2.,  2.,  2.],
           [ 3.,  3.,  3.,  3.,  3.]], dtype=float32)

but that is neither efficient nor pythonic.  Can any of you guys find a cleaner way to do this?  

Thanks in advance!

Using Numpy Vectorize on Functions that Return Vectors

How do I get the exponential weighted moving average in NumPy just like the following in [pandas][1]?

    import pandas as pd
    import pandas_datareader as pdr
    from datetime import datetime

    # Declare variables
    ibm = pdr.get_data_yahoo(symbols=&#39;IBM&#39;, start=datetime(2000, 1, 1), end=datetime(2012, 1, 1)).reset_index(drop=True)[&#39;Adj Close&#39;]
    windowSize = 20

    # Get PANDAS exponential weighted moving average
    ewm_pd = pd.DataFrame(ibm).ewm(span=windowSize, min_periods=windowSize).mean().as_matrix()

    print(ewm_pd)

I tried the following with NumPy

    import numpy as np
    import pandas_datareader as pdr
    from datetime import datetime

    # From this post: http://stackoverflow.com/a/40085052/3293881 by @Divakar
    def strided_app(a, L, S): # Window len = L, Stride len/stepsize = S
        nrows = ((a.size - L) // S) + 1
        n = a.strides[0]
        return np.lib.stride_tricks.as_strided(a, shape=(nrows, L), strides=(S * n, n))

    def numpyEWMA(price, windowSize):
        weights = np.exp(np.linspace(-1., 0., windowSize))
        weights /= weights.sum()

        a2D = strided_app(price, windowSize, 1)

        returnArray = np.empty((price.shape[0]))
        returnArray.fill(np.nan)
        for index in (range(a2D.shape[0])):
            returnArray[index + windowSize-1] = np.convolve(weights, a2D[index])[windowSize - 1:-windowSize + 1]
        return np.reshape(returnArray, (-1, 1))

    # Declare variables
    ibm = pdr.get_data_yahoo(symbols=&#39;IBM&#39;, start=datetime(2000, 1, 1), end=datetime(2012, 1, 1)).reset_index(drop=True)[&#39;Adj Close&#39;]
    windowSize = 20

    # Get NumPy exponential weighted moving average
    ewma_np = numpyEWMA(ibm, windowSize)

    print(ewma_np)

But the results are not similar as the ones in pandas.

Is there maybe a better approach to calculate the exponential weighted moving average directly in NumPy and get the exact same result as the [`pandas.ewm().mean()`][2]?

At 60,000 requests on pandas solution, I get about 230 seconds. I am sure that with a pure NumPy, this can be decreased significantly.

  [1]: http://pandas.pydata.org/pandas-docs/stable/computation.html#exponentially-weighted-windows
  [2]: http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.ewm.html#pandas.DataFrame.ewm





NumPy version of &quot;Exponential weighted moving average&quot;, equivalent to pandas.ewm().mean()

Several times now, I&#39;ve encountered this term in matlab, fortran ... some other ... but I&#39;ve never found an explanation what does it mean, and what it does? So I&#39;m asking here, what is vectorization, and what does it mean for example, that &quot;a loop is vectorized&quot; ?



What is &quot;vectorization&quot;?

So we are used to say to every R new user that &quot;*`apply` isn&#39;t vectorized, check out the Patrick Burns [R Inferno](http://www.burns-stat.com/pages/Tutor/R_inferno.pdf) Circle 4*&quot; which says (I quote):

&gt; A common reflex is to use a function in the apply family. **This is not**
&gt; **vectorization, it is loop-hiding**. The apply function has a for loop in
&gt; its definition. The lapply function buries the loop, but execution
&gt; times tend to be roughly equal to an explicit for loop.

Indeed, a quick look on the `apply` source code reveals the loop:

    grep(&quot;for&quot;, capture.output(getAnywhere(&quot;apply&quot;)), value = TRUE)
    ## [1] &quot;        for (i in 1L:d2) {&quot;  &quot;    else for (i in 1L:d2) {&quot;

Ok so far, but a look at `lapply` or `vapply` actually reveals a completely different picture:

    lapply
    ## function (X, FUN, ...) 
    ## {
    ##     FUN &lt;- match.fun(FUN)
    ##     if (!is.vector(X) || is.object(X)) 
    ##        X &lt;- as.list(X)
    ##     .Internal(lapply(X, FUN))
    ## }
    ## &lt;bytecode: 0x000000000284b618&gt;
    ## &lt;environment: namespace:base&gt;

So apparently there is no R `for` loop hiding there, rather they are calling internal C written function. 

A quick look in the [rabbit](https://github.com/wch/r-source/blob/trunk/src/main/names.c#L627-L630) [hole](https://github.com/wch/r-source/blob/trunk/src/main/apply.c#L34) reveals pretty much the same picture

Moreover, let&#39;s take the `colMeans` function for example, which was never accused in not being vectorised

    colMeans
    # function (x, na.rm = FALSE, dims = 1L) 
    # {
    #   if (is.data.frame(x)) 
    #     x &lt;- as.matrix(x)
    #   if (!is.array(x) || length(dn &lt;- dim(x)) &lt; 2L) 
    #     stop(&quot;&#39;x&#39; must be an array of at least two dimensions&quot;)
    #   if (dims &lt; 1L || dims &gt; length(dn) - 1L) 
    #     stop(&quot;invalid &#39;dims&#39;&quot;)
    #   n &lt;- prod(dn[1L:dims])
    #   dn &lt;- dn[-(1L:dims)]
    #   z &lt;- if (is.complex(x)) 
    #     .Internal(colMeans(Re(x), n, prod(dn), na.rm)) + (0+1i) * 
    #     .Internal(colMeans(Im(x), n, prod(dn), na.rm))
    #   else .Internal(colMeans(x, n, prod(dn), na.rm))
    #   if (length(dn) &gt; 1L) {
    #     dim(z) &lt;- dn
    #     dimnames(z) &lt;- dimnames(x)[-(1L:dims)]
    #   }
    #   else names(z) &lt;- dimnames(x)[[dims + 1]]
    #   z
    # }
    # &lt;bytecode: 0x0000000008f89d20&gt;
    #   &lt;environment: namespace:base&gt;

Huh? It also just calls `.Internal(colMeans(...` which we can also find in the [rabbit hole](https://github.com/wch/r-source/blob/trunk/src/main/names.c#L731). So how is this different from `.Internal(lapply(..`?

Actually a quick benchmark reveals that `sapply` performs no worse than `colMeans` and much better than a `for` loop for a big data set

    m &lt;- as.data.frame(matrix(1:1e7, ncol = 1e5))
    system.time(colMeans(m))
    # user  system elapsed 
    # 1.69    0.03    1.73 
    system.time(sapply(m, mean))
    # user  system elapsed 
    # 1.50    0.03    1.60 
    system.time(apply(m, 2, mean))
    # user  system elapsed 
    # 3.84    0.03    3.90 
    system.time(for(i in 1:ncol(m)) mean(m[, i]))
    # user  system elapsed 
    # 13.78    0.01   13.93 

In other words, is it correct to say that `lapply` and `vapply` **are actually vectorised** (compared to `apply` which is a `for` loop that also calls `lapply`) and what did Patrick Burns really mean to say?


Is the &quot;*apply&quot; family really not vectorized?

I&#39;ve found R&#39;s ifelse statements to be pretty handy from time to time.  For example:

    ifelse(TRUE,1,2)
    # [1] 1
    ifelse(FALSE,1,2)
    # [1] 2

But I&#39;m somewhat confused by the following behavior.

    ifelse(TRUE,c(1,2),c(3,4))
    # [1] 1
    ifelse(FALSE,c(1,2),c(3,4))
    # [1] 3

Is this a design choice that&#39;s above my paygrade?

Why can&#39;t R&#39;s ifelse statements return vectors?

**Are `for` loops really &quot;bad&quot;? If not, in what situation(s) would they be better than using a more conventional &quot;vectorized&quot; approach?&lt;sup&gt;1&lt;/sup&gt;**

I am familiar with the concept of &quot;vectorization&quot;, and how pandas employs vectorized techniques to speed up computation. Vectorized functions broadcast operations over the entire series or DataFrame to achieve speedups much greater than conventionally iterating over the data. 

However, I am quite surprised to see a lot of code (including from answers on Stack Overflow) offering solutions to problems that involve looping through data using `for` loops and list comprehensions. The documentation and API say that loops are &quot;bad&quot;, and that one should &quot;never&quot; iterate over arrays, series, or DataFrames. So, how come I sometimes see users suggesting loop-based solutions?

------

&lt;sub&gt;1 - While it is true that the question sounds somewhat broad, the truth is that there are very specific situations when `for` loops are usually better than conventionally iterating over data. This post aims to capture this for posterity. &lt;/sub&gt; 

Are for-loops in pandas really bad? When should I care?

Can you tell me when to use these vectorization methods with basic examples? 

I see that `map` is a `Series` method whereas the rest are `DataFrame` methods. I got confused about `apply` and `applymap` methods though. Why do we have two methods for applying a function to a DataFrame? Again, simple examples which illustrate the usage would be great!



Difference between map, applymap and apply methods in Pandas

Given a [NumPy][1] array *A*, what is the fastest/most efficient way to apply the **same** function, *f*, to **every** cell?

1. Suppose that we will assign to *A(i,j)* the *f(A(i,j))*.

2. The function, *f*, doesn&#39;t have a binary output, thus the mask(ing) operations won&#39;t help.

Is the &quot;obvious&quot; double loop iteration (through every cell) the optimal solution?

  [1]: http://en.wikipedia.org/wiki/NumPy


Efficient evaluation of a function at every cell of a NumPy array

Suppose `a1`, `b1`, `c1`, and `d1` point to heap memory, and my numerical code has the following core loop.

    const int n = 100000;

    for (int j = 0; j &lt; n; j++) {
        a1[j] += b1[j];
        c1[j] += d1[j];
    }

This loop is executed 10,000 times via another outer `for` loop. To speed it up, I changed the code to:

    for (int j = 0; j &lt; n; j++) {
        a1[j] += b1[j];
    }

    for (int j = 0; j &lt; n; j++) {
        c1[j] += d1[j];
    }

Compiled on [Microsoft Visual C++ 10.0][1] with full optimization and [SSE2][2] enabled for 32-bit on a [Intel Core 2][3] Duo (x64), the first example takes 5.5 seconds and the double-loop example takes only 1.9 seconds.

Disassembly for the first loop basically looks like this (this block is repeated about five times in the full program):

    movsd       xmm0,mmword ptr [edx+18h]
    addsd       xmm0,mmword ptr [ecx+20h]
    movsd       mmword ptr [ecx+20h],xmm0
    movsd       xmm0,mmword ptr [esi+10h]
    addsd       xmm0,mmword ptr [eax+30h]
    movsd       mmword ptr [eax+30h],xmm0
    movsd       xmm0,mmword ptr [edx+20h]
    addsd       xmm0,mmword ptr [ecx+28h]
    movsd       mmword ptr [ecx+28h],xmm0
    movsd       xmm0,mmword ptr [esi+18h]
    addsd       xmm0,mmword ptr [eax+38h]

Each loop of the double loop example produces this code (the following block is repeated about three times):

    addsd       xmm0,mmword ptr [eax+28h]
    movsd       mmword ptr [eax+28h],xmm0
    movsd       xmm0,mmword ptr [ecx+20h]
    addsd       xmm0,mmword ptr [eax+30h]
    movsd       mmword ptr [eax+30h],xmm0
    movsd       xmm0,mmword ptr [ecx+28h]
    addsd       xmm0,mmword ptr [eax+38h]
    movsd       mmword ptr [eax+38h],xmm0
    movsd       xmm0,mmword ptr [ecx+30h]
    addsd       xmm0,mmword ptr [eax+40h]
    movsd       mmword ptr [eax+40h],xmm0

The question turned out to be of no relevance, as the behavior severely depends on the sizes of the arrays (n) and the CPU cache. So if there is further interest, I rephrase the question:

- Could you provide some solid insight into the details that lead to the different cache behaviors as illustrated by the five regions on the following graph?

- It might also be interesting to point out the differences between CPU/cache architectures, by providing a similar graph for these CPUs.

Here is the full code. It uses [TBB][4] `Tick_Count` for higher resolution timing, which can be disabled by not defining the `TBB_TIMING` Macro:

    #include &lt;iostream&gt;
    #include &lt;iomanip&gt;
    #include &lt;cmath&gt;
    #include &lt;string&gt;
    
    //#define TBB_TIMING
    
    #ifdef TBB_TIMING	
    #include &lt;tbb/tick_count.h&gt;
    using tbb::tick_count;
    #else
    #include &lt;time.h&gt;
    #endif
    
    using namespace std;
    
    //#define preallocate_memory new_cont
    
    enum { new_cont, new_sep };
    
    double *a1, *b1, *c1, *d1;
    
    
    void allo(int cont, int n)
    {
    	switch(cont) {
    	  case new_cont:
    		a1 = new double[n*4];
    		b1 = a1 + n;
    		c1 = b1 + n;
    		d1 = c1 + n;
    		break;
    	  case new_sep:
    		a1 = new double[n];
    		b1 = new double[n];
    		c1 = new double[n];
    		d1 = new double[n];
    		break;
    	}

    	for (int i = 0; i &lt; n; i++) {
    		a1[i] = 1.0;
            d1[i] = 1.0;
            c1[i] = 1.0;
            b1[i] = 1.0;
        }
    }
    
    void ff(int cont)
    {
    	switch(cont){
    	  case new_sep:
    		delete[] b1;
    		delete[] c1;
    		delete[] d1;
    	  case new_cont:
    		delete[] a1;
    	}
    }
    
    double plain(int n, int m, int cont, int loops)
    {
    #ifndef preallocate_memory
    	allo(cont,n);
    #endif
    
    #ifdef TBB_TIMING	
    	tick_count t0 = tick_count::now();
    #else
    	clock_t start = clock();
    #endif
    	    
    	if (loops == 1) {
    		for (int i = 0; i &lt; m; i++) {
    			for (int j = 0; j &lt; n; j++){
    				a1[j] += b1[j];
    				c1[j] += d1[j];
                }
    		}
    	} else {
    		for (int i = 0; i &lt; m; i++) {
    			for (int j = 0; j &lt; n; j++) {
    				a1[j] += b1[j];
    			}
    			for (int j = 0; j &lt; n; j++) {
    				c1[j] += d1[j];
    			}
    		}
        }
    	double ret;
    
    #ifdef TBB_TIMING	
    	tick_count t1 = tick_count::now();
    	ret = 2.0*double(n)*double(m)/(t1-t0).seconds();
    #else
    	clock_t end = clock();
    	ret = 2.0*double(n)*double(m)/(double)(end - start) *double(CLOCKS_PER_SEC);
    #endif
    	
    #ifndef preallocate_memory
    	ff(cont);
    #endif
    
    	return ret;
    }
    
    
    void main()
    {	
    	freopen(&quot;C:\\test.csv&quot;, &quot;w&quot;, stdout);
    
    	char *s = &quot; &quot;;
    
    	string na[2] ={&quot;new_cont&quot;, &quot;new_sep&quot;};
    
    	cout &lt;&lt; &quot;n&quot;;
    
    	for (int j = 0; j &lt; 2; j++)
    		for (int i = 1; i &lt;= 2; i++)
    #ifdef preallocate_memory
    			cout &lt;&lt; s &lt;&lt; i &lt;&lt; &quot;_loops_&quot; &lt;&lt; na[preallocate_memory];
    #else
    			cout &lt;&lt; s &lt;&lt; i &lt;&lt; &quot;_loops_&quot; &lt;&lt; na[j];
    #endif
    			
    	cout &lt;&lt; endl;
    
    	long long nmax = 1000000;
    
    #ifdef preallocate_memory
    	allo(preallocate_memory, nmax);
    #endif
    	
    	for (long long n = 1L; n &lt; nmax; n = max(n+1, long long(n*1.2)))
        {
    		const long long m = 10000000/n;
    		cout &lt;&lt; n;

    		for (int j = 0; j &lt; 2; j++)
    			for (int i = 1; i &lt;= 2; i++)
    				cout &lt;&lt; s &lt;&lt; plain(n, m, j, i);
    		cout &lt;&lt; endl;
    	}
    }

It shows FLOP/s for different values of `n`.

[![Performace chart][5]][5]


  [1]: http://en.wikipedia.org/wiki/Visual_C++#32-bit_versions
  [2]: http://en.wikipedia.org/wiki/SSE2
  [3]: http://en.wikipedia.org/wiki/Intel_Core_2
  [4]: https://www.threadingbuildingblocks.org/
  [5]: https://i.stack.imgur.com/426bP.gif

Why are elementwise additions much faster in separate loops than in a combined loop?

You can apply a function to every item in a vector by saying, for example, `v + 1`, or you can use the function `arrayfun`. How can I do it for every row/column of a matrix without using a for loop?

How can I apply a function to every row/column of a matrix in MATLAB?

Let&#39;s say the bottleneck of my Java program really is some tight loops to compute a bunch of vector dot products. Yes I&#39;ve profiled, yes it&#39;s the bottleneck, yes it&#39;s significant, yes that&#39;s just how the algorithm is, yes I&#39;ve run Proguard to optimize the byte code, etc.

The work is, essentially, dot products. As in, I have two `float[50]` and I need to compute the sum of pairwise products. I know processor instruction sets exist to perform these kind of operations quickly and in bulk, like SSE or MMX.

Yes I can probably access these by writing some native code in JNI. The JNI call turns out to  be pretty expensive.

I know you can&#39;t guarantee what a JIT will compile or not compile. Has anyone *ever* heard of a JIT generating code that uses these instructions? and if so, is there anything about the Java code that helps make it compilable this way?

Probably a &quot;no&quot;; worth asking.

Do any JVM&#39;s JIT compilers generate code that uses vectorized floating point instructions?

Why, at the lowest level of the hardware performing operations and the general underlying operations involved (i.e.: things general to all programming languages&#39; actual implementations when running code), is vectorization typically so dramatically faster than looping?

What does the computer do when looping that it doesn&#39;t do when using vectorization (I&#39;m talking about the actual computations that the computer performs, not what the programmer writes), or what does it do differently?

I have been unable to convince myself why the difference should be so significant.  I could probably be persuaded that vectorized code shaves off some looping overhead somewhere, but the computer still has to perform the same number of operations, doesn&#39;t it?  For example, if we&#39;re multiplying a vector of size N by a scalar, we&#39;ll have N multiplications to perform either way, won&#39;t we?

Why is vectorization, faster in general, than loops?

In R, I have an element `x` and a vector `v`. I want to find the first index of an element in `v` that is equal to `x`. I know that one way to do this is: `which(x == v)[[1]]`, but that seems excessively inefficient. Is there a more direct way to do it?

For bonus points, is there a function that works if `x` is a vector? That is, it should return a vector of indices indicating the position of each element of `x` in `v`.

Is there an R function for finding the index of an element in a vector?

    i=np.arange(1,4,dtype=np.int)
    a=np.arange(9).reshape(3,3)
and

    a
    &gt;&gt;&gt;array([[0, 1, 2],
              [3, 4, 5],
              [6, 7, 8]])
    a[:,0:1]
    &gt;&gt;&gt;array([[0],
              [3],
              [6]])
    a[:,0:2]
    &gt;&gt;&gt;array([[0, 1],
              [3, 4],
              [6, 7]])
    a[:,0:3]
    &gt;&gt;&gt;array([[0, 1, 2],
              [3, 4, 5],
              [6, 7, 8]])

Now I want to vectorize the array to print them all together. I try

    a[:,0:i]
or

    a[:,0:i[:,None]]

It gives TypeError: only integer scalar arrays can be converted to a scalar index

numpy array TypeError: only integer scalar arrays can be converted to a scalar index

I want to calculate the row-wise dot product of two matrices of the same dimension as fast as possible. This is the way I am doing it:

&lt;!--language: python--&gt;

    import numpy as np
    a = np.array([[1,2,3], [3,4,5]])
    b = np.array([[1,2,3], [1,2,3]])
    result = np.array([])
    for row1, row2 in a, b:
        result = np.append(result, np.dot(row1, row2))
    print result

and of course the output is:

    [ 26.  14.]

Vectorized way of calculating row-wise dot product two matrices with Scipy

Does `ifelse` really calculate both the `yes` and `no` vectors -- as in, the entirety of each vector?
Or does it just calculate some values from each vector? 

Also, is `ifelse` really that slow?  



All Vectorization Solutions on Gang of Coders

Total of 17 Vectorization Solutions

Is indexing vectors in MATLAB inefficient?

Using Numpy Vectorize on Functions that Return Vectors

NumPy version of "Exponential weighted moving average", equivalent to pandas.ewm().mean()

What is "vectorization"?

Is the "*apply" family really not vectorized?

Why can't R's ifelse statements return vectors?