P3337r0

.github/workflows/latex.yml

@@ -16,7 +16,7 @@ jobs:
           submodules: recursive
 
       - name: Compile LaTeX document
-        uses: xu-cheng/latex-action@v3
+        uses: xu-cheng/latex-action@v4
         with:
           root_file: |
             D3126_Overview.tex

D3126_Overview/tex/config.tex

@@ -14,3 +14,18 @@
 %% Library chapters
 %% \newcommand{\firstlibchapter}{language.support}
 %% \newcommand{\lastlibchapter}{thread}
+
+%% Example: Override default authors for this paper
+%% \renewcommand{\paperauthors}{
+%% &Custom Author (Special Institution)\\
+%% &\href{mailto:custom@example.com}{\nolinkurl{custom@example.com}}\\
+%% &Another Author\\
+%% &\href{mailto:another@example.com}{\nolinkurl{another@example.com}}\\
+%% }
+
+%% Example: Add to default contributors for this paper
+%% \renewcommand{\papercontributors}{%
+%% \defaultcontributors\\
+%% &Special Contributor for Overview Paper\\
+%% &Additional Expert%
+%% }

D3126_Overview/tex/overview.tex

@@ -35,9 +35,8 @@ \section{Overview}
 \section{Goals and Priorities}
 
 The main goal of this library is to provide a self-consistent and systematic library of software components for
-graph computations, based on well-defined graph representations. it includes generic 
-algorithms, named requirements, views, and utilities.
-views.  
+graph computations, based on well-defined graph representations. It includes generic 
+algorithms, named requirements, views, and utilities.  
 %
 It is informed by the authors' past experience with the Boost Graph Library (BGL), the NWGraph library, the C++
 GraphBLAS, and the library proposed in P1709.  The proposed library seeks to leverage the existing Standard
@@ -168,7 +167,7 @@ \section{What this proposal is  \textbf{not}}
 \section{Impact on the Standard}
 This proposal is a pure \textbf{library} extension.
 
-\section{Interaction wtih Other Papers}
+\section{Interaction with Other Papers}
 The entirety of our proposal for graph algorithms and data structures comprises multiple companion papers: D3127 (Terminology), D3128 (Algorithms), D3129 (Views), D3130 (Container Interface), D3131 (Containers), D9903 (Operators), and D9907 (Adaptors).
 Other than these papers, there are no interactions with other proposals to the standard.
 
@@ -190,7 +189,7 @@ \section{Prior Art}
 \textbf{boost::graph} has been an important C++ graph implementation since 2001. It was developed with the goal of providing
 a modern (at the time) generic library that addressed all the needs of a graph library user. It is still a viable library used today, attesting to the value it brings.
 
-However, boost::graph was written using C++98 in an ``expert-friendly'' style, adding many abstractions and using sophisticated tempate metaprogramming, making it difficult to use by a casual developer.  Particular pain-points described in ad-hoc discussions with users  include: property maps, parameter-passing, visitors.
+However, boost::graph was written using C++98 in an ``expert-friendly'' style, adding many abstractions and using sophisticated template metaprogramming, making it difficult to use by a casual developer.  Particular pain-points described in ad-hoc discussions with users  include: property maps, parameter-passing, visitors.
 
 \medskip
 
@@ -199,7 +198,7 @@ \section{Prior Art}
 that was more accessible to the average developer. % with the latest algorithms.
 
 While NWGraph made important strides to introduce the idea of an adjacency list as a range-of-ranges and implemented many important algorithms,
-there are some areas it didn't address that come a practical use in the field. For instance, it didn't have a well-defined API for graph
+there are some areas it didn't address that are of practical use in the field. For instance, it didn't have a well-defined API for graph
 data structures that could be applied to existing graphs, and there wasn't a uniform approach to properties.
 
 This proposal takes the best of NWGraph, with previous work done for P1709 to define a Graph Container Interface, to provide a library that
