I'm still not fully recovered from the latest covid variant, so will be
skipping this one.

O.

On Tue, 9 Jul 2024 at 23:22, Michael Wong via SG19 <sg19_at_[hidden]>
wrote:

> I am also happy to cancel the meeting if we don't have enough progress
> report. Cheers.
>
> On Tue, Jul 9, 2024 at 6:19 PM Michael Wong <fraggamuffin_at_[hidden]>
> wrote:
>
>> Hi, this SG19 meeting will focus on Graph and stats
>> I know we just met 2 weeks ago so there may not be a lot of progress yet,
>> in which case this will be just a short recap/planning meeting.
>>
>> 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
>>
>> 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
>>
>>
>> * 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 DONE
>> * July 11, 2024 02:00 PM ET: Stats/ Graphs
>> * 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
>> 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 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 DONE
>> * 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
>>
> --
> SG19 mailing list
> SG19_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
>