Loren on the Art of MATLAB

Release R2008a Available 31

Posted by Loren Shure,

The first 2008 semi-annual release of MathWorks products is now available, R2008a. Over the next few months, some of my blog articles will highlight new features.

Contents

Highlights of Highlights of New Features for MATLAB

Here's a very short list, in no particular order, of some of my favorite new MATLAB features in this release.

What Are Yours?

After perusing the release notes or using R2008a, I wonder what your favorite new features are. Let me know here.


Get the MATLAB code

Published with MATLAB® 7.6

31 CommentsOldest to Newest

Hi Loren,
Some of the ones you listed above are my favorites as well (OOP, configurations, UITABLE, data brushing). Here are couple of others:

* Enhancements to code-folding (for various language constructs, and also cells!)
* File and “Directory” Comparisons Tool – now the Comparison Tool works for comparing two directories. This will be very useful for managing my demos.
* Enhancements to publish (nested cells, forced snapshot)

jiro

I think the onCleanup function might be helpful to get rid of waitbars that don’t get closed down when the program crashes. I’ve noticed that if I’m not paying attention while debugging that I’ll have a dozen waitbars lying around from various runs.

Hello,
I like the OOP which I looked at its capability for a long time but I didn’t convert my applications from a function type to OOP but with the new capability, I think it is the time that I start and convert my codes to OOP. I am wondering what is the benefit of having events when the user interface doesn’t support events ( am I wrong?) . As I know GUIE generated application uses a technique similar to events (callbacks) but its capability is very limited.

Regards

Thanks.
I did not see the example that shows how to use event for UI.

OK I am off to do a lot of programming in OOP! I need to change all of my programs to OOP. A lot of work, but it worth it.

Thanks to Mathworks team this nice feature.

Mansour

