Date: Thu, 13 Jun 2024 15:57:01 -0400
On Wed, Jun 12, 2024 at 12:27 AM Michael Wong <fraggamuffin_at_[hidden]>
wrote:
> Hi, this SG19 meeting will focus on Graph Michael Wong is inviting
> you to a scheduled Zoom meeting.
>
> Topic: SG19 monthly
> Time: 2nd Thursdays 02:00 PM Eastern Time (US and Canada)
> Every month on the Second Thu,
>
>
> Join from PC, Mac, Linux, iOS or Android:
>
> https://iso.zoom.us/j/93084591725?pwd=K3QxZjJlcnljaE13ZWU5cTlLNkx0Zz09
> Password: 035530
>
> Or iPhone one-tap :
> US: +13017158592,,93084591725# or +13126266799,,93084591725#
> Or Telephone:
> Dial(for higher quality, dial a number based on your current location):
> US: +1 301 715 8592 or +1 312 626 6799 or +1 346 248 7799 or +1
> 408 638 0968 or +1 646 876 9923 or +1 669 900 6833 or +1 253 215 8782
> or 877 853 5247 (Toll Free)
> Meeting ID: 930 8459 1725
> Password: 035530
> International numbers available: https://iso.zoom.us/u/agewu4X97
>
> Or Skype for Business (Lync):
> https://iso.zoom.us/skype/93084591725
>
> Agenda:
>
> 1. Opening and introductions
>
> The ISO Code of conduct:
> https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100397.pdf
>
> IEC Code of Conduct:
>
> https://www.iec.ch/basecamp/iec-code-conduct-technical-work
>
> ISO patent policy.
>
>
> https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm?nodeid=6344764&vernum=-2
>
> The WG21 Practices and Procedures and Code of Conduct:
>
> https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures
>
> 1.1 Roll call of participants
>
Phil, Boguslaw, Guy, Oliver, Richard, Michael, ANdrew, Jens, Scott
>
>
> 1.2 Adopt agenda
>
> 1.3 Approve minutes from previous meeting, and approve publishing
> previously approved minutes to ISOCPP.org
>
> 1.4 Action items from previous meetings
>
> 2. Main issues (125 min)
>
> 2.1 General logistics
>
> Meeting plan, focus on one paper per meeting but does not preclude other
> paper
> updates.
>
> 2024 planning
> C++23 and C++26 status
> CPPCON 2024
>
Schedule for Graph to go out
June 24: St. Louis
July 11
Aug 15
Sept 12: exit vote
Sept 15-20 CPPCON meeting
OCt 10: exit vote, last chance
Nov 14: Not possible
2024-11-18 to 23: Wrocław, Poland
<https://isocpp.org/files/papers/N4974.pdf>; Nokia
else
2025-02-10 to 15: Hagenberg, Austria
<https://isocpp.org/files/papers/N4979.pdf>; University of Applied
Sciences, Upper Austria
>
> * Jan 11, 2024 02:00 PM ET: Graph DONE
> * Feb 8, 2024 02:00 PM ET: Graph DONE
> * Mar 14, 2024 02:00 PM ET: Cancelled due to Tokyo 3-18-23
> * Apr 11, 2024 02:00 PM ET: Stats/Graph DONE
> * May 9, 2024 02:00 PM ET: Graph DONE
> * June 13, 2024 02:00 PM ET: Graph; St.louis 6-24-29
> * July 11, 2024 02:00 PM ET: Stats
> * Aug 15, 2024 02:00 PM ET: Graph
> * Sep 12, 2024 02:00 PM ET: CPPCON Sept 15-20 so canceled
> * Oct 10, 2024 02:00 PM ET: Stats
> * Nov 14, 2024 02:00 PM ET: Cancelled Wroclaw F2F
> * Dec 12, 2024 02:00 PM ET: Graph
>
>
> ISO meeting status
>
> future C++ Std meetings
>
> 2.2 Paper reviews
>
SG6 feedback pre-St.Louis 2024:
Matthias Kretz
11:41 AM (2 hours ago)
to Phil, me, Lisa
Hi Phil,
sorry for picking this back up only now. But I reviewed P3131 and P3130
again
and still don't see anything *in the papers* that requires review by SG6.
You mention CSR in P3131, but if I understand correctly, the paper only uses
it as an implementation detail, not as a library facility exposed to C++
users. There may well be topics that warrant discussion in SG6, but I don't
see them written up. If there are topics/questions related to your papers
that
you want to raise in SG6, please put them in the paper(s). I find it
especially helpful if you paper points out the feedback you need and the
challenges that you believe need to be reviewed.
So for now I continue to believe that there is nothing for SG6 to review.
And
I don't mean the topic in general — I mean the specific papers.
I hope this helps,
Matthias
On Dienstag, 19. März 2024 23:38:33 MESZ Phil Ratzloff wrote:
> compressed_graph (P3131) is an extended version of a CSR matrix. The
purpose
> of the discussion is to see if this would be valuable in the context of
> numerics/mathematics. If so, someone would need to take that on and own it
> in collaboration with our effort.
>
> How it is presented would also need to be different than what I've done to
> date.
>
> compressed_graph extends the typical CSR matrix by supporting optional
> values for rows and the compressed_graph object itself. The API for the
> graph is defined as a set of functions that apply to all graphs, defined
in
> P3130.
>
> I took this approach to minimize the public interface of compressed_graph,
> as I know containers can take a long time to get through the Committee.
>
> If it were to be used for math-oriented features, I imagine there might
need
> to be member functions added, as well as mathematical algorithms that use
> it.
>
> Review BSI Graph feedback:
> As Oliver (Rosten) said "The basic premise is important, and it would be
> fantastic to have support for graphs in the standard."
>
> The main items identified were:
> Oliver:
> - This paper is long and incomplete, it has lots of details which I think
> to be irrelevant, however things that are definitely relevant are missing
> from the paper - for example definition of graph - since people have
> different ideas. We need to add a mathematical perspective to the paper.
>
> - The structure of the paper completely changed in the new revision, so now
> it’s hard to understand what and why they have done
>
> - Another missing part is discussion of graph invariants
>
> Tom (Deakin): There’s a big missing part in “Prior art” part, GraphBLAS (
> https://graphblas.org) eminently.
>
> Some other things to add:
>
> 1. The electrical circuit example needs more explanation, and I think this
> will highlight some deep issues around representing things which are
> seemingly trivially graphs, as graphs in practice. In what sense is a
> bog-standard resistor directed? I assume the reason that the graph is
> directed is because current has a sign and in an undirected graph it
> becomes ambiguous which way the current is flowing (also you may want
> components like diodes). But the directed representation also has issues:
> "can current flow from 'Vdd' to 'n0'?" should be immediately answerable
> from the properties of Vdd and its edges. There are other ways to represent
> an electrical circuit. One is as a directed graph but with incident edges
> recorded - but iiuc, this is excluded from the latest version of the paper.
> Alternatively, one could have a mathematical object, the name of which I
> actually don't know: it looks like an undirected graph, but where each
> partial edge has additional, unique, end-point data, as well as the common
> weight. Things like this are the reason why I think we need a broader group
> to look at this proposal (i.e. beyond SG19) and if we possibly can we
> should involve someone from the mathematics community. Otherwise there's a
> real danger we end up missing important insights.
>
> 2. My comment about the structure of the paper changing was a reference to
> previous comparisons with boost::graph. I'm sure these were in an earlier
> version, or am I misremembering? Either way, it would be very helpful to
> have a proper discussion of e.g. the move away from visitors.
>
> 3. Re. the definition of a graph, there needs to be a proper discussion
> about whether the paper's definition of graph is what some authors call a
> multigraph and whether it does/does not include loops. These things are
> mentioned, in passing, when introducing algorithms, but terminology needs
> to be properly established.
>
> 4. I think we're trying to do too much in one go in this paper. I think a
> great first step would be to build on mdspan and try to standardize (or at
> least understand) what might reasonably be called an unstructured span.
> This could be represented as a vector of vectors or as a vector with some
> auxiliary storage indicating where the partitions fall. The point is that
> an unstructured span, with the right invariants, is an adjacency list. If
> we can understand unstructured span and its desirable api, I think this
> will be incredibly valuable guidance for what a standardized graph
> container might look like.
>
> 5. IIUC, this paper excludes pure connectivity graphs. These are incredibly
> helpful and, if I've understood correctly that they are not supported,
> would be a major omission. Another good reason, imo, to start with
> unstructured span!
>
> 6. I'm not convinced by the load api. We don't have a load api for vector
> etc. Moreover, would it not be preferable to have appropriate constructors?
>
>
> 2.2.1: ML topics
>
> 2.2.1.1 Graph Proposal Phil Ratsloff et al
>
> D3127 terminology
Andrew presenting
pg 3: terminology can we claw back
4: rarely a distinction between graph and graph terminology
8: OR: add multiple edges (pair of nodes connected by 2 or more edges)
Figure 3 mentions instagram
This is an R1: should add a table of what is delta with R0
10: JM: partition graph: V should add vn1-1 looks wrong, so its 2 level of
subscripting so need to fix the latex
11: typo
12: OR: represent currents, flow networks, circuits, deserves mention of
direction of current or if it is positive or negative; library needs to
support it because it is difficult; not scope creep, but fundamental;
representing them is subtle
JM: disagree, can do route finding without flow network, is enough
AL+OR: need to work through examples to get the building blocks
JM: different dimension of design, flow network is not a good example to
explain these terms, use something else; do the flow network in another
paper
OR: disagree, the necessity of these terms is revealed by this paper; how
to categorize a structure for flow network
AL: we call it multigraph for flow network, not structural, cant enforce at
compile time
OR: direct representation vs adjacency lists should be separate, not
conflated; section 10. should not have adjacency list
JM: dont introduce arc now
OR: Pure connectivity has no representation; OK
AL: will remove circuit
Appendix:
OR: data to graph do we need this at all
AL: like to avoid the property map dependency; JM: not sure what the
abstraction layer is for Djkstra
PR: current abstraction is a concept of property on a graph, edge, vertex,
so tuple is property on the edge, inside algo there are multiple values,
caller to Djkstra knows which graph and provides a function to extract the
correct distance
AL: add a djkstra example
OR: start with vertex, list of edges, tuple of properties
what is the property referring to?
AL: property represents circuit element, the current, the conductance, that
is associated with the edge
PR: to make this compile, need a second argument on the vector
AL: yes I see
JM: vertex needs a template argument
OR dont like direct representation, it will be templated on vertex and edge
weight, vertex should not know edge weight; its not the cleanest design
AL: template on edge type? OK
JM: should this be super generic graph data structure
PR:P3131 has a definition for compressed graph
JM: template on edge and vertex wright and everyhting else is impl detail
PR: can reduce internal size of graph
OR: cover vector of vector
AL: should pass that into Djkstra
PR: now you can
OR: adjacency lists is unstructured, but there are large patches that are
structured, use template param to optimize these structures through
customization
PR: depends on who is creating the data structure; have range of ranges and
how you represent that range is upto you
impl is in P3131 and it is a CSR but there could be additional
PR: how customizable should it be; want to have 1 thats good, then more can
come later
JM: containers are complex to get through LEWG; how detail should the spec
be, or impl leeway
it should support all the algorithms in the paper but not arbitrary
PR: design to adapt existing containers
I am just providing are constructors, everything else use public interface
P303 are all CPO public fns, gives back a range
your own graph datastructure can override the CPOs
What about negative edges, cycles, DAG
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3126r1.pdf
contains the list of issues at bottom
Agree on a graph DS but does not preclude other algo; needs to be trimmed
down
another paper needed: Comparison of BGL with our Graph
> Latest paper:
>
> Here’s a link to the paper (different than the previous paper reviewed).
> There are some additional updates I’m planning on making before the
> meeting.
>
>
> https://docs.google.com/document/d/1OpH-xxRri7tJTtJJIZTYmSHkkrZJkdBwm9zJ7LqolfQ/edit?usp=sharing
>
>
>
>
> P1709R3:
>
> https://docs.google.com/document/d/1kLHhbSTX7j0tPeTYECQFSNx3R35Mu3xO5_dyYdRy4dM/edit?usp=sharing
>
>
> https://docs.google.com/document/d/1QkfDzGyfNQKs86y053M0YHOLP6frzhTJqzg1Ug_vkkE/edit?usp=sharing
>
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2119r0.html>
>
> <
>
> https://docs.google.com/document/d/175wIm8o4BNGti0WLq8U6uZORegKVjmnpfc-_E8PoGS0/edit?ts=5fff27cd#heading=h.9ogkehmdmtel
> *>*
>
> Array copy semantics:
> array copy-semantics paper P1997 "Relaxing Restrictions on Arrays",
> https://wg21.link/p1997
>
> Stats feedback:
>
> P1708:
Added ISO references
OR: Erroneous instead of unspecified as another alternative is more
specific and less ambiguous
> P2376R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2376r0.pdf>
> Comments
> on Simple Statistical Functions (p1708r4): Contracts, Exceptions and
> Special cases Johan Lundberg
>
> 2.2.1.2 Reinforcement Learning Larry Lewis Jorge Silva
>
> Reinforcement Learning proposal:
>
> 2.2.1.3 Differential Calculus:
>
>
> https://docs.google.com/document/d/175wIm8o4BNGti0WLq8U6uZORegKVjmnpfc-_E8PoGS0/edit?ts=5fff27cd#heading=h.9ogkehmdmtel
>
> 2.2.1.4: Stats paper
>
> P2681R0
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2681r0.pdf>
> More
> Stats Functions Richard Dosselmann, Michael Wong
> Current github
>
> https://github.com/cplusplus/papers/issues/475
>
> https://github.com/cplusplus/papers/issues/979
>
> Stats review Richard Dosselman et al
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1708r4.pdf
>
> Feedback from Johan Lundberg and Oleksandr Korval
>
> https://isocpp.org/files/papers/D2376R0.pdf
>
> P1708R3: Math proposal for Machine Learning: 3rd review
>
> PXXXX: combinatorics: 1st Review
>
> *> std.org/jtc1/sc22/wg21/docs/papers/2020/p1708r2
> <http://std.org/jtc1/sc22/wg21/docs/papers/2020/p1708r2>*
> *> above is the stats paper that was reviewed in Prague*
> *> http://wiki.edg.com/bin/view/Wg21prague/P1708R2SG19
> <http://wiki.edg.com/bin/view/Wg21prague/P1708R2SG19>*
> *>*
> *> Review Jolanta Polish feedback.*
> *> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2119r0.html
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2119r0.html>*
>
>
> 2.2.1.4: Matrix paper
>
> 2.2.3 any other proposal for reviews?
>
> 2.3 Other Papers and proposals
>
> P1416R1: SG19 - Linear Algebra for Data Science and Machine Learning
>
> https://docs.google.com/document/d/1IKUNiUhBgRURW-UkspK7fAAyIhfXuMxjk7xKikK4Yp8/edit#heading=h.tj9hitg7dbtr
>
> P1415: Machine Learning Layered list
>
> https://docs.google.com/document/d/1elNFdIXWoetbxjO1OKol_Wj8fyi4Z4hogfj5tLVSj64/edit#heading=h.tj9hitg7dbtr
>
> 2.2.2 SG14 Linear Algebra progress:
> Different layers of proposal
>
> https://docs.google.com/document/d/1poXfr7mUPovJC9ZQ5SDVM_1Nb6oYAXlK_d0ljdUAtSQ/edit
>
> 2.5 Future F2F meetings:
>
> 2.6 future C++ Standard meetings:
> https://isocpp.org/std/meetings-and-participation/upcoming-meetings
>
> None
>
> 3. Any other business
>
> New reflector
>
> http://lists.isocpp.org/mailman/listinfo.cgi/sg19
>
> Old Reflector
> https://groups.google.com/a/isocpp.org/forum/#!newtopic/sg19
> <https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!forum/sg14>
>
> Code and proposal Staging area
>
> 4. Review
>
> 4.1 Review and approve resolutions and issues [e.g., changes to SG's
> working draft]
>
> 4.2 Review action items (5 min)
>
> 5. Closing process
>
> 5.1 Establish next agenda
>
>
> 5.2 Future meeting
> * Jan 11, 2024 02:00 PM ET: Graph DONE
> * Feb 8, 2024 02:00 PM ET: Graph DONE
> * Mar 14, 2024 02:00 PM ET: Cancelled due to Tokyo 3-18-23
> * Apr 11, 2024 02:00 PM ET: Stats/Graph DONE
> * May 9, 2024 02:00 PM ET: Graph DONE
> * June 13, 2024 02:00 PM ET: Graph; St.louis 6-24-29
> * July 11, 2024 02:00 PM ET: Stats
> * Aug 15, 2024 02:00 PM ET: Graph
> * Sep 12, 2024 02:00 PM ET: CPPCON Sept 15-20 so cancelled
> * Oct 10, 2024 02:00 PM ET: Stats
> * Nov 14, 2024 02:00 PM ET: Cancelled Wroclaw F2F
> * Dec 12, 2024 02:00 PM ET: Graph
>
wrote:
> Hi, this SG19 meeting will focus on Graph Michael Wong is inviting
> you to a scheduled Zoom meeting.
>
> Topic: SG19 monthly
> Time: 2nd Thursdays 02:00 PM Eastern Time (US and Canada)
> Every month on the Second Thu,
>
>
> Join from PC, Mac, Linux, iOS or Android:
>
> https://iso.zoom.us/j/93084591725?pwd=K3QxZjJlcnljaE13ZWU5cTlLNkx0Zz09
> Password: 035530
>
> Or iPhone one-tap :
> US: +13017158592,,93084591725# or +13126266799,,93084591725#
> Or Telephone:
> Dial(for higher quality, dial a number based on your current location):
> US: +1 301 715 8592 or +1 312 626 6799 or +1 346 248 7799 or +1
> 408 638 0968 or +1 646 876 9923 or +1 669 900 6833 or +1 253 215 8782
> or 877 853 5247 (Toll Free)
> Meeting ID: 930 8459 1725
> Password: 035530
> International numbers available: https://iso.zoom.us/u/agewu4X97
>
> Or Skype for Business (Lync):
> https://iso.zoom.us/skype/93084591725
>
> Agenda:
>
> 1. Opening and introductions
>
> The ISO Code of conduct:
> https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100397.pdf
>
> IEC Code of Conduct:
>
> https://www.iec.ch/basecamp/iec-code-conduct-technical-work
>
> ISO patent policy.
>
>
> https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm?nodeid=6344764&vernum=-2
>
> The WG21 Practices and Procedures and Code of Conduct:
>
> https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures
>
> 1.1 Roll call of participants
>
Phil, Boguslaw, Guy, Oliver, Richard, Michael, ANdrew, Jens, Scott
>
>
> 1.2 Adopt agenda
>
> 1.3 Approve minutes from previous meeting, and approve publishing
> previously approved minutes to ISOCPP.org
>
> 1.4 Action items from previous meetings
>
> 2. Main issues (125 min)
>
> 2.1 General logistics
>
> Meeting plan, focus on one paper per meeting but does not preclude other
> paper
> updates.
>
> 2024 planning
> C++23 and C++26 status
> CPPCON 2024
>
Schedule for Graph to go out
June 24: St. Louis
July 11
Aug 15
Sept 12: exit vote
Sept 15-20 CPPCON meeting
OCt 10: exit vote, last chance
Nov 14: Not possible
2024-11-18 to 23: Wrocław, Poland
<https://isocpp.org/files/papers/N4974.pdf>; Nokia
else
2025-02-10 to 15: Hagenberg, Austria
<https://isocpp.org/files/papers/N4979.pdf>; University of Applied
Sciences, Upper Austria
>
> * Jan 11, 2024 02:00 PM ET: Graph DONE
> * Feb 8, 2024 02:00 PM ET: Graph DONE
> * Mar 14, 2024 02:00 PM ET: Cancelled due to Tokyo 3-18-23
> * Apr 11, 2024 02:00 PM ET: Stats/Graph DONE
> * May 9, 2024 02:00 PM ET: Graph DONE
> * June 13, 2024 02:00 PM ET: Graph; St.louis 6-24-29
> * July 11, 2024 02:00 PM ET: Stats
> * Aug 15, 2024 02:00 PM ET: Graph
> * Sep 12, 2024 02:00 PM ET: CPPCON Sept 15-20 so canceled
> * Oct 10, 2024 02:00 PM ET: Stats
> * Nov 14, 2024 02:00 PM ET: Cancelled Wroclaw F2F
> * Dec 12, 2024 02:00 PM ET: Graph
>
>
> ISO meeting status
>
> future C++ Std meetings
>
> 2.2 Paper reviews
>
SG6 feedback pre-St.Louis 2024:
Matthias Kretz
11:41 AM (2 hours ago)
to Phil, me, Lisa
Hi Phil,
sorry for picking this back up only now. But I reviewed P3131 and P3130
again
and still don't see anything *in the papers* that requires review by SG6.
You mention CSR in P3131, but if I understand correctly, the paper only uses
it as an implementation detail, not as a library facility exposed to C++
users. There may well be topics that warrant discussion in SG6, but I don't
see them written up. If there are topics/questions related to your papers
that
you want to raise in SG6, please put them in the paper(s). I find it
especially helpful if you paper points out the feedback you need and the
challenges that you believe need to be reviewed.
So for now I continue to believe that there is nothing for SG6 to review.
And
I don't mean the topic in general — I mean the specific papers.
I hope this helps,
Matthias
On Dienstag, 19. März 2024 23:38:33 MESZ Phil Ratzloff wrote:
> compressed_graph (P3131) is an extended version of a CSR matrix. The
purpose
> of the discussion is to see if this would be valuable in the context of
> numerics/mathematics. If so, someone would need to take that on and own it
> in collaboration with our effort.
>
> How it is presented would also need to be different than what I've done to
> date.
>
> compressed_graph extends the typical CSR matrix by supporting optional
> values for rows and the compressed_graph object itself. The API for the
> graph is defined as a set of functions that apply to all graphs, defined
in
> P3130.
>
> I took this approach to minimize the public interface of compressed_graph,
> as I know containers can take a long time to get through the Committee.
>
> If it were to be used for math-oriented features, I imagine there might
need
> to be member functions added, as well as mathematical algorithms that use
> it.
>
> Review BSI Graph feedback:
> As Oliver (Rosten) said "The basic premise is important, and it would be
> fantastic to have support for graphs in the standard."
>
> The main items identified were:
> Oliver:
> - This paper is long and incomplete, it has lots of details which I think
> to be irrelevant, however things that are definitely relevant are missing
> from the paper - for example definition of graph - since people have
> different ideas. We need to add a mathematical perspective to the paper.
>
> - The structure of the paper completely changed in the new revision, so now
> it’s hard to understand what and why they have done
>
> - Another missing part is discussion of graph invariants
>
> Tom (Deakin): There’s a big missing part in “Prior art” part, GraphBLAS (
> https://graphblas.org) eminently.
>
> Some other things to add:
>
> 1. The electrical circuit example needs more explanation, and I think this
> will highlight some deep issues around representing things which are
> seemingly trivially graphs, as graphs in practice. In what sense is a
> bog-standard resistor directed? I assume the reason that the graph is
> directed is because current has a sign and in an undirected graph it
> becomes ambiguous which way the current is flowing (also you may want
> components like diodes). But the directed representation also has issues:
> "can current flow from 'Vdd' to 'n0'?" should be immediately answerable
> from the properties of Vdd and its edges. There are other ways to represent
> an electrical circuit. One is as a directed graph but with incident edges
> recorded - but iiuc, this is excluded from the latest version of the paper.
> Alternatively, one could have a mathematical object, the name of which I
> actually don't know: it looks like an undirected graph, but where each
> partial edge has additional, unique, end-point data, as well as the common
> weight. Things like this are the reason why I think we need a broader group
> to look at this proposal (i.e. beyond SG19) and if we possibly can we
> should involve someone from the mathematics community. Otherwise there's a
> real danger we end up missing important insights.
>
> 2. My comment about the structure of the paper changing was a reference to
> previous comparisons with boost::graph. I'm sure these were in an earlier
> version, or am I misremembering? Either way, it would be very helpful to
> have a proper discussion of e.g. the move away from visitors.
>
> 3. Re. the definition of a graph, there needs to be a proper discussion
> about whether the paper's definition of graph is what some authors call a
> multigraph and whether it does/does not include loops. These things are
> mentioned, in passing, when introducing algorithms, but terminology needs
> to be properly established.
>
> 4. I think we're trying to do too much in one go in this paper. I think a
> great first step would be to build on mdspan and try to standardize (or at
> least understand) what might reasonably be called an unstructured span.
> This could be represented as a vector of vectors or as a vector with some
> auxiliary storage indicating where the partitions fall. The point is that
> an unstructured span, with the right invariants, is an adjacency list. If
> we can understand unstructured span and its desirable api, I think this
> will be incredibly valuable guidance for what a standardized graph
> container might look like.
>
> 5. IIUC, this paper excludes pure connectivity graphs. These are incredibly
> helpful and, if I've understood correctly that they are not supported,
> would be a major omission. Another good reason, imo, to start with
> unstructured span!
>
> 6. I'm not convinced by the load api. We don't have a load api for vector
> etc. Moreover, would it not be preferable to have appropriate constructors?
>
>
> 2.2.1: ML topics
>
> 2.2.1.1 Graph Proposal Phil Ratsloff et al
>
> D3127 terminology
Andrew presenting
pg 3: terminology can we claw back
4: rarely a distinction between graph and graph terminology
8: OR: add multiple edges (pair of nodes connected by 2 or more edges)
Figure 3 mentions instagram
This is an R1: should add a table of what is delta with R0
10: JM: partition graph: V should add vn1-1 looks wrong, so its 2 level of
subscripting so need to fix the latex
11: typo
12: OR: represent currents, flow networks, circuits, deserves mention of
direction of current or if it is positive or negative; library needs to
support it because it is difficult; not scope creep, but fundamental;
representing them is subtle
JM: disagree, can do route finding without flow network, is enough
AL+OR: need to work through examples to get the building blocks
JM: different dimension of design, flow network is not a good example to
explain these terms, use something else; do the flow network in another
paper
OR: disagree, the necessity of these terms is revealed by this paper; how
to categorize a structure for flow network
AL: we call it multigraph for flow network, not structural, cant enforce at
compile time
OR: direct representation vs adjacency lists should be separate, not
conflated; section 10. should not have adjacency list
JM: dont introduce arc now
OR: Pure connectivity has no representation; OK
AL: will remove circuit
Appendix:
OR: data to graph do we need this at all
AL: like to avoid the property map dependency; JM: not sure what the
abstraction layer is for Djkstra
PR: current abstraction is a concept of property on a graph, edge, vertex,
so tuple is property on the edge, inside algo there are multiple values,
caller to Djkstra knows which graph and provides a function to extract the
correct distance
AL: add a djkstra example
OR: start with vertex, list of edges, tuple of properties
what is the property referring to?
AL: property represents circuit element, the current, the conductance, that
is associated with the edge
PR: to make this compile, need a second argument on the vector
AL: yes I see
JM: vertex needs a template argument
OR dont like direct representation, it will be templated on vertex and edge
weight, vertex should not know edge weight; its not the cleanest design
AL: template on edge type? OK
JM: should this be super generic graph data structure
PR:P3131 has a definition for compressed graph
JM: template on edge and vertex wright and everyhting else is impl detail
PR: can reduce internal size of graph
OR: cover vector of vector
AL: should pass that into Djkstra
PR: now you can
OR: adjacency lists is unstructured, but there are large patches that are
structured, use template param to optimize these structures through
customization
PR: depends on who is creating the data structure; have range of ranges and
how you represent that range is upto you
impl is in P3131 and it is a CSR but there could be additional
PR: how customizable should it be; want to have 1 thats good, then more can
come later
JM: containers are complex to get through LEWG; how detail should the spec
be, or impl leeway
it should support all the algorithms in the paper but not arbitrary
PR: design to adapt existing containers
I am just providing are constructors, everything else use public interface
P303 are all CPO public fns, gives back a range
your own graph datastructure can override the CPOs
What about negative edges, cycles, DAG
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3126r1.pdf
contains the list of issues at bottom
Agree on a graph DS but does not preclude other algo; needs to be trimmed
down
another paper needed: Comparison of BGL with our Graph
> Latest paper:
>
> Here’s a link to the paper (different than the previous paper reviewed).
> There are some additional updates I’m planning on making before the
> meeting.
>
>
> https://docs.google.com/document/d/1OpH-xxRri7tJTtJJIZTYmSHkkrZJkdBwm9zJ7LqolfQ/edit?usp=sharing
>
>
>
>
> P1709R3:
>
> https://docs.google.com/document/d/1kLHhbSTX7j0tPeTYECQFSNx3R35Mu3xO5_dyYdRy4dM/edit?usp=sharing
>
>
> https://docs.google.com/document/d/1QkfDzGyfNQKs86y053M0YHOLP6frzhTJqzg1Ug_vkkE/edit?usp=sharing
>
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2119r0.html>
>
> <
>
> https://docs.google.com/document/d/175wIm8o4BNGti0WLq8U6uZORegKVjmnpfc-_E8PoGS0/edit?ts=5fff27cd#heading=h.9ogkehmdmtel
> *>*
>
> Array copy semantics:
> array copy-semantics paper P1997 "Relaxing Restrictions on Arrays",
> https://wg21.link/p1997
>
> Stats feedback:
>
> P1708:
Added ISO references
OR: Erroneous instead of unspecified as another alternative is more
specific and less ambiguous
> P2376R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2376r0.pdf>
> Comments
> on Simple Statistical Functions (p1708r4): Contracts, Exceptions and
> Special cases Johan Lundberg
>
> 2.2.1.2 Reinforcement Learning Larry Lewis Jorge Silva
>
> Reinforcement Learning proposal:
>
> 2.2.1.3 Differential Calculus:
>
>
> https://docs.google.com/document/d/175wIm8o4BNGti0WLq8U6uZORegKVjmnpfc-_E8PoGS0/edit?ts=5fff27cd#heading=h.9ogkehmdmtel
>
> 2.2.1.4: Stats paper
>
> P2681R0
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2681r0.pdf>
> More
> Stats Functions Richard Dosselmann, Michael Wong
> Current github
>
> https://github.com/cplusplus/papers/issues/475
>
> https://github.com/cplusplus/papers/issues/979
>
> Stats review Richard Dosselman et al
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1708r4.pdf
>
> Feedback from Johan Lundberg and Oleksandr Korval
>
> https://isocpp.org/files/papers/D2376R0.pdf
>
> P1708R3: Math proposal for Machine Learning: 3rd review
>
> PXXXX: combinatorics: 1st Review
>
> *> std.org/jtc1/sc22/wg21/docs/papers/2020/p1708r2
> <http://std.org/jtc1/sc22/wg21/docs/papers/2020/p1708r2>*
> *> above is the stats paper that was reviewed in Prague*
> *> http://wiki.edg.com/bin/view/Wg21prague/P1708R2SG19
> <http://wiki.edg.com/bin/view/Wg21prague/P1708R2SG19>*
> *>*
> *> Review Jolanta Polish feedback.*
> *> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2119r0.html
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2119r0.html>*
>
>
> 2.2.1.4: Matrix paper
>
> 2.2.3 any other proposal for reviews?
>
> 2.3 Other Papers and proposals
>
> P1416R1: SG19 - Linear Algebra for Data Science and Machine Learning
>
> https://docs.google.com/document/d/1IKUNiUhBgRURW-UkspK7fAAyIhfXuMxjk7xKikK4Yp8/edit#heading=h.tj9hitg7dbtr
>
> P1415: Machine Learning Layered list
>
> https://docs.google.com/document/d/1elNFdIXWoetbxjO1OKol_Wj8fyi4Z4hogfj5tLVSj64/edit#heading=h.tj9hitg7dbtr
>
> 2.2.2 SG14 Linear Algebra progress:
> Different layers of proposal
>
> https://docs.google.com/document/d/1poXfr7mUPovJC9ZQ5SDVM_1Nb6oYAXlK_d0ljdUAtSQ/edit
>
> 2.5 Future F2F meetings:
>
> 2.6 future C++ Standard meetings:
> https://isocpp.org/std/meetings-and-participation/upcoming-meetings
>
> None
>
> 3. Any other business
>
> New reflector
>
> http://lists.isocpp.org/mailman/listinfo.cgi/sg19
>
> Old Reflector
> https://groups.google.com/a/isocpp.org/forum/#!newtopic/sg19
> <https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!forum/sg14>
>
> Code and proposal Staging area
>
> 4. Review
>
> 4.1 Review and approve resolutions and issues [e.g., changes to SG's
> working draft]
>
> 4.2 Review action items (5 min)
>
> 5. Closing process
>
> 5.1 Establish next agenda
>
>
> 5.2 Future meeting
> * Jan 11, 2024 02:00 PM ET: Graph DONE
> * Feb 8, 2024 02:00 PM ET: Graph DONE
> * Mar 14, 2024 02:00 PM ET: Cancelled due to Tokyo 3-18-23
> * Apr 11, 2024 02:00 PM ET: Stats/Graph DONE
> * May 9, 2024 02:00 PM ET: Graph DONE
> * June 13, 2024 02:00 PM ET: Graph; St.louis 6-24-29
> * July 11, 2024 02:00 PM ET: Stats
> * Aug 15, 2024 02:00 PM ET: Graph
> * Sep 12, 2024 02:00 PM ET: CPPCON Sept 15-20 so cancelled
> * Oct 10, 2024 02:00 PM ET: Stats
> * Nov 14, 2024 02:00 PM ET: Cancelled Wroclaw F2F
> * Dec 12, 2024 02:00 PM ET: Graph
>
Received on 2024-06-13 19:57:18