I've been working on adapting the stacked bar chart example (http://bl.ocks.org/mbostock/1134768). The problem I'm having is that there's
always outerpadding. The API lists the outer padding as a 3rd option, but omitting
it or setting it to 0 still leaves some padding. In most cases, it isn't too bad,
but with large data sets it tends to be a huge amount of padding. For all the code
relevant to my issue, you can check the link above. It's not very noticeable in that
example, but the first bar isn't drawn until about 12 pixels (in larger data sets I'm using
this can be at 100 or more pixels); I want it to start at 0 pixels.
Thanks! If you need any more explanation just let me know and I'll do my best.
EDIT: After testing, it appears rangeBands() starts at 0, but I'm still not sure why the rounding
from round bands would round as much as it did. Oh well, I can deal with using rangeBands.
Related
I'm confused with the bar with adjustment in MATLAB, for example, when use bar like:
bar(randsample(0:0.0001:1,100),randn(100,1))
I get an image like this:
It seems like the bar is too thin to have a good look. After searching for help, I can use the code like:
bar(randsample(0:0.0001:1,100),randn(100,1),50)
and I get this:
Seems much better. But if I change the sample number from 100 to 10, the same code won't work.
bar(randsample(0:0.0001:1,10),randn(10,1),50)
I hope I have explained my issue clear. It seems like the third parameter of the bar function is a relative width, which correlates to the input size of the first and second parameter. Can I fix the absolute bar width no matter how many data points input? or there is a better function to draw figures like this? Thanks a lot for any help!
user #am304 is right about the width parameter
What happened in your code is that you set x values to results from randsample(0:0.0001:1,10)
If you give your plot a width of 1 it means that 2 bars which are directly next to each other would touch each other with an equally spaced x.
In your case, you have an irregular x spacing.
The width of the bar is determined by the minimum distance between two x values (which you get from randsample()). Sometimes this space - and therefore the width of your bar - is very tiny. Sometimes it is broader.
Change the with to 1 and make multiple plots. You will notice that two are always touching each other and no one is overlapping and all the others have spaces in between. If you change the width to 50 the plots will somethimes overlap heavily (depending on the randomness from randsample) because your bars are 50 times bigger then the minimum width between two x values.
In case of your randsample(0:0.0001:1,100) example it is just more likely that two values are close to each other, therefore increasing the width helps you see something (because the bars overlap).
From the documentation:
bar(___,width) sets the relative bar width, which controls the
separation of bars within a group. Specify width as a scalar value.
Use this option with any of the input argument combinations in the
previous syntaxes.
The example provided is as follows:
Set the width of each bar to 40 percent of the total space available
for each bar.
y = [75 91 105 123.5 131 150 179 203 226 249 281.5];
bar(y,0.4)
So bottom line is: the width is specified as a % of the total space available for each bar. Yoru problem comes from the fact that you have far too many bars, so the space available for each bar is tiny. Setting the width to 50 or 5000% of the space available just means that each bar will overlap quite substantially on the neighbouring bars. Because you have so many, the middle plot looks "reasonable" as I suspect a lot of the bars are overlapped and a lot of them are at zero, so you just can't see them. If you go down to a sensible number of bars, as in your last example, then setting the width to 5000% looks ridiculous as you found out.
So to summarise: reduce the number of bars and specify the bar width between >0 and 1 (1 being no gap, all the bars touching each other).
A better way to plot things with random x locations is to use stem. By default, it draws a line from the zero line to the datum, with a circle representing each datum. But this can be modified. For example:
stem(randsample(0:0.0001:1,100),randn(100,1), 'Marker','none', 'LineWidth',4)
creates a plot similar to your second attempt, but with bars of a fixed width (4 points).
What I aim:
I want to have a table cell, in which every cell is horizontally divided in two halves. The upper half will contain 4 labels, and the lower half will contain 4 values which correspond to these labels.
Of these 4 items in every horizontal half, each of the last 3 items will occuppy 2/7 of total width, and the remaining 1 item will occupy the remaining of the total width, which is 1/7 of total width.
What I tried:
Putting a horizontal stack view in the content view of table cell.
Which will contain two vertical stack views
Where the upper vertical stack view will contain the labels and the lower vertical stack view will contain the values.
In short, I did this:
But I am getting these conflicts:
I really don't understand why I am getting these conflicts. I feel like I have provided enough constraints for auto layout to do the layout correctly.
Could you please tell me what is wrong here?
I'm on Xcode 8 and using iPhone 7 Plus as view, if that would make any difference.
This is a simpler case, and it isn't working as well:
Conflicts:
As you have provided the detail nobody can get understand and help to resolve your auto-layout issues, I suggest you to clear all constraints and try re-apply all the constraints again , give proper leading and trailing with x and y position the constraints will definitely works good,
Once you will try to apply twice or thrice you ll get know the exact problem and it will be get resolved quickly.
For auto-layout more practice needed to understand it briefly.
Hope it will help to you,
Thanks.
I am using Rickshaw (based on d3.js) to plot stacked bar charts. The problem is that the first bar is usually way more higher than the others, ruining the visual feedback.
Using logarithmic scale is (I guess) not an option here, because then the proportions between stacks in a bar will get broken. I wanted to introduce a horizontal break like in following image:
However, I cannot find any out-of-the box feature of Rickshaw or d3.js to do something like this. Any suggestions on how to make one?
This would require quite a bit of additional work. Here's an outline of what you would have to do.
Create two scales, one for the lower part and one for the upper. Set domains and ranges accordingly.
Pass values to the lower scale, capping them at the maximum domain value such that bars that are longer will reach the maximum.
Pass values to the upper scale, filtering those that are lower than the minimum.
You basically need to create two graphs that are aligned with each other to give the impression that there's just one. If you keep that in mind, doing it shouldn't be too difficult.
Here's a quick and dirty proof of concept that uses the linear scale's .clamp(true) to prevent the bars from becoming too long for values outside the domain.
The d3fc-discontinuous-scale component adapts any other scale (for example a d3 linear scale) and adding the concept of discontinuities. These discontinuities are determined via a 'discontinuity provider', which can be used to create one or more 'gaps' in a scale.
For example, to remove a range, you can construct a scale as follows:
var scale = scaleDiscontinuous(scaleLinear())
.discontinuityProvider(discontinuityRange([50, 75]))
Here is a complete example that shows how to use this to create a 'break' in a scale in order to render values that have large gaps in their overall range.
https://bl.ocks.org/ColinEberhardt/b60919a17c0b14d745c881f48effe681
I want to display overlapping boxplots using Sigmaplot 12. When I choose the scale for the x-axis as linear then the boxes do indeed overlap but are much too thin. See figure below. Of course they should be much wider.
When I choose the scale of the x-axis to be "category", then the boxes have the right width, but are arranged along each single x-value.
I want the position as in figure 1 and the width as in figure 2. I tried to resize the box in figure 1 but when I choose 100% in "bar width" than it still looks like Figure 1.
many thanks!
okay, I found the answer myself. In Sigmaplot, there is often the need to prepare "style"-columns, for example if you want to color your barcharts, you need a column that holds the specific color names.
For my boxplot example I needed a column that has the values for "width". These had to be quite large (2000) in order to have an effect. Why ? I have no idea. First I thought it would be because of the latitude values and that the program interprets the point as "1.000"s, but when I changed to values without decimals, it didn´t get better.
Well, here is the result in color.
Have fun !
I'm using FreeType2 for font rendering, and I need to get a global bounding box for all fonts, so I can align them in a nice grid. I call FT_Set_Char_Size followed by extracting the global bounds using
int pixels_x = ::FT_MulFix((face->bbox.xMax - face->bbox.xMin), face->size->metrics.x_scale );
int pixels_y = ::FT_MulFix((face->bbox.yMax - face->bbOx.yMin), face->size->metrics.y_scale );
return Size (pixels_x / 64, pixels_y / 64);
which works, but it's quite a bit too large. I also tried to compute using doubles (as described in the FreeType2 tutorial), but the results are practically the same. Even using just face->bbox.xMax results in bounding boxes which are too wide. Am I doing the right thing, or is there simply some huge glyph in my font (Arial.ttf in this case?) Any way to check which glyph is supposedly that big?
Why not calculate the min/max from the characters that you are using in the string that you want to align? Just loop through the characters and store the maximum and minimum from the characters that you are using. You can store these values after you rendered them so you don't need to look it up every time you render the glyphs.
I have a similar problem using freetype to render a bunch of text elements that will appear in a grid. Not all of the text elements are the same size, and I need to prerender them before I know where they would be laid out. The different sizes were the biggest problem when the heights changed, such as for letters with descending portions (like "j" or "Q").
I ended up using the height that is on the face (kind of like you did with the bbox). But like you mentioned, that value was much to big. It's supposed to be the baseline to baseline distance, but it appeared to be about twice that distance. So, I took the easy way out and divided the reported height by 2 and used that as a general height value. Most likely, the height is too big because there are some characters in the font that go way high or way low.
I suppose a better way might be to loop through all the characters expected to be used, get their glyph metrics and store the largest height found. But that doesn't seem all that robust either.
Your code is right.
It's not too large.
Because there are so many special symbols that is vary large than ascii charater. . view special big symbol
it's easy to traverse all unicode charcode, to find those large symbol.
if you only need ascii, my hack method is
FT_MulFix(face_->units_per_EM, face_->size->metrics.x_scale ) >> 6
FT_MulFix(face_->units_per_EM, face_->size->metrics.y_scale ) >> 6