@@ -271,7 +270,7 @@ \section{Namespaces}
 \item[]\tcode{std::ranges/graph}, \tcode{std::ranges::graph::views} and \tcode{std::ranges::graph::edgelist}
 \end{itemize}
 The advantage of these two options are that there would be no requirement to use the ranges:: prefix for things
-in the std::ranges namespace, a common occurance.
+in the std::ranges namespace, a common occurrence.
 
 \section{Notes and Considerations}
 There are some interesting observations that can be made about graphs and how they compare and contrast to the 
@@ -298,7 +297,7 @@ \section{Notes and Considerations}
 \end{itemize}
 
 The addition of concepts to the standard library is a serious consideration because, once added, they cannot 
-be removed. We believe that adjacency lists as a range-of-ranges merits the addition new concepts but we recognize that it
+be removed. We believe that adjacency lists as a range-of-ranges merits the addition of new concepts but we recognize that it
 may be a controversial decision. Toward that end, we will continue to include them to help clarify the examples given
 and are assumed to be "For exposition only" as suggested implementation until a clear decision to include them, or not, 
 is made.

D3127_Terminology/tex/terminology_0.tex

@@ -85,7 +85,7 @@ \subsection{Graph Representation: Enumerating the Vertices}
 We summarize some remaining terminology about vertices and edges.
 \begin{itemize}
 \item 
-An edge $e_k$ may  be \emph{directed}, denoted as the ordered pair $e_k=(v_i, v_j)$, or it may be
+An edge $e_k$ may be \emph{directed}, denoted as the ordered pair $e_k=(v_i, v_j)$, or it may be
   \emph{undirected}, denoted as the (unordered) set $e_k=\{v_i, v_j\}$.  The edges 
 in $E$ are either all directed or all undirected,
   corresponding respectively to a \emph{directed graph} or to an \emph{undirected} graph.
@@ -390,7 +390,7 @@ \section{Bipartite Graphs}
 %
 Thus, a graph, as we have defined it, cannot model the IMDB.  
 
-There is a small generalization we can make to the definition of graph that will result in a suitable abstraction for modeling the IMDB.  In particular, we need one set of vertices corresponding to actors, another set of vertices corresponding to movies, and then a set of edges corresponding to the relationships between actors and movies.  There are two kinds of relationships to consider actors in movies or movies starring actors.  To be well-defined, the edge set may only contain one kind of relationship.  To capture this kind of model, we define a \emph{structurally bipartite graph} $H = \{ U, V, E \}$, where vertex sets $U$ and $V$ are enumerated $U = \{ u_0, u_1, \ldots , u_{n0} \}$ and $V  = \{ v_0, v_1, \ldots v_{n1}\}$, 
+There is a small generalization we can make to the definition of graph that will result in a suitable abstraction for modeling the IMDB.  In particular, we need one set of vertices corresponding to actors, another set of vertices corresponding to movies, and then a set of edges corresponding to the relationships between actors and movies.  There are two kinds of relationships to consider: actors in movies or movies starring actors.  To be well-defined, the edge set may only contain one kind of relationship.  To capture this kind of model, we define a \emph{structurally bipartite graph} $H = \{ U, V, E \}$, where vertex sets $U$ and $V$ are enumerated $U = \{ u_0, u_1, \ldots , u_{n0} \}$ and $V  = \{ v_0, v_1, \ldots v_{n1}\}$, 
 and the edge set $E$ consists of pairs $(u_i, v_j)$ where $u_i$ is in $U$ and $v_j$ is in $V$.
 
 The \emph{adjacency matrix representation of a structurally bipartite graph} is
@@ -404,7 +404,7 @@ \section{Bipartite Graphs}
  \end{array}
  \right.
  \]