ps: I just found that I still has R2007B :(

I’ve spent some time reviewing the release notes & have some comments:

Nice to see the clearvars function. The FRP seems to be well written. At first I didn’t like that it only had 4 examples for 8 syntax options. But, it doesn’t seem unreasonable after I’ve read it in detail.

It looks like the Variable Editor will be nice.

Thanks, Oliver. It’s good to hear that some of the new the documentation is working well for you.

–Loren

Loren, I’m most excited about JIT acceleration for user classes. The most burning question is, of course, will this improve my current code, written in the @myClass style, or do I need to convert to the new myClass.m style?

Naor-

I believe the JIT acceleration for user classes is for the new style classes.

–Loren

I think that new oop (handle classes) will revolutionize the way big Matlab applications are implemented. Since Version 7 we could emulate some oop features with nested functions and function handles. I have following questions:

- is the new oop internal implementation based on/similiar to that of the nested functions?
– will handle classes be garbage collected? It is a problem with nested function – once defined they reside in memory even if the workspace they were defined in no longer exist. –> Memory leaks
– has the new oop the performance problem which plagued nested functions? Example http://mathforum.org/kb/message.jspa?messageID=6009303&tstart=0

New OO syntax is good. Your list was missing packages i.e. namespaces. Sad that 2007b does not support packages, new OO code works (at least up to some level) with 2007b, which makes translation smoother.

So the next big thing should be real improvements on GUI programming, uitable is nice but…

Mikhail-

The object system is separate from nested functions though they both rely on some of the same underpinnings.

If a handle to a nested function exists, then the nested function workspace must be retained. If you have example code with nested functions that leaves a memory leak, please, please, please send it in to technical support:

http://www.mathworks.com/support/service_request/login_servicerequests.html?targetURL=/support/service_requests/contact_support.do

so we can look into it and fix it.

–Loren

Mikhail,
To your comments on performance of function handles and handle objects: internally, handle objects and nested function handles use the same memory management system. Handle objects (and nested function handles), get destroyed when no longer reachable from any MATLAB workspace. This is different from garbage collection in that it allows handle objects to have destructors that are called immediately when an object becomes unreachable as opposed to some later point. There is a performance penalty in that more time is spent every time a reference to a handle object goes out of scope (to make sure it didn’t become unreachable). We are continuously working on improving the algorithms for managing handles and these improvements may affect both nested function handles and handle objects.

Dave,
you write about improving garbage collection algorithms, Loren wrote few posts earlier about JIT acceleration. I wonder why reinvent the wheel? Why do not translate Matlab code into java bytecode like Groovy and Scala do and let JVM solve the problems you are struggling with? I understand that it would mean a radical change in the language philosophy.

I dream about native access to swing. I am sure all java geeks would love Matlab axes object (although not being free)! And “Matlab corner” in the “Java Developer’s Jounal” would also rocket your sales!

I got rather badly bitten by the inefficiencies of memory handling in nested functions (as mentioned by Mikhail in post 11). With small test data sets, my program worked well. With large data sets, run-time increased dramatically, even though I was not running out of memory. The profiler wasn’t much help, because the time didn’t seem to be accounted for anywhere.

I would like to say that I think sharing of variables within nested functions is a really useful feature, and I suspect that this is only a problem when a relatively large number of workspaces are in existence simultaneously.

Mike-

I think you are right. The memory hanging around is going to depend on usage, how large the workspaces are, and how many of them are. We are also continually looking for ways to be smarter on memory and we think there is some room for more efficiency for some uses of nested functions. Fixing those requires a lot of work at home that people are designing.

–Loren

Mikhail,
The question of levaraging the JVM and bytecode is an interesting one that we do think about. However, we have to consider the impact of how MATLAB differs from Java. For example, MATLAB doesn’t use garbage collection (GC) so the JVM can’t solve the specific problem we are struggling with. We do have to worry about performance, but we don’t have to deal with the semantic problems created by GC. The GC reclaims memory by destroying objects when memory becomes scarse, but ignores all sorts of other resources. In Java, these other resources need to be handled by explicit destruction (typically through close or dispose methods). People are tempted to use finalizers as if they were destructors, but the semantics of finalizers have enormous complexity from running on a special thread to the potential to “resurrect” objects to the lack of a deterministic ordering.
-Dave

Hi Dave,

Lexical scoping is the answer to many of the other object lifecycle problems. It is my one pet peeve in Matlab, the lack of lexically scoped blocks ( anonymous multiline functions) and a yield and ensure keyword. Many problems would just go away.

open(‘/etc/passwd’, ‘r’ ) @(fid)
… read(fid, 10);
… function_with_error();
end

Implementation of open is

function open(file, flags)
try
…fid = fopen(file, flags)
…yield fid
ensure
…fclose(fid)
end
end

Essentially the block becomes a transaction on the file handle. The file handle is generated and yielded to the block. If the block generates an exception the ensure keyword within the open function still closes the file handle whilst propagating the exception to a higher level.

The user never has to worry about closing the file handle as it is done automatically for them at the end of the block.

Dear Loren,

I just started to use matlab r2008a. I really like the better support for object-orientation, but I do run into some strange problems. For instance, I defined the following graph class:

classdef graph > g = graph([0 1 0;1 0 1;0 1 0])

ans =

0 1 0
1 0 1
0 1 0

>> neighbours(g,1)

ans =

2
4
6
8

>> find(g(1,:) | g(:,1)’)

ans =

2

>> neighbours(g,2)
??? Index exceeds matrix dimensions.

Error in ==> graph>graph.neighbours at 26
ne = find(obj(v,:) | obj(:,v)’);

So the call to neighbours seems to lead to problems in indexing behaviour, or do I overlook something?

Regards,

Marcel

Right, I pasted the class definition into the previous post but this doesn’t seem to be supported. The point is; I just subclass from double, define a constructor with contents: obj = obj@double(g) and a function neighbours(obj,v) with contents ne = find(obj(v,:) | obj(:,v)’);

The above results are then obtained…

I am a long time Matlab user on FreeBSD OS, and for each new Matlab release I hope to see Matlab fully supported of FreeBSD.
Since Matlab6.5 I cannot get Matlab working on FreeBSD through the Linux emulation.

I love the idea of the new OOP developments. It eliminates a lot of the code that I write over and over, like get- and set- methods.

I just got a trial of 2008a, so I’ve only gotten my feet wet. Meta-classes, abstract declarations, dynamic properties, and the dot-sytnax for calling methods (e.g. obj.method(var) instead of method(obj,var)) are all great features for making tools that are easy to use and maintain. The ability to declare static methods for a class is a godsend.

The first glaring omission I see is static properties. Why weren’t they included with the new OOP? Am I missing something?

-Arthur

Hi Arthur:

You can define static properties by setting the Constant attribute for properties to true. The values can only be changed by a static method of the class with static properties.

Hope this helps.
Nausheen

Hi Nausheen,

Thanks for the correction. That helps! I must have attempted to modify my constant property with an object method when I tried. Is there a particular reason that public static variables are not allowed? Obviously they can be controlled from outside a class using static get and set methods, but it seems peculiar that public/private/protected options would be implemented for object properites and not class properties. In playing with 2008a, it does seem like there would be some tricky ambiguities or hard-to-find errors if a user could assign a public static class property (e.g. classname.propname=10;), and instead, due to a type-o (e.g. classnam.propname=10;), got a new struct in the workspace named “classnam.”

Is the direction of MATLAB’s new OOP features modeled after any existing languages (e.g. Java, C#, Python)? Should users expect additions to the OOP feature set in future releases?

Hi Arthur:

Both class and class instance(object) properties can be scoped by the public/protected/private qualifier. Static properties are associated with a class and are declared public to access them outside the class. So, I am not sure why you say that public/protected/private options are not implemented for class properties. Could you clarify?

The ambiguity in property names isn’t unique to static properties. Mistakes with typos could be avoided with the help of an affordance like tab-completion for properties which we are looking to provide in the future.

OOP in MATLAB isn’t modeled after any particular language but several languages including Java, C++, and C# have had an impact on its design. We will continue to evolve our offering in this area.

Nausheen

Many thanks for your responses, Nausheen.

I haven’t figured out how to make a class property that can be modified/assigned. Using the “Constant” attribute on a property, like you mentioned, makes the value unchangeable.

As an example:

classdef myclass
properties (Constant, SetAccess=public)
prop=1; % initial value
end
methods
function set1(obj,val)
obj.prop=val;
end
end
methods (Static,Access=public)
function set2(val)
myclass.prop=val;
end
end
end

… and then I try to use use the class to modify my property:

>> myclass
ans =
myclass
properties:
prop: 1
list of methods
>> myclass.set2(10)
>> myclass
ans =
myclass
properties:
prop: 1
list of methods
>> obj=myclass()
obj =
myclass
properties:
prop: 1
list of methods
>> obj.set1(10)
??? Setting the ‘prop’ property of the ‘myclass’ class is not allowed.

Error in ==> myclass>myclass.set1 at 7
obj.prop=val;

None of my attempts have been successful. This behavior is consistent with my idea of a constant (never ever changing). Yet, in the documentation under the heading “Defining Named Constants,” it says, “Note that setting the Constant attribute to true effectively sets the SetAccess to private, so that the values of the properties cannot be changed outside of the class.” That implies that one should be able to change the value of a constant from within a class’s method as I tried, and it also implies a conflict with my combination of “Constant” and “SetAccess=public” above.

Is there a way to modify my example to implement a class property whose value is publicly changeable (i.e. myclass.prop=10), yet uniform across all instances of the class?

Any progress on this question of static properties? One can clearly define them, for example here is a classdef file:

—————————
classdef myClass
properties (Static)
x = 1 ;
end
methods (Static)
function f(val)
myClass.x = val ;
end
end
end
—————————

and the get method works:

—————————
> myClass.x
ans = 1
—————————

but the set method does not work, either on the command-line or via a static method function!

Thanks,
Lee

Constant properties may not be changed from the initial value specified in the property declaration. There are a couple of reasons why MATLAB works the way it does. First, MATLAB has longstanding rules that variables always take precedent over the names of functions and classes and that assignment statements introduce a variable if one doesn’t already exist. Thus, any expression of the form “A.B = C” will introduce a new variable A that is a struct array containing a field B whose value is C. If “A.B = C” could refer to a static property of class A, then class A would take precedent over variable A and this would be a very significant incompatibility with prior releases of MATLAB. It would mean that an m-file containing the assignment statement “A.B = C” could have its meaning changed by the introduction of a class named A somewhere on the MATLAB path. MATLAB programmers have always been able to rely on assignment statements introducing variables that shadow any other use of the same name.

Second, we have observed that static data is rarely used in other classes except as private data within the class or as public constants. For example, a survey of several Java class libraries found that all public static fields were also final. In MATLAB, Constant properties can be used like “public final static” fields in Java. For data internal to a class, MATLAB already has persistent variables that can be created inside of private or protected methods or local functions privately used by a class. There are also good reasons to avoid static data in MATLAB where possible. If a class has static data, it can be difficult to use the same class in multiple applications because the static data can be a source of conflicts among applications. In some other languages, this is less of an issue because different applications are separately compiled into executables running in different processes with different copies of class static data. In MATLAB, frequently many different applications may be running in the same process and environment with a single copy of each class.

These postings are the author's and don't necessarily represent the opinions of MathWorks.