I know what a cell array is. I just came to the following line:
cell_array = cell([], 1);
What does that mean? How can we read the above line?
Thanks.
So this makes a 0x1 empty cell array. As in literally 0 rows and 1 column. You could make a 0x0 cell array like this:
cell_array = {}
which makes sense to me. I do that sometimes like if you can't preallocate before a loop, sometimes it's useful to concatenate onto or to go cell_array(end) = ... in the loop.
I really don't know why you'd prefer a 0x1 but this question shows how it differs from a 0x0. So I mean, if for some weird reason you are running a for loop on this empty array you know it will run at least once :/ But that's really scraping the barrel for a reason. I think just stick with = {}.
EDIT:
As #radarhead points out, this is one way to preset the number of columns if you plan on concatenating new rows in a loop.
cell is used to allocate a cell array, in this case: cell_array.
So an empty cell of size 0x1 is allocated.
However, this is no usefull syntax for cells. For other (custom) objects it can be useful to generate such empty arrays
myArray = myObject.empty(0, 1);
Related
I'm trying to delete multiple consecutive and non-consecutive columns from a 80-column, 1-row cell array mycells. My question is: what's the correct indexing of a vector of columns in Matlab?
What I tried to do is: mycells(1,[4:6,8,9]) = [] in an attempt to remove columns 4 to 6, column 8 and 9. But I get the error: A null assignment can have only one non-colon index.
Use a colon for the first index. That way only the 2nd index is "non-colon". E.g.,
mycells(:,[4:6,8,9]) = []
MATLAB could have been smart enough to recognize that when there is only one row the 1 and : amount to the same thing and you will still get a rectangular array result, but it isn't.
Before getting the above VERY VERY HELPFUL AND MUCH SIMPLER answers, I ended up doing something more convoluted. As it worked in my case, I'll post it here for anyone in future:
So, I had a cell array vector, of which I wanted to drop specific cells. I created another cell array of the ones I wanted to remove:
remcols = mycells(1,[4:6,8,9])
Then I used the bellow function to overwrite onto mycells only those cells which are different between remcols and mycells (these were actually the cells I wanted to keep from mycells):
mycells = setdiff(mycells,remcols)
This is not neat at all but hopefully serves the purpose of someone somewhere in the world.
I have a 2D array, and have computed necessary updates along a given dimension of it using a 1D array (said updates can't be computed in place as earlier calculations would override values needed in later calculations). I thus want to copy the updates into my 2D array. The most obvious way to do this would, at first glance, appear to be to use Array slicing and Array.blit.
I have tried the approach of extracting the relevant dimension using array slicing, and then blitting across to that, but that doesn't update the values inside the 2D array. I think what is happening is that a new, separate, 1D array is being created when I make the slice, and the values are being blitted into that new array, which of course is dropped a moment later when it goes back out of scope.
I suppose you could say that I was expecting the slicing to return a view into the 2D array which would work for the blit function call, but instead the slicing actually returns a new array with the values copied into it (which, thinking about it, is what slicing does otherwise, I believe).
Currently I am using a workaround whereby I create a 2D array, where one of the dimensions is only 1 element wide (thus effectively re-creating a 1D array), and then using Array2D.blit. I would prefer to do it directly though, both because I find this ugly, and moreover because it would be quite useful elsewhere in my program where I can't just declare a 1D array as 2D.
My first approach:
let srcArray = Array.zeroCreate srcArrayLength
... // do relevant computation
srcArray.[index] <- result
... // finish computation
Array.blit srcArray 0 destArray.[index, *] 0 srcArrayLength
My current approach:
let srcArray = Array2D.zeroCreate 1 srcArrayLength
... // do relevant computation
srcArray.[0,index] <- result
... // finish computation
Array2D.blit srcArray 0 0 destArray index 0 1 srcArrayLength
The former approach has no effect on my destination 2D array. The latter approach works where I use it, but as I said above it isn't nice, and cannot be used in another situation, where I have a jagged 2D array (i.e. 'a[][]) that I would like to blit across from.
How might I go about achieiving my aim? I thought of Span/Memory, but it wasn't clear to me if and how they could be used here. Alternatively, if you can spot a better way to do this that doesn't involve blit, I'm all-virtual-ears.
I figured out a fairly good solution to this, with the help of someone over in the F# Foundation Slack. Since nobody else has posted an answer, I'll put this one up.
Both Array.Copy (note that that is the .NET Array.Copy method, not the F#-specific Array.copy) and Buffer.BlockCopy were suggested to me. Array.Copy still complains about mismatching array types, but Buffer.BlockCopy ignores the dimensionality of the supplied array, and merely copies the specified number of bytes from one location to another. Using this and relying on the fact that 2D arrays are really stored as 1D arrays in row-major order (the same as C, I believe), it is quite possible to overwrite the last dimension of a multi-dimensional array reasonably cleanly.
I updated the code from the 'current approach' in my question to the below:
let srcArray = Array.zeroCreate srcArrayLength
... //do relevant computation
srcArray.[index] <- result
... //finish computation
Buffer.BlockCopy(srcArray, 0, destArray, firstDimIndex * lengthOfSecondDim * sizeof<'a>, lengthOfSecondDim * sizeof<'a>
Not only does it do the job in a way which I personally find a bit tidier, but it has a side-benefit in that it is noticeably faster than the second approach described in the question - I haven't yet run a benchmark to quantify the difference though.
I had several (500) files which I imported it into Matlab. There are 500 cells and each cell has data of size {5000 by 2} each. I want to save
them separately into arrays like M and N in a loop. like M(i) and N(i) so that i can do any kind of processing or fitting with the data within the loop.
k=1:500
value(k) = {mydata{k}(:).data};
IV{1,k}=value{1,k};
A(k)=cat(1, IV{1,k});
M(k)=A(:,1);
N(k)=A(:,2);
If I check it , "H = cat(1, IV{1,4});" concatenation command works perfectly for saving into single arrays. But it's not working into loop. I think the problem lies in the correct usage of cell array contents.
I like cell2mat in situations like this. https://www.mathworks.com/help/matlab/ref/cell2mat.html
I would turn your cell into an array, you might be able to avoid a for loop entirely.
I'm at a loss for what to do in my program (written in C). There is a large matrix of numbers (an image) that I am processing. The processing happens one line at a time, with reference to the previous line, so I only need to access two lines of numbers at a time.
Originally, I tried a 2 by X array but once I save the information for the third line, the array is upside down with the third line of the image in the first row of the array and the second line of the image in the second row of the image.
Is there a better way to correct this other than simply copying the second row of the array to the first row? Maybe it wouldn't be so bad, but I would imagine doing that for every other line of the image would be expensive. Should I use two pointers on the image instead?
I apologize if this is a common thing that can be easily looked up but I couldn't figure out how to begin looking. If anyone needs clarification, let me know. Thank you very much!
Diagram of what numbers I need access to:
http://www.gliffy.com/go/publish/5968966
I suppose that you are processing the image as you read it, or as you decompress it, or some such, for if you already had the whole thing in memory in usable form then you would just use that.
I see two reasonably good alternatives:
Instead of hard-coding the indices of the earlier and later lines in your 2 by x array, use variables to track which row contains which line.
Use a 1-D array for each line, and use pointers to track which one contains the current line and which one contains the previous line.
(Though really, those boil down to pretty much the same thing.) Either way, you can avoid needless copying.
Let's assume you have:
struct rbg_t bitmap[X][Y];
To get a window of dimensions X by 2, it is like this:
struct rgb_t *first_line = bitmap[0], *second_line=bitmap[1];
Then you can process the two lines like so:
for(int i=0;i<X;++i)
{
do_work(first_line[i], second_line[i]);
}
To shift the window down by one, you can do this:
first_line+=sizeof(struct rgb_t)*X;
second_line+=sizeof(struct rgb_t)*X;
Where X is the width of the bitmap
I am using a simple for loop to crop a large amount of images and then storing them in a cell array. I keep getting the message:
The variable croppedSag appears to change size on every loop iteration. Consider preallocating for speed.
I have seen this several times before while coding in MATLAB. I have always ignored it and am curious how much preallocating will increase the runtime if I have, say, 10,000 images or a larger number?
Also, I have read about preallocating in the documentation and it says to use zeros() for that purpose. How would I use that for the code below?
croppedSag = {};
for i = 1:sagNum
croppedSag{end+1} = imcrop(SagArray{i},rect);
end
I didn't quite follow the examples in the documentation.
Pre-allocating an array is always a good idea in Matlab. The alternative is to have an array which grows during each iteration through a loop. Each time an element is added to the end of the array, Matlab must produce a totally new array, copy the contents of the old array into the new one, and then, finally, add the new element at the end. Pre-allocating eliminates the need to allocate a new array and spend time copying the existing contents of the array into the new memory.
However, in your case, you might not see as much benefit as you might expect. When copying the cell array to a new, enlarged cell array, Matlab doesn't actually have to copy the contents of the cell array (the image data), but only pointers to that data.
Nonetheless, there is no reason not to pre-allocate (unless you actually don't know the final size in advance). Here's a pre-allocated version of your loop:
croppedSag = cell(1, sagNum);
for ii = 1:sagNum
croppedSag{ii} = imcrop(SagArray{ii}, rect);
end
I also changed the index variable "i" to "ii" so that it doesn't over-write the imaginary unit.
You can also re-write this loop in one line using the cellfun function:
croppedSag = cellfun(#(im) imcrop(im, rect), SagArray);
Here's a blog entry that might be informative:
Matlab - Speed up your Code by Preallocating the size of Arrays, Cells, and Structures