Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong internal durations matrix with different location_index on same location #909

Closed
jcoupey opened this issue Mar 28, 2023 · 1 comment · Fixed by #912
Closed

Wrong internal durations matrix with different location_index on same location #909

jcoupey opened this issue Mar 28, 2023 · 1 comment · Fixed by #912
Labels
Milestone

Comments

@jcoupey
Copy link
Collaborator

jcoupey commented Mar 28, 2023

Say I have a simple instance like:

{
  "jobs": [
    {
      "id": 1,
      "location": [
        2.38403,
        48.88413
      ],
      "location_index": 1
    },
    {
      "id": 2,
      "location": [
        2.35862,
        48.84212
      ],
      "location_index": 2
    }
  ],
  "vehicles": [
    {
      "id": 1,
      "start": [
        2.29822,
        48.85116
      ],
      "start_index": 0
    }
  ],
  "matrices": {
    "car": {
      "costs": [
        [
          0,
          2,
          1
        ],
        [
          2,
          0,
          1
        ],
        [
          1,
          1,
          0
        ]
      ]
    }
  }
}

If I log the content of the durations matrix from Input::set_matrices, I get an expected:

0	2027	1291	
2087	0	1386	
1257	1343	0

Now if I add another job that has the same location as job 2 but a different location_index, such as:

    {
      "id": 3,
      "location": [
        2.35862,
        48.84212
      ],
      "location_index": 3
    }

then the durations matrix becomes:

0	2027	1291	0	
2087	0	1386	0	
1257	1343	0	0	
0	0	0	0

In other words, the size is correct in term of the number of total location_index values, but the additional row/column does not get filled. This is due to the fact that the matrix is computed based on Input::_locations (we use an indirection to go back to user-defined index values). But in case of custom location_index values, additional locations are only store here if they have a new coordinate.

A work-around to avoid hitting this problem is to make sure to re-use the same location_index value in case coordinates are identical. Which sounds like a good practice anyway.

@jcoupey jcoupey added the bug label Mar 28, 2023
@jcoupey
Copy link
Collaborator Author

jcoupey commented Apr 3, 2023

A simple way to fix this would be to not change the client code:

auto search = _locations_to_index.find(job.location);
if (search == _locations_to_index.end()) {
_locations.push_back(job.location);
_locations_to_index.insert(
std::make_pair(job.location, _locations.size() - 1));
} else {

but to make sure that considering a new Location with the same coordinates as an existing one but a different user-defined index value is not considered already present in _locations_to_index above. This could be achieved by adjusting the way Location objects are hashed.

@jcoupey jcoupey added this to the v1.14.0 milestone Apr 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant