C++ Logo

SG19

Advanced search

Subject: Re: Feb 11 SG19 monthly call
From: Michael Wong (fraggamuffin_at_[hidden])
Date: 2021-02-11 14:53:30


On Wed, Feb 10, 2021 at 12:53 PM Michael Wong <fraggamuffin_at_[hidden]>
wrote:

> SG19 Machine Learning 2 hours. This session will focus on Graph but with
> updates from all the others
> optionally.
>
> Link to Automatic differentiation proposal:
>
>
> https://docs.google.com/document/d/175wIm8o4BNGti0WLq8U6uZORegKVjmnpfc-_E8PoGS0/edit?ts=5fff27cd#heading=h.9ogkehmdmtel
>
> Hi,
>
> Michael Wong is inviting you to a scheduled Zoom meeting.
>
> Topic: SG19 monthly Dec 2020-Feb 2021
> Time: Jan 14, 2020 02:00 PM Eastern Time (US and Canada)
> Every month on the Second Thu, until Feb 11, 2021, 3 occurrence(s)
> Dec 10, 2020 02:00 PM ET 1900 UTC DONE
> Jan 14, 2021 02:00 PM ET 1900 UTC DONE
> Feb 11, 2021 02:00 PM ET 1900 UTC
> Please download and import the following iCalendar (.ics) files to your
> calendar system.
> Monthly:
>
> https://iso.zoom.us/meeting/tJctf-2tpzotGNHL5pZqwtjELee0mcG2zzCi/ics?icsToken=98tyKuCrrjMuH92UtxuCRowqAoqgLO_xmH5ajY11sEr1OTFEdgnTGudHYr98N4rK
>
> 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
> The IEC Code of Conduct:
>
> https://basecamp.iec.ch/download/iec-code-of-conduct-for-delegates-and-experts/
>
> 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:
>
> Dec 10, 2020 02:00 PM ET1900 UTC Stats DONE
> Jan 14, 2021 02:00 PM ET 1900 UTCReinforcement Learning and Diff
> Calculus DONE
> Feb 11, 2021 02:00 PM 1900 UTC ET Graph
>
> ISO meeting status
>
> future C++ Std meetings
>
> 2.2 Paper reviews
>
> 2.2.1: ML topics
>
> 2.2.1.1 Graph Proposal Phil Ratsloff et al
>
> P1709R1: Graph Proposal for Machine Learning
>
> 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>
>
D1709R3
input from Andrew sutton/Lumsdaine
embracing ranges
using references for vertices and edges ok for contiguous space but bad for
Deque; these are iterators
east const is now west const to be std consistent
std graph namespace is std so no separate namespace
data structure into their own paper O1-O7

O5 algorithm
connected component
incidence graph a collection of vertex range and vertex edge range
requires undirected graph; very few algorithms requires directed or
undirected
will not have to describe in text what this means

all the other algorithms will be affected in similar way
vertex range and vertex edge range just needs to be forward ranges and this
opens it up for other graphs to use these concepts
directed and undirected is a data property; so 2 overloads for directed
and undirected
this gives one starting point, and no an arbitrary starting point

why graph is mutable ref vs const ref? yes probably cosnst ref
names like vertex are at the top level and may intersect with other names

02- uniform graph interface
traits are here
graph has its own value type and allocator
then the outward and inward range

can I remove the const version of these?
then I can shrink the number of function down
with that we can have concepts

adjacency edge is adjacent vertex through the edges

when algorithm dont use them then refactor them; if the do use them, then
add them to the interface

edge_list graph

concepts behaviorally defined instead of syntactically, can we replace
traits class with customization points
for users who want to bring their own graphs to the library
allow concepts that are type drive and not syntactically driven
like edge_key for their type then they dont need traits

directed graph is an ordered pair; undirected graph is an unordered pair
vertex path is a range of vertex iterators

iterator with vertex type and edge type

added graph_T and graph allocator type

vertex_difference_t

concept I added helps me to consolidate things, else would need to add it
for every different kind of iterators

non_const is better to enable to cover both cases, WW will send you some
patterns; no traits class, just pure deductions

03- Directed Graph interface
is following the template that 02 was building

04- is the adaptors that takes an incidence graph
vertex-vertex range and edge_list_range adaptors

shortest path: 2 paths of that length, do we output one or both?
if they want to bring their own graphs into this it will be an overload

07-undirected_adjacency_list
can talk about this at a higher level

with vertexes, is that a sized range? what is expectation for edge ranges?
in some algorithm you want the degree of each vertex which is the size of
the range
dont want to make requirement on concepts that the algorithm is going to
need, but now the interface will constrain it
some algorithm had both edge, and vertex, but some also had adjacency
pulled vertex list graph as part of definition

CORE list:
P3?
COncepts and algorithms, and no API (Concept is defined in API): 5 2 1 3 0
needs some reorganization

Uniform API, Algorithm and 2 data structues directed 0 5 4 3 0
  Uniform API, Algorithm and 2 data structues directed 0 0 3 7 0

uniform API, algo, and directed adjacency_vector data structure

set of algo, and subset concept requried by those algo; no need for data
structire, if they CPOs then the ycan take as graph; graph withotu algo is
not useful

RFRM has his own paper similar to this graph
your paper is graph only, worry that it woudl be difficult to rewrite my
paper so I can use algo from your paper
N3700 Hierarchical Data structure
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3700.html
how to adapt this data structure as a graph?
there is no graph, should be able cal DFS BFS on vector and not do anything
fancy to that
and people should be able to use graph in some larger context

a concept that has an edge key, and call edge key function, so what type
does it have and what does it return? auto will just return what it return,
excessive typing is old fashion
use decltype to extract actual type
as long as that type satisfies the concept then algorithm should still work
in concept I have an edge key function, then I am not worry the type it
returns

Since I mentioned reddit. Here's the thread I referred to..
https://www.reddit.com/r/cpp/comments/lfc96p/n3700_hierarchical_data_structures_and_related/

> 2.2.1.2 Reinforcement Learning Larry Lewis Jorge Silva
>
> Reinforcement Learning proposal:
>
> 2.2.1.3 Differential Calculs:
>
>
> https://docs.google.com/document/d/175wIm8o4BNGti0WLq8U6uZORegKVjmnpfc-_E8PoGS0/edit?ts=5fff27cd#heading=h.9ogkehmdmtel
>
>
> 2.2.1.4: Stats paper
>
> https://github.com/cplusplus/papers/issues/979
>
> Stats review Richard Dosselman et al
>
> P1708R3: Math proposal for Machine Learning: 3rd review
>
> PXXXX: combinatorics: 1st Review
>
> > 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
> >
> > Review Jolanta Polish feedback.
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2119r0.html
>
> 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
>
> TBD
>
> 5.2 Future meeting
>
> April 8 2021 02:00 PM Eastern Time ( 1800 UTC ): Stats
>
>



SG19 list run by sg19-owner@lists.isocpp.org

SG19 Archives on Google Groups