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_at_[hidden]> wrote:

>
>
> On Thu, Jun 10, 2021 at 12:18 PM will wray <wjwray_at_[hidden]> wrote:
>
>> Here's a link to the P2128 rebuttal draft:
>> *n2740* Arguments against a[i...] syntax for multidimensional indexing
>> <https://github.com/willwray/n2740/blob/main/P2128_rebuttal.md>
>> A bit long - here's a direct link to the Case Summary
>> <https://github.com/willwray/n2740/blob/main/P2128_rebuttal.md#case-summary>
>>
>>
>
> P2128
> variadic subscript operator takes more indexes instead of function call
> operator overload
> the authors felt it didnt matter either way
>
> python compatible interface
> it doesnt really fit within C/C++ type system
>
> vector bool and valarray gives back proxy, so what is a comma separated
> list in [ ] mean? rust and D is slice and returns array type
> single index drops rank
>
> selecting the indexes for that result
> multidim array: switch from functional indexing to square brackets
>
>
>
> mixed concerns:
> n number papers are wg14 papers, this needs to be P number for WG21
> excecpt SG22
> current 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 builtin
> so core language proposal is language agnostic
> this is not different from operator () already do as there is no
> inheritance
>
> that is covered in P2128
>
> the syntax shown here is new syntax
>
> a..b is different then 1,2
>
> conflict 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 integers
> then why ask for variaidic? its expensive because of multiple objects at
> compile time, brace_init version has init list
> its a popular feature but what is future costs
>
> we want uniform syntax,
>
>
> need to talk to more people about the cost to oppose a,b
>
>
> there is a core lang feature to allow this syntax does not affetc builtin
> types to leave C do what they want in this area
>
> objection mdspan using bracket multidim syntax, should wait for LEWG
> discussing mdspan, and that has nothing to do with C
> no impact core on builti nunless non-member operators
>
>
>
>
>
>
>
>
>>
>>
>> On Wed, Jun 9, 2021 at 11:04 AM Michael Wong <fraggamuffin_at_[hidden]>
>> 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_at_[hidden]> 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 arguments
>>>> against 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_at_[hidden]> wrote:
>>>>
>>>>> SG19 Machine Learning 2 hours. This session will focus on Reinforcement
>>>>> Learning and a review of Stats feedback from
>>>>> P2376R0
>>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2376r0.pdf> 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: 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:
>>>>>
>>>>> 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=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
>>>>> >
>>>>>
>>>>> Stats feedback:
>>>>>
>>>>> P2376R0
>>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2376r0.pdf> 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:
>>>>>
>>>>>
>>>>> https://docs.google.com/document/d/175wIm8o4BNGti0WLq8U6uZORegKVjmnpfc-_E8PoGS0/edit?ts=5fff27cd#heading=h.9ogkehmdmtel
>>>>>
>>>>> 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 included
> python just does blind sort, mlogm
>
> conflict on some formulas
> mean, skewness are fine
> kurtosis too
> pearson variant deletes the second term
> swap order of parameter in Clause 4
>
> 4.1.1 call the mean without projection, on a std::vector
> if vector <float> means we get a float, not double because integral, if
> int, then I will get double back
> what is customization anticipated, please use long double?
>
> do we want a second one? No i want something else
> 2 problems: can only specify templ argument positionally R, P first before
> I can give value for capital result parameter
> this is unfriendly, depends on Rp
> 2. general algo front matter say must specify templ arg explicitly because
> order can change between impl
>
> have we looked at non commutativity? no, we dont say anything order with
> parallel
>
> can we use projection that converts to long double? third parameter is
> fully defined by the other 2 so yes
>
> in 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
> float
> can integer become float?
> integer vector then makes no sense to compute the mean
> embedded HW where floats are done in HW and double is emulated, so taking
> result of projection customized may be right
> yes GPUs can have some bigger number of floats
>
> prefer we go with simple option returning result from deduction, so want
> promoted integral type? for mean ok but std. deviation
>
> if 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 result
>
> yes integers are problematic case and likely overflow as Marco said, in my
> environment
>
> want easy way for people to specify projection
>
> LEWG have 2 months notice
>
> Johan ask that empty range should return naN
>
> this 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=infinity
>
> any deviation from IEEE mathematical thing needs to be explained, not
> opposed
>
> on 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 surprise
>
> yes, 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 well
>
>
> since this is a required fn parameter, it does not need a default
>
> adding a virtual fn base abstract interface is no to me, due to
> performance, inlining issue
>
> customization in C++ we just add another template parameter or use a
> concept of what an accumulator is, also why the copy assignment operator
>
> another is parallel accumulation without synchronization, and have an
> additional method like aggregate
>
> custom accumulator object is OK? yes
>
> stddev or spelled out in full should be asked to LEWG as a question and
> justified
>
> might not matter that it is like random number
>
> not having range here can change the interafce, leave it as open issue
>
> a division involved here, divide by projected type, in general floating
> point accumulation is complex, so we dont have raw doubles
> a projection should interfere with the type as little as possible; can
> auto deduce the return type of this by default
>
>
> naming Fisher Pearson from mumpy is it better to have descriptive names,
> so Fisher may be the only type; no real standard
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> also 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 here
>
> can 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.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
>>>>>
>>>>>
>>>>> 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_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
>>>>>
>>>>