Comments on: How to Safely Try Unknown Code http://blogs.mathworks.com/loren/2007/11/02/how-to-safely-try-unknown-code/ Loren Shure works on design of the MATLAB language at <a href="http://www.mathworks.com/">The MathWorks</a>. She writes here about once a week on MATLAB programming and related topics. <br><br><a href="/images/loren-full.jpg"><img src="/images/loren.jpg"></a> Mon, 23 Nov 2009 01:28:48 +0000 http://wordpress.org/?v=2.3.1 By: Mark Hoemmen http://blogs.mathworks.com/loren/2007/11/02/how-to-safely-try-unknown-code/#comment-22243 Mark Hoemmen Tue, 27 Nov 2007 15:57:53 +0000 http://blogs.mathworks.com/loren/2007/11/02/how-to-safely-try-unknown-code/#comment-22243 Ha, yes, "more good ideas than time" should be considered a good thing, as it means our work is not yet done! ;-) mfh Ha, yes, “more good ideas than time” should be considered a good thing, as it means our work is not yet done! ;-)

mfh

]]> By: Loren http://blogs.mathworks.com/loren/2007/11/02/how-to-safely-try-unknown-code/#comment-21667 Loren Mon, 19 Nov 2007 19:50:34 +0000 http://blogs.mathworks.com/loren/2007/11/02/how-to-safely-try-unknown-code/#comment-21667 Mark- Lots more good ideas than time is the reason why. It's certainly been requested and on the enhancement list for consideration. --Loren Mark-

Lots more good ideas than time is the reason why. It’s certainly been requested and on the enhancement list for consideration.

–Loren

]]> By: Mark Hoemmen http://blogs.mathworks.com/loren/2007/11/02/how-to-safely-try-unknown-code/#comment-21653 Mark Hoemmen Mon, 19 Nov 2007 17:25:52 +0000 http://blogs.mathworks.com/loren/2007/11/02/how-to-safely-try-unknown-code/#comment-21653 Incidentally, why isn't eig(rand(3))(2) supported? I find myself composing vector- or matrix-valued functions a lot (maybe because I'm a Lisp hacker instead of an old-school Fortran card-puncher ;-) ), and I find it awkward to create temp variables all the time. Of course the notation can get hard to understand after composing a lot of functions, but two or three isn't too bad for someone who reads a lot of Lisp. I'm happy to find your blog so now I have someone to pester about Matlab syntax ;-) I'm very grateful, though, that the bugs in the Matlab 6.? parser have been fixed. (There were certain matrix and function call expressions like [foo (x), 1, 2] in which the space between the function name "foo" and its argument list broke the parser. Leaving a space between a function name and its argument list is a common habit among C coders who use GNU C formatting conventions. Matlab 7 seems to have fixed this parser bug.) Many thanks! Incidentally, why isn’t

eig(rand(3))(2)

supported? I find myself composing vector- or matrix-valued functions a lot (maybe because I’m a Lisp hacker instead of an old-school Fortran card-puncher ;-) ), and I find it awkward to create temp variables all the time. Of course the notation can get hard to understand after composing a lot of functions, but two or three isn’t too bad for someone who reads a lot of Lisp.

I’m happy to find your blog so now I have someone to pester about Matlab syntax ;-) I’m very grateful, though, that the bugs in the Matlab 6.? parser have been fixed. (There were certain matrix and function call expressions like

[foo (x), 1, 2]

in which the space between the function name “foo” and its argument list broke the parser. Leaving a space between a function name and its argument list is a common habit among C coders who use GNU C formatting conventions. Matlab 7 seems to have fixed this parser bug.)

Many thanks!

]]> By: Tim Davis http://blogs.mathworks.com/loren/2007/11/02/how-to-safely-try-unknown-code/#comment-20572 Tim Davis Wed, 07 Nov 2007 02:51:55 +0000 http://blogs.mathworks.com/loren/2007/11/02/how-to-safely-try-unknown-code/#comment-20572 Yes, Loren, this is just what I need - Thanks. I try to write code that back-ports to older versions and attempts to be robust against possible future changes (putting try/catch around the use of deprecated functions, so the code works when the functions really get deleted in a future release, for example). As an aside: I like the suggested enhancement for subsref ... assuming it doesn't cause any chaos. I'm sure MATLAB-golfers will like it too. Sometimes ideas that look great on the surface get really nasty when you dig into the details, though ... like the new bsxfun function (which works well) in contrast to extending the basic syntax to do the same thing (which doesn't work well at all but is very tempting to consider). Yes, Loren, this is just what I need - Thanks. I try to write code that back-ports to older versions and attempts to be robust against possible future changes (putting try/catch around the use of deprecated functions, so the code works when the functions really get deleted in a future release, for example).

As an aside: I like the suggested enhancement for subsref … assuming it doesn’t cause any chaos. I’m sure MATLAB-golfers will like it too.

Sometimes ideas that look great on the surface get really nasty when you dig into the details, though … like the new bsxfun function (which works well) in contrast to extending the basic syntax to do the same thing (which doesn’t work well at all but is very tempting to consider).

]]>