Matlab crashes but Octave doesn't

The program below runs in Octave but crashes Matlab 2014. Mathworks won't help because my contract has run out. Any ideas would be helpful.
X = [1 , 2 ,3 , 4 ,5];
Y = [1,4,9,4, 1];
xdata = X(:);
A = [xdata.^2, xdata, ones(size(xdata))]
b = log(Y(:));
x = A\b
mu = -x(2)/x(1)/2;
sigma = sqrt( -1/2/x(1) );
A0 = exp(x(3)+mu^2/(2*sigma^2));

14 Comments

On Win10, R2018b your script runs and displays
A =
1 1 1
4 2 1
9 3 1
16 4 1
25 5 1
x =
-0.5119
3.0716
-2.5896
>>
Works for me in R2014a and R2014b on Mac.
Question: Would you just happen to be running on MS Windows, with an AMD Jaguar processor?
Very helpful. My instutition paid for what should have been a working copy. And they won't pay for an upgrade because they don't trust Mathworks to produce upgrades that are downward compatible.
No. I'm running on a MAC.
And just to make sure my last comment was not directed at you.
The number of vendors who will commit to downwards compatibility is vanishingly small.
Committing to downwards compatibility requires that formal proof methods be used to prove software 100% correct in every respect -- which in turn really just shifts the burden to proving that the specification is 100% correct.
You cannot commit to downards compatibility without formal proof methods because otherwise the risk is too high that you might have had a bug in a past release, and if you ever had a bug then backwards compatibility requires that all later releases have exactly the same bug in every respect.
Committing to downwards compatability is not possible for any software that relies on external interfaces provided by an operating system, such as graphics systems, because those could have bugs that you would then need to replicate forever in the name of downward compatibility.
Effectively, committments to downward compatibility can only be made for programs that accept only US-ASCII 65 character input and emit only US-ASCII 65 character output, with no file I/O, and with no dynamic memory allocation (only fixed size static memory.) A program which is sized to run in 650 megabytes of memory at some historical point is not backwards compatible if at some later point it permits using up to 1 gigabyte of memory.
Fiar enough. So I'm stuck with a copy of Matlab which for some reason isn't running properly but which seems to run on other machines.
Is Octave downward compatible?
And they trust open source software enough to use it, but not commercially produced software? With some companies it's the opposite - they prefer or require commercially available and validated software over open source software.
post the crash dump. There is a chance we might happen to recognize something .
if you single step is the crash in the last line?
Which osx version are you using ?
Douglas Brenner
Douglas Brenner on 2 Jan 2019
Edited: per isakson on 2 Jan 2019
It crashed on line x = A\b. I check the the values of b and found two elements were zero. In case that was the problem, I modified my input but that didn't help. The crash dump is attached. I'm running 10.14.2
R2014a and R2014b are not supported for MacOS 10.14. R2018b is the first supported version for MacOS 10.14.
The fault appears to be occuring in
mxArray_tag* fullMldivideSolverT<double>(mxArray_tag*, mxArray_tag*, bool)
Ok. But that doesn't mean anything to me.
Essentially, it means you can't use MATLAB for this, at least a too old release on a too new computer. I'm actually surprised MATLAB even started up. Complain to your institution (as if that will help.) But you can try. Argue that as new students enter the system, they are bringing in new (current) computers.
Apple made changes to MacOS that prevent older versions of MATLAB from running. (See my previous remarks about external interfaces...)

Sign in to comment.

 Accepted Answer

James Tursa
James Tursa on 2 Jan 2019
What happens if you do the A\b differently? E.g., doing the LU decomposition manually and then backsolving yourself? Or doing pinv(A)*b?

More Answers (2)

If you need it in MATLAB, then pay the money and upgrade. It doesn't crash for me on R2018b. It gives:
A =
1 1 1
4 2 1
9 3 1
16 4 1
25 5 1
x =
-0.511931276922301
3.07158766153381
-2.58955627854091
Give that man a cigar and thank you very much.
pinv(A)*b work as I suspect doing the LU decomposition manually would.

Tags

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!