When you use Zedgraph for linegraphs and set IsSmooth to true, the lines are nicely curved instead of having hard corners/angles.
While this looks much better for most graphs -in my humble opinion- there is a small catch. The smoothing algorithm makes the line take a little 'dive' or 'bump' before going upwards or downwards.
In most cases, if the datapoint are themselves smooth, this isn't a problem, but if your datapoints go from say 0 to 15, the 'dive' makes the line go under the x-axis, which makes it seems as though there are some datapoints below zero (which is not the case).
How can I fix this (prefably easily ;)
No simple answer for this. Keeping the tension near zero will be your simplest solution.
ZedGraph uses GDI's DrawCurve tension parameter to apply smoothness, which is probably Hermite Interpolation. You can try to implement your own Cosine Interpolation, which will keep local extremes because of its nature. You can look at the this link to see why:
http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/interpolation/
EDIT: Website is down. Here is a cached version of the page:
http://web.archive.org/web/20090920093601/http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/interpolation/
You could try to alter the myCurve.Line.SmoothTension property up or down and see if that helps.
Related
TL;DR: can anyone help w/ geospatial things in R using geom_raster() in ggplot?
Basically it seems that my issue is stemming from the fact that I don't have perfectly gridded values (aka I get this message: "Warning: Raster pixels are placed at uneven vertical/horizontal intervals and will be shifted. Consider using geom_tile() instead."). So, if I switch to geom_tile, then I can control the size of the tiles, but then they look chunky and awful since there's no interpolation feature in geom_tile. If I use geom_raster, I think it gets confused what size it should plot the pixels since it's not perfectly gridded, so when I facet my ggplot, the output sometimes will have teeny tiny dots (or even no dots at all) on some facets, and pretty maps on the other facets. When I round the lat/lon coordinates to 0 decimal places, this fixes the teeny tiny / no dots problem, but then ends up with things just like geom_tile (chunky with no blending between).Any ideas on how to fix this? I think if there's a way to manually interpolate to fill in NA values so that I do have nice symmetrically-gridded data, then geom_raster should work fine. Like what needs to happen is for each situation where we're missing a value at a certain lat/lon, we need to take the mean value between the two closest neighboring points to fill in that missing lat/lon point on the grid. But I'm not sure how to do this (aka how to convert from my dataframe into all the different spatial classes and back again). Then again, this manual approach might be overcomplicating things and I'd love a simpler solution. (fingers crossed)
I'm building this in a shiny app with crazy long code, and a very large dataset, but happy to share additional info as needed!
example plot
example plot2
warning example
I've been trying to plot a tangent plane to a quadratic surface for a really long time yesterday with a couple of nice helpers.
It works well if below the surface to some degree as above, but as soon as it's further and steeper away it looks extremely distorted.
Even when we made it much smaller, it just looks super weird.
Is there something we forgot to consider?
Thank you!
I tried sympy and plotly too, it's the same, from below it looks quite nice, as soon as it goes to the sides it's starts to look weird.
Should I use a different coordinate system (meshgrid) to make it more aligned?
Im trying to transform a path along an arc.
My project is running on osX 10.8.2 and the painting is done via CoreAnimation in CALayers.
There is a waveform in my project which will be painted by a path. There are about 200 sample points which are mirrored to the bottom side. These are painted 60 times per second and updated to a song postion.
Please ignore the white line, it is just a rotation indicator.
What i am trying to achieve is drawing a waveform along an arc. "Up" should point to the middle. It does not need to go all the way around. The waveform should be painted along the green circle. Please take a look at the sketch provided below.
Im not sure how to achieve this in a performant manner. There are many points per second that need coordinate correction.
I tried coming up with some ideas of my own:
1) There is the possibility to add linear transformations to paths, which, i think, will not help me here. The only thing i can think of is adding a point, rotating the path with a transformation, adding another point, rotating and so on. But this would be very slow i think
2) Drawing the path into an image and bending it would surely lead to image-artifacts.
3) Maybe the best idea would be to precompute sample points on an arc, then save save a vector to the center. Taking the y-coordinates of the waveform, placing them on the sample points and moving them along the vector to the center.
But maybe i am just not seeing some kind of easy solution to this problem. Help is really appreciated and fresh ideas very welcome. Thank you in advance!
IMHO, the most efficient way to go (in terms of CPU usage) would be to use some form of pre-computed approach that would take into account the resolution of the display.
Cleverly precomputed values
I would go for the mathematical transformation (from linear to polar) and combine two facts:
There is no need to perform expansive mathematical computation
There is no need to render two points that are too close from each other
I have no ready-made algorithm for you, but you could use a pre-computed sin or cos table, and match the data range to the display size in order to work with integers.
For instance imagine we have some data ranging from 0 to 1E6 and we need to display the sin value of each point in a 100 pix height rectangle. We can use a pre-computed sin table and work with integers. This way displaying the sin value of a point would be much quicker. This concept can be refined to get a nicer result.
Also, there are some ways to retain only significant points of a curve so that the displayed curve actually looks like the original (see the Ramer–Douglas–Peucker algorithm on wikipedia). But I found it to be inefficient for quickly displaying ever-changing data.
Using multicore rendering
You could compute different areas of the curve using multiple cores (can be tricky)
Or you could use pre-computing using several cores, and one core to do finish the job.
The affine transforms Apple use have "scale" defined as "does not affect translation"
This seems to me completely wrong, and doesn't match what I'd expect from normal affine transforms (where a scale multiplied by a translation DOES affect the translation), and makes it extremely difficult to work with real-world problems, where "scaling" is expected to scale the entire co-ordinate system, not just the local co-ords of a single object at a time.
Is there a safe way within Apple's library to workaround this problem (i.e. make "scale" apply to the whole matrix, not just the non-translation parts)?
Or have I made a stupid mistake and completely misunderstood what's happening with the scaling, somehow?
I'm pretty sure that just means it doesn't affect the translation values in the matrix. CGAffineTransform isn't some special brand of math, it's just a regular transformation matrix. It works like any other transformation matrix you've ever used.
Ah. Embarassing. My mistake: arguments to concat were wrong way around! At least I can leave this here and hopefully help the next person to make such a dumb mistake.
I had a Concat call with the arguments the wrong way around; obviously, "translating" a "scale" works as expected - the scale doesn't affect the translate!
When I googled this issue, I hit a couple of pages that talked about CGAffineTransform doing scale and translate independently. Confirmation bias :( I read that and assumed it was true. Doh.
FYI: CGAffineTransformConcat( A, B ) ... does: Matrix A * Matrix B ... i.e. "A's effects first, then B's effects"
So, make sure your scaling matrix is the second argument (or the "later" argument if you have a chain of nested Concat calls).
So I have a Latex file with some plots. However there's a problem with the figure floats in the image. I have a picture right before a page break, and latex pushes the to big plot down to the next. Fine enough. But then it decides to go smart and push up the section after the plot, to the free space that was left when the picture was pushed down. The result is as you understand pretty confusing, if you are discussing plots.
Here is some code
\subsection{Part A2.1.6}
The Xsi2-distrubution with h=40 and 1\% significance gives 63.7(22.2) which
is significantly smaller than both Ljung-Box applied to the linear and
quadratic residuals, from which we can conclude that the residuals are not iid,
and that the linear and quadratic models are not as good as wanted.
\begin{figure}[h!]
\hspace*{-2.5cm}
\centering
\includegraphics[scale=0.40]{plot7_MEGAPLOT.png}
\hspace*{-2.5cm}
\vspace*{-0.5cm}
\caption{Plot of raw and deseasonalized dat}
\end{figure}
\\
\section{Part A2.2}
\subsection{Part A2.2.1}
The main qualitative difference between the plots/roots is that we have an
converging oscillating function for the complex roots while the real values
gives us a weakly oscillating converging function.
It sounds like you might need the placeins package to prevent floats crossing a section barrier.
I've summarised this and most of the other solutions for handling float placements here.
This is quite normal. If there is not enough space for a figure, then the space shouldn't be left blank; it should be filled with whatever text comes next in the document. (You don't see quarter-empty pages in professionally published books, for example.)
If you don't want the figures to float, then you can use [H], but I don't recommend it because as you've discovered it leaves lots of blank space.
My recommendation to everyone using floats is to not give them a placement argument at all (the default is [tbp]) or use [htbp] and let LaTeX put things where it likes. Getting good spacing once the document is finished is as much a problem of tweaking the surrounding material as it is playing with the float parameters.
By the way, no discussion of how LaTeX handles floats is complete without a link to Robin Fairbairn's FAQ entry on the subject.
What you don't say is what you expect to see. If the plot is too big for "here", then LaTeX has to put it on the next page (or a page of floats). That leaves some space which, as Will says, should be filled with something. What effect are you hoping to see?