What is the meaning of Jittering in Orange3? What function does it serve?
In the Scatter Plot widget there is a slide bar option called 'Jittering', what does it do?
From Wikipedia:
jitter is the deviation from true [...] signal
The use in Orange, as this article neatly sums up, refers to random plotted perturbations of true data so as to more clearly reveal the density of discrete/nominal data points.
The same plot without (left) and with (right) jittering:
Related
As you see I am new to stackoverflow and Gnuplot, so please forgive me if I am not asking in the right way or right place ! :-
I have a scatter of (Y) data values/points collected over a range of dates. I can plot them against an x-axis of the dates and I have a 'fit' function of the form f(x)= a*x+b.
My problem is that this function extends/plots beyond the date range of the data points if I plot the data in a window which has a date range beyond that of the collected data. ie. the plotted function fills the whole window.
In other words : I want a window space (xrange) over say 50days but while the data is being collected (a few days only) I want the fitted function to occupy only the region of the so-far collected data and to then extend in sync with it as more data is plotted later.
Am I making sense !
Showing the unwanted
Thanks for any help.
Add a separate range for the fit line:
set xrange [10:50] # applies to the entire plot
plot 'data' using 1:2 with points title "Data", \
[12:25] fit(x) with lines title "fit"
I have gone through a couple of YOLO tutorials but I am finding it some what hard to figure if the Anchor boxes for each cell the image is to be divided into is predetermined. In one of the guides I went through, The image was divided into 13x13 cells and it stated each cell predicts 5 anchor boxes(bigger than it, ok here's my first problem because it also says it would first detect what object is present in the small cell before the prediction of the boxes).
How can the small cell predict anchor boxes for an object bigger than it. Also it's said that each cell classifies before predicting its anchor boxes how can the small cell classify the right object in it without querying neighbouring cells if only a small part of the object falls within the cell
E.g. say one of the 13 cells contains only the white pocket part of a man wearing a T-shirt how can that cell classify correctly that a man is present without being linked to its neighbouring cells? with a normal CNN when trying to localize a single object I know the bounding box prediction relates to the whole image so at least I can say the network has an idea of what's going on everywhere on the image before deciding where the box should be.
PS: What I currently think of how the YOLO works is basically each cell is assigned predetermined anchor boxes with a classifier at each end before the boxes with the highest scores for each class is then selected but I am sure it doesn't add up somewhere.
UPDATE: Made a mistake with this question, it should have been about how regular bounding boxes were decided rather than anchor/prior boxes. So I am marking #craq's answer as correct because that's how anchor boxes are decided according to the YOLO v2 paper
I think there are two questions here. Firstly, the one in the title, asking where the anchors come from. Secondly, how anchors are assigned to objects. I'll try to answer both.
Anchors are determined by a k-means procedure, looking at all the bounding boxes in your dataset. If you're looking at vehicles, the ones you see from the side will have an aspect ratio of about 2:1 (width = 2*height). The ones viewed from in front will be roughly square, 1:1. If your dataset includes people, the aspect ratio might be 1:3. Foreground objects will be large, background objects will be small. The k-means routine will figure out a selection of anchors that represent your dataset. k=5 for yolov3, but there are different numbers of anchors for each YOLO version.
It's useful to have anchors that represent your dataset, because YOLO learns how to make small adjustments to the anchor boxes in order to create an accurate bounding box for your object. YOLO can learn small adjustments better/easier than large ones.
The assignment problem is trickier. As I understand it, part of the training process is for YOLO to learn which anchors to use for which object. So the "assignment" isn't deterministic like it might be for the Hungarian algorithm. Because of this, in general, multiple anchors will detect each object, and you need to do non-max-suppression afterwards in order to pick the "best" one (i.e. highest confidence).
There are a couple of points that I needed to understand before I came to grips with anchors:
Anchors can be any size, so they can extend beyond the boundaries of
the 13x13 grid cells. They have to be, in order to detect large
objects.
Anchors only enter in the final layers of YOLO. YOLO's neural network makes 13x13x5=845 predictions (assuming a 13x13 grid and 5 anchors). The predictions are interpreted as offsets to anchors from which to calculate a bounding box. (The predictions also include a confidence/objectness score and a class label.)
YOLO's loss function compares each object in the ground truth with one anchor. It picks the anchor (before any offsets) with highest IoU compared to the ground truth. Then the predictions are added as offsets to the anchor. All other anchors are designated as background.
If anchors which have been assigned to objects have high IoU, their loss is small. Anchors which have not been assigned to objects should predict background by setting confidence close to zero. The final loss function is a combination from all anchors. Since YOLO tries to minimise its overall loss function, the anchor closest to ground truth gets trained to recognise the object, and the other anchors get trained to ignore it.
The following pages helped my understanding of YOLO's anchors:
https://medium.com/#vivek.yadav/part-1-generating-anchor-boxes-for-yolo-like-network-for-vehicle-detection-using-kitti-dataset-b2fe033e5807
https://github.com/pjreddie/darknet/issues/568
I think that your statement about the number of predictions of the network could be misleading. Assuming a 13 x 13 grid and 5 anchor boxes the output of the network has, as I understand it, the following shape: 13 x 13 x 5 x (2+2+nbOfClasses)
13 x 13: the grid
x 5: the anchors
x (2+2+nbOfClasses): (x, y)-coordinates of the center of the bounding box (in the coordinate system of each cell), (h, w)-deviation of the bounding box (deviation to the prior anchor boxes) and a softmax activated class vector indicating a probability for each class.
If you want to have more information about the determination of the anchor priors you can take a look at the original paper in the arxiv: https://arxiv.org/pdf/1612.08242.pdf.
I am trying to make a simple arcade shooter like Galaga in TIBasic. I have successfully created some code that lets you move your character (an "X") horizontally across the screen while shooting a bullet that clears everything along the vertical path it takes. However, I'm having a problem with the "rocks" that are supposed to fall from the screen and disappear when hit. When I shoot the rock, it is cleared by the bullet, but then continues going down the screen until it hits the bottom of the screen. Here's the code for the rocks:
//outside the game loop:
1->R
//inside game loop:
If not(R=8)
Then
R+1->R
If R>1
Then
Output(E-1, 1, " " //removes last rock
End
Output(R, 1, "R" //replaces last rock with one below it (traveling towards the ground)
End
This code obviously doesn't stop the "R" from continuing to go down the screen when it is cleared (by the way, I just use Output(...," ") on wherever the bullet was to clear away anything the bullet hits). So, how would I check if the rock was cleared away on the last iteration of the game loop? Is there a way to check if something (the "R") is at a certain place on the screen in order to check if it was cleared away by a bullet on the last iteration? Or is there a better way? Thanks for the help!
It appears that the code you have doesn't test if the bullet is in the same place as the rock. To have this collision, you'd need to compare the "R" y-value of the rock with the y-value of your bullet you displayed, and compare the x-value of the rock (however you store that) with the x-value of the bullet. If both are equal to each other, then they have collided, and you can "delete" the rock by setting it to whatever value signifies it doesn't exist anymore. Assuming R is the y-value of the rock, S is the x-value of the rock, Y is the y-value of the bullet, and X is the x-value of the bullet, In the code to move the rock, I'd put this somewhere:
:If R=Y and S=X
:DelVar R
//You could also delete the bullet here because it's "stopped" by the rock
This code will test if the two are collided and set R to 0 (meaning it doesn't exist). If you wanted, you could also add a text-version of an explosion to give it some more flair. Good luck with your project, and I hoped this helped!
When making a game in Ti-Basic, there are 2 options for which "screen" to put it on: The text screen of the calculator, using functions like Disp and Output, and the graph screen, using Text, as well as the drawing functions, stored pictures, and pxl and pt functions. I'm not sure about how to check the text out put screen for the presence of an object on the screen, but the graph function has the Pxl-Test function:
:Pxl-Test(y,x)
Someone else may have know how to check for something on the text screen, but I suggest switching to the graph screen to make use of this function.
If you are going to switch to using the graph output here are some things to note:
The text function is
:Text(row,col,output)
Row and col are switched from the Output function
Rows and cols are measured in pixels on the screen, as opposed to the space it takes to type a letter
Most letters are 3 pixels wide, spaces are 1 pixel wide, so it will take multiple spaces to clear out an unwanted character
You may need to disable the graph axis (FORMAT menu), the y-functions (VARS menu, then right to Y-VARS), and the stat-plots (STAT PLOT menu) in the begging of the program then restore them at the end.
One last not on using the Pxl-Test function is that it tests a group of pixels, while a letter. For now let's pretend you only use Rs and an X in your program (I don't know if you do or don't), so you should test a spot on that character that is relatively unique to that character.
Good luck!
I'm trying to diagnose and fix a bug which boils down to X/Y yielding an unstable result when X and Y are small:
In this case, both cx and patharea increase smoothly. Their ratio is a smooth asymptote at high numbers, but erratic for "small" numbers. The obvious first thought is that we're reaching the limit of floating point accuracy, but the actual numbers themselves are nowhere near it. ActionScript "Number" types are IEE 754 double-precision floats, so should have 15 decimal digits of precision (if I read it right).
Some typical values of the denominator (patharea):
0.0000000002119123
0.0000000002137313
0.0000000002137313
0.0000000002155502
0.0000000002182787
0.0000000002200977
0.0000000002210072
And the numerator (cx):
0.0000000922932995
0.0000000930474444
0.0000000930582124
0.0000000938123574
0.0000000950458711
0.0000000958000159
0.0000000962901528
0.0000000970442977
0.0000000977984426
Each of these increases monotonically, but the ratio is chaotic as seen above.
At larger numbers it settles down to a smooth hyperbola.
So, my question: what's the correct way to deal with very small numbers when you need to divide one by another?
I thought of multiplying numerator and/or denominator by 1000 in advance, but couldn't quite work it out.
The actual code in question is the recalculate() function here. It computes the centroid of a polygon, but when the polygon is tiny, the centroid jumps erratically around the place, and can end up a long distance from the polygon. The data series above are the result of moving one node of the polygon in a consistent direction (by hand, which is why it's not perfectly smooth).
This is Adobe Flex 4.5.
I believe the problem most likely is caused by the following line in your code:
sc = (lx*latp-lon*ly)*paint.map.scalefactor;
If your polygon is very small, then lx and lon are almost the same, as are ly and latp. They are both very large compared to the result, so you are subtracting two numbers that are almost equal.
To get around this, we can make use of the fact that:
x1*y2-x2*y1 = (x2+(x1-x2))*y2 - x2*(y2+(y1-y2))
= x2*y2 + (x1-x2)*y2 - x2*y2 - x2*(y2-y1)
= (x1-x2)*y2 - x2*(y2-y1)
So, try this:
dlon = lx - lon
dlat = ly - latp
sc = (dlon*latp-lon*dlat)*paint.map.scalefactor;
The value is mathematically the same, but the terms are an order of magnitude smaller, so the error should be an order of magnitude smaller as well.
Jeffrey Sax has correctly identified the basic issue - loss of precision from combining terms that are (much) larger than the final result.
The suggested rewriting eliminates part of the problem - apparently sufficient for the actual case, given the happy response.
You may find, however, that if the polygon becomes again (much) smaller and/or farther away from the origin, inaccuracy will show up again. In the rewritten formula the terms are still quite a bit larger than their difference.
Furthermore, there's another 'combining-large&comparable-numbers-with-different-signs'-issue in the algorithm. The various 'sc' values in subsequent cycles of the iteration over the edges of the polygon effectively combine into a final number that is (much) smaller than the individual sc(i) are. (if you have a convex polygon you will find that there is one contiguous sequence of positive values, and one contiguous sequence of negative values, in non-convex polygons the negatives and positives may be intertwined).
What the algorithm is doing, effectively, is computing the area of the polygon by adding areas of triangles spanned by the edges and the origin, where some of the terms are negative (whenever an edge is traversed clockwise, viewing it from the origin) and some positive (anti-clockwise walk over the edge).
You get rid of ALL the loss-of-precision issues by defining the origin at one of the polygon's corners, say (lx,ly) and then adding the triangle-surfaces spanned by the edges and that corner (so: transforming lon to (lon-lx) and latp to (latp-ly) - with the additional bonus that you need to process two triangles less, because obviously the edges that link to the chosen origin-corner yield zero surfaces.
For the area-part that's all. For the centroid-part, you will of course have to "transform back" the result to the original frame, i.e. adding (lx,ly) at the end.
I want to test each pixel in an image and check it's color if it is white then I must display
the corresponding (x,Y) for that pixel but I didn't find until now a function that help me
do something like that. So please if you have such function tell me.
thanks at all
If you are using matlab for image editting, the function for this purpose would be imread, i.e. if you have a MN image them imread would split it in a matrix of [MN*3], i.e. a 3 dimensional array representing RGB components of the image. Now if at a given X,Y coordinate, all the three i.e. Red, Green and Blue components have equal value, then that pixel is not color. If they have different values then it is coloured pixel. Using an if condition check and generate a new picture matrix accordingly. Display the new picture matrix.
I don't know if there is such a function. maybe in some deep graphics toolkit? it'll certainly not be part of a basic language framework (i.e. core stuff in objc or system in c#).
you might have to bite the bullet and just work your way through all of the pixels manually in o(n^2).
foreach horizontal pixel
foreach vertical pixel
if(pixel at (horizontal,vertical) is white)
return (horizontal, vertical)