mirror of
https://github.com/graphhopper/jsprit.git
synced 2020-01-24 07:45:05 +01:00
prepare release - update whats_new
This commit is contained in:
parent
74e8912087
commit
f1cbf42d4e
1 changed files with 30 additions and 0 deletions
30
WHATS_NEW.md
30
WHATS_NEW.md
|
|
@ -3,14 +3,44 @@ WHATS NEW
|
|||
------------------------------
|
||||
<b>2014-03-??</b> new release **v1.6**
|
||||
|
||||
When reviewing the feedback from our users, we realized that jsprit cannot solve certain kinds of problems adequately.
|
||||
To illustrate and characterize them, look at the following examples.
|
||||
|
||||
jsprit, which was basically specific configurations of the schrimpf-algorithm was/is good and fast at solving this:
|
||||
|
||||

|
||||
|
||||
The algorithm results in what we expect by looking at the problem. Look at what happened when we add similar job-clusters
|
||||
between depot and the existing clusters.
|
||||
|
||||

|
||||
|
||||
Obviously, the way we ruined and recreated wasn't sufficient to solve the problem reasonably.
|
||||
To make it even more obvious, we added a number of job cloud surrounding
|
||||
the depot. The schrimpf-algorithm (as we configured it) yields the following solution.
|
||||
|
||||

|
||||
|
||||
This is definitely not the intuitive solution, one would expect when looking at the problem sharply.
|
||||
|
||||
Therefore, we put much effort into analysing this and designing a new algorithm (which is still based on the
|
||||
schrimpf principles). We implemented two new ruin strategies: worst and cluster ruin, and we added
|
||||
noise to the ruin and recreation strategies. Moreover, the new algorithm makes use of regretInsertion by default.
|
||||
On all benchmarking instances, our new algorithm performs better (or at least as good
|
||||
as) than the previous algorithms in terms of solution quality. However, it comes with higher computational costs.
|
||||
Look at how the new algorithm solves the above problem
|
||||
|
||||

|
||||
|
||||
which is the intuitive solution. Along with this we made a number of incremental changes to simplify the implementation
|
||||
which, in turn, makes your life easier when designing your own algorithm.
|
||||
|
||||
The second major improvement is that we changed the way locations are defined. Instead of separately assigning location-id and coordinates,
|
||||
we encapsulated these attributes in an object called Location. It is not only clearer, but it
|
||||
allows you to assign a location index. Thus, you can save the transport times and distances
|
||||
between locations in (fast) arrays rather than maps (see FastVehicleRoutingTransportCostMatrix).
|
||||
|
||||
|
||||
------------------------------
|
||||
<b>2014-12-12</b> new release **v1.5**
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue