I'm trying to graph some data points. The X coordinates tend to be inversely proportional to the Y coordinates, so I decided to try graphic in '1/x' space (replace every x with 1/x).
This makes the graph a lot more evenly spaced, but there's a problem: I'm not sure how to pick where the tick marks / grid lines should go.
Here's an example graph (with points labelled by their original X coordinate):
In the above example I spaced the tick marks evenly (in the original space). They end up too clustered near the left (infinity) and too dispersed near the right. Is there a nice rule for where I should increase the spacing?
Just a link to other 'inverse space' graphs would be useful, so I can see how they placed ticks.
What I ended up doing was:
Place a major tick at every power of 10, until you get really close to the origin (infinity). Also place a major tick at infinity.
Place 9 minor ticks between each major tick, corresponding to changing the most significant digit. So 2,3,4,...9 between 1 and 10. 20,30,40,...,90 between 10 and 100.
Place labels on every major tick, until they get too close.
Also place labels on minor ticks, from right to left, whenever there's room.
The result looks like this:
Which is not great (and the colors aren't quite right), but it's good enough for my purposes for now.
Related
I am generating multiple plots of different datasets in succession using MATLAB. I would like the legend positions to be such that they don't overlap on the plotted lines and it would be ideal if this placement could be done automatically.
I am aware of setting the 'Location' to 'best' to achieve this but the placement of the legend tends to be awkward when 'best' is used (below). Also, I would like the legend to be inside the plot. I also came across a way to make the legend transparent (here) so that it does not render the plotted data invisible, but explicitly placing the legend elsewhere is what I am looking for.
Is there a way to place the legend at the extremes of the image ('NorthWest', 'SouthWest' etc) automatically such that it does not overlap on the plotted data (apart from the methods suggested above)?
So, you have tried using Location instead of Position? For example:
x =1:100;
y = x.^2;
lgd = legend('y = x.^2');
set(lgd,'Location','best')
and you are getting odd results correct? A quick way of solving this would be to still use Location, with best, and extract the coordinates:
lgd.Position
You should get something like this:
ans =
0.7734 0.3037 0.1082 0.0200
which maps to:
[left bottom width height]
You will need to focus on left and bottom. These two values, left and bottom, specify the distance from the lower left corner of the figure to the lower left corner of the legend, and they are analogous to the grid frame you are using.
Then, depending on the size of the frame (I would suggest you use axis([XMIN XMAX YMIN YMAX]) for this, if possible), you can pinpoint the position of the legend within the grid. What you can do next, is check if and which of your graphs in the plot cross paths with the legend (maybe define a relative distance function based on some distance threshold) and if they do, then randomly reposition the legend (i.e. change the values of left and bottom) and repeat until your conditions are met.
If this still troubles you I can write a short snippet. Finally, know that you can always opt for placing the legend on the outside:
set(lgd,'Location','BestOutside')
I have some energy 24 hour consumption data of many days.
Plotting a specific day gives me vertical axis of consumption and horizontal axis of time.
I would like to plot for lets say 1 year.
If I use "hold on/off" command, it plots all days together on top of each other.
How can i plot in a way that for the second day, the plots goes to the continue of the first plot (horizontal axis extends automatically)? So, when I have the complete plot, it shows 365 days of energy consumption based on hour. It's like the horizontal axis is repeating while the vertical axis is updating. I'm talking about MATLAB.
You can still use hold on and plot each day separately (if I understand your question properly, this is what you want, separate plotting). Simply make sure your x-axis values are correct. So e.g. if you have one measurement value per hour, the plot day 1:
plot(1:24,valDay1,'k-')
then for day 2:
plot(25:48,valDay2,'r-')
etc. This will line things up correctly. Also, consider using a datetime as x axis values
So, I found my solution which is very simple. I don't know how it didn't occur earlier.
I just had to use ";" and that's it.
Like this:
DAY=[day1;day2;day3]
plot(DAY)
So basically, the graph labeled "Thermal Wind" has an extreme value that compresses the y-values for all the other plots, making it much harder to see any of the individual variations in the other plots. Is there a way to neatly cut off this extreme value? I could just rescale the y limit to a maximum of 40, but then this looks ugly.
As for the alternative I've tried - it's here:
I would recommend trying to plot it on a log scale. The function you'll want to consider using is semilogx, though for completeness I recommend also reading the help file on loglog.
Alternately, you could use subplot to generate multiple plots, one of which is zoomed into a region of interest.
Are the outlier points errors in the data, or do they represent extreme cases?
If they are not valid data, just manually exclude them from the data, plot the graph, and include a text clarification when describing the graph. If they are valid data, then trimming them would misrepresent the data, which isn't a good thing.
Graphs of data aren't art: their main goal isn't to be pretty; it's to provide a useful visualization of data. There are some minimum requirements on appearance, however: the axes have to be labeled, the units have to be meaningful, the different curves have to be visually distinct, etc. As long as your graph has these things, you shouldn't expect to lose marks for presentation.
There are two approaches that I use:
One approach would be transform the data so it will fill the plot nicely. Make the transform so that it wouldn't touch the range - say -10 to +10. In your case you could choose it so that 100 transforms to +15 and -100 to -15.
For clarity you need to then also set and label the y ticks appropriately. And for nice style make sure the line changes slope when it goes over the border.
I plot the data as is. But set the axis limits say from -10 to +10. Where points lay outside I place upwards and downwards triangles along the border to mark in which direction the "outliers" would be. Obviously this is only good when there aren't too many.
It became apparent that I needed to attempt to modify CorePlot code to allow me to plot Polar/Radar plots, due to heavy memory usage trying to plot circles/spokes as ScatterPlots.
I realised I could continue to use CPTScatterPlot for the actual polar data, however somehow I needed to modify the drawGridLinesInContext, such that instead of straight lines at each location, CPTXCoordinate would draw the circular line, CPTYCoordinate would be ignored, and CPTZCoordinate would draw the spokes.
I had to create new classes based on their XY siblings viz CPTPolarGraph, CPTPolarPlotSpace, CPTPolarAxisSet, CPTPolarAxis. The new code continues to use X and Y axis to plot those axes, however a Z axis was introduced to manage the spokes.
Now I seem to have cracked this, however if I scroll up and down, the circles continue to pass through the X and Y axis ticks, as they should do, but when I scroll left and right, the circles get redrawn and no longer sit on the ticks.
I obviously got some more debugging to do here, but was hoping for some pointers from the CorePlot crew, as to what might be happening
.
I can zip my modified version of CorePlot_1.1, including a example polar scatter plot, and forward if needs be.
The positioning of the centreViewPoint tracks precisely, as the spokes are always generated from the same point, wherever the centre is in the plotArea. The rings are also always generated from the same centre.
It seems to me that somehow, the diameters of the rings when I scroll left right get changed from the first plot presentation, yet when I scrolled Up-down they don't. Notice that when the plot is scrolled to left edge or right edge the major rings are line up on the major ticks again, as are the minor.
I tried reversing the code such that only the CPTCoordinateY get plotted, and I see the same effect, except scrolling up-down exhibits the changing in ring diameter size.
Now perhaps CGPoint startViewPoint = [thePlotSpace plotAreaViewPointForPlotPoint:startPlotPoint]; which establishes the diameter of a ring from its x-coordinate, is not returning correctly. Although perhaps also the locations set are changing, but why should they if no zooming has been done.
I'm kind of struggling here, as when I walk through the code the locations don't appear to change.
This is likely a pixel alignment issue. The tick drawing code aligns the tick marks with the pixel grid but the new axis drawing does not. Look at CPTAlignRectToUserSpace() and the other alignment functions in CPTUtilities.h.
Edit:
You also may need a custom setter method for the zRange in the plot space. Make it similar to the xRange and yRange setters. The notifications fired by these methods are important—they force other parts of the graph to redraw when the plot space changes.
is it possible to find the center of the big black spot(the area which with the set?)
I've tried to loop through all points which are in the set, sum their locationד and eventually divided by the num of points which are in the set.
it didn't work as expected because the the set isn't formed, e.g its not a perfect sphere or a square therefore the center always changes. is there another way of finding the center?
thanks!
Look for centers of mandelbrot set hyperbolic components
http://fraktal.republika.pl/eigensolve.html
That shape is a perfect cardioid (no other similar shapes in the Mandelbrot set are perfect cardioids, they are somewhat distorted).
Check Wikipedia, you'll find the equation for calculating the cardioid itself: http://en.wikipedia.org/wiki/Cardioid
Note, however that at the borders of the Mandelbrot map (where the black and non-black area meets) deciding whether a point belongs to the map or not, heavily depends on how many times you iterate z = z^2 + c. If you iterate it 50 times, the main cardioid will be smaller than if you iterate it 500 times because with 500 iteration more points at the border will go to infinity.