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