Good way to get phase difference between vectors? - matlab

So I have two vectors:
>> [phase exp_phase]
ans =
0.2266 0
-0.0702 0
-0.0070 0
-0.0854 0
0.0888 0
3.1403 -3.1416
-2.9571 -3.1416
-0.1441 0
-0.2660 0
2.8749 -3.1416
0.0126 0
-2.9309 -3.1416
0.0064 0
phase is obtained by atan2(b,a). I want to figure out the phase difference. The problem is that I obviously want the difference between -3.00 and +3.00 to be roughly 0.28, but at the same time I want the difference between -2.72 and +3.00 to be the same.
It's probably trivial but I can't figure out a good way to do it :(

say you have two angles, w1=+3 and w2=-3 (both in radians).
to find the smallest angular difference, do the following:
atan2(sin(w1-w2),cos(w1-w2))
ans =
-0.2832

If you are finding the phase with arctan, then I assume you have two vectors already in Cartesian coordinates, and you used atan2 to get the phase value of the polar coordinates. Just find the phase difference in Cartesian coordinates directly. I might be messing up this formula (my trig is rusty so google it), but it is something like acos((a . b)/|a||b|). If this is the correct formula, it gives the phase difference for two vectors, anyway there is "a" formula for this calculation in Cartesian coordinates. You might be able to avoid the atan2 function twice (unless you also need to know the actual phases).

Related

Matlab- finding the smallest deviation in a struct

I have a struct like this mesh.m_1_0.Deformation_Entformung;
the second field is a struct from m_1_0 till m_3_5 in 6 steps;
the Deformation_Entformung is a matrix with 6 columns and 325562 rows, whereby the first 3 columns contain coordinates (x,y,z).
Now I'm interested in the coordinates that are the closest to (33.5 -88.7801,-0.4480).
This is my code:
SNames = fieldnames(mesh); % SName = m_1_0,m_1_5...m_3_5
for loopIndex = 1:numel(SNames)
stuff = mesh.(SNames{loopIndex}).Deformation_Entformung;
mesh.(SNames{loopIndex}).('Deformation_Entformung_Koordi')=...
stuff(min(stuff(:,1)-33.5) & min(stuff(:,2)--88.7801) & ...
min(stuff(:,3)-0.4480), :);
end
The code runs, but the problem is that the answer is always the first row of the matrix Deformation_Entformung.
I would be glad, if someone could give me a hint.
Well, first of all you mix up indices with values.
min(stuff) returns the minimal value of stuff. So when you write stuff(min(stuff)) that's certainly not doing what you want it to do.
Secondly, if min(stuff(:,1)-33.5) would actually return an index (which it doesn't), then the index would be the same whether you searched for min(stuff(:,1)+100) or min(stuff(:,1)-500000). So the program would still not be doing what you want it to do.
Additionally, the way you are trying to search for the closest point does not even work from a mathematical point of view (even if your programming had no errors). The closest point is not necessarily the closest in each single coordinate. For example, [1 1 1] is certainly closer to [0 0 0] than [20 0 0], [0 20 0] and [0 0 20]. But it is not the closest one in each single coordinate. In fact it is not the closest one in any coordinate.
There might be even more issues with your code, but for starters you should work on how to determine distances. After you master that you should try to pick points with minimal distance. And only after you master both of these should you try to integrate everything into the rest of your stuff. No point in trying to do everything at once.

Calculating value y for each XI and XII in MATLAB:

I am currently working in matlab to design a way to reconstruct 3D data. For this I have two pictures with black points. The difference in the amount of points per frame is key for the reconstruction, but MATLAB gives an error when matrixes are not equal. This is happening becaus the code is not doing what I want it to do, so can anyone hel me with the following?
I have two columns of Xdata: XLI and XRI
What matlab does when I do XLI-XRI is substracting the pairs i.e XLI(1)-XRI(1) etc, but I want to substract each value of XRI of every value of XLI. i.e
XLI(1)-XRI(1,2,3,4 etc)
XLI(2)-XRI(1 2 3 4 etc)
and so on
Can anyone help?
I think you are looking for a way to deduct all combinations from eachother. Here is an example of how you can do that with bsxfun:
xLI = [1 2 3]
xRI = [1 2]
bsxfun(#minus,xLI ,xRI')
I cannot comment on Dennis's post (not enough points on this website) : his solution should work, but depending on your version of Matlab you might get a "Error using ==> bsxfun" and need to transpose either xLI or xRI for that to work :
bsxfun(#minus,xLI' ,xRI)
Best,
Tepp

Dot Product: * Command vs. Loop gives different results

I have two vectors in Matlab, z and beta. Vector z is a 1x17:
1 0.430742139435890 0.257372971229541 0.0965909090909091 0.694329541928697 0 0.394960106863064 0 0.100000000000000 1 0.264704325268675 0.387774594078319 0.269207605609567 0.472226643323253 0.750000000000000 0.513121013402805 0.697062571025173
... and beta is a 17x1:
6.55269487769363e+26
0
0
-56.3867588816768
-2.21310778926413
0
57.0726052009847
0
3.47223691057151e+27
-1.00249317882651e+27
3.38202232046686
1.16425987969027
0.229504956512063
-0.314243264212449
-0.257394312588330
0.498644243389556
-0.852510642195370
I'm dealing with some singularity issues, and I noticed that if I want to compute the dot product of z*beta, I potentially get 2 different solutions. If I use the * command, z*beta = 18.5045. If I write a loop to compute the dot product (below), I get a solution of 0.7287.
summation=0;
for i=1:17
addition=z(1,i)*beta(i);
summation=summation+addition;
end
Any idea what's going on here?
Here's a link to the data: https://dl.dropboxusercontent.com/u/16594701/data.zip
The problem here is that addition of floating point numbers is not associative. When summing a sequence of numbers of comparable magnitude, this is not usually a problem. However, in your sequence, most numbers are around 1 or 10, while several entries have magnitude 10^26 or 10^27. Numerical problems are almost unavoidable in this situation.
The wikipedia page http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems shows a worked example where (a + b) + c is not equal to a + (b + c), i.e. demonstrating that the order in which you add up floating point numbers does matter.
I would guess that this is a homework assignment designed to illustrate these exact issues. If not, I'd ask what the data represents to suss out the appropriate approach. It would probably be much more productive to find out why such large numbers are being produced in the first place than trying to make sense of the dot product that includes them.

expand vector with interpolated values

I have two vectors that happen to be lat and long that I extracted from a shape file. I would like to interpolate the values so I have the same resolution as the points from which I am finding the distance.
I found this question and another question that almost solve my problem. The difference is I do not know the spacing between my vector points (they vary) and I want to make sure I always have at most 0.0042 deg between points. Below are the first 10 points of my lat/long vectors.
latlim=interp1(latlim,1:0.001:numel(latlim)); gets me what I want to avoid any aliasing but I'd like to get exactly 0.0042 between points rather than just 1000 new points for the sake of efficiency. I have a lot of points to iterate on.
latlim=[78.1530 77.9963 77.6970 77.4092 77.7322 78.0511 78.1530 NaN 78.8044 78.6020];
latlim=interp1(latlim,1:0.001:numel(latlim));
lonlim=[-111.2644 -109.8545 -110.1869 -112.0512 -113.5343 -112.7246 -111.2644 NaN -110.9637 -109.6631];
lonlim=interp1(lonlim,1:0.001:numel(lonlim));
Thanks!
I hope I understood your question:
If you want a constant step of 0.042 then try:
lonlim = interp1( lonlim, lonlim(1): 0.042 :lonlim(end) );
This will create a vector starting at the first value of lonlim, which is lonlim(1), with a step of 0.042, until the last value of lonlim, which is lonlim(end).
Hope it works! :)

Linspace vs range

I was wondering what is better style / more efficient:
x = linspace(-1, 1, 100);
or
x = -1:0.01:1;
As Oli Charlesworth mentioned, in linspace you divide the interval [a,b] into N points, whereas with the : form, you step-out from a with a specified step size (default 1) till you reach b.
One thing to keep in mind is that linspace always includes the end points, whereas, : form will include the second end-point, only if your step size is such that it falls on it at the last step else, it will fall short. Example:
0:3:10
ans =
0 3 6 9
That said, when I use the two approaches depends on what I need to do. If all I need to do is sample an interval with a fixed number of points (and I don't care about the step-size), I use linspace.
In many cases, I don't care if it doesn't fall on the last point, e.g., when working with polar co-ordinates, I don't need the last point, as 2*pi is the same as 0. There, I use 0:0.01:2*pi.
As always, use the one that best suits your purposes, and that best expresses your intentions. So use linspace when you know the number of points; use : when you know the spacing.
[Incidentally, your two examples are not equivalent; the second one will give you 201 points.]
As Oli already pointed out, it's usually easiest to use linspace when you know the number of points you want and the colon operator when you know the spacing you want between elements.
However, it should be noted that the two will often not give you exactly the same results. As noted here and here, the two approaches use slightly different methods to calculate the vector elements (here's an archived description of how the colon operator works). That's why these two vectors aren't equal:
>> a = 0:0.1:1;
>> b = linspace(0,1,11);
>> a-b
ans =
1.0e-016 *
Columns 1 through 8
0 0 0 0.5551 0 0 0 0
Columns 9 through 11
0 0 0
This is a typical side-effect of how floating-point numbers are represented. Certain numbers can't be exactly represented (like 0.1) and performing the same calculation in different ways (i.e. changing the order of mathematical operations) can lead to ever so slightly different results, as shown in the above example. These differences are usually on the order of the floating-point precision, and can often be ignored, but you should always be aware that they exist.