|
Has anyone implemented clarke and wright algorithm with multiple truck capacities.If yes please help me with implementing the same. Thanks
Hemanth
|
|
|
|
|
Try this: Single-Depot VRP[^].
They don't give you the code but there's more than enough information to show you how to implement it.
|
|
|
|
|
plz help me in writing an algorithm of the following problem
Problem:
"Let S be a set of n disjoint line segments in the plane, and let p be a point not on any of the line segments of S. We wish to determine all line segments of S that p can see, that is, all line segments of S that contains some points q so that the open segment pq does not intersect any line segment of S. Give an O(nlogn) time algorithm for this problem that uses a rotating half line with its endpoint at p."
regards,
Irfan
|
|
|
|
|
Sounds like homework to me.
What have you done to solve this yourself? Any code that doesn't work? Google is your friend!
Dave.
|
|
|
|
|
you are a good algorithm writer as I think.
please help me in this regard. I could not find anything relevent to this problem.
kindly do this for me please.
I am waiting for your positive response.
regards,
|
|
|
|
|
Here is an algorithm that solves your particular problem and many others as well:
1. formulate your problem (you did very well at that)
2. open the Google search page and enter the entire problem description into the textbox
3. click the "Search" button
4. wait a few seconds to see a small number of hits out of an often huge number of hits.
5. scan the list, open the ones that look most promising.
6. if necessary, click for the next page of hits.
7. repeat steps 4,5,6 if no solution found yet.
For your particular problem, there are over 50,000 hits. Now only two possibilities remain:
A. some of those contain a decent answer; problem solved.
B. they all repeat the problem without offering the solution; it is therefore safe to assume nobody knows the answer, so don't waste your time and ours, go do something completely different instead.
Good luck.
|
|
|
|
|
Sorry, but this is the worst advice I can imagine. 
Do NOT search google! SOLVE the problem! And don't crib...
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
gajatko wrote: Do NOT search google! SOLVE the problem!
I agree. But there is nothing wrong with researching the problem on google for the sake of better clarity or understanding of the problem, but using google just to find an answer to the problem is a whole different matter.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Thanks. BTW I think that a glass of wine helps more than hours spent on googling around.
After this pointless and amazing[^] discusion, I'll try to finally figure out the thing. 
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
gajatko wrote: After this pointless and amazing[^] discusion, I'll try to finally figure out the thing.
I remember seeing that. Total 
I would like to figure it out, too, but I have other priorities 
gajatko wrote: BTW I think that a glass of wine helps more than hours spent on googling around.
Yup, any alcoholic beverage can be useful when researching 
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Nobody is going to do a homework problem for you - that defeats the entire point of homework. Homework is given to you so that you learn from it. Having somebody else hand you the answer is not learning. In fact, soliciting answers like this is equivalent to plagiarism because you basically hand in someone else's work. Plagiarism is a serious offense in most educational institutions.
That having been said, it is okay to ask for help when you have demonstrated some effort and are stuck on a particular aspect of the problem and its solution. So, if that is the case, you should discuss your work so far and point out the specific issue you are struggling with. You will receive much more constructive responses using that approach.
|
|
|
|
|
73Zeppelin wrote: Plagiarism is a serious offense in most educational institutions.
I second that. Saw a guy one time who got caught cheating on a test in the class before my class, and the instructor really laid down the law on him.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
You already have a clue: a rotating halfline. I'd try to represent the points in polar coordinates with P as a centre, then sort them by angles and do something with it.
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
At last a sensible reply! The original question as phrased was out of order sure but perhaps the guy doesn't have a clue where to start asking how to do this, perhaps its difficult phrasing the question in a second language.
Why not just offer some advice as Gajatko has done and try to stimulate a discussion instead of simply ranting about homework blah blah blah. It always sounds to me like you all have a massive chip on the shoulders - nobody ever helped you with your homework is that it?
Nice one Gajatko
Apathy Rules - I suppose...
Its not the things you fear that come to get you but all the things that you don't expect
|
|
|
|
|
Imagine the following interactive mathematical application:
- the data loaded in the application is split in two different 'types'
- the first type, let's call it the 'interactive' side of the application, contains data that is manipulated (added, deleted, changed, ...) by the user. It's effect on other data can be immediately calculated and we can quite easily determine which parts of the screen needs to be redrawn to make the screen back consistent
- the second type, let's call it the 'constraint' side of the application, contains data that is less frequently manipulated by the user. But if it is manipulated, it could have an impact on any element of the 'interactive' side.
The problem is that there is no one-to-one relation between elements in the 'constraints' side and elements in the 'interactive' side. If we want to show the user an always-up-to-date 'interactive' view, certain complex calculations are needed which can easily take up several minutes.
My current approach is to disable the 'interactive' side from the moment anything is changed on the 'constraint' side. The user can then continue to work on the 'constraint' side, but if he wants to go back to the 'interactive' side of the application, he will have to perform a full recalculation.
Result: a slow, but always consistent application (regarding the 'interactive' side).
The alternative could be to keep the 'interactive' side enabled while the user is changing elements in the 'constraint' side. Often the user can know what the impact is of his changes on the 'interactive' side and simply pressing F5 on the correct cell in the interactive grid can then calculate the effects from the 'constraint' side to that specific cell of the 'interactive' side.
Result: a faster, but not always consistent application, meaning the user could draw conclusions from incorrect values.
Does anyone of you have an application with a similar problem (choosing between slow and consistent or fast and inconsistent)? Any tips on how to have a fast(er) application with still having a quite good data consistency in the 'interactive' side?
Thanks in advance for your tips.
Enjoy life, this is not a rehearsal !!!
|
|
|
|
|
Hi,
First of all I would not mind if you were to give a more concrete description of your app...
Second, IMO if the app, due to changes in the constraints, is going to modify the interactive fields, then those fields must be disabled (or even hidden) for as long as they are unstable. It is completely unacceptable to have the user enter data and later find out it gets modified or even deleted automatically after a while.
Finally if a calculation takes minutes, it is a candidate for optimization. No one wants to wait any longer than necessary in front of a screen.
|
|
|
|
|
I'm afraid that's almost all the information I can give without going into the gory details.
The problem is that in many cases, if the user changes constraint X it only has an impact on interactive field Y, and in 90% of the cases, the user knows this, but the application doesn't.
The application can only know this after performing a global consistency check, which can take several minutes, due to the use of complex mathematical formulas.
Compare this with pivot tables in Excel. Changing the slightest value in a sheet may invalidate a cell in the pivot table.
Excel doesn't automatically recalculate the whole pivot table because it probably takes too much time, but in practice and in most cases the user could know what the exact effect is, and live without a pivot table that is not necessarily up-to-date.
Enjoy life, this is not a rehearsal !!!
|
|
|
|
|
You need to identify the dependencies between data elements in the interactive side and elements in the constraint side. Then when a constraint element is changed, you only update the interactive-side data which is dependent on it.
This structure has been studied in Artificial Intelligence for some time. The main references are:
Doyle, J., "A Truth Maintenance System," Artificial Intelligence 12 (1979) 231-272.
de Kleer, J., "An Assumption-Based TMS," Artificial Intelligence 28 (1986), 127-162.
|
|
|
|
|
|
You're not uniformly sampling the entire space, thats why there "seems" to be a bias to one area in your image - you should not be using an exponential distribution.
the crux of the inner-loop of the algorithm is:
loop begin:
random_point = select_uniformly_random_point_from(minx,miny,maxx,maxy);
nearest_point_in_graph = nearest(Graph,random_point);
new_point = nearest_point_in_graph + deltaQ |nearest_point_in_graph - random_point|
add_to_graph(Graph,nearest_point_in_graph,new_point);
loop end
yours does't look like that at all.
Note:
1. The routine "select_uniformly_random_point_from", when plotting the points its selects should look similar to this image: http://www.codeproject.com/KB/recipes/Wykobi/wykobi_randpntsaabb.png[^] if it doesn't then you have a problem.
2. this statement "new_point = nearest_point_in_graph + deltaQ |nearest_point_in_graph - random_point|" looks something like this in code:
new_point.x = nearest_point_in_graph.x + deltaQ |nearest_point_in_graph.x - random_point.
new_point.y = nearest_point_in_graph.y + deltaQ |nearest_point_in_graph.y - random_point.y|
3. Don't mix graphical or GUI aspects with computational code, its generally considered bad practice.
|
|
|
|
|
Don't cross post. You've posted this same thing in four different forums. 
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
I've been working on improving my Sieve of Eratosthenes routine ever since I first had to write one in Pascal way back in college (well, not constantly), always trying to reach a higher maximum. I just got around to writing one in C#.
I was reading up on Wheel Factorization (at least the type described on Wikipedia) as a way to extend my reach while using the same amount of memory. It turns out that, because I consider only the odd integers, I am already using a simple form of Wheel Factorization. Now I'm interested in getting to the next step, but I'm stumped by the statement:
"
The remaining numbers in the wheel contain mostly prime numbers. Use other methods such as Sieve of Eratosthenes to remove the remaining non-primes.
" -- Wikipedia
When I look at the example given, I don't see how Sieve of Eratosthenes can be successfully applied to each spoke separately. It appears I have to allocate memory for all the spokes I need to check (1 and 5) and sieve them concurrently, which won't extend the range (for a given amount of memory) as much as I was hoping.
Let's say I want to allocate only enough memory for twelve flags.
(1) With a one-spoke wheel we get the classic Sieve:
1 2 3 4 5 6 7 8 9 10 11 12
(2) But we know we don't need to check the even numbers, so we can use those twelve flags to represent only the odd numbers and thereby double our reach:
1 3 5 7 9 11 13 15 17 19 21 23
(3) If we use a fully-allocated two-spoke wheel we still only reach 12, which gains us nothing:
1 3 5 7 9 11
2 4 6 8 10 12
(4) But we don't need to allocate spoke 2, so we can use that memory to double our reach:
1 3 5 7 9 11 13 15 17 19 21 23
2 4 6 8 10 12 14 16 18 20 22 24 << not allocated
It should be apparent that (4) is equivalent to (2), notice that the sieve can successfully be applied to spoke 1.
(5) When we get to a 6-spoke wheel we can have it fully-allocated, which is little better than (3):
1 7
2 8
3 9
4 10
5 11
6 12
(6) Or, preferably, only allocate one spoke at a time as I did in (4):
1 7 13 19 25 31 37 43 49 55 61 67
2 8 14 20 26 32 38 44 50 56 62 68 << not allocated
3 9 15 21 27 33 39 45 51 57 63 69 << not allocated
4 10 16 22 28 34 40 46 52 58 64 70 << not allocated
5 11 17 23 29 35 41 47 53 59 65 71 << to be allocated later
6 12 18 24 30 36 42 48 54 60 66 72 << not allocated
In theory, this will extend the reach by a factor of six; in practice it won't, because 25 and 55 appear in spoke 1 while their factors are in spoke 5.
Unlike (4) we can't successfully apply Sieve of Eratosthenes to each spoke separately.
(7) So we have to allocate both spoke 1 and spoke 5, yielding only a tripling of our reach:
1 7 13 19 25 31
2 8 14 20 26 32 << not allocated
3 9 15 21 27 33 << not allocated
4 10 16 22 28 34 << not allocated
5 11 17 23 29 35
6 12 18 24 30 36 << not allocated
And then we have to be able to apply Sieve of Eratosthenes to both spokes concurrently. Which is where I'm at now.
I see how it can be done, but I suspect that the calculations involved may not be worth the trouble.
Have any of you done this?
|
|
|
|
|
Hi PIEBALD,
PIEBALDconsult wrote: Have any of you done this?
no I have not done sieves for a long time. I have done some large prime stuff, where simple sieves are not appropriate.
Wheel sieves become effective only if you use several primes at once, so do not use just 2 and 3 to get 2 spokes out of 6; instead use say 2, 3, 5, 7, 11, 13, 17 and notice you will have a large number of spokes (equal to the product of the primes used, hence more than 1000) of which most don't need to be allocated.
The aim of the wheel stuff is to reduce memory needs, hence extending the possible range for a given
memory footprint; when implemented appropriately, I expect it to be somewhat faster than a regular sieve with the same range, since a number of divisions/remainder operations are avoided, at the expense of some bookkeeping code. Unfortunately the missing spokes correspond mopstly to the most obvious non-primes, those that are recognized easily since they fail one or more of the very early division tests (with low divisors such as 2, 3, 5...) , so it is essentially the cheapest non-primes that get skipped, resulting in a modest cycles gain; the memory gain however is significant.
One optimization aspect is about how to store the spokes; they should aim for a good locality of data
(hence reusing data that is already in cache), while not causing cache trashing, so if each spoke were an array, don't give array dimensions that are powers of 2, but rather go for some strange value (a prime is often a good choice for array sizes) in this respect.
Once you got the spoke logic correct and efficient, you can easily experiment and enlarge the collection of basic primes, yielding more spokes, and more cycles gained. You then can research the optimal set of spoke primes as a function of available memory...
Enjoy!
|
|
|
|
|
Luc Pattyn wrote: Once you got the spoke logic correct and efficient, you can easily experiment and enlarge the collection of basic primes
Right, that's where I'm at. And it looks like the tactic that seemed to work with six spokes won't work with thirty spokes so it's not a general solution. 
|
|
|
|
|
PIEBALDconsult wrote: won't work with thirty spokes
So it seems a change of tactics is what you need.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
