Skip to content
New issue

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

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

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant