Date: Fri, 14 Mar 2025 10:30:48 -0400
On Thu, Mar 13, 2025 at 12:26 AM Michael Wong <fraggamuffin_at_[hidden]>
wrote:
> Hi, this SG19 meeting will focus on stats and graphs.
> 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, Richard, Scott, Andrew, Michael
>
>
> 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
>
>
>
>
> * Jan 9, 2025 02:00 PM ET: Cancelled
> * Feb 13, 2025 02:00 PM ET: Hagenberg F2F; Cancelled
> * Mar 13, 2025 02:00 PM ET: Graph
> * Apr 10, 2025 02:00 PM ET: Stats
> * May 8, 2025 02:00 PM ET: Graph
> * June 12, 2025 02:00 PM ET: Stats
> * July 10, 2025 02:00 PM ET: Graphs
> * Aug 14, 2025 02:00 PM ET: Stats
> * Sep 11, 2025 02:00 PM ET: Graph, CPPCON
> * Oct 9, 2025 02:00 PM ET: Stats
> * Nov 13, 2025 02:00 PM ET: Graph
> * Dec 11, 2025 02:00 PM ET: Stats
>
>
> ISO meeting status
>
> future C++ Std meetings
>
> 2.2 Paper reviews
>
> For graph, we have a new draft of P3337 Comparison paper that compares the
> library in performance against boost::graph and NWGraph.
>
> If Andrew is able to attend, he should be able to review the changes he's
> made to P3126 and P3127.
>
>
The meeting discussed the challenges of scheduling meetings due to Daylight
Saving Time (DST) differences. Key points included the need to finalize the
stats paper, addressing objections raised by Oliver, and the implications
of constexpr functions and error handling. Richard proposed not performing
costly error checks for stats functions, following existing standards. Phil
presented a comparison paper on graph algorithms, showing that the proposed
graph performs well against Boost and Northwest graphs, with some
exceptions in single-source shortest paths. Andrew discussed the need for a
high-level overview and background paper on graph terminology, aiming for
approval by May 8. The team emphasized the importance of publishing drafts
for feedback.
Action Items
- [ ] Send the draft background and terminology paper to the reflector
for feedback.
- [ ] Incorporate feedback and prepare the background and terminology
paper for submission to LEWG by May 8th.
- [ ] Finalize the comparison paper and send it to the reflector.
- [ ] Ensure the algorithm paper is ready for submission to LEWG by May
8th.
- [ ] Incorporate changes to the descriptor implementation and ensure it
is ready for submission to LEWG by May 8th.
OutlineMeeting Introduction and Scheduling Challenges
- Michael Wong explains the difficulty of scheduling meetings due to
Daylight Saving Time (DST) differences between Europe and North America.
- Michael mentions the importance of having updates despite the
scheduling challenges.
- The meeting is necessary to make progress before the June meeting in
Sofia.
- Michael notes the presence of key team members like Scott, Richard,
Phil, and Andrew.
Discussion on Meeting Formalities and Time Constraints
- Michael Wong emphasizes the need to get through formalities quickly
due to DST issues.
- Richard Dosselman mentions he doesn't need much time for his
presentation.
- Michael decides to let other team members present first due to time
constraints.
- Scott mentions he has another meeting in about an hour and 15 minutes,
prompting Michael to prioritize presentations.
Richard's Presentation on Stats Paper
- Richard Dosselman presents a short document addressing questions
raised in Oliver's paper.
- Richard explains the proposed statistic functions are not designed to
imitate mathematical functions like sine and exponential.
- Discussion on whether constexpr functions can raise exceptions and the
implications for stats functions.
- Michael Wong and other team members discuss alternative error handling
methods for constexpr functions.
Error Handling and Constexpr Functions
- Michael Wong explains the fundamental conflict between constexpr
evaluation and exception handling.
- Discussion on alternative error handling methods for constexpr
functions, including static assert, error codes, and custom error flags.
- Richard suggests not performing costly error checks for stats
functions, following existing precedents in the standard.
- Team members agree with the approach of not performing costly error
checks.
Discussion on Overloaded Templates and Views
- Richard Dosselman discusses the idea of overloaded templates for stats
functions to allow users to override data types.
- Michael Wong and other team members discuss the feasibility and
benefits of this approach.
- Discussion on the use of views and transforms to handle different data
types without additional runtime cost.
- Team members agree that using views and transforms is a suitable
solution.
Phil's Presentation on Graph Comparison Paper
- Phil presents a comparison paper written by Kevin Dewees, comparing
three different graph implementations: stood graph, Northwest graph, and
Boost graph.
- The comparison includes syntax differences, performance numbers, and
memory usage.
- Discussion on the performance of single-source shortest paths and the
potential need for profiling.
- Team members discuss the implications of memory allocation for graph
algorithms and the need for allocators.
Andrew's Presentation on High-Level Overview and Background Paper
- Andrew presents two papers: a high-level overview and a background
paper on graph terminology and implementation.
- The papers aim to clarify terminology and address non-intuitive
aspects of graph algorithms.
- Discussion on the need for detailed descriptions of graph
representations and the implications for complexity.
- Andrew mentions the need for feedback from the reflector and the
importance of publishing drafts for review.
Discussion on Graph Library Implementation and Algorithms
- Michael Wong emphasizes the importance of publishing drafts to get
feedback and shorten the approval process.
- Andrew discusses the need for an algorithm paper with actual code or
interfaces for LEWG.
- Michael Wong and other team members discuss the timeline for getting
papers approved by May 8.
- The team agrees to push for approval by May 8 and to actively seek
feedback on drafts.
Final Remarks and Next Steps
- Michael Wong outlines the next meeting dates: April 10, May 8, and
June 12.
- The team discusses the importance of getting the overview and
background papers approved by May 8.
- Andrew mentions the need to finalize the papers and get them out to
the reflector for feedback.
- The meeting concludes with a plan to continue working on the papers
and seeking feedback from the reflector.
>
> P3495 from Oliver/Mark
>
> >From Phil: There are updates to the P3126 Overview and P3127 Background
> and
> Terminology papers for the Graph Library. They haven’t been published yet,
> but it would be helpful to get input on them before they’re published.
>
>
>
> Since the changes are a response to Oliver’s concerns, I think Oliver and
> Andrew would need to attend to make it useful to have a session for the
> Graph Library. Unless they want to do that, I think we can send draft
> versions to the reflector, unless there’s a better idea.
>
>
> 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
>
> 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:
>
> 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 9, 2025 02:00 PM ET: Cancelled
> * Feb 13, 2025 02:00 PM ET: Hagenberg F2F; Cancelled
> * Mar 13, 2025 02:00 PM ET: Graph
> * Apr 10, 2025 02:00 PM ET: Stats
> * May 8, 2025 02:00 PM ET: Graph
> * June 12, 2025 02:00 PM ET: Stats
> * July 10, 2025 02:00 PM ET: Graphs
> * Aug 14, 2025 02:00 PM ET: Stats
> * Sep 11, 2025 02:00 PM ET: Graph, CPPCON
> * Oct 9, 2025 02:00 PM ET: Stats
> * Nov 13, 2025 02:00 PM ET: Graph
> * Dec 11, 2025 02:00 PM ET: Stats
>
wrote:
> Hi, this SG19 meeting will focus on stats and graphs.
> 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, Richard, Scott, Andrew, Michael
>
>
> 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
>
>
>
>
> * Jan 9, 2025 02:00 PM ET: Cancelled
> * Feb 13, 2025 02:00 PM ET: Hagenberg F2F; Cancelled
> * Mar 13, 2025 02:00 PM ET: Graph
> * Apr 10, 2025 02:00 PM ET: Stats
> * May 8, 2025 02:00 PM ET: Graph
> * June 12, 2025 02:00 PM ET: Stats
> * July 10, 2025 02:00 PM ET: Graphs
> * Aug 14, 2025 02:00 PM ET: Stats
> * Sep 11, 2025 02:00 PM ET: Graph, CPPCON
> * Oct 9, 2025 02:00 PM ET: Stats
> * Nov 13, 2025 02:00 PM ET: Graph
> * Dec 11, 2025 02:00 PM ET: Stats
>
>
> ISO meeting status
>
> future C++ Std meetings
>
> 2.2 Paper reviews
>
> For graph, we have a new draft of P3337 Comparison paper that compares the
> library in performance against boost::graph and NWGraph.
>
> If Andrew is able to attend, he should be able to review the changes he's
> made to P3126 and P3127.
>
>
The meeting discussed the challenges of scheduling meetings due to Daylight
Saving Time (DST) differences. Key points included the need to finalize the
stats paper, addressing objections raised by Oliver, and the implications
of constexpr functions and error handling. Richard proposed not performing
costly error checks for stats functions, following existing standards. Phil
presented a comparison paper on graph algorithms, showing that the proposed
graph performs well against Boost and Northwest graphs, with some
exceptions in single-source shortest paths. Andrew discussed the need for a
high-level overview and background paper on graph terminology, aiming for
approval by May 8. The team emphasized the importance of publishing drafts
for feedback.
Action Items
- [ ] Send the draft background and terminology paper to the reflector
for feedback.
- [ ] Incorporate feedback and prepare the background and terminology
paper for submission to LEWG by May 8th.
- [ ] Finalize the comparison paper and send it to the reflector.
- [ ] Ensure the algorithm paper is ready for submission to LEWG by May
8th.
- [ ] Incorporate changes to the descriptor implementation and ensure it
is ready for submission to LEWG by May 8th.
OutlineMeeting Introduction and Scheduling Challenges
- Michael Wong explains the difficulty of scheduling meetings due to
Daylight Saving Time (DST) differences between Europe and North America.
- Michael mentions the importance of having updates despite the
scheduling challenges.
- The meeting is necessary to make progress before the June meeting in
Sofia.
- Michael notes the presence of key team members like Scott, Richard,
Phil, and Andrew.
Discussion on Meeting Formalities and Time Constraints
- Michael Wong emphasizes the need to get through formalities quickly
due to DST issues.
- Richard Dosselman mentions he doesn't need much time for his
presentation.
- Michael decides to let other team members present first due to time
constraints.
- Scott mentions he has another meeting in about an hour and 15 minutes,
prompting Michael to prioritize presentations.
Richard's Presentation on Stats Paper
- Richard Dosselman presents a short document addressing questions
raised in Oliver's paper.
- Richard explains the proposed statistic functions are not designed to
imitate mathematical functions like sine and exponential.
- Discussion on whether constexpr functions can raise exceptions and the
implications for stats functions.
- Michael Wong and other team members discuss alternative error handling
methods for constexpr functions.
Error Handling and Constexpr Functions
- Michael Wong explains the fundamental conflict between constexpr
evaluation and exception handling.
- Discussion on alternative error handling methods for constexpr
functions, including static assert, error codes, and custom error flags.
- Richard suggests not performing costly error checks for stats
functions, following existing precedents in the standard.
- Team members agree with the approach of not performing costly error
checks.
Discussion on Overloaded Templates and Views
- Richard Dosselman discusses the idea of overloaded templates for stats
functions to allow users to override data types.
- Michael Wong and other team members discuss the feasibility and
benefits of this approach.
- Discussion on the use of views and transforms to handle different data
types without additional runtime cost.
- Team members agree that using views and transforms is a suitable
solution.
Phil's Presentation on Graph Comparison Paper
- Phil presents a comparison paper written by Kevin Dewees, comparing
three different graph implementations: stood graph, Northwest graph, and
Boost graph.
- The comparison includes syntax differences, performance numbers, and
memory usage.
- Discussion on the performance of single-source shortest paths and the
potential need for profiling.
- Team members discuss the implications of memory allocation for graph
algorithms and the need for allocators.
Andrew's Presentation on High-Level Overview and Background Paper
- Andrew presents two papers: a high-level overview and a background
paper on graph terminology and implementation.
- The papers aim to clarify terminology and address non-intuitive
aspects of graph algorithms.
- Discussion on the need for detailed descriptions of graph
representations and the implications for complexity.
- Andrew mentions the need for feedback from the reflector and the
importance of publishing drafts for review.
Discussion on Graph Library Implementation and Algorithms
- Michael Wong emphasizes the importance of publishing drafts to get
feedback and shorten the approval process.
- Andrew discusses the need for an algorithm paper with actual code or
interfaces for LEWG.
- Michael Wong and other team members discuss the timeline for getting
papers approved by May 8.
- The team agrees to push for approval by May 8 and to actively seek
feedback on drafts.
Final Remarks and Next Steps
- Michael Wong outlines the next meeting dates: April 10, May 8, and
June 12.
- The team discusses the importance of getting the overview and
background papers approved by May 8.
- Andrew mentions the need to finalize the papers and get them out to
the reflector for feedback.
- The meeting concludes with a plan to continue working on the papers
and seeking feedback from the reflector.
>
> P3495 from Oliver/Mark
>
> >From Phil: There are updates to the P3126 Overview and P3127 Background
> and
> Terminology papers for the Graph Library. They haven’t been published yet,
> but it would be helpful to get input on them before they’re published.
>
>
>
> Since the changes are a response to Oliver’s concerns, I think Oliver and
> Andrew would need to attend to make it useful to have a session for the
> Graph Library. Unless they want to do that, I think we can send draft
> versions to the reflector, unless there’s a better idea.
>
>
> 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
>
> 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:
>
> 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 9, 2025 02:00 PM ET: Cancelled
> * Feb 13, 2025 02:00 PM ET: Hagenberg F2F; Cancelled
> * Mar 13, 2025 02:00 PM ET: Graph
> * Apr 10, 2025 02:00 PM ET: Stats
> * May 8, 2025 02:00 PM ET: Graph
> * June 12, 2025 02:00 PM ET: Stats
> * July 10, 2025 02:00 PM ET: Graphs
> * Aug 14, 2025 02:00 PM ET: Stats
> * Sep 11, 2025 02:00 PM ET: Graph, CPPCON
> * Oct 9, 2025 02:00 PM ET: Stats
> * Nov 13, 2025 02:00 PM ET: Graph
> * Dec 11, 2025 02:00 PM ET: Stats
>
Received on 2025-03-14 14:31:06