Sparse Matrices in Python from Matlab R2014b

First of all, you can’t pass sparse matrices, so you have to have enough RAM to hold the full matrix and probably a copy or two of it. This is more just to show how it could be done, and hope that the Mathworks will improve the passing of variables in future releases of Matlab.

All commands are issued in Matlab R2014b.

a = eye(5);
A = py.numpy.reshape(a(:)',size(a));
As = py.scipy.sparse.csc_matrix(A)

As =
Python csc_matrix with properties:

dtype: [1x1 py.numpy.dtype]
has_sorted_indices: 1
nnz: 5
shape: [1x1 py.tuple]
maxprint: 50
indices: [1x1 py.numpy.ndarray]
data: [1x1 py.numpy.ndarray]
indptr: [1x1 py.numpy.ndarray]
format: [1x1 py.str]
(0, 0) 1.0
(1, 1) 1.0
(2, 2) 1.0
(3, 3) 1.0
(4, 4) 1.0

Matlab R2014b: passing matrices to/from Python

As noted in my earlier post, this is awkward because Matlab doesn’t understand Numpy arrays. Matlab understands lists, dicts, sets, scalars, and other less frequently used classes from Python. Let’s do an example with the “clown” image included with Matlab. All commands here are executed in Matlab R2014b.

First off, here are some Python packages that don’t currently work from Matlab R2014b (just hard crash Matlab)
scikit-image
cv2 (opencv 2.4)

NOTE: The use of the ‘F’ parameter to and from Python in the .reshape() and .ravel() methods–this is crucial or your matrix will be transposed inside Python!


load clown % 200x320 image is now in variable X
Xp = py.numpy.reshape(X(:)',size(X),'F'); % I ravel X to a row vector, and unravel with Numpy
Yp = py.scipy.ndimage.gaussian_filter(Xp,3); % SciPy works, but Scikit-image doesn't for me
% now let's come back to Matlab
Y = reshape(cell2mat(cell(Yp.ravel('F').tolist())),size(X)); % a regular Matlab 2-D matrix
imshow(Y,map) %map comes from when you load clown

% now let's do something similar in Matlab--note I didn't make the filter truncation radius the same, so the numerical results differ.
F = fspecial('gaussian',[15,15],3);
M = imfilter(X,F);
imshow(M,map)

Of course normally you would be using Python for a function not readily available in Matlab, but this was a side-by-side working example.

My Comment on Draft AGU Data Position Statement

http://sciencepolicy.agu.org/draft-data-position-statement-comment/

I like the new emphasis on documentation. I would strengthen this even further by emphasizing the provision of open-source code/API that allows at minimum recreation of all figures in published papers, and canonical registration cases. Publication of source code AND compilation instructions (example: GPL) necessary to recreate all paper figures should be an essential requirement for publication.

Video Software Defined Radio lectures from WPI

At youtube, from Worcester Polytech Inst.:
ECE4305

ECE5312

Matlab R2014b: X11 forwarding and OpenGL

The new plotting engine in Matlab R2014b has caused some hangups and reduced quality plots for people using Matlab over X11 forwarding.

Consider starting Matlab this way:

matlab -nosoftwareopengl

figure
set(gcf,'renderermode','manual','renderer','painters')
plot(randn(100,1))

If you can’t start Matlab with the -nosoftwareopengl open, omit that open and try plotting with the

set(gcf….’painters’) line as shown above for each figure.

 

Matlab R2014b: installing the integrated OpenCV support

Initially it appears that to use OpenCV from Matlab R2014b, you will need to write your OpenCV calls in C++, using all the usual Mex stuff. This is not very convenient to me; it would be much more convenient to use the friendly syntax of Python. However the Python support in Matlab R2014b allows passing only 1xN arrays, so there would be reshaping involved to/from Python that would slow things down.

The mexopencv package that has been available for some time (and that works with earlier versions of Matlab) seems to be more user-friendly once installed–you use it much like any other Matlab toolbox, without you needing to code in C++/Mex yourself.

Bottom line: I’ll still be using Python/OpenCV without Matlab, or even C++/OpenCV, which looks easier than using Mex with Matlab. I am glad Mathworks has taken this step; maybe the mexopencv people will make the R2014b OpenCV support easier to use by making a bunch of .cpp functions to compile once and then call.

This process gets the packages downloaded and installed:
http://www.mathworks.com/help/vision/ug/install-data-for-computer-vision-system-toolbox.html

The directory with examples is at:

~/Documents/MATLAB/SupportPackages/R2014b/opencvinterface/toolbox/vision/supportpackages/visionopencv/example/

Here’s how the first example, the Foreground Detector works from Matlab:

cd ~/Documents/MATLAB/SupportPackages/R2014b/opencvinterface/toolbox/vision/supportpackages/visionopencv/example/ForegroundDetector

mexOpenCV backgroundSubtractorOCV.cpp

testBackgroundSubtractor

You will see a Video Player window pop up with cars driving by, with the cars detected outlined in white rectangles.

Matlab 2014b Python: can only pass 1xN vectors!

Note that for Matlab 2014b, which is the first version of Matlab to have official support for Python, you can only to TO python a 1xN vector. You have to reshape the matrix into a 1xN vector when passing the matrix into Python, and reshape back to a matrix inside Python, but  I think Matlab will make copies at both reshapings.

Note that Numpy ndarrays are not understandable by Matlab, you will have to make your Numpy array into a 1-D list and then send it back. Yikes that’s a lot of memory copying!

I can pass
py.numpy.sqrt(2)

ans=1.4142
 and

py.numpy.sqrt([2,2])

ans=[ 1.41421356  1.41421356]

but I cannot pass
py.numpy.sqrt([2,2;2,2])
Error using py.numpy.sqrt
Conversion of MATLAB 'double' to Python is only supported for 1-N vectors.

the link below seems to confirm that you cannot pass normal 2D matrices to Python from Matlab R2014b:

http://www.mathworks.com/help/matlab/matlab_external/passing-data-to-python.html?searchHighlight=python%20array#buialof-51

Matplotlib: 3-D mesh wiregrid example

Some of the Matplotlib 3-D examples out there are a little out of date. Here is a minimal working example for the current version of Matplotlib 1.4


#!/usr/bin/env python
from mpl_toolkits.mplot3d import Axes3D # this line must come before the next line!
from matplotlib.pyplot import figure,show
from numpy import linspace,meshgrid,pi,sin #for testing
'''
key point: the line "from mpl_toolkits.mplot3d import Axes3D" needs to come before
the "from matplotlib.pyplot import ...." line in the FIRST file you run.
To be sure, I make the "from mpl_toolkits.mplot3d ..." line come first in my
main function file (the one I invoke from the command line or Spyder)
'''

def test():
    x,y = meshgrid(linspace(0,2*pi),linspace(0,2*pi))

    z = sin(x+0.5*y)
    ax = figure().gca(projection='3d')
    ax.plot_wireframe(x,y,z)
    show()

if __name__ == '__main__':
    test()


Matplotlib: force integer labeling of axis

When plotting output of simulations with Matplotlib, sometimes we want to label an axis as say “instantiation #” or “Sample #” or “try #” or the like.
To do this, you need to do:

import matplotlib.pyplot as plt
from matplotlib.ticker import MaxNLocator
....
ax = plt.figure().gca()
...
ax.xaxis.set_major_locator(MaxNLocator(integer=True))

This will make the x-axis have integer-only labels. You can do the same for yaxis if you want.

Amateur Radio band plans: strong FM adjacent to weak signal modes thoughts

I was in an conversation with regard to a 902MHz enthusiast list, and we were discussing issues that may be unique to the 902MHz band due to the ARRL band plan, that was adapted to reflect reality in much of the USA with regard to easily adaptable commercial equipment.

The real life ham bands where the FM next to weak signal situation might occur (in the USA) based on the ARRL band plan include:
50MHz: The SSB/CW only and “any mode” meet at 50.3MHz. Maybe most FM operators stay about 51MHz? I have the equipment for this band but regrettably don’t listen often.
144MHz: I assume most weak signal work is at least 100kHz away from the popular 144.390MHz APRS frequency
220MHz: Again a case of ~100kHz spacing between FM and whatever weak signal work may exist
440MHz: The satellite band with what are typically very directive antennas keep multi-MHz separation between FM and weak-signal
900MHz: I would expect below 902.080MHz and above 902.120MHz to be trashed for weak signal operators according to the band plan.

The situation I felt hinges on:
a) what the relevant FCC specifications demand for “off-channel, in-band” emissions — is this just specified as say -60dB so many kHz from center channel, or with an emission mask. In either case, is the specification sufficient to protect a weak signal operator within N km of a powerful FM transmitter?
b) If the specification is not sufficient for weak signal protection from nearby (in range) FM transmitters, do the practical filter implementations used by the most frequently used equipment provide enough protection any way as a corollary to meeting the FCC specification?