I have a linear optimization problem:
minimize c^T x
where A x = b
But I want to find the 'worst case scenario' when b is flexible (m_i < b_i < M_i). A naive approach would be applying a non-linear optimization to the linear one:
maximize [minimize c^T x where A x = b] where b_min < b < b_max
Is there any better way to do this?
Maybe a real example:
The famous diet problem, where we look for a cheapest combination of foods that satisfy all nutritional requirements. But as nutritional requirements aren't completely set (and depend on person and his daily activity), constraints are flexible and we want to find a worst case scenario - what would be most expensive set of constraints - if food combination is optimized.
https://en.wikipedia.org/wiki/Bilevel_optimization - this is basically what I need, I'll try the linked optimizer and post the result.
Related
Hey guys i have a quiz tommorow i am facing some problems finding time complexity of recursive programm of selection sort can any one explain how is it n^2. And also one more question that some sorting algorithms loops have n/2 time complexity what is the meaning of /2 sorry for newbie question.
#include <iostream>
using namespace std;
// recursive function to perform selection sort on subarray arr[i..n-1]
void selectionSort(int arr[], int i, int n)
{
// find the minimum element in the unsorted subarray[i..n-1]
// and swap it with arr[i]
int min = i;
for (int j = i + 1; j < n; j++)
{
// if arr[j] element is less, then it is the new minimum
if (arr[j] < arr[min])
min = j; // update index of min element
}
// swap the minimum element in subarray[i..n-1] with arr[i]
swap(arr[min], arr[i]);
if (i + 1 < n)
selectionSort(arr, i + 1, n);
}
Finding time complexity is often described in a way that is not really very helpful. Here is how it works for Selection Sort.
passes
The very first time through the algorithm, you must scan all n elements of the data.
The very next time through (on recursion), you must scan all but one, which is (n-1).
And so on. We can write the number of times we look at/compare an element as:
n + (n-1) + (n-2) + ... + 2 + 1
(You can quibble about that last term, but for simplicity here we just won't care. You'll see why in just a second.)
math identities
This particular series (notice all the additions) is called an “arithmetic progression”. The difference between each term is 1. The first term is n and the last term is 1 (or 2, whatever).
And using some math most people don’t remember (or weren’t taught) in High School, we can rewrite that sum as:
n(n+1)
──────
2
(Yes, again, that last term is actually supposed to be a two, even though I’ve left it at one.)
as n grows arbitrarily large
Big O doesn’t care much about friendly values of n. It cares about what happens when n gets arbitrarily big. We say “n grows towards infinity”.
As it does, we can notice two things happening:
That division by 2 becomes insignificant: ∞/2 → ∞
That addition by 1 (or whatever) is also insignificant: ∞(∞+1) → ∞(∞)
So ultimately, we have infinity, er, n multiplied by itself. The equation simplifies to:
n(n+1)
────── → n²
2
complexity bounds
The worst case behavior is n², so we annotate that as “O(n²)”. But notice that the best case is also n². We annotate that as “Ω(n²)”. Finally, since the best and worst case behaviors are the same, we have a very nice tight bound on the behavior of the function. We annotate this as “Θ(n²)”.
Hence, selection sort has Θ(n²) complexity.
holy quiznak! I’m supposed to do this myself!!?
Yes, unfortunately, figuring out complexity is one of those things that people treat as if it were really easy — even when they don’t understand it well themselves. It takes some familiarity with math and some practice. The typical response is as in the links provided you above: ‘look at these common cases and choose the one that most closely matches’. I personally find that less satisfyingly instructive. It is also one of those things that university professors expect you to pick up right away.
My advice: don’t worry too hard. Do your best to understand the underlying principles. What we are doing is finding a function (like y=x²) that represents an algorithm’s behavior whenever its input is really large (n → ∞).
Being able to follow through the paths that the algorithm takes and recognizing when those paths are expensive is a more important ability than being able to come up with a mathematician’s answer. If you really need it you can always find a mathematician to help, either at the university or on the internet if you ask in the right places.
And, of course, feel free to take time to try to understand better and practice. Being able to do it right is a valuable skill, regardless of whether others see it.
:O)
I have a 2d map in my rts. On the map there are some units. I want to check if there is any unit in range of another. The units range is given in fields. See the image:
On the pic none of units (red, blue, green) can attack each other. I want to, for example check, for example if there is any units in range of blue. The answer is no. I know the blue's range and position, I also know positions of the rest. I also know if the map xy is occupied. How can I check this?
You want to iterate over all points (x + i, y + j) around your unit at (x, y) such that
|i| + |j| <= R ,
where R is the range of attack. (This is a disk in the L1-metric.) So, like this:
for (i = -R; i <= +R; ++i)
{
jRange = R - abs(i);
for (j = -jRange; j <= +jRange; ++j)
{
// access (x + i, y + j)
}
}
Alternatively, you can halve the outer loop by unrolling:
for (i = 0; i <= R; ++i)
{
jRange = R - i;
for (j = -jRange; i <= +jRange; ++j)
{
// access (x - i, y + j)
// if (i > 0) access (x + i, y + j)
}
}
As #Alink says, you'll have to handle the map boundary in some way or another.
On other answers (too long as comment):
Pathfinding is really wrong here. First of all, we have a grid with no restrictions and equal costs. Using any kind of pathfinding is neither necessary nor makes sense at all. I get that you are thinking ahead in a way that this exact property might change / usually is different for RTS games, but I really think we should stick to the exact problem if the author carried it out precisely and quite well.
Especially, A* is a terrible, terrible choice:
Dijkstra calculates shortest paths to all destinations from a given source node. A* uses the fact that you often have one distinct destination and a heuristic can be used to "guide" Dijkstra in the right direction. It makes you reach the interesting destination earlier and therefore you pay a small overhead. If you want to check areas "around" some source node (the unit here), this just counter-productive.
Bitmaps will have the problem of aligning them with the grid. Either way there surely are ways to optimize and check more they once field at once, but those are just optimizations, imho.
On the problem itself:
I have no experience with games at all, so this is w.r.t of the abstract problem you outline above. I have added some speculations on your RTS application but take them with a grain of salt.
Simply checking all fields around a unit, as suggested by Kerrek SB is pretty good. No unnecessary field is checked and all fields are accessed directly. I think I'd propose the same thing.
If the number of the checks from the question greatly dominates the number of unit movements (I doubt it, because of the "real-time" thing), it might be possible to precompute this problem for every unit and update it whenever a unit moves. I'll propose something that is more hungry for memory and most probably inferior to the straightfoward approach Kerrik SB proposed:
If a unit U moves to field F, it will:
notify all Unitis registered at F that they now can attack something
register itself at all the fields around F that it can now reach and
at the same time check if one of this fields is already occupied so that it could attack right away
remember all those fields to "unregister" once U moves away in the future
Consequently, each unit will know if it has something in range and does not have to recalculate that. Moving a unit will trigger recalculation only for that given unit and fields will simply notify only relevant other units.
However, there is memory overhead. And "real-time" and plenty of units moving all the time will largely decrease benefits. So I have a strong feeling this isn't the best way to go, either. However, depending on your requirements it might also work very well.
Create a bitmap for the ranges of each unit, this will allow you to shape them in any shape you want.
Simplified example:
char range1[] =
"010"
"111"
"010";
char range2[] =
"00100"
"01110"
"11111"
"01110"
"00100";
And so on...
then just check if the point lays on the bitmap (you have to figure that out yourself).
I would use a pathfinding algorithm, especially since map squares can be occupied, you'll need a pathfinding algorithm sooner or later. A* would probably be the easiest one to implement for you and perform well enough for your given scenario. It is very well described on wikipedia, and googling it should return a lot of results for you as well as sample code.
You would basically calculate a path between each entity and another. If that path exceeds the given range for the unit, it is out of range. This could of course be optimized so that you will not continue checking once all the range is exhausted.
Please, can someone explaine this:
If documentations says that STL std::vector finding element speed performace = O(ln(n)),
what does it mean.
O(ln(n)) - what is "O", where I can read about that?
And where I can read about performace of other STL containers preformance
Thank you very much
Big O notation is a way to measure how an algorithm will scale as the size of the data on which it is working grows.
Finding an element if a vector is usually O(n), it's only O(lg(n)) when the vector is sorted and you use one of the binary search family of algorithms.
The complexity of each algorithm is specified in the standard and also in any reference (such as the above link to std::lower_bound).
BTW, ln is log on base e, but all logarithms are the same complexity so even though a binary search only performs lg (log2) operations it's technically correct to say it's O(ln(n)).
Big-O notation is about the time complexity of a programs performance.
so O(ln(n)) means that accessing elements in std::vector as the vector gets larger is proportional to ln(size_of_vector), but this is only with a sorted vector using binary search. Binary search performs faster than linear search because you eliminate possible elements twice as fast, thus the ln is really a log base 2.
http://en.wikipedia.org/wiki/Big_O_notation
This is known as the Big O notation, it is an expression of the asymptotic complexity of a given algorithm and in relation with some parameters.
asymptotic means that we are not interested in the first few cases, but about the behavior of the algorithm when the size of the input parameters grow.
the parameters depend on the algorithm to be measured
an operation in which we are interested
For example, in the case of a binary search we express a relationship between the number of comparison performed depending on the size of the set in which we search.
The running time can usually be inferred from this, but it is not always true, especially if one didn't picked up the right "operation" with regard to the implementation or hardware constraints.
There was a nice post a few days ago speaking about sorting using a tape as storage. Because the complexities in searching express the number of comparison and using a tape as storage the runtime is mostly affected by the movement of the tape... it turned out that bubblesort would perform better than quicksort despite being described as slower in general.
The O is big O notation. It describes the runtime complexity of an algorithm. Essentially it's the number of operations required to compute the answer.
All the other answers have cleared up O, to find the typical complexity of a given algorithm look at a decent reference, such as this. At the bottom of each algorithm, the complexity of the algorithm is documented.
O is an abbreviation for "Order". It's a measure of the running time of the operation.
For example, this code is O(n^2) because it's going to execute n*n times.
int n = 100;
for (int i = 0; i < n; ++i) {
for (int j = 0; j < n; ++j) {
}
}
I am starting to work with boost graph library. I need a best-first search, which I could implement using astar_search by having zero costs. (Please correct me if I'm wrong.)
However, I wonder if there is another possibility of doing this? If the costs are not considered, the algorithm should be slightly more efficient.
EDIT: Sorry for the unclear description. I am actually implementing a potential field search, so I don't have any costs/weights associated with the edges but rather need to do a steepest-descent-search (which can overcome local minima).
Thanks for any hints!
You could definitely use A* to tackle this; you'd need h(x) to be 0 though, not g(x). A* rates nodes based on F which is defined by
F(n) = g(n) + h(n).
TotalCost = PathCost + Heuristic.
g(n) = Path cost, the distance from the initial to the current state
h(n) = Heuristic, the estimation of cost from current state to end state.
From Wikipedia:
Dijkstra's algorithm, as another
example of a best-first search
algorithm, can be viewed as a special
case of A* where h(x) = 0 for all x.
If you are comfortable with C++, I would suggest trying out YAGSBPL.
As suggested by Aphex's answer, you might want to use Dijkstra's algorithm; one way to set the edge weights is to set w(u, v) to potential(v) - potential(u), assuming that is nonnegative. Dijkstra's algorithm assumes that edge weights are positive and so that distances increase as you move away from the source node. If you are searching for the smallest potential, flip the sides of the subtraction; if you have potentials that go both up and down you might need to use something like Bellman-Ford which is not best-first.
I'm using C++ to write a ROOT script for some task. At some point I have an array of doubles in which many are quite similar and one or two are different. I want to average all the number except those sore thumbs. How should I approach it? For an example, lets consider:
x = [2.3, 2.4, 2.11, 10.5, 1.9, 2.2, 11.2, 2.1]
I want to somehow average all the numbers except 10.5 and 11.2, the dissimilar ones. This algorithm is going to repeated several thousand times and the array of doubles has 2000 entries, so optimization (while maintaining readability) is desired. Thanks SO!
Check out:
http://tinypic.com/r/111p0ya/3
The "dissimilar" numbers of the y-values of the pulse.
The point of this to determine the ground value for the waveform. I am comparing the most negative value to the ground and hoped to get a better method for grounding than to average the first N points in the sample.
Given that you are using ROOT you might consider looking at the TSpectrum classes which have support for extracting backgrounds from under an unspecified number of peaks...
I have never used them with so much baseline noise, but they ought to be robust.
BTW: what is the source of this data. The peak looks like a particle detector pulse, but the high level of background jitter suggests that you could really improve things by some fairly minor adjustments in the DAQ hardware, which might be better than trying to solve a difficult software problem.
Finally, unless you are restricted to some very primitive hardware (in which case why and how are you running ROOT?), if you only have a couple thousand such spectra you can afford a pretty slow algorithm. Or is that 2000 spectra per event and a high event rate?
If you can, maintain a sorted list; then you can easily chop off the head and the tail of the list each time you work out the average.
This is much like removing outliers based on the median (ie, you're going to need two passes over the data, one to find the median - which is almost as slow as sorting for floating point data, the other to calculate the average), but requires less overhead at the time of working out the average at the cost of maintaining a sorted list. Which one is fastest will depend entirely on your circumstances. It may be, of course, that what you really want is the median anyway!
If you had discrete data (say, bytes=256 possible values), you could use 256 histogram 'bins' with a single pass over your data putting counting the values that go in each bin, then it's really easy to find the median / approximate the mean / remove outliers, etc. This would be my preferred option, if you could afford to lose some of the precision in your data, followed by maintaining a sorted list, if that is appropriate for your data.
A quick way might be to take the median, and then take the averages of number not so far off from the median.
"Not so far off," being dependent of your project.
A good rule of thumb for determining likely outliers is to calculate the Interquartile Range (IQR), and then any values that are 1.5*IQR away from the nearest quartile are outliers.
This is the basic method many statistics systems (like R) use to automatically detect outliers.
Any method that is statistically significant and a good way to approach it (Dark Eru, Daniel White) will be too computationally intense to repeat, and I think I've found a work around that will allow later correction (meaning, leave it un-grounded).
Thanks for the suggestions. I'll look into them if I have time and want to see if their gain is worth the slowdown.
Here's a quick and dirty method that I've used before (works well if there are very few outliers at the beginning, and you don't have very complicated conditions for what constitutes an outlier)
The algorithm is O(N). The only really expensive part is the division.
The real advantage here is that you can have it up and running in a couple minutes.
avgX = Array[0] // initialize array with the first point
N = length(Array)
percentDeviation = 0.3 // percent deviation acceptable for non-outliers
count = 1
foreach x in Array[1..N-1]
if x < avgX + avgX*percentDeviation
and x > avgX - avgX*percentDeviation
count++
sumX =+ x
avgX = sumX / count
endif
endfor
return avgX