Does MATLAB have any support for hash tables?
I am working on a problem in Matlab that requires a scale-space representation of an image. To do this I create a 2-D Gaussian filter with variance sigma*s^k for k in some range., and then I use each one in turn to filter the image. Now, I want some sort of mapping from k to the filtered image.
If k were always an integer, I'd simply create a 3D array such that:
arr[k] = <image filtered with k-th guassian>
However, k is not necessarily an integer, so I can't do this. What I thought of doing was keeping an array of ks such that:
arr[find(array_of_ks_ = k)] = <image filtered with k-th guassian>
Which seems pretty good at first thought, except I will be doing this lookup potentially a few thousand times with about 20 or 30 values of k, and I fear that this will hurt performance.
I wonder if I wouldn't be better served doing this with a hash table of some sort so that I would have a lookup time that is O(1) instead of O(n).
Now, I know that I shouldn't optimize prematurely, and I may not have this problem at all, but remember, this is just the background, and there may be cases where this is really the best solution, regardless of whether it is the best solution for my problem.
Matlab does not have support for hashtables. EDIT Until r2010a, that is; see @Amro's answer.
To speed up your look-ups, you can drop the find, and use LOGICAL INDEXING.
arr{array_of_ks==k} = <image filtered with k-th Gaussian>
or
arr(:,:,array_of_ks==k) = <image filtered with k-th Gaussian>
However, in all my experience with Matlab, I've never had a lookup be a bottleneck.
To speed up your specific problem, I suggest to either use incremental filtering
arr{i} = GaussFilter(arr{i-1},sigma*s^(array_of_ks(i)) - sigma*s^(array_of_ks(i-1)))
assuming array_of_ks is sorted in ascending order, and GaussFilter calculates the filter mask size based on the variance (and uses, 2 1D filters, of course), or you can filter in Fourier Space, which is especially useful for large images and if the variances are spaced evenly (which they most likely aren't unfortunately).