-From this adjacency matrix representation we can readily construct  coordinate and compressed sparse representations.  The only structural difference between the representations of a structurally bipartite graph and that of a unipartite graph is that of vertex cardinality.  That is, in a unipartite graph, edges map from $V$ to $V$, and hence the values in the left hand column and in the right hand column of a coordinate representation would be in the same range: $[0, |V|)$.  However, for a structurally bipartite graph, this is no longer the case.  Although the coordinate representation still consists of pairs of vertex indices, the range of values in the left hand column is $[0, |U|)$, while in the right hand column it is $[0, |V|)$.  Similarly, the compressed representation will have $|U|$ entries, but the values stored in each entry may range from $[0, |V|)$.  We note that these are constraints on values, not on structure.
+From this adjacency matrix representation we can readily construct coordinate and compressed sparse representations.  The only structural difference between the representations of a structurally bipartite graph and that of a unipartite graph is that of vertex cardinality.  That is, in a unipartite graph, edges map from $V$ to $V$, and hence the values in the left hand column and in the right hand column of a coordinate representation would be in the same range: $[0, |V|)$.  However, for a structurally bipartite graph, this is no longer the case.  Although the coordinate representation still consists of pairs of vertex indices, the range of values in the left hand column is $[0, |U|)$, while in the right hand column it is $[0, |V|)$.  Similarly, the compressed representation will have $|U|$ entries, but the values stored in each entry may range from $[0, |V|)$.  We note that these are constraints on values, not on structure.
 
 
 \begin{figure}[ht]
@@ -474,9 +474,9 @@ \section{Partitioned Graphs}
 
 % These are definitely already covered in the examples above.
 % \subsection{From Edge List to Adjacency List}
-% \andrew{Scan edge list and insert edgest into adjacency list.  Adjacency list must support insertion.}
+% \andrew{Scan edge list and insert edges into adjacency list.  Adjacency list must support insertion.}
 % \subsection{Edge List and Adjacency List: Compressed Edge List}
-% \andrew{Using a sort and group-by (or a sort, a run-length encoding, and a scan), we can compactify the edge-list reprentation and at the same time obtain an adjacency-list representation -- one that is memory and compute efficient.  Best of both worlds.  Has same basic structural principles as CSR / CSC matrices in linear algebra -- but much more general.}
+% \andrew{Using a sort and group-by (or a sort, a run-length encoding, and a scan), we can compactify the edge-list representation and at the same time obtain an adjacency-list representation -- one that is memory and compute efficient.  Best of both worlds.  Has same basic structural principles as CSR / CSC matrices in linear algebra -- but much more general.}
 
 \section{Regarding Algorithms}
 
@@ -599,7 +599,7 @@ \section{Graphs and Sparse Matrices}
 A sparse matrix can be considered as a structurally bipartite graph representation.  Suppose that we have a sparse matrix $A$ represented as $\{(i, j, a_{ij})\}$.  We can create a structurally bipartite  $J = \{U, V, E\}$ such that $(i,j)$ is in $E$ if and only if $\{(i, j, a_{ij})\}$ is in $A$.  The coordinate and compressed representations for a sparse matrix are the same as for the graph (and, in fact, the terminology ``coordinate'' and ``compressed sparse'' originate in sparse numerical linear algebra).  For a matrix, the sets $U$ and $V$ have a particular meaning.  Either the indices of $U$ consist of row numbers and $V$ of column numbers, or vice versa.  In the former case, a compressed representation is known as ``compressed sparse row.''  In the latter case, it is known as ``compressed sparse column.''
 
 \andrew{This code is from nwgraph, need to bring it up to std::graph}
