Matlab crashes but Octave doesn't
Show older comments
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
per isakson
on 2 Jan 2019
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
>>
Walter Roberson
on 2 Jan 2019
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?
Douglas Brenner
on 2 Jan 2019
Douglas Brenner
on 2 Jan 2019
Walter Roberson
on 2 Jan 2019
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.
Douglas Brenner
on 2 Jan 2019
Image Analyst
on 2 Jan 2019
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.
Walter Roberson
on 2 Jan 2019
Edited: Walter Roberson
on 2 Jan 2019
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
on 2 Jan 2019
Edited: per isakson
on 2 Jan 2019
Walter Roberson
on 2 Jan 2019
R2014a and R2014b are not supported for MacOS 10.14. R2018b is the first supported version for MacOS 10.14.
Walter Roberson
on 2 Jan 2019
The fault appears to be occuring in
mxArray_tag* fullMldivideSolverT<double>(mxArray_tag*, mxArray_tag*, bool)
Douglas Brenner
on 2 Jan 2019
John D'Errico
on 2 Jan 2019
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.
Walter Roberson
on 2 Jan 2019
Apple made changes to MacOS that prevent older versions of MATLAB from running. (See my previous remarks about external interfaces...)
Accepted Answer
More Answers (2)
Image Analyst
on 2 Jan 2019
1 vote
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
Douglas Brenner
on 2 Jan 2019
0 votes
Categories
Find more on Logical in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!