matlab vs. python question
I'm interested in this comparison (not in starting yet another flame fest). I actually know nothing about matlab, but almost all my peers use it. One of the things I recall reading on this subject is that matlab doesn't support OO style programming. I happened to look on the matlab vendor's website, and found that it does have classes. OTOH, I've seen at least some matlab code, and never saw anyone use these features. I'm perfectly happy with python myself, but I wonder if anyone has good arguments for why to prefer python over matlab?
Neal Becker wrote:
I'm interested in this comparison
There have got to be comparison's on the web -- google away! My few comments:
I happened to look on the matlab vendor's website, and found that it does have classes.
Matlab added classes in a fairly recent version, so technically, yes, it does support OO. However, OO aside, Python is, in many ways, are far more sophisticated and capable language. It is better suited to larger projects, and well suited to wide variety of software development, rather than just numerical work. Indeed, python+numpy supports more sophisticated numerical work too (more data types, etc). So, my reasons for using python+numpy (I did my entire dissertation with Matlab -- I loved it at the time): * Better, more flexible language. * I can use it for other things I do: web programming, sophisticated GUIs, etc. * It integrates well with lots of other libraries * It's free: both $$ and libre What's better about Matlab: * A wider selection of out-of-the-box numerical routines. * Excellent integration of command-line and plotting. In short, $$ and freedom aside, I think Matlab provides a slightly more productive environment for interactive experimentation and quickie prototypes and scripts, but much less productive for larger projects, or for people that need to do non-numerical work too. just my $0.2 -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Hi, On 4/25/07, Neal Becker <ndbecker2@gmail.com> wrote:
I'm interested in this comparison (not in starting yet another flame fest). I actually know nothing about matlab, but almost all my peers use it. One of the things I recall reading on this subject is that matlab doesn't support OO style programming. I happened to look on the matlab vendor's website, and found that it does have classes. OTOH, I've seen at least some matlab code, and never saw anyone use these features.
Actually, I think I know why you've never seen anyone use matlab objects, and this is because they are implemented in a rather strange way that makes them painful to use. I know because I've used them a lot myself, and I still have the scars, Matthew
Neal Becker wrote:
I'm perfectly happy with python myself, but I wonder if anyone has good arguments for why to prefer python over matlab?
The things that I get annoyed with every time I have to read some Matlab code are the lack of namespaces and first-class function objects. -- 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 attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On 4/25/2007 8:34 PM, Robert Kern wrote:
The things that I get annoyed with every time I have to read some Matlab code are the lack of namespaces and first-class function objects.
Matlab does have first-class function objects. You can get a handle to any function using the @ operator. Matlab has closures as well. function f = addn(n) tmp = n function y = closure(x) y = x + tmp end f = @closure end The most recent version of Matlab also have classes and namespaces implemented properly - not like the old broken Matlab objects. But I've never used it as I have stopped paying for maintenance of my Matlab license - I use Python anyway. But if it weren't for NumPy, SciPy and Matplotlib, I would probably still be using Matlab. As a programming language Matlab is very weak compared to Python. Matlab is to Fortran what Python is to Lisp. As an advanced desktop calculator Matlab has the edge. But that has more to do with the interactive environment and available toolboxes than the language it self. It is also easier to write C or Fortran extensions for Matlab than for Python. Sturla Molden
Sturla Molden wrote:
On 4/25/2007 8:34 PM, Robert Kern wrote:
The things that I get annoyed with every time I have to read some Matlab code are the lack of namespaces and first-class function objects.
Matlab does have first-class function objects. You can get a handle to any function using the @ operator. Matlab has closures as well.
I wish people would use them, then. -- 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 attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On 4/26/07, Robert Kern <robert.kern@gmail.com> wrote:
Sturla Molden wrote:
On 4/25/2007 8:34 PM, Robert Kern wrote:
The things that I get annoyed with every time I have to read some Matlab code are the lack of namespaces and first-class function objects.
Matlab does have first-class function objects. You can get a handle to any function using the @ operator. Matlab has closures as well.
I wish people would use them, then.
I think part of the problem is that most people who learn Matlab learn it in school strictly as a computing tool rather than a programming language. But there are many language features that people just don't know about, because writing nice programs is not usually the emphasis in the courses where Matlab is taught and used. Python is better generally as a language, although the self. thing makes me want to pull my hair out sometimes. I find myself bending over backwards to avoid creating classes just because converting a function into a method generally results in an annoying amount of self.this self.that self.theother junk. --bb
On Apr 25, 2007, at 12:46 PM, Bill Baxter wrote:
On 4/26/07, Robert Kern <robert.kern@gmail.com> wrote:
Sturla Molden wrote:
On 4/25/2007 8:34 PM, Robert Kern wrote:
The things that I get annoyed with every time I have to read some Matlab code are the lack of namespaces and first-class function objects.
Matlab does have first-class function objects. You can get a handle to any function using the @ operator. Matlab has closures as well.
I wish people would use them, then.
I think part of the problem is that most people who learn Matlab learn it in school strictly as a computing tool rather than a programming language. But there are many language features that people just don't know about, because writing nice programs is not usually the emphasis in the courses where Matlab is taught and used.
Python is better generally as a language, although the self. thing makes me want to pull my hair out sometimes. I find myself bending over backwards to avoid creating classes just because converting a function into a method generally results in an annoying amount of self.this self.that self.theother junk.
Agree w/most of what you've said, but will add one other thing that drives me nuts in python that hasn't been a problem in Matplotlib: In Python, if interacting w/the interpreter as your primary IDE, and if you've got multiple files that depend on one another that you're modifying, then you need to restart the interpreter frequently b/c otherwise things in the interpreter can be stale; IOW, changes to several interdependent files aren't easy to import so that everything in your interpreted environment reflects the latest code. Yeah, there's reload tricks, but doing them in the right order and the right number of times can be a pain when dependencies are cyclic. I realize in general that this issue of stale code is just difficult, that its not inherently a Python problem per se, for automatic percolation of code changes backwards in time is difficult in general, but I've never had the problem bite me when I was developing in Matlab. I just save whatever file, and it appears that whatever's latest on disk is what's executed. (Friends who know more about PL than I tell me I've been lucky.) It was particularly a problem for me when I was using matplotlib interactively, which relates to this discussion b/c people often use Matlab for the graphing. W/that package, I couldn't use something like IDLE in such a way that it restarted its session every time I asked it to run a changed file. IDLE was nice, though, in that it had mouse-settable break points for debugging. That's the other big miss for me: Python's debugger is cumbersome to use. Chris mentioned the IDE issue earlier. IMHO, IPython is a better IDE than IDLE, but its features (e.g. %psource prints code from disk, so most recent changes are displayed, but it doesn't reflect the code that an object actually executes) caused me even more confusion regarding stale code initially. I've finally gotten used to developing w/IPython (using Francisco's debug_here() hack for better debugging integration), and I'm almost as productive as I was before, but it took several months to get there. I've used Matlab's GUI stuff a bit and didn't find it as awful as others on this post claim. It also has the nice advantage of handling both GUI and figure-related threads in the same loop, so I could use it to write more sophisticated applications than one should do when using matplotlib+python alone. But I've yet to really use Python- based GUIs, which are probably much better than what Matlab has to offer. HTH, --b
belinda thom kirjoitti:
On Apr 25, 2007, at 12:46 PM, Bill Baxter wrote:
Agree w/most of what you've said, but will add one other thing that drives me nuts in python that hasn't been a problem in Matplotlib:
In Python, if interacting w/the interpreter as your primary IDE, and if you've got multiple files that depend on one another that you're modifying, then you need to restart the interpreter frequently b/c otherwise things in the interpreter can be stale; IOW, changes to several interdependent files aren't easy to import so that everything in your interpreted environment reflects the latest code. Yeah, there's reload tricks, but doing them in the right order and the right number of times can be a pain when dependencies are cyclic.
I realize in general that this issue of stale code is just difficult, that its not inherently a Python problem per se, for automatic percolation of code changes backwards in time is difficult in general, but I've never had the problem bite me when I was developing in Matlab. I just save whatever file, and it appears that whatever's latest on disk is what's executed. (Friends who know more about PL than I tell me I've been lucky.)
I've been using the attached autoreload code (by Thomas Heller, different versions are probably floating around the net) rather successfully for a more Matlabish feel to IPython. It reloads modules every time their files have been changed. Of course, this doesn't solve all staleness problems you describe, but only eliminates manual work involved in solving the most common ones. Reloading modules does have pitfalls [1], but at least in my use these haven't really mattered much in practice. I think having autoreload functionality bundled with IPython (maybe turned off per default) would be quite useful: although in some rare cases autoreloading doesn't work in the ideal way, it's very convenient not to have to type reload(foo) after every change, especially when tweaking for example plotting scripts. Pauli [1] For example, instances of classes created are not updated on reload, but continue using the old code. Also, from foo import * imports are not updated, so you'll have to manually touch files that do this if 'foo' has been changed.
Thank you so much! When I finally get a moment to take a break, I'll look in more detail into using your suggestion. --b On Apr 26, 2007, at 12:47 AM, Pauli Virtanen wrote:
belinda thom kirjoitti:
On Apr 25, 2007, at 12:46 PM, Bill Baxter wrote:
Agree w/most of what you've said, but will add one other thing that drives me nuts in python that hasn't been a problem in Matplotlib:
In Python, if interacting w/the interpreter as your primary IDE, and if you've got multiple files that depend on one another that you're modifying, then you need to restart the interpreter frequently b/c otherwise things in the interpreter can be stale; IOW, changes to several interdependent files aren't easy to import so that everything in your interpreted environment reflects the latest code. Yeah, there's reload tricks, but doing them in the right order and the right number of times can be a pain when dependencies are cyclic.
I realize in general that this issue of stale code is just difficult, that its not inherently a Python problem per se, for automatic percolation of code changes backwards in time is difficult in general, but I've never had the problem bite me when I was developing in Matlab. I just save whatever file, and it appears that whatever's latest on disk is what's executed. (Friends who know more about PL than I tell me I've been lucky.)
I've been using the attached autoreload code (by Thomas Heller, different versions are probably floating around the net) rather successfully for a more Matlabish feel to IPython. It reloads modules every time their files have been changed.
Of course, this doesn't solve all staleness problems you describe, but only eliminates manual work involved in solving the most common ones. Reloading modules does have pitfalls [1], but at least in my use these haven't really mattered much in practice.
I think having autoreload functionality bundled with IPython (maybe turned off per default) would be quite useful: although in some rare cases autoreloading doesn't work in the ideal way, it's very convenient not to have to type reload(foo) after every change, especially when tweaking for example plotting scripts.
Pauli
[1] For example, instances of classes created are not updated on reload, but continue using the old code. Also, from foo import * imports are not updated, so you'll have to manually touch files that do this if 'foo' has been changed. """
autoreload.py - automatically reload changed source code into a running program
You might want to add the following to your ~/.ipython/ipythonrc
import_mod sys execute sys.path.append('path/where/this/file/resides') import_mod autoreload execute autoreload.run()
or adding the following
import sys sys.path.append('path/where/this/file/resides') import autoreload autoreload.run()
to some startup file.
Created: Thomas Heller, 2000-04-17 Modified: Pauli Virtanen, 2006 """
# $Id: autoreload.py 3117 2006-09-27 20:28:46Z pauli $ # # $Log: autoreload.py,v $ # Revision 1.9 2001/11/15 18:41:18 thomas # Cleaned up and made working again before posting to c.l.p. # Added code to update bound (or unbound) methods as suggested # by Just van Rossum. Thanks! # # ... # # Revision 1.1 2001/10/04 16:54:04 thomas # Discovered this old module on my machine, it didn't work too well, # but seems worth to continue with it... # Checked in as a first step.
__version__ = "$Revision: 1.9 $".split()[1]
# ToDo: # # Cannot reload __main__ - explain why this cannot work, # and explain a workaround. # # Optimize - the number of watches objects (in old_objects) # grows without limits. Think if this is really necessary...
import time, os, threading, sys, types, imp, inspect, traceback
def _get_compiled_ext(): for ext, mode, typ in imp.get_suffixes(): if typ == imp.PY_COMPILED: return ext
# the official way to get the extension of compiled files (.pyc or .pyo) PY_COMPILED_EXT = _get_compiled_ext()
class ModuleWatcher: running = 0 def __init__(self): # If we don't do this, there may be tracebacks # when shutting down python. import atexit atexit.register(self.stop)
def run(self): if self.running: print "# autoreload already running" return print "# starting autoreload" self.running = 1 self.thread = threading.Thread(target=self._check_modules) self.thread.setDaemon(1) self.thread.start()
def stop(self): if not self.running: print "# autoreload not running" return self.running = 0 self.thread.join() #print "# autoreload stopped"
def _check_modules(self): skipped = {} while self.running: time.sleep(0.01) for m in sys.modules.values(): if not hasattr(m, '__file__'): continue if m.__name__ == '__main__':
# we cannot reload(__main__) First I thought we # could use mod = imp.load_module() and then # reload(mod) to simulate reload(main), but this # would execute the code in __main__ a second # time.
continue file = m.__file__ dirname = os.path.dirname(file) path, ext = os.path.splitext(file)
if ext.lower() == '.py': ext = PY_COMPILED_EXT file = os.path.join(dirname, path + PY_COMPILED_EXT)
if ext != PY_COMPILED_EXT: continue
try: pymtime = os.stat(file[:-1])[8] if pymtime <= os.stat(file)[8]: continue if skipped.get(file[:-1], None) == pymtime: continue except OSError: continue
try: superreload(m) if file[:-1] in skipped: del skipped[file[:-1]] except: skipped[file[:-1]] = pymtime import traceback traceback.print_exc(0)
def update_function(old, new, attrnames): for name in attrnames: setattr(old, name, getattr(new, name))
def superreload(module, reload=reload, _old_objects = {}): """superreload (module) -> module
Enhanced version of the builtin reload function. superreload replaces the class dictionary of every top-level class in the module with the new one automatically, as well as every function's code object. """ ## start = time.clock() # retrieve the attributes from the module before the reload, # and remember them in _old_objects. for name, object in module.__dict__.items(): key = (module.__name__, name) _old_objects.setdefault(key, []).append(object) # print the refcount of old objects: ## if type(object) in (types.FunctionType, types.ClassType): ## print name, map(sys.getrefcount, _old_objects[key])
## print "# reloading module %r" % module
module = reload(module) # XXX We have a problem here if importing the module fails!
# iterate over all objects and update them count = 0 # XXX Can we optimize here? # It may be that no references to the objects are present # except those from our _old_objects dictionary. # We should remove those. I have to learn about weak-refs! for name, new_obj in module.__dict__.items(): key = (module.__name__, name) if _old_objects.has_key(key): for old_obj in _old_objects[key]: if type(new_obj) == types.ClassType: old_obj.__dict__.update(new_obj.__dict__) count += 1 elif type(new_obj) == types.FunctionType: update_function(old_obj, new_obj, "func_code func_defaults func_doc".split()) count += 1 elif type(new_obj) == types.MethodType: update_function(old_obj.im_func, new_obj.im_func, "func_code func_defaults func_doc".split()) count += 1 ## stop = time.clock() ## print "# updated %d objects from %s" % (count, module) ## print "# This took %.3f seconds" % (stop - start)
return module
_watcher = ModuleWatcher()
run = _watcher.run stop = _watcher.stop
__all__ = ['run', 'stop', 'superreload'] _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Actually, all the points in this thread have been very good points but I just want to add my 2 cents since I was in your boat just a month ago and decided to try out python after seeing what it could do. In short, I decided to look elsewhere as I was dealing with vector data in database and maintaining so many different function and files was getting hard and while Matlab has classes they are very unwieldy to use and it is such an oddity in matlab that using them would confuse whoever uses your code anyway. At least in my experience. However after playing with Python, matplotlib and numpy I have found that the code is much cleaner, the language is much more powerful and clean, matplotlib is extremely capable for 2D plotting and iPython integrates all those things very well. The only thing I miss about matlab are the help tool which is quite frankly the best I have seen, the many different toolboxes, the compatibility with most hardware DAC and just the fact damn near everyone in the scientific community uses either Matlab or plain Fortran/C/C++. However, I would disagree that Python with all its tools going to replace Matlab well for everything. For large projects, for advanced programmers and for non-standard things such as complex database handling (in my case) it is definitly a clear winner. However, I would be weary of getting Matlab completely out of the picture because I find it is still a much better tool for algorithm testing, scripting and other "use for a week" functions . Hope this helps a bit too. On Apr 27, 1:23 am, belinda thom <b...@cs.hmc.edu> wrote:
Thank you so much! When I finally get a moment to take a break, I'll look in more detail into using your suggestion.
--b
On Apr 26, 2007, at 12:47 AM, Pauli Virtanen wrote:
belinda thom kirjoitti:
On Apr 25, 2007, at 12:46 PM, Bill Baxter wrote:
Agree w/most of what you've said, but will add one other thing that drives me nuts in python that hasn't been a problem in Matplotlib:
In Python, if interacting w/the interpreter as your primary IDE, and if you've got multiple files that depend on one another that you're modifying, then you need to restart the interpreter frequently b/c otherwise things in the interpreter can be stale; IOW, changes to several interdependent files aren't easy to import so that everything in your interpreted environment reflects the latest code. Yeah, there's reload tricks, but doing them in the right order and the right number of times can be a pain when dependencies are cyclic.
I realize in general that this issue of stale code is just difficult, that its not inherently a Python problem per se, for automatic percolation of code changes backwards in time is difficult in general, but I've never had the problem bite me when I was developing in Matlab. I just save whatever file, and it appears that whatever's latest on disk is what's executed. (Friends who know more about PL than I tell me I've been lucky.)
I've been using the attached autoreload code (by Thomas Heller, different versions are probably floating around the net) rather successfully for a more Matlabish feel to IPython. It reloads modules every time their files have been changed.
Of course, this doesn't solve all staleness problems you describe, but only eliminates manual work involved in solving the most common ones. Reloading modules does have pitfalls [1], but at least in my use these haven't really mattered much in practice.
I think having autoreload functionality bundled with IPython (maybe turned off per default) would be quite useful: although in some rare cases autoreloading doesn't work in the ideal way, it's very convenient not to have to type reload(foo) after every change, especially when tweaking for example plotting scripts.
Pauli
[1] For example, instances of classes created are not updated on reload, but continue using the old code. Also, from foo import * imports are not updated, so you'll have to manually touch files that do this if 'foo' has been changed. """
autoreload.py - automatically reload changed source code into a running program
You might want to add the following to your ~/.ipython/ipythonrc
import_mod sys execute sys.path.append('path/where/this/file/resides') import_mod autoreload execute autoreload.run()
or adding the following
import sys sys.path.append('path/where/this/file/resides') import autoreload autoreload.run()
to some startup file.
Created: Thomas Heller, 2000-04-17 Modified: Pauli Virtanen, 2006 """
# $Id: autoreload.py 3117 2006-09-27 20:28:46Z pauli $ # # $Log: autoreload.py,v $ # Revision 1.9 2001/11/15 18:41:18 thomas # Cleaned up and made working again before posting to c.l.p. # Added code to update bound (or unbound) methods as suggested # by Just van Rossum. Thanks! # # ... # # Revision 1.1 2001/10/04 16:54:04 thomas # Discovered this old module on my machine, it didn't work too well, # but seems worth to continue with it... # Checked in as a first step.
__version__ = "$Revision: 1.9 $".split()[1]
# ToDo: # # Cannot reload __main__ - explain why this cannot work, # and explain a workaround. # # Optimize - the number of watches objects (in old_objects) # grows without limits. Think if this is really necessary...
import time, os, threading, sys, types, imp, inspect, traceback
def _get_compiled_ext(): for ext, mode, typ in imp.get_suffixes(): if typ == imp.PY_COMPILED: return ext
# the official way to get the extension of compiled files (.pyc or .pyo) PY_COMPILED_EXT = _get_compiled_ext()
class ModuleWatcher: running = 0 def __init__(self): # If we don't do this, there may be tracebacks # when shutting down python. import atexit atexit.register(self.stop)
def run(self): if self.running: print "# autoreload already running" return print "# starting autoreload" self.running = 1 self.thread = threading.Thread(target=self._check_modules) self.thread.setDaemon(1) self.thread.start()
def stop(self): if not self.running: print "# autoreload not running" return self.running = 0 self.thread.join() #print "# autoreload stopped"
def _check_modules(self): skipped = {} while self.running: time.sleep(0.01) for m in sys.modules.values(): if not hasattr(m, '__file__'): continue if m.__name__ == '__main__':
# we cannot reload(__main__) First I thought we # could use mod = imp.load_module() and then # reload(mod) to simulate reload(main), but this # would execute the code in __main__ a second # time.
continue file = m.__file__ dirname = os.path.dirname(file) path, ext = os.path.splitext(file)
if ext.lower() == '.py': ext = PY_COMPILED_EXT file = os.path.join(dirname, path + PY_COMPILED_EXT)
if ext != PY_COMPILED_EXT: continue
try: pymtime = os.stat(file[:-1])[8] if pymtime <= os.stat(file)[8]: continue if skipped.get(file[:-1], None) == pymtime: continue except OSError: continue
try: superreload(m) if file[:-1] in skipped: del skipped[file[:-1]] except: skipped[file[:-1]] = pymtime import traceback traceback.print_exc(0)
def update_function(old, new, attrnames): for name in attrnames: setattr(old, name, getattr(new, name))
def superreload(module, reload=reload, _old_objects = {}): """superreload (module) -> module
Enhanced version of the builtin reload function. superreload replaces the class dictionary of every top-level class in the module with the new one automatically, as well as every function's code object. """ ## start = time.clock() # retrieve the attributes from the module before the reload, # and remember them in _old_objects. for name, object in module.__dict__.items(): key = (module.__name__, name) _old_objects.setdefault(key, []).append(object) # print the refcount of old objects: ## if type(object) in (types.FunctionType, types.ClassType): ## print name, map(sys.getrefcount, _old_objects[key])
## print "# reloading module %r" % module
module = reload(module) # XXX We have a problem here if importing the module fails!
# iterate over all objects and update them count = 0 # XXX Can we optimize here? # It may be that no references to the objects are present # except those from our _old_objects dictionary. # We should remove those. I have to learn about weak-refs! for name, new_obj in module.__dict__.items(): key = (module.__name__, name) if _old_objects.has_key(key): for old_obj in _old_objects[key]: if type(new_obj) == types.ClassType: old_obj.__dict__.update(new_obj.__dict__) count += 1 elif type(new_obj) == types.FunctionType: update_function(old_obj, new_obj, "func_code func_defaults func_doc".split()) count += 1 elif type(new_obj) == types.MethodType: update_function(old_obj.im_func, new_obj.im_func, "func_code func_defaults func_doc".split()) count += 1 ## stop = time.clock() ## print "# updated %d objects from %s" % (count, module) ## print "# This took %.3f seconds" % (stop - start)
return module
_watcher = ModuleWatcher()
run = _watcher.run stop = _watcher.stop
__all__ = ['run', 'stop', 'superreload'] _______________________________________________ Numpy-discussion mailing list Numpy-discuss...@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ Numpy-discussion mailing list Numpy-discuss...@scipy.orghttp://projects.scipy.org/mailman/listinfo/numpy-discussion
Hi,
However, I would disagree that Python with all its tools going to replace Matlab well for everything. For large projects, for advanced programmers and for non-standard things such as complex database handling (in my case) it is definitly a clear winner. However, I would be weary of getting Matlab completely out of the picture because I find it is still a much better tool for algorithm testing, scripting and other "use for a week" functions .
Thanks - that seems very fair. I think you're right that the level of help for matlab is far superior, and easier to get to, than numpy / python. Can you say anything more about the features of matlab that you miss for the 'use a week' functions? It might help guide our thoughts on potential improvements... Thanks a lot, Matthew
Use a week functions are basically function that you use for a short period of time where a full fledged well designed program is more of a waste of time than anything else. Other then that, for what you miss it really, really depends on your applications and goals. I work on signal processing and analysis which is very well supported by numpy/ scipy/matplotlib but if you were working in neural networks, finance, etc... then python wouldn't be as productive right out of the box. I suppose the general rule would be, if your project is large and to be used by a lot of people then Python is probably much better and more portable, not everyone will need a Matlab License with the proper version. On the other hand, if you are more interested in small projects where speed of development is more important than long term sustainability of the code Matlab is probably better. This is usually the case in research environment, at least until you figure out exactly what you want to do, then switch to python. I hope this help, but either way the decision will have to be made on your end given that it's impossible for anyone else to have all the information about your situation. But keep in mind there is no clear winner, one tool is good for one thing and another one is good for another. Python and Matlab just have a large amount of overlap. On Apr 28, 7:09 am, "Matthew Brett" <matthew.br...@gmail.com> wrote:
Hi,
However, I would disagree that Python with all its tools going to replace Matlab well for everything. For large projects, for advanced programmers and for non-standard things such as complex database handling (in my case) it is definitly a clear winner. However, I would be weary of getting Matlab completely out of the picture because I find it is still a much better tool for algorithm testing, scripting and other "use for a week" functions .
Thanks - that seems very fair. I think you're right that the level of help for matlab is far superior, and easier to get to, than numpy / python. Can you say anything more about the features of matlab that you miss for the 'use a week' functions? It might help guide our thoughts on potential improvements...
Thanks a lot,
Matthew _______________________________________________ Numpy-discussion mailing list Numpy-discuss...@scipy.orghttp://projects.scipy.org/mailman/listinfo/numpy-discussion
Le Samedi 28 Avril 2007 20:03, Simon Berube a écrit :
(...) On the other hand, if you are more interested in small projects where speed of development is more important than long term sustainability of the code Matlab is probably better. This is usually the case in research environment, at least until you figure out exactly what you want to do, then switch to python.
I hope this help, (...)
I guess the point of the question was, in what way should numpy/scipy be improved in order to get the same usability at those cases, according to you ? It's not as obvious as you make it sound, and there also are for sure some advantages in the ipython/scipy stack over matlab's prompt, usability-wise. Any experiences which helps in improving it is thus useful Thanks, Benjamin
On 4/29/07, Benjamin Thyreau <benjamin@decideur.info> wrote:
Le Samedi 28 Avril 2007 20:03, Simon Berube a écrit:
(...) On the other hand, if you are more interested in small projects where speed of development is more important than long term sustainability of the code Matlab is probably better. This is usually the case in research environment, at least until you figure out exactly what you want to do, then switch to python.
I hope this help, (...)
I guess the point of the question was, in what way should numpy/scipy be improved in order to get the same usability at those cases, according to you ? It's not as obvious as you make it sound, and there also are for sure some advantages in the ipython/scipy stack over matlab's prompt, usability-wise. Any experiences which helps in improving it is thus useful
I like ipython's post-fix ? help. I was back in Matlab a couple of days ago and that's one of the few things I missed about my Numpy setup. I often find I'm typing a command and then I realize I don't recall what the arguments are so then I can just type one extra '?' to get the help. Of course even better would be if ipython were in a GUI, and docstrings could just be proactively prefectched and displayed in another pane while I type, or argument lists could be popped up like in PyCrust. Sadly, other than that I can't think of a whole lot about the numpy environment that I like better than the Matlab environment. (just talking about the environment here -- not the language). Matlab's debugger is very nicely integrated with the prompt, and plots just work, always, and are fast without having to think about ion/ioff stuff or show(). Never need any prayers to the god of GUI event loops to keep plots from freezing things up with Matlab. It's also refreshing to just be able to type "zeros" and "rand" and not have to worry about namespace prefixes. On the other hand I think I yelled a profanity out loud when Matlab gave me the "can't define functions in a script" error. I'd completely forgotten that particular bit of Matlab stupidity. There are probably ways to make the numpy environment more like the above. But there needs to be a 'button' that sets everything up like that or most people just won't find it. For instance maybe ipython could install a "Numpy Interactive" link that uses the -pylab flag and also pulls the numpy namespace into the global one. For debugger integration, is there any way to set up ipython so that on errors it will pop up a GUI debugger that shows the line of source code where the error occured and let you set break points? --bb
"Bill Baxter" <wbaxter@gmail.com> writes:
also pulls the numpy namespace into the global one. For debugger integration, is there any way to set up ipython so that on errors it will pop up a GUI debugger that shows the line of source code where the error occured and let you set break points?
Sure -- use emacs and ipython.el (I know this is not a very satisfactory answer if you are not an emacs user). 'as
On May 5, 2007, at 6:54 AM, Alexander Schmolck wrote:
"Bill Baxter" <wbaxter@gmail.com> writes:
also pulls the numpy namespace into the global one. For debugger integration, is there any way to set up ipython so that on errors it will pop up a GUI debugger that shows the line of source code where the error occured and let you set break points?
Sure -- use emacs and ipython.el (I know this is not a very satisfactory answer if you are not an emacs user).
Or maybe we can try to work out some quick how-tos with this: http://www.digitalpeers.com/pythondebugger/ Has anybody used it before? I've had it lying around w/ the intent to use it, but haven't gotten around to it just yet. -steve
Bill Baxter wrote:
Of course even better would be if ipython were in a GUI, and docstrings could just be proactively prefectched and displayed in another pane while I type, or argument lists could be popped up like in PyCrust.
I think someone was working on iPython-PyCrust integration at some point -- it would be nice! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
All good points stated here. Unfortunatly I'm not able to contribute, and as stated also in other thread, scipy/python was not born for being a clone of matlab (uhmm well probably matplotlib at first was). What would be the "killer" distro for matlab ? An updated distro with numpy/scipy/matplotlib, all in one (also portable can be good ;) A good workspace (with an interactive button) just to not get figures freezed Copy and paste from spreadsheet with a small windows to look at your variables after that there would be no more reason to use matlab.. If any guru/ generous programmer is listening ;)... My two cents Giorgio
On Tue, May 08, 2007 at 12:18:56PM +0200, Giorgio Luciano wrote:
A good workspace (with an interactive button) just to not get figures freezed
I am not sure what you mean by "figures freezed" but I would like to check that you are aware of ipython, and its "-pylab" switch that allows a nice interactive workflow from the command line with figures. Under windows you most often have to create manually a shortcut to add the switch, unfortunately. Gaël
Thanks Gael, I dont' use Ipython, but Ide in interactive mode and everything is fine (changed matplotlibrc and then se switch on in configuration). I just meant hat if you dont' know it or dont' pay attention to start with the correct shortcut etc. etc. you dont' have an "immediate" interactive environment. I will try ipython too ;) Giorgio
On 08/05/07, Gael Varoquaux <gael.varoquaux@normalesup.org> wrote:
On Tue, May 08, 2007 at 12:18:56PM +0200, Giorgio Luciano wrote:
A good workspace (with an interactive button) just to not get figures freezed
I am not sure what you mean by "figures freezed" but I would like to check that you are aware of ipython, and its "-pylab" switch that allows a nice interactive workflow from the command line with figures. Under windows you most often have to create manually a shortcut to add the switch, unfortunately.
Unfortunately this seems to make it impossible for me to use ctrl-c or any other method to interrupt an interminable computation (on MPL 0.90.0). Very frustrating. Anne
On Tue, May 08, 2007 at 11:51:23AM -0400, Anne Archibald wrote:
Unfortunately this seems to make it impossible for me to use ctrl-c or any other method to interrupt an interminable computation (on MPL 0.90.0). Very frustrating.
AFAIK this is fixed in the latest release of ipython (Kudos to the development team !). Gaël
On 4/25/2007 9:31 PM, Robert Kern wrote:
The things that I get annoyed with every time I have to read some Matlab code are the lack of namespaces and first-class function objects. Matlab does have first-class function objects. You can get a handle to any function using the @ operator. Matlab has closures as well.
I wish people would use them, then.
You have to realize that Matlab is mainly used by people who are not skilled programmers but scientists and engineers, the majority of which have never used anything else except perhaps Fortran 77. An array is the most advanced data structure they will ever need. I should know, I was among them for several years. Then I did something as silly as teaching myself C++. God knows why. Matlab gives interactive access to Fortran arrays and libraries, e.g. LAPACK. That is what Matlab was designed to do and it does that very well. Even the name Matlab reflects that, it is an abbreviation for "matrix laboratory". I am not surprised that most Matlab users do not use facilities like function handles or closures. But Matlab does have that, nevertheless. Sturla Molden
On 25/04/07, Sturla Molden <sturla@molden.no> wrote:
You have to realize that Matlab is mainly used by people who are not skilled programmers but scientists and engineers, the majority of which have never used anything else except perhaps Fortran 77. An array is the most advanced data structure they will ever need. I should know, I was among them for several years. Then I did something as silly as teaching myself C++. God knows why.
I have a quibble with this. I work with scientists too, and while an array is usually the most sophisticated data structure they ever use, it's not the most sophisticated data structure they ever *need*. Many many times I've seen a project that is more limited, more error-prone, slower, and more painful to use because the programmer didn't know about or didn't use the right programming tools. Or was using a language that didn't make them readily available. Take, for example, optparse. Hardly a scientific package, indeed, but it makes little command-line utilities vastly easier to write right. And at least in our group, small command-line utilities do an awful lot of the work. Now, teaching us to actually write half-decent programs is another story... Anne M. Archibald
On 4/25/07, Anne Archibald <peridot.faceted@gmail.com> wrote:
On 25/04/07, Sturla Molden <sturla@molden.no> wrote:
You have to realize that Matlab is mainly used by people who are not skilled programmers but scientists and engineers, the majority of which have never used anything else except perhaps Fortran 77. An array is the most advanced data structure they will ever need. I should know, I was among them for several years. Then I did something as silly as teaching myself C++. God knows why.
I have a quibble with this. I work with scientists too, and while an array is usually the most sophisticated data structure they ever use, it's not the most sophisticated data structure they ever *need*. Many many times I've seen a project that is more limited, more error-prone, slower, and more painful to use because the programmer didn't know about or didn't use the right programming tools. Or was using a language that didn't make them readily available.
Yep. I remember a discussion with a guy whose only experience was FORTRAN. I tried to point out the utility of such things as lists, stacks, and fifo's in adaptive algorithms. He just didn't see the need, mostly because he was unfamiliar with those data structures and just didn't think that way, so missed all the possibilities. Chuck
I used to use them frequently. --b On Apr 25, 2007, at 12:31 PM, Robert Kern wrote:
Sturla Molden wrote:
On 4/25/2007 8:34 PM, Robert Kern wrote:
The things that I get annoyed with every time I have to read some Matlab code are the lack of namespaces and first-class function objects.
Matlab does have first-class function objects. You can get a handle to any function using the @ operator. Matlab has closures as well.
I wish people would use them, then.
-- 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 attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Sturla Molden wrote:
It is also easier to write C or Fortran extensions for Matlab than for Python.
Really? I"m not so sure about that -- I found mex file writing pretty painful. With weave, boost, pyrex, swig, f2py, etc, the hardest thing about writing extensions for Python is choosing which tool to use! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Christopher Barker wrote:
Sturla Molden wrote:
It is also easier to write C or Fortran extensions for Matlab than for Python.
Really? I"m not so sure about that -- I found mex file writing pretty painful.
With weave, boost, pyrex, swig, f2py, etc, the hardest thing about writing extensions for Python is choosing which tool to use!
I agree with Sturla here, up until Pyrex. Looking at the Python API, swig, f2py, etc. I found mex files far more straightforward. Mostly this is because of the (mostly) single datatype in Matlab: the double matrix. Having to do reference counting in the Python API is a drag. Now, with Pyrex, that's a different matter entirely. Pyrex makes extension writing so incredibly easy, its one of the major reasons I switched from Matlab to Python. I'm trying to convince some people at work to explore Python as a Matlab replacement. If all you do is numerics, then Matlab is easier (by a little). Once you go beyond numerics (which you do for any real project), like reading datafiles, interfacing with the Internet, accessing databases, etc... suddenly Python is a *lot* nicer. bb -- ----------------- bblais@bryant.edu http://web.bryant.edu/~bblais
Christopher Barker wrote:
It is also easier to write C or Fortran extensions for Matlab than for Python. Really? I"m not so sure about that -- I found mex file writing pretty
Sturla Molden wrote: painful.
With weave, boost, pyrex, swig, f2py, etc, the hardest thing about writing extensions for Python is choosing which tool to use!
I agree with Sturla here, up until Pyrex. Looking at the Python API, swig, f2py, etc. I found mex files far more straightforward. Mostly this is because of the (mostly) single datatype in Matlab: the double matrix. Having to do reference counting in the Python API is a drag. It is a drag, but the matlab's way of doing things is totally broken, not simple. The Matlab C api is one of the reason why I looked at python in the first place. First, the memory management in mex files is unusable for anything non trivial (for example, what happens if you do Ctrl+C, but you are calling a function from a library which does malloc ? You're screwed; many 3rd party mex files crash when you use ctrl+C in matlab). Also, wrapping with ctypes is really several order of magnitude easier AND more powerful than mex files. One thing I use to impress
Brian Blais wrote: people used to matlab is to translate mex examples using ctypes: instead of many lines of boring glue *in C*, a few lines of python The other big drawback of matlab is the lack of data structures which are not arrays. Cell is again, unusable for most things (most algorithms do not work on them): in python, you have list and dictionaries, and they certainly first class citizens in the language. Finally, doing complex GUI is impossible in matlab. More generally, doing things not directly related to numerical computing is really difficult in matlab, because the language is not suitable for general programming, and because of the totally brain damaged C api. I've done a fairly big amount of matlab programming, and consider myself quite familiar with it. I've done complex mex programming, even some java programming for interacting between matlab and java list/hashmap, etc... When you do those kind of things, the limitations of matlab are striking. Matlab is simpler to use for simple things: for me, there is no question about that fact. But python makes easy things just a bit more complicated, and all other things possible. The perfect example is namespace: not having namespace IS easier, at first. But this quickly makes things unmanageable. Functions are easier in matlab, but when you want to define function with many arguments and default values, this also becomes quickly unmanageable. David
Brian Blais wrote:
I agree with Sturla here, up until Pyrex. Looking at the Python API, swig, f2py, etc. I found mex files far more straightforward. Mostly this is because of the (mostly) single datatype in Matlab: the double matrix.
well, that's not really fair. I've written extensions to Numeric (but the same would be true for numpy) that only work on 2-d double arrays -- that was easy. Generalizing to other types and shapes is a pain, but you don't even have that option with Matlab.
Having to do reference counting in the Python API is a drag.
Yes, it is. But every tool, other than writing to the C API directly, takes care of that for you.
Now, with Pyrex, that's a different matter entirely. Pyrex makes extension writing so incredibly easy,
Yes, very cool. I haven't used it for anything real, but f2py looks very easy too, if you're working with Fortran. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Neal Becker wrote:
I'm perfectly happy with python myself, but I wonder if anyone has good arguments for why to prefer python over matlab?
From my own experience, once you move past static plots and want to include some kind of interactive GUI (that is, build an actual application) then you are in for a world of pain. Also, there are far fewer tools and options for rich GUI development in Matlab than in python.
participants (19)
-
Alexander Schmolck -
Anne Archibald -
belinda thom -
Benjamin Thyreau -
Bill Baxter -
Brian Blais -
Bryan Van de Ven -
Charles R Harris -
Christopher Barker -
David Cournapeau -
Gael Varoquaux -
Giorgio Luciano -
Matthew Brett -
Neal Becker -
Pauli Virtanen -
Robert Kern -
Simon Berube -
Steve Lianoglou -
Sturla Molden