I want to know how will it affect to the Cyclomatic Complexity when having multiple start or stop nodes in a control flow diagram.If you could explain the relationship between Cyclomatic Complexity and Start/Stop nodes it will be a great help.
• A control flow graph can consist of many starts and stops. But according to McCabe's theory, if it is consist of multiple starts and stops it doesn't satisfy the formula.
Related
Graph theory Algorithm problem
Consider a set of, say p single-core processors which have been assigned q programs is given
along with:
– start times for the programs
– end times for the programs
– Total processing time to complete a program
Programs can be stopped, restarted, and moved between processors without any penalty.
i. Device an algorithm to schedule the running of programs on processors such that
the deadlines are met.
ii. Trace the algorithm for a set of values of your choice
I don't know which algorithm to use bellman-ford or floyd warshall or ford-fulkerson or dijksta's or kruskal's or prim's algorithm.
What algorithms could be used here, and what would be the correct way to formulate this problem using graph theory language?
You can use Dijkstra to find the critical path, if you set the edge costs to the reciprocal of the task duration. Then always choose to run a ready task if it is on the critical path, otherwise choose a non critical task at random.
This is the bare bones of the algorithm. Lots of details to sort out. You can see all the details at https://github.com/JamesBremner/TaskGraphScheduler
I have a graph with a guarantee that it can be divided into two equal-sized partitions (one side may be 1 larger than the other), with no edges across this partition. I initially thought this was NP-hard, but I suspect it might not be. Is there any (efficient) way of solving this?
It's possible to solve your problem in time O(n2) by combining together two well-known algorithms.
When I first saw your problem, I initially thought it was going to relate to something like finding a maximum or minimum cut in a graph. However, since you're specifically looking for a way of splitting the nodes into two groups where there are no edges at all running between those groups, I think what you're looking for is much closer to finding connected components of a graph. After all, if you break the graph apart into connected components, there will be no edges running between those components. Therefore, the question boils down to the following:
Find all the connected components of the graph, making a note of how many nodes are in each component.
Partition the two connected components into two groups of roughly equal size - specifically, the size of the group on one side should be at most one more than the size of the group on the other.
Step (1) is something that you can do using a breadth-first or depth-first search to identify all the connected components. That will take you time O(m + n), where m is the number of edges and n is the number of nodes.
Step (2), initially, seems like it might be pretty hard. It's reminiscent of the partition problem, which is known to be NP-hard. The partition problem works like this: you're given as input a list of numbers, and you want to determine whether there's a split of those numbers into two groups whose totals are equal to one another. (It's possible to adapt this problem so that you can tolerate a split that's off by plus or minus one without changing the complexity). That problem happens to be NP-complete, which suggests that your problem might be hard.
However, there's a small nuance that actually makes the apparent NP-hardness of the partition problem not an issue. The partition problem is NP-hard in the case where the numbers you're given are written out in binary. On the other hand, if the numbers are written out in unary, then the partition problem has a polynomial-time solution. More specifically, there's an algorithm for the partition problem that runs in time O(kU), where k is the number of numbers and U is the sum of all those numbers. In the case of the problem you're describing, you know that the sum of the sizes of the connected components in your graph must be n, the number of nodes in the graph, and you know that the number of connected components is also upper-bounded by n. This means that the runtime of O(kU), plugging in k = O(n) and U = O(n), works out to O(n2), firmly something that can be done in polynomial time.
(Another way to see this - there's a pseudopolynomial time algorithm for the partition problem, but since in your case the maximum possible sum is bounded by an actual polynomial in the size of the input, the overall runtime is a polynomial.)
The algorithm I'm alluding to above is a standard dynamic programming exercise. You pick some ordering of the numbers - not necessarily in sorted order - and then fill in a 2D table where each entry corresponds to an answer to the question "is there a subset of the first i numbers that adds up to exactly j?" If you're not familiar with this algorithm, I'll leave it up to you to work out the details, as it's a really beautiful problem to solve that has a fairly simple and elegant solution.
Overall, this algorithm will run in time O(n2), since you'll do O(m + n) = O(n2) work to find connected components, followed by time O(n2) to run the partition problem DP to determine whether the split exists.
Hope this helps!
Does anybody know how to best implement a randomized algorithm (Monte Carlo simulation to approximate a value) to run in a fixed time (5 minutes)?
i.e. the algorithm will continue to take new samples until the execute time is around 5 minutes?
This algorithm could help to compare different randomized methods in a fixed time.
Thank you.
Your question is a bit vague but there are a couple possible answers. If you are simply sampling independently over and over (so sampling is typically very fast, compared to how much total time you have), then all you need is access to a system timer in your language so that you can detect whenever your running time is essentially equal to your maximum allowed running time, then halt and give your estimate.
However there are also randomized algorithms that have EXPECTED running time, and they may or not finish in the maximum allowed time. If that is what you're dealing with, then the best approach is to understand the distribution on running time according to whatever randomness assumptions, and then set up a strategy where you run an algorithm for a specified amount of time and then halt if it hasn't finished, and then restart with new randomness. For example, if the probability of finishing within N steps is 0.9 and the probability of finishing within 2N steps is 0.01, otherwise you finish in more than 2N steps, then your best strategy if you only have 2N steps available is to restart after N steps if you haven't finished. This maximizes the probability of finishing within 2N steps.
As #Nico Schertler said you just have a while condition based on time then you can use any one of these examples of monte carlo simulation as normal just within a while loop that uses time as a constraint.
http://rosettacode.org/wiki/Monte_Carlo_methods#MATLAB
I've recently become interested in graph theory and after investing with the bioinformatics toolbox for MATLAB I have found the graphshortestpath function incredibly useful. However, when using the function the run times are always very similar, whether I set the function to Breadth-first search, Dijkstra's algorithm or Bellman Ford algorithm. I have tried with varying amounts of nodes from a few hundred to hundreds of thousands and still the run times are almost identical.
Now on the graphshortestpath page on the MATLAB website Dijkstra's algorithm shows a time complexity that would suggest it would be substantially faster than the other two algorithms.
From what I have read the time complexity is more of a worst case scenario, but I was expecting to see at least a slight difference in run times.
see here (http://www.mathworks.co.uk/help/bioinfo/ref/graphshortestpath.html)
Am I missing something here?
Any help would be greatly appreciated.
Just a guess here, but depending on how you are measuring the performance, you might be spending a lot of time actually drawing the graph path -- which is likely to cost more than the actual search.
Try adding timing metrics that exclude the drawing process before compare. Note of course, that your dependency will be not only on the number of vertices, but also, the number of edges in your graph.
As I am implementing a simple load balancing service, I think Big-O is a key factor for it's future performance and scalability. But I could find no reference regarding the big-O of both algorithms (WRR & RR).
I made a try to calculate both of them.
(WARING my calculations might be wrong but I'll edit the post as soon as I get a rightful answer)
n-> number of serving nodes (and weights)
z-> number of waiting/incompleted tasks
For WRR: O(nnz)
For RR: O(z^2)
For WRR: O(1)
For RR: O(1)
So the real question is, if my calculations are right but most important which algorithm perform the fastest in a case of continuous load balanced (to each running node) thousand submitted tasks per second.
Some helpful references:
A Very nice RR implementation
A stackoverflow question regarding WRR
Cheers!
So what is it exactly you need to measure? As big O is for algorithm performance, it seems the reasonable thing to measure is the time complexity for each sheduling decision, i.e. how many operations are required to match one task to one node.
Round robin
Both the list of ready nodes and the list of waiting tasks can be implemented as queues, and operations on queues can be implemented constant amortized time. So except for the time required when you need to allocate new memory for your queue, you operate in O(1).
Weighted round robin
If your weights are fixed and commensurable, then you can achieve the same complexity here as well: simply place each node into the cyclic queue several times, proportional to its weight. One can formulate an algorithm to space them evenly within the queue. For most practical applications, some moderate quantization will lead to weights which can be represented as (i.e. scaled to) reasonably small integers.
Other considerations
Do you get any feedback at all about whether your nodes are busy or idle? If you do, then RR should work well enough, since you didn't state any fairness requirements. If you don't have idle feedback, then WRR might make sense. But in that case, the number z in your formulas appears somewhat confusing, since how can tasks be waiting if you don't know whether nodes are ready to accept them? If they are waiting because the balancer can't handle them fast enough, then this still shouldn't matter for your considerations, as you can imagine the queue of tasks as before the scheduling algo: the length of that queue has no impact on what happens in the scheduler. Again assuming all tasks are the same to you, without priorities, QoS guarantees or similar meta information.