numpy.random are not optimized. If matlab use the random number from mkl, they will be much faster.
Fred On Mon, Apr 2, 2012 at 12:04 PM, David Cournapeau <[email protected]> wrote: > > > On Mon, Apr 2, 2012 at 4:45 PM, Chris Barker <[email protected]> wrote: >> >> On Mon, Apr 2, 2012 at 2:25 AM, Nathaniel Smith <[email protected]> wrote: >> > To see if this is an effect of numpy using C-order by default instead of >> > Fortran-order, try measuring eig(x.T) instead of eig(x)? >> >> Just to be clear, .T re-arranges the strides (Making it Fortran >> order), butyou'll have to make sure your ariginal data is the >> transpose of whatyou want. >> >> I posted this on slashdot, but for completeness: >> >> the code posted on slashdot is also profiling the random number >> generation -- I have no idea how numpy and MATLAB's random number >> generation compare, nor how random number generation compares to >> eig(), but you should profile them independently to make sure. > > > While this is true, the cost is most likely negligeable compared to the cost > of eig (unless something weird is going on in random as well). > > David > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
