On Thu, Jun 13, 2019 at 10:03 AM 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
> 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
>
Michael, Matthew Galati, Jens Maurer, Mateusz Nowak, Richard Dosselmann,
Kirsten Lee, David Gillies, Phil Ratzloff, Marco Foco, Vincent Reverdy

1.2 Adopt agenda
>
Approve.

> 1.3 Approve minutes from previous meeting, and approve publishing
> previously approved minutes to ISOCPP.org
>
Approve

> 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
>

Cologne meeting F2F: propose Friday afternoon again for SG19 (Friday
morning for SG14 Linear Algebra)

>
> 2.2 Paper reviews
>
> Any papers proposed for review at COLOGNE? Deadline June 17
>
DG: underlying GPU description
Affinity
https://github.com/codeplaysoftware/standards-proposals/blob/master/affinity/cpp-23/d1437r0.md
Executors
SG1

SG14: Linear Algebra

> 2.2.1: ML topics
> Differentiable Programing by Marco Foco
>
https://docs.google.com/document/d/1_5TJCBvI6fZSdyuK7_Cpo5XwdoIS24DDbEPh2JjqQsg/edit?ts=5cf823e2#heading=h.t1fxx74w88nq

Added Max
how to perform automatic differentiation: uses information from computation
to achieve same result as symbolic, but this tends to explode inside
can use tmpl expr to analyze the tree
can use intermediate computation, can use variables and does not repeat
expression, put CSE into variable and lessen explosion
Julia describes how they did it using SSA language
is this for core language? yes
follow constexpr: initally minimal expression that differentiates
expressions, say what you cant use in these expression
constexpr went with a negative list, though a positive list may be simpler
this needs a lot of narrative, motivation, to fight the perception that it
is narrowly targeted, why compiler implementer would expend effort, can
this benefit non-ML, lots of code that never heard of or use differentiation
is this a foundation building block?
can this ride on reflection? These need to analyze the AST, and not just
reflect information, we need AST manipulation, analyze the out parameters,
how do u differentiate reinterpret cast? Many things make no sense to
differentiate
Need a lot of examples of what transformation would look like f->f' what is
the partial derivative look like
for the scientific world, this is useful but we need to serve the wider
industry
need an implementer to help, like Daveed,
a reference implementation will be needed, Max might be able
add all the information in the paper, link to slide in reference
Could this be done with expr templ? first layer, then ask for core change
in later layers? Yes I explain why not Library solutions
The problem with tmpl is we loose the types, and types are needed in
creating and modifying the AST, differentiate an expr, needs a generic
lambda, so inject sampling variables, please explain this in paper to allow
other people to suggest different techniques
Phipps, Eric T <etphipp_at_[hidden]> of Kokkos interested

> Richard Dosselmann
>
> https://docs.google.com/document/d/1VAgcyvL1riMdGz7tQIT9eTtSSfV3CoCEMWKk8GvVuFY/edit
>
added lots of eaxmples, mean, std dev
how is this not accumulate and adding after the fact? underneath is how
that is done
build Tony tables, before and after
any advantages other then being common enough?
Boost accumulate has these
should we add geometric or harmonic means?
median: how to deal with non-numeric type, are they comparable
binary op why? override the operator
but you need a comparator... OK
need both examples for comparator and binary op usage
Mode: also works for nonnumerics
when mode is not unique? python throws exception
Does input has to be sorted? change example if not
make sorting same as what is in unique, same for median
can we return the range of the most used elements? Yes then you get
location as well, and if there are differences, then you have access, like
the address
still need equality comparator
std dev: can we add math formula to the paper
look at Random number section that shows the math
latex can gen pdf, and you can add pdf
returning std dev and not variance? any one want the variance? (just square
it yourself if needed)
need to add note on precision, look at std accumulate as an example
usually dont have default arguments in algo section, just overloads so more
overloads is not bad
any other basic stats? covariance for correlation, kurtosis from boost
accumulate, ok to ignore
future works section
need to reorder s1 and s2
Prob distribution: P1450 from Vincent needed ... do people feel this is
needed?
intended to generate random number
for normal distribution, mean and std dev are parameter
this may be a separate paper on mean and std dev, do it in a different layer










> Graph Proposal for Machine Learning
>
> https://docs.google.com/document/d/13rdk1Xq8ZshUiTL5QASK1N2yD5bLwK3lQjbDs5yIF6o/edit
>
Phil
want adjacency list, array, matrix, bidirections and undirected graphs
adjacency list use link list for incoming and outgoing edges, so we can
iterate all of the edges all at once
add a layering plan for future proposals
functional interface based on Ranges spec
could this interface be used for previous proposal as well?
they are not integrated with ranges terminology, using a pair of iterators,
use ranges types instead
how will algo work on forward type of graph, then rewrite for the same
thing for the undirected? Like having different names?
out_edge_list argues for a functional interface, begin is not stl style
why it has no constructor parameter? due to larger memory requirement
can

conditional<graph_value_needs_wrap<EV>::value, graph_value<EV>, EV>::type;
this be conditional .. T
too many template parameters? may be not the right level of abstraction?
Should we have number of different classes?
also consider functional interface for shortest path
motivation why a class? does it store state ?
erase does not allow templ type deductions for any of the many templ
parameters
how does this relate to boost graph library; uses a concept-like mechanism
to generalize, vs very specific types in this proposal
when BGL was reviewed 7 years ago, found somethings missing,
suggest we compare with existing solution, on BGL; BGL was an interface on
top of existing impl, which may add complexity
my concern was the property lookup was column based so needed array indexing
Can we remove specific types when we plug in graphs into algo? Not sure
SImilar to STL containers and Algo using iterators
DFS and BFS match what BGL had? Why does it take the specific Graph type,
why not mine? I see, like it
But how do I transition from one object to edges? we need to find out what
mechanism, can help optimize this, like pointers?
Andrew Lumsdaine & Jens Maurer are both urging we focus on Algorithms first
eventually this should be conceptified
need concept for what is a vertex and what is an edge, and these will be
contained in data structures
how are they related, how to go from one to another, also dynamic generated
transitive closure of graph as an algorithm example
diff algo has different requirement on what it wants to do to the graph:
evaluate weighs, or insert edges,
e.g. enumerate edges from a vertex, using a range based for loop using out
and in edges

Vincent on trees

hfinkel_at_[hidden]


> D1416R1: 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: Bob Steagall
> 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-07-15 to 20: Cologne, Germany; *Nicolai Josuttis
> - *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
> April 11 1-3 ET: Graph design
> May 9
> Jun 13: June 17 Mailing deadline
> Jul 11 - cancelled? C++ Standard Meeting Cologne
> Aug 8
> Sep 12
> Oct 10
> Nov 14 - cancelled due to DST change and switching to a new cycle.
>