-The following code snippet illustrates a sparse matrix vector product when a compressed adjacency representation  is interpreted as a compressed sparse row matrix.
+The following code snippet illustrates a sparse matrix vector product when a compressed adjacency representation is interpreted as a compressed sparse row matrix.
 \begin{lstlisting}[language=C++]
   for (auto&& [row, u_neighbors] : make_neighbor_range(graph)) {
     for (auto&& [col, val] : u_neighbors) {

D3128_Algorithms/tex/algorithms.tex

@@ -76,7 +76,7 @@ \subsection{Other Algorithms}
 Additional algorithms that were considered but not included in this proposal are shown in Table \ref{tab:other_algorithms}. 
 Tier X algorithms are variations of shortest paths algorithms that complement the Single Source, Multiple Target algorithms 
 in this proposal.
-It is assumed that future proposals will include them, thought the exact mix for each proposal will depend on feedback received
+It is assumed that future proposals will include them, though the exact mix for each proposal will depend on feedback received
 and our experience with the current proposal.
 
 \phil{We may want to revisit the Driver idea in the future after we have more algorithms.}
@@ -114,7 +114,7 @@ \subsection{Other Algorithms}
 \end{center}
 \end{table}
 
-\andrew{All Pairs: Tier 2?  People bring this up alot -- but it is very expensive in terms of computation and memory.}
+\andrew{All Pairs: Tier 2?  People bring this up a lot -- but it is very expensive in terms of computation and memory.}
 \phil{If it's useful to enough people it should be included. Users can make their own determination of whether they want to use it, based on the cost.}
 
 \phil{The same variations for Shortest Paths algorithms can also be useful for topological sort.}
@@ -510,7 +510,7 @@ \subsection{Initialization}
             \begin{itemize}
                   \item \lstinline{shortest_path_infinite_distance()} returns the largest distance value,
                         typically \lstinline{numeric_limits<DistanceValue>::max()} for numeric types.
-                  \item \lstinline{shortest_path_zero()} returns a value for for a zero-length path,
+                  \item \lstinline{shortest_path_zero()} returns a value for a zero-length path,
                         typically \lstinline{0} for numeric types.
             \end{itemize}
 \end{itemdescr}
@@ -762,7 +762,7 @@ \subsubsection{Bellman-Ford Shortest Paths}
       %\pnum\result
       \pnum\returns 
             \begin{itemize}
-                  \item \lstinline{optional<vertex_id_t<G>} If no negative weight cycle is found, 
+                  \item \lstinline{optional<vertex_id_t<G>>} If no negative weight cycle is found, 
                         there is no associated vertex id. If a negative weight cycle is found, a
                         vertex id in the cycle is returned. \lstinline{find_negative_cycle}
                         can be called to get the vertex ids of the cycle.
@@ -824,10 +824,10 @@ \subsubsection{Bellman-Ford Shortest Distances}
       %\pnum\result
       \pnum\returns 
             \begin{itemize}
-                  \item \lstinline{optional<vertex_id_t<G>} If no negative weight cycle is found, 
+                  \item \lstinline{optional<vertex_id_t<G>>} If no negative weight cycle is found, 
                         there is no associated vertex id. If a negative weight cycle is found, a
                         vertex id in the cycle is returned. \lstinline{bellman_ford_shortest_paths} must be used
-                        to get the predecessors if it is importantant to get the vertex ids of the cycle
+                        to get the predecessors if it is important to get the vertex ids of the cycle
                         using \lstinline{find_negative_cycle}.
             \end{itemize}
       \pnum\complexity $\mathcal{O}(|E| \cdot |V|)$. Complexity may also be affected when visitor events are called. \\
@@ -1162,7 +1162,7 @@ \subsection{Connected Components}
                   \item
                         \lstinline{component[v]} is the connected component id of vertex \lstinline{v}.
                   \item
-                        There is at least one Connected Component, with compondent id of \lstinline{0}, for \lstinline{num_vertices(g) > 0}.
+                        There is at least one Connected Component, with component id of \lstinline{0}, for \lstinline{num_vertices(g) > 0}.
             \end{itemize}
       %\pnum\result
       %\pnum\returns
@@ -1497,7 +1497,7 @@ \subsection{Prim Minimum Spanning Tree}
                   \item
                         \lstinline{size(weight) >= to num_vertices(g)}.
                   \item
-                        \lstinline{size(predecessor >= to num_vertices(g)}.
+                        \lstinline{size(predecessor) >= num_vertices(g)}.
             \end{itemize}
       \pnum\effects
             \begin{itemize}

D3129_Views/tex/revision.tex

@@ -13,7 +13,7 @@ \subsection*{\paperno r1}
             The range returned by \tcode{edgelist_view} adheres to the \tcode{basic_sourced_index_edgelist} concept,
             and to the \tcode{has_edge_value} concept if a \tcode{evf(uv)} function is passed. The same applies to
             all \textit{sourced} versions of the BFS, DFS and Topological Sort views.
-      \item Restore the allocator parameters on the DFS, BFS and Toplogical Sort views, based on feedback and 
+      \item Restore the allocator parameters on the DFS, BFS and Topological Sort views, based on feedback and 
             by SG14/SG19 joint meeting.
       \item Add a note that we will be unable to support a freestanding graph library in this proposal because
             of the need for \tcode{stack}, \tcode{queue} and potential \tcode{bad_alloc} exception in many of 

D3129_Views/tex/views.tex

@@ -24,7 +24,7 @@ \section{Introduction}
 %
 
 The views in this paper provide common ways that algorithms use to traverse graphs. They are a simple as iterating 
-through the set of vertices, or more complex ways such as depth-first search and breadth-first search. The also 
+through the set of vertices, or more complex ways such as depth-first search and breadth-first search. They also 
 provide a consistent and reliable way to access related elements using the View Return Types, and guaranteeing expected 
 values, such as that the target is really the target on unordered edges.
 
@@ -87,7 +87,7 @@ \subsection{\tcode{struct vertex_info<VId, VV>}}\label{vertex-view}\mbox{} \\
      \lstinputlisting{D3129_Views/src/vertex_info.hpp}
 }
 
-Specializations are defined with \tcode{V=void} or \tcode{VV=void} to suppress the existance of their associated member variables, 
+Specializations are defined with \tcode{V=void} or \tcode{VV=void} to suppress the existence of their associated member variables, 
 giving the following valid combinations in Table \ref{tab:vertex-view} . For instance, the second entry, \tcode{vertex_info<VId, void>} 
 has one member \tcode{\{vertex_type vertex;\}} and \tcode{value_type} is \tcode{void}.
 \begin{table}[h!]
@@ -123,7 +123,7 @@ \subsection{\tcode{struct edge_info<VId, Sourced, E, EV>}}\label{edge-view}\mbox
      \lstinputlisting{D3129_Views/src/edge_info.hpp}
 }
 
-Specializations are defined with \tcode{Sourced=true|false}, \tcode{E=void} or \tcode{EV=void} to suppress the existance of the associated 
+Specializations are defined with \tcode{Sourced=true|false}, \tcode{E=void} or \tcode{EV=void} to suppress the existence of the associated 
 member variables, giving the following valid combinations in Table \ref{tab:edge-view} . For instance, the second entry, 
 \tcode{edge_info<VId,true,E>} has three members \tcode{\{source_id_type source_id; target_id_type target_id; edge_type edge;\}} 
 and \tcode{value_type} is \tcode{void}.
@@ -161,7 +161,7 @@ \subsection{\tcode{struct neighbor_info<VId, Sourced, V, VV>}}\label{neighbor-vi
      \lstinputlisting{D3129_Views/src/neighbor_info.hpp}
 }
 
-Specializations are defined with \tcode{Sourced=true|false} or \tcode{EV}=void to suppress the existance of the 
+Specializations are defined with \tcode{Sourced=true|false} or \tcode{EV}=void to suppress the existence of the 
 associated member variables, giving the following valid combinations in Table \ref{tab:neighbor-view} . For instance, the second entry, 
 \tcode{neighbor_info<V,true>} has two members \tcode{\{source_type source; target_type target;\}} 
 and \tcode{value_type} is \tcode{void}.
@@ -363,7 +363,7 @@ \subsection{Common Types and Functions for ``Search'' }
 };
 
 // stop searching from current vertex
-template<class S)
+template<class S>
 void cancel(S search, cancel_search);
 
 // Returns distance from the source vertex to the current vertex,