Scalar quantization, as Wikipedia puts it,
“is the process of approximating a continuous range of values (or a very large set of possible discrete values) by a relatively-small set of discrete symbols or integer values.”
Generally, the process involves mapping from an interval of numbers in the range to a single number in the domain. Because it is a process so heavily used in signal compression, it is useful to have a function to perform it at high speeds in MATLAB. The Communications Toolbox includes a quantiz function, which maps a vector of floats to a vector of integers given another vector of ranges, but being implemented as an m-file, it is slow.
However, the base toolbox (the one that has all of the general MATLAB tools), has the histc function. histc, given a data vector and a vector of bin edges, counts the number data elements in each bin. The lesser known second output of histc actually returns the bin number for each data element, the process of quantization.
For example, suppose we wanted to perform 3-bit uniform quantization for the numbers between 0 and 1, i.e., given a data vector x and evenly distributed bins between 0 and 1, we wanted to map each data value to an integer 0 through 7.
>> x = rand(1, 100); >> e = linspace(0, 1, 8); >> [n, idx] = histc(x, e);
The previous snippet yields each element of x mapped to a number 1 through 8 in idx (we may subtract 1 to get 3-bit numbers 0 through 7).
To approximate x using the bin edges (codebook) and quantization indices, we may:
>> y = e(idx);
If we had subtracted 1 from the idx, we would have to add it back in at this stage. The same procedure holds for any non-overlapping, ordered, quantization partitions, e.g., exponential, Lloyd-Max. For large data-sets, and reasonable size codebooks, the space savings are significant as is the performance of histc over quantiz.

Earlier, I complained that MATLAB’s Object Orientation was lacking and suggested an improvement. As it turns out, MATLAB already has an extremely similar mechanism to the one I suggested, but has not documented it. The mechanism has existed since at least 7.3 (R14.3), but has several changes in R2006b.
The simplest class definition is:
classdef myclass
<statement-1>
<statement-2>
.
.
.
<statement-N>
end
Generally, the statements inside of the class will be method and field declarations, but any valid MATLAB is valid within the class definition.
This syntax is new as of R2006b. In R2006a and R14.3, classdef must be replaced with class
As before, m-files with class definitions must be placed in directories named @classname For example, an m-file named myclass.m might define a class myclass by opening the file with classdef myclass, but to be recognized as a class, myclass.m must be in a directory called @myclass on the MATLAB path.
More information forthcoming.
More information forthcoming.
This OO API supports fine-grained access controls (public, private, protected) for both fields and methods. More information forthcoming.
This OO API simplifies inheritance. Suppose myclass should inherit from baseclass. When defining myclass, we write:
classdef myclass<baseclass
<statement-1>
<statement-2>
.
.
.
<statement-N>
end
The only change from the standard class definition is the addition of baseclass to the class definition line.
Like variables passed into and returned from functions, MATLAB implements lazy copy when assigning values to class fields. For example,
>> a = rand(1000); >> x = myclass(); >> y = myclass(); >> x.data = a; >> y.data = a;
This snippet requires enough memory to hold a, (plus some small overhead to hold the class data for x and y) but does not copy a unless a, x.data, y.data is modified. Hence the above snippet will require roughly only 8MB of memory rather than 24MB.
I am preparing longer documentation and will post it when complete. For longer examples, see the implementations of memmapfile and timeseries in MATLAB.
The structure of the above documentation is borrowed from the Python Tutorial’s chapter on classes.

I found a nasty bug in MATLAB last week: when using the Generic Library Interface, MATLAB will not recognize C structures with no fields, even though they are valid C constructs. I filed this bug with MATLAB and a business day later, got this reply:
Currently there are no workarounds to resolve this issue . We hope to have it rectified in a future release.
That should actually read:
We don’t have any idea how to fix that problem, but if we figure it out, we’ll be charging you for it whenever we get around to releasing a new version.
Thanks Mathworks!

For a long time now, it has been possible to create classes in Matlab. Sort of. Except that there’s no pass by reference, so calling a set() method on a class has no real meaning. My biggest problem with Matlab’s classes though are that they require the @classname directories with individual m-file function underneath.
If I wanted private methods in my class, I would create another folder named private and stick more m-files in there.
So as it stands, if I wanted to create a class myclass that contained two public methods, foo and bar and some private functions, I would create a directory structure like so:
@myclass/
foo.m
bar.m
private/
priv1.m
priv2.mBut what other approach is there?
Since R14, Matlab has had named inner classes. Conveniently, these inner classes share the workspace with their surrounding classes, but their surrounding function does not share a workspace with them. Also, inner functions within a single function are able to access eachother. Now how hard would it be to introduce a class keyword (or something else since class() is already a function) that encapsulates a number of inner functions. Each function would be public, a la Python (or introduce public, private, protected keywords) and an entire class could be published in a single file, like every other language out there.
For example, we could rewrite the above set of m-files as:
class myclass
function foo(x, y)
% Some stuff happens in here
end
function bar(a, b)
% Some more stuff happens in here
end
end
Supposing that we wanted our class to inherit from something, we could easily write myclass(yourclass) or something similar to denote inheritance.
Now, we have a self contained class that requires only a single new keyword (putting in private methods might take a little more, but Mathworks could be lazy and use double underscores or something like Python). Like before, there is no access to internal variables, but we have the same functionality while being much easier on developers.
So, any Matlab gurus or Mathworks engineers out there that can tell me why this is a terrible idea?
Oh, could we get interfaces or abstract classes too?
