This is the line from your example where blue is assigned to myLine.Color:

myLine.Color = blue;

But it should be:

myLine.Color = 'blue';

Is this correct?

I am asking this because the first version is not working on my computer.

Kind regards,

Dominik

Alan

]]>First, note that there is a very simple symbolic explanation for why the stated result is generally false. Since L is invertible, LAL^(-1) = D is equivalent to A = L^(-1) D L. Since the inverse of a lower triangular matrix is lower triangular, and since a diagonal matrix is trivially lower triangular, A is a product of lower triangular matrices, and hence, lower triangular. Since A is also symmetric, the only possible way this could be true is if A is actually a diagonal matrix.

Now, why would L A L^T make sense? Since A is positive definite symmetric (and some folks would say that “symmetric” is redundant, others would disagree), A has a choleski factorization (look up the Matlab command for this core function). That is, there is a lower triangular matrix C so that A = C C^T where the matrix C (and hence C^T ) has an entrywise positive diagonal. Some folks prefer to modify this factorization as A = M D M^T where M is a lower triangular matrix with all diagonal entries equal to 1. (To obtain M from C, let X = diag(sqrt(diag(C)); then M = C X^(-1) and D = X.^2 .) Since M is lower triangular with all diagonal entries 1, L= M^(-1) exists. Also, M^T = (L^(-1))^T = (L^T)^(-1). So A = M D M^T = L^(-1) D (L^T)^(-1). Then L A L^T = D.

symbolic and numerical experimenting are at the heart of doing mathematics, and I love how you exploited the power of Matlab to determine that there was an error with the asserted formula. Theory allows us to understand my a result is generally false, and what additional restrictions might make it true. Experimentation or theory allows us to speculate about what the author (versus the typesetter?) might have meant, and theory allows us to determine a related but true result.

]]>I’m generally quite excited about the changes to the graphics. In particular, the new histograms are awesome! I also really like the change in behaviour of “hold on”.

I am, however, running into problems with printing figures (on OS X 10.9.5). These problems are:

- When printing to eps, the file size has increased considerably. Admittedly, I am plotting a rather large data set (1200*139 data points), but the old system had no problem with this. For example, the following code results in a 3 MB file with R2012a and a 28.4 MB file with R2014b. Specifying the opengl renderer reduces the file size, but it is no longer a vector format.

w = randn(1200,139) + 1j*randn(1200,139); plot(w,'.'); print -depsc test.eps

- The bounding box definition is no longer compatible with all eps interpreters. It seems to be fine (tight) with some programs such as Inkscape and when converting to pdf with ps2pdf, but other software such as OS X’s Preview render it as a figure at the bottom of a letter sized sheet of paper.

Finally, printing to pdf instead of eps solves the file size problem, but not the bounding box problem. I have tried to use “set(gcf,’PaperPositionMode’,'auto’)”, but I still get a pdf that is letter sized with a figure in the centre.

In the mean time I am using png’s for managable file sizes and a tight bounding box, but I would ultimately prefer a vector format. I appreciate any comments you might have on this issue.

]]>I know about the position property of the colorbar – but this does not include the ticklabels. In former Matlab version I was used to determining the extra space by reading out ‘tightInset’ – this seems to be impossible right now.

Thank you for your response,

Ralf Hielscher

]]>