On Tue, Dec 10, 2019 at 9:21 PM Michael Wong <fraggamuffin_at_[hidden]> wrote:

> SG19 Machine Learning 2 hours
>
> Hi,
>
> Michael Wong is inviting you to a scheduled Zoom meeting.
>
> Topic: SG19 monthly Dec 2019-Mar 2020
> Time: Dec 12, 2019 01:00 PM Eastern Time (US and Canada)
> Every month on the Second Thu, until Mar 12, 2020, 4 occurrence(s)
> Dec 12, 2019 01:00 PM
> Jan 9, 2020 01:00 PM
> Feb 13, 2020 01:00 PM
> Mar 12, 2020 01:00 PM
> Please download and import the following iCalendar (.ics) files to
> your calendar system.
> Monthly:
> https://iso.zoom.us/meeting/u5IudOyrrD0o6QfidlHRJTh2cH9H6gRuPA/ics?icsToken=98tyKu-urTgvGdaTslyCe7MtOZX_bN-xjSd_rKpZkDfXKRRbMADeb8oUNYBqIPmB
>
> Join from PC, Mac, Linux, iOS or Android: https://iso.zoom.us/j/663353262
>
> Or iPhone one-tap :
> US: +14086380968,,663353262# or +16468769923,,663353262#
> Or Telephone:
> Dial(for higher quality, dial a number based on your current
> location):
> US: +1 408 638 0968 or +1 646 876 9923 or +1 669 900 6833 or
> 877 369 0926 (Toll Free) or 877 853 5247 (Toll Free)
> Meeting ID: 663 353 262
> International numbers available: https://iso.zoom.us/u/abhaIjFKLZ
>
> Or Skype for Business (Lync):
> https://iso.zoom.us/skype/663353262
>
>
> Agenda:
>
> 1. Opening and introductions
>
> 1.1 Roll call of participants
>
Michael Wong, Phil Ratzloff, Andrew Lumsdaine, Duygu Cakmak, Matthew
galati, Richard Dosselmann, Lukasz Wojakowski, Jesun Firoz, Scott McMillan,
DOmagoj Saric

> 1.2 Adopt agenda
>
Yes

> 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
> All C++ reflector are now moved to listserv
>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
>
C++20 progress

>
> 2.2 Paper reviews
>
> Review Belfast results.
>
> 2.2.1: ML topics
>
> Richard Dosselman
>
> P1708R1: Math proposal for Machine Learning
>
> https://docs.google.com/document/d/1VAgcyvL1riMdGz7tQIT9eTtSSfV3CoCEMWKk8GvVuFY/edit
>
Now in latex
for these simple stat functions, should they be stand alone (simpler to
implement as well if you want to add new functions, but now you have
multiple scan of data if you wnat to do all the algorithms), or aggregate
those into a class type structure ( can do a single scan for multiple
algorithm similar to boost accumulate)
Vote results from belfast:
Should the author continue with the functionality and direction of
accumulator set or return to version 1?
(SF = accumulator_set, SA = version 1)

SF F N A SA
3 7 2 0 0
Favor accumulator set

But how do we add new functions and extend but that adds accessing the guts

Mode require passing a range and fill it up for all modes,
concern about havign multiple modes in the set of data,
Jens did not like returing a vector as it allocates memory, most STL pass
their own preallocated data structure

BFS and DFS traversal requires something allocated in the back, so no
allocation may be too hard a restriction
Can still extend for images or a set of images for facial recognition for
de-nosing
also Belfast asked for support for complex numbers




>
> P1709R1: Graph Proposal for Machine Learning
>
>
> https://docs.google.com/document/d/1QkfDzGyfNQKs86y053M0YHOLP6frzhTJqzg1Ug_vkkE/edit?usp=sharing
> <
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1QkfDzGyfNQKs86y053M0YHOLP6frzhTJqzg1Ug_vkkE%2Fedit%3Fusp%3Dsharing&data=02%7C01%7CPhil.Ratzloff%40sas.com%7C729b2cf8502641e4ae5e08d749064578%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C637058163592253027&sdata=4UQm8tqrcUbiZsr200UMrOaEModJYGNgP1oNot9PbAg%3D&reserved=0>
>
>
reviewing Belfast feedback
this algorithmic centric approach was good to continue, and in conjunction
with range based interpretation of graphs, and also doign it at compile
time with constexpr
and finally also address parallel executon, also question about using simd

ok constexpr was an oversight, so updated the read-only functions, unclear
whether we should change others
parallelism should be per- algorithm ? Yes seems reasonable, parallel graph
algo are not well understood, the best parallel graph algo is not just a
parallelized version of sequential, so I dont think that is a sensible algo
to have parallel DFS by just adding an execution policy, these things dont
parallelize, BFS also have synchronization issue; some have a priority
queue and requires single stepping

