Scatter Plot with different "markers" and "data labels"
이전 댓글 표시
a=[32.0 30.0 29.0 42.0 61.0 81.0]
b=[0.9 0.8 0.2 0.4 0.3 0.10]
c={'US'; 'GM'; 'SA'; 'IN'; 'EG'; 'BZ'}
scatter(a,b)
xlim([0 50])
ylim([0 1])
refline
grid
I need a "scatter plot" with different "markers" and "data labels" (array in c). Also the refline should always start from (zero,zero)
댓글 수: 2
Adam
2020년 2월 18일
doc refline
seems to have various options that take arguments.
Charles Hendricks
2022년 11월 23일
() Determine the cubic spline equations for the data set below: () Plot f(x) as scatter plot, then add splines for each segment. a. (2pts) X and Y axes must be labeled properly x 0 100 200 400 600 800 1000 f(x) 0 0.653 1.0000 0.841 0.376 0.18813 0.08
채택된 답변
추가 답변 (1개)
Adam posted first but will add slightly different way to get to same place (sans some of the finishing niceties...)
Why scatter is so braindead re: markers by point is a wonder... :(
But, you can use plot instead; end up at similar thing in that multiple scatter calls also generate a handle for each call as do multiple lines in plot
N=nan(size(a)); % dummy placeholder NaN array (see why later...)
hL=plot([N;a],[N;b]); % create the plot w/ data, no markers, yet...
mkr={'o','+','*','x','s','d'}; % some markers...
set(hL,{'marker'},mkr') % now put the markers on...
m=a.'\b.'; % compute LS slope no intercept model via backslash operator
refline(m,0)
ylim([0 1])
grid
results in same figure as above w/o the labels yet.
The nan() array is needed to force plot to treat the two row vectors as separate columns by actually passing an array instead of just vectors--plot() will force a vector of either row or column to be treated as a single line instead of making a separate line by column as we need here to add a marker to each. NaN values are silently ignored so they don't show up as data; they're just placeholders to make plot do what is wanted.
댓글 수: 5
+1
Update: ignore this unless you want to be confused :D
I didn't know about this syntax m=a.'\b.';
It's mentioned briefly in the Tips section of mldivide but it differs so much from other Matlab syntax it makes me wonder if there are other similar syntaxes that treat a char array in this way. It's strange to me.
Also, m = b/a may be simpler and easier to understand.
"...if there are other similar syntaxes that treat a char array in this way."
??? a, b are doubles in OP's problem, they're (badly named it would appear) variables for his plot and the line. Not sure what the comment about char() arrays refers to at all.
mldivide is the general-purpose linear systems tool; as the Tips and Algorithms section indicate, it's got all sorts of tricks built into it for all kinds of things...before the geometric (but relatively recent) explosion of toolboxen and special-purpose functions or tools, it was the go-to. The relationship to mrdivide is there but I rarely remember it being of the age that many problems were only solvable by "rolling your own" design matrix and solving it instead of having something like fitlm that has the facility to not solve for the intercept. In the olden days, backslash and polyfit/polyval were about all there were.
The particular expression of a.'\b.' is simply another way of writing a(:)\b(:) to have column instead of row vectors as
>> a\b
ans =
0 0 0 0 0 0
0 0 0 0 0 0
0 0 0 0 0 0
0 0 0 0 0 0
0 0 0 0 0 0
0.0111 0.0099 0.0025 0.0049 0.0037 0.0012
>>
not what we wanted at all...
But, back on the subject raised re: char() variables -- they're still just integers internally, only that the visual representation is encoded to match the ASCII equivalent. Internally, other than the limited range, "numbers is numbers"...
>> char(a.')\b.'
ans =
0.0069
>>
Of course, one can't do
char(a.')\char(b.')
because b is floating point value that is non-integral and
>> double(char(b))
ans =
0 0 0 0 0 0
>>
which isn't the same numeric representation as for integer values fitting in range of uint8
I see my mistake. At first glance I saw the line m=a.'\b.', and misinterpretted '\b.' to be a char array and some kind of unconvensional syntax of the backslash operator which is why I was surprised.
Now I clearly see that .' is merely a transpose without the compex conjugate operation imposed by ' alone. It's one of the few cases where the dot operator does not signify element-wise operations (or field-indexing of a structure). So, I'll blame it on faulty perceptual grouping ;)
Ah! Knowing what had written, I had failed to notice the possibility of misgrouping to have the perception of a char() string...
While not often for most, probably, the difference between " . '" and " .' " is profound if one has any complex variables around. Since much of my past consulting work dealt in the complex domain routinely, I soon learned to invariably use the dot version unless I specifically wanted/needed the other. Accidentally changing to the complex transpose vis a vis not if one is simply rearranging a variable's storage orientation is an insidious and often very difficult bug to find.
Adam Danz
2020년 2월 19일
I also use .' by default unless I'm transposing a cell array or some non-numeric datatype. I believe it was about a year ago I learned the importance of that. Still, when I see a.'\b.' my brain wants to see the char interpretation first. It's like the blue/gold dress.
카테고리
도움말 센터 및 File Exchange에서 Scatter Plots에 대해 자세히 알아보기
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!

