Date: Fri, 14 Apr 2023 09:34:49 +0200
On 13/04/2023 22.54, Oliver Rosten via SG19 wrote:
> Hi folks,
>
> Further to today's meeting I wanted to add a further thought about standardizing explicitly named algorithms, such as Dijksrta's.
>
> To recap:
>
> 1. I expressed worry with this direction as I think we should be standardizing what algorithms do, rather than how they do it. I drew an analogy with sort and stable_sort: this is what is standardized, not quick_sort, merge_sort etc. Therefore, my preference is the shortest_path 'driver' approach.
>
> 2. A counter-argument was given that users may wish to specify a particular algorithm since e.g. Dijkstra's is inappropriate if there are negative weights.
>
> That's pretty much where we left it at the meeting.
>
> However, I think what point 2 is really highlighting is that the shortest_path 'driver' algorithm should be sufficiently flexible to disambiguate things like this (and this is true regardless of whether there are explicitly named alternatives). For example, I could imagine an overload set with a tag parameter indicating whether there are negative weights.
Agreed with the general idea, but please let's not have overload sets
with tag parameters if we're not dealing with a constructor and we're
not dealing with an open-ended set of possibilities.
It's "sort" and "stable_sort", thus it should be "shortest_path_positive_weights"
and "shortest_path" (details of names tbd), i.e. functions are differentiated by name.
Jens
> Hi folks,
>
> Further to today's meeting I wanted to add a further thought about standardizing explicitly named algorithms, such as Dijksrta's.
>
> To recap:
>
> 1. I expressed worry with this direction as I think we should be standardizing what algorithms do, rather than how they do it. I drew an analogy with sort and stable_sort: this is what is standardized, not quick_sort, merge_sort etc. Therefore, my preference is the shortest_path 'driver' approach.
>
> 2. A counter-argument was given that users may wish to specify a particular algorithm since e.g. Dijkstra's is inappropriate if there are negative weights.
>
> That's pretty much where we left it at the meeting.
>
> However, I think what point 2 is really highlighting is that the shortest_path 'driver' algorithm should be sufficiently flexible to disambiguate things like this (and this is true regardless of whether there are explicitly named alternatives). For example, I could imagine an overload set with a tag parameter indicating whether there are negative weights.
Agreed with the general idea, but please let's not have overload sets
with tag parameters if we're not dealing with a constructor and we're
not dealing with an open-ended set of possibilities.
It's "sort" and "stable_sort", thus it should be "shortest_path_positive_weights"
and "shortest_path" (details of names tbd), i.e. functions are differentiated by name.
Jens
Received on 2023-04-14 07:34:52