positive from Belfast
AL promotes a graph as range of ranges
BGL17 is a Better Graph Library using C++17
MS VS has range V3 and COncepts

So wanted to try it out with an example of adjacency array,
so look at how the graph is built, the ranges, and the implementation of
BFS and DFS
using the German route from the paper as starting point

vector of cities and edges
3 landas for cities and edge value first and seocnd

now we have pritning the structure
iterating through vertices, gettign key, outgoing edges, explciit for now
but could change to auto

BGL17 has bfs and dfs based on both nodes and vertexes

now using an iterator based on approach be cause it has depth
if not care about depth then use the range based which is second solution

the boolean is it always recorded? Yes always recorded
can we overrde the implementation? BGL17 philosophy was trying to get as
far away from original BGL
can put al lvisitor code in the body of the range based adaptor; I used BGL
and I thought that was useful
I was doign an experiment to see if this works to solve both flexibility
and performance as vsiitor can take a hit with performance

we could create a visitor that visits both edge and vertices, but it would
be more complcated to write; so MG if you can think of an example where
this does not work that would be great? I cant think of how such an eaxmple
would look like.

Centrality would be a great next algorithm,

the final one is BFS edge

now look at BFS/DFS implementation

One interestign observation is that range itself contains the content ot
state of the iteration, so as you are iteratign through so if you call
begin, it returns location of where you iterated to; this allows itrator to
be copied in a light weigh way

so need a const begin ...

created a concept called SearchableGrpahConcept
has a forward range,
to get begin and end of edges, we need to pass in the graph for context
this i causing us to have free function

so in bfs and dfs we dont have to worry whether it is directed, we just
wnat teh range of graphs to default to a set of vertices
but if you want begin of graph it returns the begin of the vertex collection
if you want begin of vertex it is begin of outedge

the ago is based on having an integral vertex key, so if we dont have an
integral vertex key, these algo wont work
yes, we wanted to have this key type that we can dereference n both the
inner and outer range
so maximal set only works on an edge list

with algorithmic centric approach, different ones will have different
requirements, we might be able to boil it down to a small list of
requirements

so enfornce to start an edge list, or user gives you an adjacency list
directly for the definition of the graph

in general, different algo knows what requirement they have, cocept define
formally what those algorithms are

we can also have nested concepts,

if it supports both the nwill have to do somethign extra to select. This
needs experiment in future

if we dont enable that design then we are lost, as we are trying to follow
STL separation of algo and containers, he intent here is that we have free
functions and we can create a single structure with the types

the whole properties might have issue when properties is mutable

data members are graph stack, vector bool
this boils down to how this is constructed

does vertex return the from or to? the to for directed graph
grabbing the key could be a hit for performance, if we know we have
integers that have no need for hasing with key labels, why are we dealing
with it
define concept for speed version
also about code size
OK so we have a template parameter in the definition of the graph? Right
and if we check if it is consecutive, the nskip key lookup, as these can
make a big difference

adjacency array with edges stored consecutively a vector or DAG, real impl
is kept in impl file along with free functions that tie this to adjanceny
array

can have this directed on any type or any structure

so we need to pass allocator since we cant add anything

cant prevent user from using the free functions, may be consequence so need
education

dont look directly to see a graph,

no public funcions for removign edges so its semi-mutable


constructor have 2 template statements, one for the graph and the other for
the constructor itself

static usage of grapph requires separet th container from algorithm so I
can define a struct of my own that obeys an interface?
then we can statically allocate the value then we wont have to wait for
constexpr STL

perhaps library can have a tool that generate static graph from dynamic
ones, like serialize an unordered map translates a dynamic TF graph to a
static C++ graph

XLA and glow will analyze a graph structure in any format like onyx nnef,
and do fusioin transformation, reordering, and generate machine code , so I
am lookign at this proposal to generate reusable tool for these graph

next iteration of paper is more examples, and more functions, and
implementing the algo

suggest we also have an undirected graph and tha twould help. AL mentions
other ones in BGL17 would also help















> Differentiable Programing by Marco Foco
>
Workign on it for next call

> 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.2.3 any other proposal for reviews?
>
> 2.3 Other Papers and proposals
>
> 2.5 Future F2F meetings:
>
> 2.6 future C++ Standard meetings:
> https://isocpp.org/std/meetings-and-participation/upcoming-meetings
>
>
> -2020-02-10 to 15: Prague, Czech Republic
>
> - 2020-06-01 to 06: Bulgaria
> - 2020-11-6-14: (New York, tentative)
> - 2021-02-22 to 27: Kona, HI, USA
>
> 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
>
> Dec 12, 2019 01:00 PM
> Jan 9, 2020 01:00 PM: Jan 13 is mailing deadline
> Feb 13, 2020 01:00 PM
> Mar 12, 2020 01:00 PM
>