Here are the attendees:

Michael Wong |

Richard Dosselmann |

Oleksandr Koval |

Jens Maurer |

Guy Davidson |

Marco Foco |

John McFarlane |

Will Wray |

Andrew Lumsdaine |

René Ferdinand Rivera Morell |

Oleksandr Koval |

Ozan Irsoy |

Scott Moe |

Phil Ratzloff |

Ritwik Dubey |

Ronan Keryell |

Luke D'Alessandro |

Scott Moe |

Sayan Ghosh (PNNL) |

Izzy Muerte |

On Thu, Jun 10, 2021 at 3:59 PM Michael Wong <fraggamuffin@gmail.com> wrote:

On Thu, Jun 10, 2021 at 12:18 PM will wray <wjwray@gmail.com> wrote:Here's a link to the P2128 rebuttal draft:n2740Arguments against a[i...] syntax for multidimensional indexing

A bit long - here's a direct link to the Case SummaryP2128variadic subscript operator takes more indexes instead of function call operator overloadthe authors felt it didnt matter either waypython compatible interfaceit doesnt really fit within C/C++ type systemvector bool and valarray gives back proxy, so what is a comma separated list in [ ] mean? rust and D is slice and returns array typesingle index drops rankselecting the indexes for that resultmultidim array: switch from functional indexing to square bracketsmixed concerns:n number papers are wg14 papers, this needs to be P number for WG21 excecpt SG22current paper only means we want mdspan to provide comma separated multi dim, only allow operator [ ] to take comma separated only if you index a class type, not builtinso core language proposal is language agnosticthis is not different from operator () already do as there is no inheritancethat is covered in P2128the syntax shown here is new syntaxa..b is different then 1,2conflict is expectation; if you index with a range, it is syntax error,we do have invokable concept in C++20, for call operator, discussion on integers but we can index on more then integersthen why ask for variaidic? its expensive because of multiple objects at compile time, brace_init version has init listits a popular feature but what is future costswe want uniform syntax,need to talk to more people about the cost to oppose a,bthere is a core lang feature to allow this syntax does not affetc builtin types to leave C do what they want in this areaobjection mdspan using bracket multidim syntax, should wait for LEWG discussing mdspan, and that has nothing to do with Cno impact core on builti nunless non-member operatorsOn Wed, Jun 9, 2021 at 11:04 AM Michael Wong <fraggamuffin@gmail.com> wrote:Thank you for the correction WIll. We should have time for your paper. Thank you.On Wed, Jun 9, 2021 at 10:52 AM will wray <wjwray@gmail.com> wrote:Should be tomorrow June 10, right? (Title says "June 9")The agenda looks quiet.If there is interest I'd like to give a short presentation, ~10 mins, with argumentsagainst C++ proposal P2128 "Multidimensional subscript operator".I'm writing a rebuttal paper for SG22 and could do with feedback before submitting it.

The topic is relevant to SG19 too, as it targets the mdspan API.I'll post a link here.On Wed, Jun 9, 2021 at 10:27 AM Michael Wong via SG19 <sg19@lists.isocpp.org> wrote:SG19 Machine Learning 2 hours. This session will focus on Reinforcement

Learning and a review of Stats feedback from

P2376R0 Comments on Simple Statistical Functions (p1708r4): Contracts, Exceptions and Special cases Johan Lundberg Hi,

Michael Wong is inviting you to a scheduled Zoom meeting.

Topic: SG19 monthly

Time: 02:00 PM Eastern Time (US and Canada) 1800 UTC Stats

Every month on the Second Thu,

June 10, 2021 02:00 PM ET 1800 UTC Reinforcement Learning, stats feedback

Jul 8, 2021 02:00 PM ET 1800 UTC Graph?Aug 12 2021 02:00 PM ET 1800 UTC Differential calculus

Join from PC, Mac, Linux, iOS or Android:

https://iso.zoom.us/j/93084591725?pwd=K3QxZjJlcnljaE13ZWU5cTlLNkx0Zz09

Password: 035530Or 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/agewu4X97Or Skype for Business (Lync):

https://iso.zoom.us/skype/93084591725Agenda:

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=-2The WG21 Practices and Procedures and Code of Conduct:

https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures1.1 Roll call of participants

1.2 Adopt agenda

1.3 Approve minutes from previous meeting, and approve publishing

previously approved minutes to ISOCPP.org1.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:June 10, 2021 02:00 PM ET 1800 UTC Reinforcement Learning, stats feedback

