On Thu, Oct 10, 2019 at 12:13 PM Michael Wong <fraggamuffin_at_[hidden]>
wrote:

> SG19 Machine Learning 2 hours
> Topic: ISOCPP SG19 Machine Learning
> Time: May 9, 2019 1:00 PM Eastern Time (US and Canada)
> Every month on the Second Thu, until Sep 12, 2019, 5 occurrence(s)
> May 9, 2019 1:00 PM
> Jun 13, 2019 1:00 PM
> Jul 11, 2019 1:00 PM
> Aug 8, 2019 1:00 PM
> Sep 12, 2019 1:00 PM
>
> Oct 10, 2019 1 Pm
>
> Please download and import the following iCalendar (.ics) files to
> your
> calendar system.
> Monthly:
>
> https://iso.zoom.us/meeting/405838761/ics?icsToken=fe375cbeab0268c23180f074fc6795e459a2bcd0fd6bdf9a8e146fa2acd22ef0
>
> Join from PC, Mac, Linux, iOS or Android: https://iso.zoom.us/j/405838761
>
> Or iPhone one-tap :
> US: +14086380968,,405838761# or +16468769923,,405838761#
> 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
> 853 5247 (Toll Free) or 877 369 0926 (Toll Free)
> Meeting ID: 405 838 761
> International numbers available: https://zoom.us/u/abhaIjFKLZ
>
> Or Skype for Business (Lync):
> https://iso.zoom.us/skype/405838761
> <https://iso.zoom.us/skype/405838761>
>
> Agenda:
>
> 1. Opening and introductions
>
> 1.1 Roll call of participants
>
Millan Girkar (Intel), Phil Ratsloff( SAS), Marco Foco (nvidia0, Andrew
Lumsdaine (U W), Richard Dosselwamn (U R), Michael Wong (CP), Jens Maurer,
Domagoj Saric

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
> All C++ reflector are now moved to listserv
>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
>
> 2.2 Paper reviews
>
> Review Belfast paper submission strategy
>
https://isocpp.org/papers
to submit papers
need an isocpp password

> 2.2.1: ML topics
> Differentiable Programing by Marco Foco
>
new person implemented in clang
He will be at Belfast
Vassil Vassilev

> Richard Dosselman
>
> P1708R1: Math proposal for Machine Learning
>
> https://docs.google.com/document/d/1VAgcyvL1riMdGz7tQIT9eTtSSfV3CoCEMWKk8GvVuFY/edit
>
instead of independent functions that ake one pass over the data, that was
based on python
we have a range where we can walk once so computation are free and do
multiple scan
load a variety of entity over that range
and individually load the value to be evaluated

Mean: has an overload and not just set
just like evrything else in general standards algorithm template, follows
the accumulator function as well
e.g:
integer list of fixed pre-determiend size
then accumulator which operates over that set
this is like boost accumulator library, given a set then load a function,
from eric niebler
versatile as to which set it applies to
first one does just one statistics

e.g. 2
structure, o have to have notion of what mean is
now accumumulating over a set of point, but result is a single scalar
lambda describe what we mean to be computing the average
can use this to create midpoint, geometric and harmonic mean is for the
future
3.3
median requires sorting you wont know the middle until sorted
quick select is a popular same designer as quick sort
return value: iterator to the individual mean median, now aming for
structure where we return a first or second median
can ask for both mean and median
should we allow people to know there are 2 medians
why get<1> instead <0>, off by 1 error

when I apply median will get 2 values, magenta and cyan
python for median of even number integers, probably averages them resulting
in floats as they dont have support for integers
no support for strings? averaging signals, images
dont design it to force string to work, it is outside of problem domains,
but if it works great
for mean yo usum individual pixels and divide by number of elements
if you have an image unit8, when u accumulate it in a wider type, after
dividing it goes back to unit8
so intermediate type is also different
std::accumulate already support different types for accumulator, this is
good

Mode: needs a hash table
where is the vector and why optional? possibility if there is no return
value at all
are there several results?
worry we are returning a vector as it allocates memory which means passing
in an allocator, a range would be better

but this would deviate from standard unlike median mean
we seem to have this problem anyway
Not sure how a range would be use in this case, it would have to be sorted
order

Standard deviation
simpler cases
dont do example 2 in 3.5, look at ranges for projections that have
algorithm built in
3.6 Variance
asked for by Jens,

Median /mode seems to need different treatment , needs memory allocation,
and hash tables

>
> 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>
>
>
>
was trying to support OO interface, now switching to a functional interface
like erasing an edge on a vertex, so need the context of a graph
store a graph pointer, so now start lookign at concepts, what are those
functions instead of having a table

COncepts: there are just definitions, no implemenation yet, trying to
present the concepts that will be useful throughout definiiton we will be
using
using _c to designate a concept type
have to get vertexes and edges of the graph
there is an arithmetic concept, based on the arithmetic type
for depth-search first

intoduced type_traits for is this an adjancey array, list , etc
there is graph value type
vertex key, vertex value,

ways of creating vertex, can pass vertex by rvalue reference, can erase
vertexes or in a range, clear, find
can erase edges, or based on in out edge iterator
can find an edge based on vertex iterators or keys
can do same for in out edge
why does adjancey list return a Grpah type? Yes, it was suppose to be a
pointer to an object (that is newly allocated object, then it needs to be a
managed pointer or object by value, and should not be return by raw
pointer; Ok if we return unique pointer the need to do more work for a
shraed pointer) , need to specify what G means, this needs some more
attention

why shoudl this helper function be at the top level? Should we not use
concept based,
all kinds of data structure that can meet the concept of the graph or
adjanceny list and that should make up a list of vectors, we had that in
BGL; seems like you want to be able build up from that to sparse matrix

depth first and breath first search are really iterators! agree
so Iterator example shows how to create a graph G1 with adjacency list
DFS range first item is vertex where you are at, the second part s a
sentinel
yes this makes perfect sense to me, definitely approach we have been using
for BGL 17
same example in breath first search with different ordering coming out

graph_c G is reused everywehere, should they not be differerent concepts,
as BFS and DFS is just reading, if you are reusing this for erase function
,
 yes so far these are generic

TopoSort

Algorithm
shortest path
BFSP
dijkstra reuires nonnegatve weighs, consier a concept for that which would
require unsigned integers
there are no unsigned doubles, and doubles is a possible weights
connected component is an undirected graph

Dont do tuples, as they dont have names as they use get<0>, which we dont
know what they are
get named members like ranges
Do you have a description of graph_c concept? Yes in Concepts, directed
and undirected
need to have good definitions
an unidrected graph should not be required to have an erase function. Is
that from easable? May be just check
I Have a concept Erasable
could be mixing 2 things, algo which operate on a graph, and these Graph
functions that appear to operate on predefined graph data structure that
you offer in your library and they look the same but take your specific
Graph type, they should take a generic graph type.
Agree, but they could be overwritten wit user-defined functions and these
perform the desire goal.
But now you require each of these functions and that expands the interface
greatly
I see if I want to adapt my thing, then I want to know what I want to
override, this is the point of Concept
Right, I cant tell what the minimum set of operations that is needed

industry is moving away from library solutions like TVM, Glow these are
compile time generated graphs
yes in scope just not today,
vertexes and edges are compield time constnat and these would be optimized

vertex iterator concept, some produce pairs of vertex iterator, no implied
navigation on these vertexes
what does increment do on these? Nothing for shortest path. Perhaps minimum
requirement to satisfy
so no need for ++ unless I really need it but for some algo, being an
iterator vs being a pointer or reference really means, you dont really need
a random access iterator into the next function?

example for transitive closure for modifying tht grah nd how to produce a
fresh graph tht is a transitive closure of another graph to demonstrate the
interface as given works

why create_adjancency list just creates a graph. So why need a special
creation function for graph? Because I was trying to create a functional
definition.

adjacency list that is initiliazed with an initialized list? Yes useful

also having global functions that modify graphs.




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
>
> - *2019-11-04 to 09: Belfast, Northern Ireland;* Archer Yates
>
> -2020-02-10 to 15: Prague, Czech Republic
>
> - 2020-06-01 to 06: Bulgaria
> - 2020-11: (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
>
> Aug 8
> Sep 12
> Oct 10: Mailing deadline Oct 7
> Nov 14 - cancelled due to DST change and switching to a new cycle.
>