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?
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 written up a variation on Melinda Green's Buddhabrot method for visualizing the Mandelbrot set. Here it is:
http://pastebin.com/RH6dD77F
To create an animation I rendered hundreds of the individual images with slight variations. The variation is a transformation of the coefficients of the generating function as if they were an abstract vector in a space of coefficients. All of that produced incredible structures in the video...
http://www.youtube.com/watch?v=S2uMAvL_5Fo
The problem? As you can tell, the quality on each image is rather low because it takes forever using the method I came up with (the copies I have on my computer are a little better quality, but still look like old reel-to-reel movies). I'm hoping to find a few methods for increasing quality or lowering output time.
Thanks for any suggestions. I would really like to produce more detailed versions of these. Obviously there is much more structure in the graininess of these images.
You can try something like boxcounting, http://imagej.nih.gov/ij/plugins/fraclac/FLHelp/BoxCounting.htm. If buddhabrot is some sort mandelbrot you can skip some empty boxes. You can use a kd-tree like in packing lightmaps to subdivide the surface.
Currently I'm working on a little project just for a bit of fun. It is a C++, WinAPI application using OpenGL.
I hope it will turn into a RTS Game played on a hexagon grid and when I get the basic game engine done, I have plans to expand it further.
At the moment my application consists of a VBO that holds vertex and heightmap information. The heightmap is generated using a midpoint displacement algorithm (diamond-square).
In order to implement a hexagon grid I went with the idea explained here. It shifts down odd rows of a normal grid to allow relatively easy rendering of hexagons without too many further complications (I hope).
After a few days it is beginning to come together and I've added mouse picking, which is implemented by rendering each hex in the grid in a unique colour, and then sampling a given mouse position within this FBO to identify the ID of the selected cell (visible in the top right of the screenshot below).
In the next stage of my project I would like to look at generating more 'playable' terrains. To me this means that the shape of each hexagon should be more regular than those seen in the image above.
So finally coming to my point, is there:
A way of smoothing or adjusting the vertices in my current method
that would bring all point of a hexagon onto one plane (coplanar).
EDIT:
For anyone looking for information on how to make points coplanar here is a great explination.
A better approach to procedural terrain generation that would allow
for better control of this sort of thing.
A way to represent my vertex information in a different way that allows for this.
To be clear, I am not trying to achieve a flat hex grid with raised edges or platforms (as seen below).
)
I would like all the geometry to join and lead into the next bit.
I'm hope to achieve something similar to what I have now (relatively nice undulating hills & terrain) but with more controllable plateaus. This gives me the flexibility of cording off areas (unplayable tiles) later on, where I can add higher detail meshes if needed.
Any feedback is welcome, I'm using this as a learning exercise so please - all comments welcome!
It depends on what you actually want and what you mean by "more controlled".
Do you want to be able to say "there will be a mountain on coordinates [11, -127] with radius 20"? Complexity of this this depends on how far you want to go. If you want just mountains, then radial gradients are enough (just add the gradient values to the noise values). But if you want some more complex shapes, you are in for a treat.
I explore this idea to great depth in my project (please consider that the published version is just a prototype, which is currently undergoing major redesign, it is completely usable a map generator though).
Another way is to make the generation much more procedural - you just specify a sequence of mathematical functions, which you apply on the terrain. Even a simple value transformation can get you very far.
All of these methods should work just fine for hex grid. If artefacts occur because of the odd-row shift, then you could interpolate the odd rows instead (just calculate the height value for the vertex from the two vertices between which it is located with simple linear interpolation formula).
Consider a function, which maps the purple line into the blue curve - it emphasizes lower located heights as well as very high located heights, but makes the transition between them steeper (this example is just a cosine function, making the curve less smooth would make the transformation more prominent).
You could also only use bottom half of the curve, making peaks sharper and lower located areas flatter (thus more playable).
"sharpness" of the curve can be easily modulated with power (making the effect much more dramatic) or square root (decreasing the effect).
Implementation of this is actually extremely simple (especially if you use the cosine function) - just apply the function on each pixel in the map. If the function isn't so mathematically trivial, lookup tables work just fine (with cubic interpolation between the table values, linear interpolation creates artefacts).
Several more simple methods of "gamification" of random noise terrain can be found in this paper: "Realtime Synthesis of Eroded Fractal Terrain for Use in Computer Games".
Good luck with your project
So upon seeing images from Godus I was wondering how to generate a simple, non-interactive, 2D image with different colors for different heights or layers of heights like on the picture below.
I was just thinking in terms of generating the basic layers of colors for the topography without the houses, trees objects and units. I wasn't thinking in terms of creating a graphics engine that would solve this, but a simple way to generate a flat image on the screen.
The question is two-fold:
1, What kind of data could be used for this sort of generation? I was thinking maybe ASCII art which is kind of easy to create and modify to quickly change the topography, but would be difficult to provide height information.
2, What existing frameworks, classes, methods or methodologies could be used for solving the generation after having the data ready.
Godus:
ASCII art (northern europe with ! for Norway, # for Sweden, $ for Finland and % for Russia:
(Taken from the MapBox docs: http://mapbox.com/developers/utfgrid/#map_data_as_ascii_art)
If you want to create a simple 2D, contoured image, I would try the following:
Create some height data. I'd just use a grey-scale image for that, rather than ascii. You can author basic height-maps in MS Paint, or anything similar.
Smooth the data. For example, apply a blur, or increase the resolution using a smooth filter.
Consider clamping all height data below a certain point - this represents a water level, if you want that.
Quantise the data. The more you quantise, the fewer but more obvious the contours.
Apply a false colouring, via a palette lookup. For example a : low lying areas blue, for water, then yellow, for sand, green for grass, brown for earth, grey for rock, and white for snow.
The important parts are the enlarging/smoothing filter, which creates more interesting shapes to your contours, and the quantisation which actually creates the contours themselves.
You can play with the stages of this. For example you could introduce some noise to the terrain, to make it look more natural if your source data is very clean. Or you could increase the smoothing if you want everything very rounded.
If you want to use ascii, you could just generate a bitmap directly from that, which wouldn't be tricky. The ascii you use as an example though is split up by country rather than terrain, so the false-colouring and contouring would probably do the wrong thing. You could probably use it as input to a simple terrain generator, perhaps just having a couple of chars to denote where you want land, sea, mountains, etc.
Here's a very basic example I knocked up, it's just an application of the technique I suggested. I didn't use any frameworks or libs, just a few simple image processing functions, and an height-map of Europe I found:
There are lots of non-image-based CAPTCHA ideas floating around. But what about the old-fashioned way?
What are the elements of a good image CAPTCHA? What visual elements are hard for computers, but easier for humans? What about mistakes, elements that are easier for computers than they are for humans? What are good techniques for increasing the speed of a CAPTCHA generator?
Here's an example of a CAPCHA I've been working on. It generates the functions for two sine waves, then stretches a text between them. It lays that over a background drawn from a pool of images.
How could this be improved? (Specifically, I'm using PHP GD.) Things that come to mind are:
Change the color of the text, possibly making it multicolored.
Add "scratches" or marks that mildly obscure the text.
Add to the distortion so that it's affected by sine waves horizontally as well.
What goes into a superb image CAPTCHA?
Edit:
I know that there are some very worthy third-party CAPTCHA resources. I'm looking for attributes that make them good. I'd like to use my own CAPTCHAs, just for the purpose of self-improvement. So, you can talk about reCAPTCHA, but it's not exactly what I'm looking for.
Also, it has been brought up that not only the image, but also the experience matters, so feel free to comment on that.
Make each letter/number out of a pattern, I.E. unconnected dots. Meaning the computer has no way of knowing that a dot is part of a letter other than pattern recognition (which they don't have yet.) Then the usual distortions and random lines.
How you do this is the challenge.
EDIT: Also, bonus points for patterns of different shapes, and try alpha transparency on the characters (on the edges or the whole character), so they merge with the background.
Make letters difficult to separate. Use handwriting-like font or add lines that join letters. Decrease and randomize spacing between letters.
Add wave distortion in other axis too. Distortion in one axis only can be relatively easily analyzed and reversed.
Don't bother with color background at all. It's super-easy to automatically filter black from other colors. Your background hinders only humans.
Don't add scratches or other noise unless it has the same thickness as letters. Noise-removal algorithms can easily remove things that are thinner than letters.
What if the color of the letters faded into other colors... for instance the 5 can start off as yellow on top and fade into blue or something. The colors chosen should be random.
With the multicolored background it might make it hard for the computer to pickup where the background ends and the character begins.. and hopefully it would not be too difficult for the human to actually pick up the pattern.
Instead of generating captcha you can create a captcha table in your database and you yourself create the table by search on google for good captcha images.
So no need to worry "Will this generation method work?"
I really hate CAPTCHA on sites, they just annoy me, but if you want to try and make a robust one try the following:
Ability to get a new image without submitting
Spoken version for the visually impaired
Non-uniform characters
I've used Recaptcha on a few sites, it's a nice and robust solution.
Or if you want to be really funky about it check out this: http://research.microsoft.com/asirra/
Algorithms that try to break captcha are pattern matchers that work by a few different ways: scaling and skewing the symbols that they already know about, finding and tracing edges, and counting interior holes to help. If you can break the letter up into pieces, vary the letter quality, or add strong lines or “scratches” along the letters these techniques will help. However all of this is fairly moot considering we have recaptcha for this purpose and it’s a wonderful third party app for this. Additionally captcha will help the security of your site, but will not stop those who are truly enticed.
I like the idea of KittenAuth and Microsoft's Asirra project. The idea is that, while OCR will eventually evolve to break your traditional captcha, the ability to distinguish a kitten from a dog is many orders of magnitude more complex a problem, while absolutely trivial for humans.
This solution, while probably the sexiest captcha idea ever, has the limitation of not being easily portable to hearing-impaired methods.
What about shearing and shuffling bands to mangle display and mouse-only input?
Start by taking your sine-wave morphed text, divide into horizontal bands or maybe even a grid.
That makes optical recognition harder and might allow you to avoid the kind of nasty background games that make some captchas hard for humans.
For a site where you can rely on local drag in the browser, instead of typing in an entry use shuffling requiring the user to re-order pieces (just in sloppy order, not like one of those puzzles). Or, if you wanted to use clicks alone, the classic sliding tile puzzle.
Note, I've run into a captcha where you had to identify which of N cartoons had an animal in them which succeeded in blocking me!
Wellington Grey sums up the AI CAPTCHA race nicely.
You could add a random array of fonts so that GD renders each character using a different one.
Be wary of suggestions of ReCaptcha. I have submitted incorrect input into it a couple few dozen times, and have had success each time. Several of those times I have submitted incorrect input for both words rather than just the most obscured word; the success rate, as I said, has been 100%.
I also think that image-based CAPTCHAs are user-hostile and should be avoided wherever possible. The advantage of text-based solutions is that you can tailor them to your site's audience, adding a level of obscurity that may trip up machines as they become more savvy with text-based solutions.
At the very least, don't use this all the time:
(source: codinghorror.com)