Jul 8, 2021 02:00 PM ET 1800 UTC Graph?

Aug 12 2021 02:00 PM ET 1800 UTC Differential calculus

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=sharinghttps://docs.google.com/document/d/1QkfDzGyfNQKs86y053M0YHOLP6frzhTJqzg1Ug_vkkE/edit?usp=sharing

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2119r0.html>

Stats feedback:

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

2.2.1.4: Stats paper

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

Oleksandr feedback:mode should be includedpython just does blind sort, mlogmconflict on some formulasmean, skewness are finekurtosis toopearson variant deletes the second termswap order of parameter in Clause 44.1.1 call the mean without projection, on a std::vectorif vector <float> means we get a float, not double because integral, if int, then I will get double backwhat is customization anticipated, please use long double?do we want a second one? No i want something else2 problems: can only specify templ argument positionally R, P first before I can give value for capital result parameterthis is unfriendly, depends on Rp2. general algo front matter say must specify templ arg explicitly because order can change between implhave we looked at non commutativity? no, we dont say anything order with parallelcan we use projection that converts to long double? third parameter is fully defined by the other 2 so yesin 4.1: why 2 kind of return parameter for integer and float? why not just float? if any integral, then double, double becomes double, float becomes floatcan integer become float?integer vector then makes no sense to compute the meanembedded HW where floats are done in HW and double is emulated, so taking result of projection customized may be rightyes GPUs can have some bigger number of floatsprefer we go with simple option returning result from deduction, so want promoted integral type? for mean ok but std. deviationif you keep natural return type of operation, then you overflow, so agree with this doube conversion by default for integral types because it gives the correct resultyes integers are problematic case and likely overflow as Marco said, in my environmentwant easy way for people to specify projectionLEWG have 2 months noticeJohan ask that empty range should return naNthis part needs rationale, and a period at the end of sentences, + infinity with mean, why not infinity? 0+infinity compute mean is not infinity. Yes but the mathematical definition of mean gets infinity by IEEE, inifnity/2=infinityany deviation from IEEE mathematical thing needs to be explained, not opposedon balance, prefer what the naive impl is if the behaviour of algo follows that, helps to reduce surprise, especially if input is not useful like inf, then possibly a branch to reduce efficiency, should be optimized for sensible inputs, least surpriseyes, I find this surprising and agrees with Jens, especially if both sequences empty, inf does not make sense,integral or integer type returned without infinity, like fixed point type in particular, also rational types as wellsince this is a required fn parameter, it does not need a defaultadding a virtual fn base abstract interface is no to me, due to performance, inlining issuecustomization in C++ we just add another template parameter or use a concept of what an accumulator is, also why the copy assignment operatoranother is parallel accumulation without synchronization, and have an additional method like aggregatecustom accumulator object is OK? yesstddev or spelled out in full should be asked to LEWG as a question and justifiedmight not matter that it is like random numbernot having range here can change the interafce, leave it as open issuea division involved here, divide by projected type, in general floating point accumulation is complex, so we dont have raw doublesa projection should interfere with the type as little as possible; can auto deduce the return type of this by defaultnaming Fisher Pearson from mumpy is it better to have descriptive names, so Fisher may be the only type; no real standardalso might want to limit the type of these somehwo; can it be any random type, or same type as the projected type, ok ignore me herecan it be arithmetic else illformed? then that constraint cannot be expanded? NO user cannot put overloads in std namespace--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.html2.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.tj9hitg7dbtrP1415: Machine Learning Layered list

https://docs.google.com/document/d/1elNFdIXWoetbxjO1OKol_Wj8fyi4Z4hogfj5tLVSj64/edit#heading=h.tj9hitg7dbtr2.2.2 SG14 Linear Algebra progress:

Different layers of proposal

https://docs.google.com/document/d/1poXfr7mUPovJC9ZQ5SDVM_1Nb6oYAXlK_d0ljdUAtSQ/edit2.5 Future F2F meetings:

2.6 future C++ Standard meetings:

https://isocpp.org/std/meetings-and-participation/upcoming-meetingsNone

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

Jul 8, 2021 02:00 PM ET 1800 UTC Graph?Aug 12 2021 02:00 PM ET 1800 UTC Differential calculus

SG19 mailing list

SG19@lists.isocpp.org

https://lists.isocpp.org/mailman/listinfo.cgi/sg19