On Thu, Jun 10, 2021 at 12:18 PM will wray <wjwray@gmail.com> wrote:
Here's a link to the P2128 rebuttal draft:
n2740 Arguments against a[i...] syntax for multidimensional indexing
A bit long - here's a direct link to the Case Summary 

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@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 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@lists.isocpp.org> wrote:

SG19 Machine Learning 2 hours. This session will focus on Reinforcement
Learning and a review of Stats feedback from

P2376R0Comments on Simple Statistical Functions (p1708r4): Contracts, Exceptions and Special casesJohan Lundberg


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


1. Opening and introductions

The ISO Code of conduct:
The IEC Code of Conduct:

ISO patent policy.

The WG21 Practices and Procedures and Code of Conduct:

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 Graph Proposal Phil Ratsloff et al

P1709R1: Graph Proposal for Machine Learning





Stats feedback:

P2376R0Comments on Simple Statistical Functions (p1708r4): Contracts, Exceptions and Special casesJohan Lundberg Reinforcement Learning Larry Lewis Jorge Silva

Reinforcement Learning proposal: Differential Calculus:

https://docs.google.com/document/d/175wIm8o4BNGti0WLq8U6uZORegKVjmnpfc-_E8PoGS0/edit?ts=5fff27cd#heading=h.9ogkehmdmtel Stats paper

Current github



Stats review Richard Dosselman et al


Feedback from Johan Lundberg and Oleksandr Korval


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
> Review Jolanta Polish feedback.

2.2.3 any other proposal for reviews?

2.3 Other Papers and proposals

P1416R1: SG19 - Linear Algebra for Data Science and Machine Learning

P1415: Machine Learning Layered list

2.2.2 SG14 Linear Algebra progress:
Different layers of proposal

2.5 Future F2F meetings:

2.6 future C++ Standard meetings:


3. Any other business

New reflector


Old Reflector

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


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