Using matlab's "convhulln" (3D), my code sometimes crashes complaining of "initial facet 1 coplanar with the interior". This is correct when I inspect the shape of the object visually. But could I somehow check for this before using convhulln on the object, so I could avoid crash ? And find out which direction co-planarity lies in, so I could then use convhulln in a correct way ?
If your only concern is not crashing the code, you can use the following structure:
try
% Do your calculations
catch
%This is evaluated if something went wrong
end
Related
I am using Matlab 2016a. I have four matrices of size 2044x1572x84 and am trying to regress each column of each matrix to produce a new 2044x1572 matrix of regression coefficients. I need to use parfor; a for loop would take way too long.
When I use the below code using test data (e.g. using rand to make four matrices of 50x50x40) the code executes with no errors. However, when I try using the same code in a cluster with the full 2044x1572x84 matrices I get a transparency violation error with regards to the table: Error using table (line 247) Transparency violation error. I've tried modifying the table code to fix this but only get a suite of other errors.
I'm unsure how to fix the error in this case, particularly given that the success of the code seems to be dependent on the size of the input data. I'm not particularly familiar with parfor, and any feedback on what I may be doing wrong would be greatly appreciated.
COEFF_LST=ones(2044,1572);
parfor i=1:2044
for j=1:1572
ZZ=squeeze(ARRAY_DETREND_L2_LST(i,j,:));
XX=squeeze(ARRAY_DETREND_L2_ONDVI(i,j,:));
YY=squeeze(ARRAY_DETREND_WB_85(i,j,:));
LL=squeeze(ARRAY_DETREND_L2_CNDVI(i,j,:));
T=table(ZZ,XX,YY,LL,'VariableNames',{'LST','ONDVI','DROUGHT','NDVI'});
lm=fitlm(T);
array=table2array(lm.Coefficients);
COEFF_LST(i,j)=array(3,1);
end
end
The table constructor uses inputname under certain circumstances - that can cause transparency violations inside parfor. I realise it's inconvenient, but perhaps you could try "hiding" the table call inside a separate function. I.e.
parfor ...
T = myTableBuilder(ZZ,XX,...);
end
function t = myTableBuilder(varargin)
t = table(varargin{:});
end
In this case I'm getting a transparency error with table, so a simple solution that works is to not use table.
In this case the code would be:
Predictor_Matrix=horzcat(ZZ,XX,YY);
lm = fitlm(Predictor_Matrix,WW);
This works on a cluster without throwing any errors.
I keep getting this error. I received this error after I corrected for logical integer error. The only way I could think of programming this was defining the initial value and then start euler's method at the next t value since it uses the previous solution to find the next one. But by doing this I am getting this error? I'm unsure how to fix it. I tried to end one step from my final value but that didn't work either. Thanks for the help. For the problem we had to create the function and call it. I was initially using n=8.
function [exeuler] = pb3(n)
%using explicit euler to solve ODE with input n and outputting exeuler as
%the answer
%n=steps t,y are initial conditions
h=3/n;
t=logical((1+h):h:4);
back=logical(t-h);
exeuler(1)=2; %defines the initial value
exeuler(t)=exeuler(back)+h*(t.^2-(2*exeuler(back)/t));
end
Well, I am sorry, but you haven't showed much of effort. For the future, please provide the complete code (i.e. with example function and so on). This is very unclear.
I think your problem is in these lines:
t=logical((1+h):h:4);
exeuler(t)=exeuler(back)+h*(t.^2-(2*exeuler(back)/t));
cause t is a vector. You are calling vector with non-integer values as index. Then, I guess, you get the wrong amount of exeuler(t)'s which leads to the error.
And for-loop is missing, isn't it? Because you don't use the Euler method stepwise andd therefore f(t+1) doesn't really depend on f(t).
So, my advice in general would be not to correct this error, but to rethink your algorithm.
I am having problem when I try to store rmabackadj function's output to a variable. The function works properly when no output variable is assigned. This function is part of bioinformatics toolbox.
So the issue is when I try to run the following it works properly:
rmabackadj(myprobeData.PMIntensities)
But when I try to run the following I get an error:
>> A = rmabackadj(myprobeData.PMIntensities)
Warning: Colon operands must be real scalars.
> In rmabackadj>findMaxDensity at 255
In rmabackadj at 164
Error using ksdensity>parse_args (line 162)
X must be a non-empty vector.
Error in ksdensity (line 114)
[axarg,yData,n,ymin,ymax,xispecified,xi,u,m,kernelname,...
Error in rmabackadj>findMaxDensity (line 255)
[f, x] = ksdensity(z, min(z):(max(z)-min(z))/npoints:max(z), 'kernel', 'epanechnikov');
Error in rmabackadj (line 164)
mu = findMaxDensity( o(o < mu));
I searched for it online as well, but I couldn't find any result. Does anybody have any idea about the cause of this error?
PS: When I assign ans variable to a new variable, it is properly assigned.
A = ans
I'm pretty sure this is a bug.
Firstly, the reason it errors only when you supply an output argument is because there's an internal switch in the function that calculates different things based on nargout. That's an odd design, but not necessarily a bug.
Internal to rmabackadj there are two subfunctions findMaxDensity and findMaxDensity2. The main routine calls findMaxDensity, which is supposed to find an initial guess for the parameter mu. However (when I run the documentation example that you mention in your comment), it finds a terrible guess right on the edge, leading to an error.
When I edit the file to call findMaxDensity2 rather than findMaxDensity, it seems to produce a reasonable guess, and runs fine with no error. I can't vouch for whether the guess is actually "correct", but it seems reasonable to me, and it's only functioning as an initial guess to start off a better estimation process. (NB if you do this yourself, make sure to save a copy of the old version first).
I would guess that this is a bug, either that findMaxdensity is generating an unusually poor guess that should be caught, or that really it should be calling findMaxDensity2 and the code has not been updated to call a new subfunction.
Either way, I would report it to MathWorks.
PS I am running MATLAB R2011b. Check first if the issue has been fixed, or behaves differently, in more recent versions.
Mathworks confirmed this bug and issued a work around for it and mentioned this may be fixed in future releases.
One possible workaround is to add the following conditional at line 163 of rmabackadj function
% estimate mu from left-of-the-mode data
if any(o < mu)
mu = findMaxDensity( o(o < mu));
end
The bug for N<1000 samples has been confirmed as well but no work around has been issued yet.
I will update the thread if the work around for N<1000 samples bug.
I have a project to transform an image using dwt.
I successfully done it using function dwt2, and now I try to use function dwt3 by changes some code from the function dwt2 (add more subband: 8 subbands). Unfortunately, an error comes out, which said "Too many output arguments".
My question is, what is the right way to write MATLAB code for dwt3? Is it not same as dwt2, just add more subbands?
Just by looking at the official documentation for dwt2 and dwt3, I see that dtw3 has only 1 output variable, whereas dtw2 has 4.
I assume you just replaced the string dtw2 in your code to dwt3, without paying attention to the amount of allowed output variables. So there you go, that's where the error "too many output variables" comes from...
If dwt3 only returns the transformed vector, cut the number of output variables to 1, and I'm sure the error will away:
Y = dwt3(X, 'db2');
Here I transformed X using dwt3 with the Daubechies 2-tap wavelet, and stored the result in Y.
P.S
You need to show more code if you want more productive, helpful answers...
So I am debugging some Matlab code and I get the dimension-doesn't-agree-error for some expressions. It's all nice that Matlab points to the correct line etc. However it would be nice if Matlab would output the dimensions of the variables involved in the error text so I don't have to deal with sizing them up myself. Sometimes for a long expression deep in a for loop it's a real hassle to figure out what exactly all dimensions are.
So is there a setting or hack for this?
The easiest way to deal with this issue is to type dbstop if error in the command window, and then to run the code. MATLAB will then stop execution right before it would throw the error, and it will open the editor on the line where the error would be thrown. Then you can inspect the array sizes at your leisure, and you can even, in the command window, try out possible fixes, because you will have access to all the variables currently active in the code.
You can try the try-catch-end block.
E.g.
try
%# Some error prone code
a = getA(b);
catch err_msg
%# Display any information you want
disp(size(b));
%# Display the error message
disp(err_msg.identifier);
disp(err_msg.message);
end
You can also throw in a breakpoint in the catch block if you want to evaluate things yourself.