04-10-2013 03:42 AM
Well, unless you have reduced the size of the image while posting it, your graph is more or less 300 pixels wide. This gives you 4.7 pixels/bar, which includes the gap between bars. Unless you significantly enlarge your graph, I see no possibility to have a really different aspect! This is how 64 data points look with different graph widths:
You may be possibly drawing rectangles without separating gap, so that your bars are wider, and this is probably your best option with such a small graph.
(in the above image, the smaller graph has 2-pixels bars with 2 pixels gap, the medium one has 5-pixels bars with 3 pixels gap and the largest one has 8-pixels bars with 4 pixels gap)
04-10-2013 01:31 PM
The width of each bar is 80% of the gap between two consecutive data points, with a minimum width of 3 pixels (in Roberto's example above, the 256 pixel graph actually has 3-pixel bars, because the slightly darker "highlight" lines are included in the width).
I can't explain why mzimmers' bars are so thin. One possibility would be that the points are not uniformly distributed (which could happen if these were PlotXY or PlotX plots), since in that case, the width of the bar is 80% of the minimum gap between two consecutive data points.
Luis
04-11-2013 02:43 AM
Hello Luis, I would like to elaborate a little more on this subject to be sure I understand correctly how things work.
Let's consider a 256 pixels graph with 64 bars inside. According to your notes, it should give a (256/64)=4 pixels space for each (bar+separator); 80% of space is 3.2 which I suppose the system approximates as a 3 pixels bar with 1 pixel of separation.
However, as you can see in the picture below, bars are 2 pixels wide and there is a 2 pixels separation between them; additionally, no highlight line can be seen, as you can see in the detail zoomed on the right (the diagonal line is an artifex I drew in Paint to evidence pixels). I tested this with several backgrounds (black, white, green and VAL_PANEL_GRAY) and never saw anything but the bars. Can you explain this a little bit more please?
04-11-2013 08:49 AM
Very interesting discussion. A couple of things come to mind: in my instance, I may have been the victim of an unfortunate combination of plot width and number of points. Since you can't have a fraction of a pixel, my data may have led to a very un-random rounding down of the calculated widths.
Here's the same data plotted with rectangles:
This is the routine that drew the rectangles:
int plotBar(int plotID, int x, int y, int color) { int plotHandle; int rc; const double GAP = 0.1; double x1, x2, y1, y2; if (color == VAL_GREEN) // the Q representation { x1 = x; x2 = x + 1 - GAP; } else { x1 = x + GAP; x2 = x + 1; } y1 = 0; y2 = y; plotHandle = PlotRectangle (PANEL_MAIN, plotID, x1, y1, x2, y2, color, color); if (plotHandle > 0) rc = 0; else rc = -1; return rc; }
Also, I remember that blue is an unfortunate color for small lines...maybe my graph wasplaying tricks on our eyes a little. So, I changed that color to green.
04-11-2013 10:25 AM
Hi,
just a tiny comment: I don't remember the meaning of your x axis but shouldn't you better center your rectangles? I. e.
x1 = x - 0.5;
x2 = x + 0.5;
04-11-2013 10:28 AM
Hey, Wolfgang -
I should have supplied more information. The 64 bars are actually a representation of 32 complex numbers. The first color is the real component; the second, the imaginary.
I thought it might be a little easier to look at if the two bars comprising a complex were abutting, so I coded it that way. Feel free to disagree.
In real life, the imaginary components will be so close to 0 most of the time that it won't really matter anyway.
04-11-2013 11:44 AM
Hi Roberto,
You're right. I took another look and I found the reason for the discrepancy. The graph control does set up a minimum width of 3. This width is then used to draw a rectangle that has a right edge value that is 3 greater than its left edge value. However, the API that is being used to draw the rectangle considers the right edge (and bottom edge) to be outside the rectangle itself, which means that the visible width really becomes two.
You're also right in that there is no highlighting. The reason I had mentioned the highlighting is because I zoomed into the 256-pixel screenshot of your previous post in my browser, saw the dark red highlight lines there, and because I had forgotten about the subtracted pixel from the rectangle, I assumed that the highlights were part of the 3-pixel width.
So, I need to correct the formula: bar_width = round (min_interval * 0.8) - 1, with a minimum of 2.
Ok, so with that out of the way, I'm really confused that I'm looking at a two-color bar plot in your post. How did you do that??
Luis
04-11-2013 11:48 AM
I can tell you how I did the two-color thing: two separate calls to PlotY(). One has every odd element zeroed, and the color red specified. The other has every even element zeroed, and the color green specified.
Not ideal, perhaps, but it works.
04-11-2013 04:08 PM
Same as mzimmers
04-12-2013 12:24 PM
Ah, okay.
In looking at the gaps between two consecutive bars, it's not really valid to be measuring gaps across different plots. But since each individual plot also has a zero-value bar in the same exact position, then I guess it's okay.
Thanks for the explanation!
Luis