>> > Is the difference because of mutability versus immutability, or >> > because of C code in Numpy versus Matlab code? Are you comparing >> > bananas and pears? >> >> It consisted of something like this > > > Your code does a lot of unnecessary work if you're just trying to > demonstrate immutability is faster or slower than mutability. A simple > test that just adds one to each element would have much less overhead. > > In any case, there's no doubt that immutable objects require extra time > to create compared to re-using an existing mutable object, and that time > is probably O(N) (until you approach the limits of available contiguous > memory, in which case you could see O(N**2) or worse behaviour). But an > order of magnitude difference? > > >> I wasn't comparing bananas against pears. Mathworks informed me they >> were using my code to investigate why Matlab was showing such slow- >> downs. I am not sure what they found out, eventially. I have also >> wondered if immutability vs. mutability was the reason, as NumPy >> generates temporary arrays. But I have not found a better explanation >> either. Anyhow, ~30 seconds for Matlab vs. ~3 seconds for Python is a >> major difference. > > How does Matlab speed compare to Python in general? Ruby, for example, is > an order of magnitude slower than Python (at least it was last time I > looked)
For what operations? Under what circumstances? I'm just being pedantic because you mentioned comparing bananas and pears ...... >, not because of immutable arrays, but just because of the speed > of the language. Ummmm, what is 'speed of a language'? I thought ruby or python or anything else as a language is separate from their implementations. Implementations might have 'speed' but languages don't. Aren't you comparing bananas and pears again? Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
