> Sturla Molden wrote:
>> For the same problems where you would use meshgrid in Matlab.
>
> well, I used to use meshgrid a lot because MATLAB could not do
> broadcasting. Which is probably why the OP has been trying to use it.
mgrid and ogrid are both meshgrids, with ogrid having a sparse
represen
On Fri, Jan 9, 2009 at 16:04, Christopher Barker wrote:
> Sturla Molden wrote:
>> For the same problems where you would use meshgrid in Matlab.
>
> well, I used to use meshgrid a lot because MATLAB could not do
> broadcasting. Which is probably why the OP has been trying to use it.
>
> A note for
Sturla Molden wrote:
> For the same problems where you would use meshgrid in Matlab.
well, I used to use meshgrid a lot because MATLAB could not do
broadcasting. Which is probably why the OP has been trying to use it.
A note for the docs:
The docs refer to ogrid and nd_grid, and as far as I can
>> However, just using the slices on the matrix instead of passing the
>> slices through ogrid is faster.
>
> So what is ogrid useful for?
For the same problems where you would use meshgrid in Matlab. That is
certain graphics problem for example; e.g. evaluating a surface z = f(x,y)
over a grid o
On Fri, Jan 9, 2009 at 15:40, Christopher Barker wrote:
> So what is ogrid useful for?
>
> Just curious...
Floating point grids.
x, y = ogrid[0:1:101j, 0:1:101j]
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad a
Robert Kern wrote:
> Instead, if you put both arguments into ogrid:
>
> In [4]: ogrid[0:5, 0:6]
> Out[4]:
> [array([[0],
>[1],
>[2],
>[3],
>[4]]),
> array([[0, 1, 2, 3, 4, 5]])]
>
> We get the kind of arrays you need. These shapes are compatible,
> through broadca
On Fri, Jan 9, 2009 at 11:32, Nicolas ROUX wrote:
> Thanks !
>
> -1- The code style is good and the performance vs matlab is good.
> With 400x400:
> Matlab = 1.56 sec (with nested "for" loop, so no optimization)
> Numpy = 0.99 sec (with broadcasting)
>
>
> -2- Now with the code below I have s
> -2- Now with the code below I have strange result.
> With w=h=400:
>- Using "slice"=> 0.99 sec
>- Using "numpy.ogrid" => 0.01 sec
It is not equivalent. The ogrid version only uses diagonal elements, and
does less work.
> It seems "ogrid" got better performance, but broadcas
Nicolas ROUX wrote:
> -2- Now with the code below I have strange result.
> With w=h=400:
> With w=400 and h=300:
>- Using "numpy.ogrid", => broadcast ERROR !
>
> The last broadcast error is:
> "ValueError: shape mismatch: objects cannot be broadcast to a single shape"
This is probably a br
iscussion-boun...@scipy.org] On Behalf Of Sturla Molden
Sent: Friday, January 09, 2009 4:47 PM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Numpy performance vs Matlab.
> I simplified the code to focus only on "what I" need, rather to bother you
> with the fu
> I simplified the code to focus only on "what I" need, rather to bother you
> with the full code.
def test():
w = 3096
h = 2048
a = numpy.zeros((h,w), order='F') #Normally loaded with real data
b = numpy.zeros((h,w,3), order='F')
w0 = slice(0,w-2)
w1 = slice(1,w-1)
Sorry my previous mail was probalby not clear.
This mail was following the tread we had before, so with some discussion
legacy.
I simplified the code to focus only on "what I" need, rather to bother you
with the full code.
I wrote below a code closer to what I need, where you will agree that
vect
> I understand the weakness of the missing JITcompiler in Python vs Matlab,
> that's why I invistigated numpy vectorization/broadcast.
> (hoping to find a cool way to write our code in fast Numpy)
>
> I used the page http://www.scipy.org/PerformancePython to write my code
> efficiently in Numpy.
>
Hi !
Thanks a lot for your fast/detailed reply.
A very good point for Numpy ;-)
I spent all my time trying to prepare my testcase to better share with you,
that's why I didn't reply fast.
I understand the weakness of the missing JITcompiler in Python vs Matlab,
that's why I invistigated numpy ve
On Wed, Jan 07, 2009 at 07:29:41PM +0100, Xavier Gnata wrote:
> Well it is the best pitch for numpy versus matlab I have read so far :)
> (and I 100% agree)
+1. This is an excellent text. IMHO it should be on the wiki somewhere.
Gaël
___
Numpy-discussio
On 7-Jan-09, at 2:26 PM, Sturla Molden wrote:
> Matlab does not have broadcasting. Array shapes must always match.
Not totally true. They introduced a clunky, clunky syntax for it in
version 7, IIRC, called 'bsxfun'.
See http://tinyurl.com/9e7kyt . It's a better solution than indexing
with a
On Wed, Jan 7, 2009 at 10:19, Nicolas ROUX wrote:
> Hi,
>
> I need help ;-)
> I have here a testcase which works much faster in Matlab than Numpy.
>
> The following code takes less than 0.9sec in Matlab, but 21sec in Python.
> Numpy is 24 times slower than Matlab !
> The big trouble I have is a la
On 1/7/2009 7:52 PM, josef.p...@gmail.com wrote:
> But, I think,
> matlab is ahead in parallelization (which I haven't used much)
Not really. There is e.g. nothing like Python's multiprocessing package
in Matlab. Matlab is genrally single-threaded. Python is multi-threaded
but there is a GIL. A
On Wed, Jan 7, 2009 at 1:32 PM, Sturla Molden wrote:
> On 1/7/2009 6:56 PM, Christopher Barker wrote:
>
>>> So for simple loops python looses, but for other things, python wins
>>> by a huge margin.
>>
>> which emphasizes the point that you can't write code the same way in the
>> two languages, th
On 1/7/2009 6:51 PM, Christopher Barker wrote:
> Even with this nifty JIT,
It is not a very nifty JIT. It can transform some simple loops into
vectorized expressions. And it removes the overhead from indexing with
doubles.
But if you are among those that do
n = length(x)
m = 0
for i = 1.0 :
On 1/7/2009 6:56 PM, Christopher Barker wrote:
>> So for simple loops python looses, but for other things, python wins
>> by a huge margin.
>
> which emphasizes the point that you can't write code the same way in the
> two languages, though I'd argue that that code needs refactoring in any
> la
A Wednesday 07 January 2009, Christopher Barker escrigué:
[clip]
> Even with this nifty JIT, I think Python has many advantages -- if
> your code is well written, there will be a only a few places with
> these sorts of performance bottlenecks, and weave or Cython, or SWIG,
> or Ctypes, or f2py can
Well it is the best pitch for numpy versus matlab I have read so far :)
(and I 100% agree)
Xavier
> On 1/7/2009 4:16 PM, David Cournapeau wrote:
>
>
>> I think on recent versions of matlab, there is nothing you can do
>> without modifying the code: matlab has some JIT compilation for loops,
>>
On 1/7/2009 4:16 PM, David Cournapeau wrote:
> I think on recent versions of matlab, there is nothing you can do
> without modifying the code: matlab has some JIT compilation for loops,
> which is supposed to speed up those cases - at least, that's what is
> claimed by matlab.
Yes it does. After
josef.p...@gmail.com wrote:
> So for simple loops python looses, but for other things, python wins
> by a huge margin.
which emphasizes the point that you can't write code the same way in the
two languages, though I'd argue that that code needs refactoring in any
language!
However, numpy's refe
> Nicolas ROUX wrote:
>> The big trouble I have is a large team of people within my company is ready
>> to replace Matlab by Numpy/Scipy/Matplotlib,
we like that!
>> This is a testcase that people would like to see working without any code
>> restructuring.
>> The reasons are:
>> - this way of
A test case closer to my applications is calling functions in loops:
Python
---
def assgn(a,i,j):
a[i,j,0] = a[i,j,1] + 1.0
a[i,j,2] = a[i,j,0]
a[i,j,1] = a[i,j,2]
return a
print "Start test \n"
dim = 300#0
a = numpy.zeros((dim,dim,3))
start = tim
On Wed, Jan 7, 2009 at 10:58 AM, Grissiom wrote:
> On Wed, Jan 7, 2009 at 23:44, Ryan May wrote:
>>
>> Nicolas ROUX wrote:
>> > Hi,
>> >
>> > I need help ;-)
>> > I have here a testcase which works much faster in Matlab than Numpy.
>> >
>> > The following code takes less than 0.9sec in Matlab, bu
On Wed, Jan 7, 2009 at 23:44, Ryan May wrote:
> Nicolas ROUX wrote:
> > Hi,
> >
> > I need help ;-)
> > I have here a testcase which works much faster in Matlab than Numpy.
> >
> > The following code takes less than 0.9sec in Matlab, but 21sec in Python.
> > Numpy is 24 times slower than Matlab !
> for i in range(dim):
>for j in range(dim):
>a[i,j,0] = a[i,j,1]
>a[i,j,2] = a[i,j,0]
>a[i,j,1] = a[i,j,2]
> for i = 1:dim
>for j = 1:dim
>a(i,j,1) = a(i,j,2);
>a(i,j,2) = a(i,j,1);
>a(i,j,3) = a(i,j,3);
>end
> end
Hi,
The two loops ar
Nicolas ROUX wrote:
> Hi,
>
> I need help ;-)
> I have here a testcase which works much faster in Matlab than Numpy.
>
> The following code takes less than 0.9sec in Matlab, but 21sec in Python.
> Numpy is 24 times slower than Matlab !
> The big trouble I have is a large team of people within my
Nicolas ROUX wrote:
> Hi,
>
> I need help ;-)
> I have here a testcase which works much faster in Matlab than Numpy.
>
> The following code takes less than 0.9sec in Matlab, but 21sec in Python.
> Numpy is 24 times slower than Matlab !
> The big trouble I have is a large team of people within my
Hi,
I need help ;-)
I have here a testcase which works much faster in Matlab than Numpy.
The following code takes less than 0.9sec in Matlab, but 21sec in Python.
Numpy is 24 times slower than Matlab !
The big trouble I have is a large team of people within my company is ready to
replace Matlab
33 matches
Mail list logo
