Notes:
On Thu, Nov 14, 2024 at 7:56 AM Michael Wong <fraggamuffin_at_[hidden]> wrote:

> Hi I am not sure if this means we should hold a meeting. Given that Oliver
> just wrote a D paper with Mark,it would be good to have a look at it. So
> even though it will be 3 am, I will set it up. I will ask Phil to chair,and
> will wake up to start it, though I will likely not be able to stay up
> through it. Thank you.
>
> Hi, this SG19 meeting will focus on stats and graphs.
>
> Michael Wong is inviting you to a scheduled Zoom meeting.
>
> Topic: SG19 monthly
> Time: 2nd Thursdays 02:00 PM Eastern Time (US and Canada)
> Every month on the Second Thu,
>
>
> 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
>
> IEC Code of Conduct:
>
> https://www.iec.ch/basecamp/iec-code-conduct-technical-work
>
> 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
>
> Oliver, Richard, Pete, Mark, Michael, Jens, Scott


> 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
>
>
>
> * Jan 11, 2024 02:00 PM ET: Graph DONE
> * Feb 8, 2024 02:00 PM ET: Graph DONE
> * Mar 14, 2024 02:00 PM ET: Cancelled due to Tokyo 3-18-23
> * Apr 11, 2024 02:00 PM ET: Stats/Graph DONE
> * May 9, 2024 02:00 PM ET: Graph DONE
> * June 13, 2024 02:00 PM ET: Graph; St.louis 6-24-29 DONE
> * July 11, 2024 02:00 PM ET: Stats/ Graphs DONE
> * Aug 15, 2024 02:00 PM ET: Graph DONE
> * Sep 12, 2024 02:00 PM ET: CPPCON Sept 15-20 so canceled DONE
> * Oct 10, 2024 02:00 PM ET: Stats
> * Nov 14, 2024 02:00 PM ET: Wroclaw F2F
> * Dec 12, 2024 02:00 PM ET: Graph
>
>
> ISO meeting status
>
> future C++ Std meetings
>
> 2.2 Paper reviews
>
>
RESTART AT 2:45 PM Eastern TIME



P3495 from Oliver/Mark
>
P3495R0.pdf <https://isocpp.org/files/papers/P3495R0.pdf>
>From Mark: for `vector_two_norm`:
https://eel.is/c++draft/linalg#algs.blas1.nrm2-3
*Returns: The square root of the sum of the square of init and the squares
of the absolute values of the elements of v.*

Ask Inbal: Why isn't my paper on the agenda.
https://github.com/orgs/cplusplus/projects/30

Sg19 stats Oliver feedback

The discussion focused on the SG19 stats paper, highlighting issues with
unspecified values, state-of-the-art design, and API concerns. Key points
included the need to address unspecified results due to non-finite inputs,
insufficient elements, and floating-point exceptions. The boost
accumulators' performance charts lack error bars, and their parallel
execution should be explored. Accuracy trade-offs and the need for
consistent results between free functions and accumulators were discussed.
API concerns were raised about defaulted Booleans, return types, and the
potential for a constructor taking a range of elements. Explicit template
parameters for initial values were proposed to improve clarity.
Action Items

   - [ ] Expand the discussion on unspecified values, including
   justification for the handling of NaNs, infinities, and insufficient
   elements.
   - [ ] Provide more details on the Boost accumulators, including
   performance data with error bars.
   - [ ] Explore the design space around handling ranges with insufficient
   elements in depth, and justify the choices made in the paper.
   - [ ] Discuss the accuracy and parallel processing aspects of the
   design, including guarantees provided by the free functions versus the
   accumulators.
   - [ ] Address the API concerns, such as the use of defaulted Booleans
   and the return type of the accumulator's operator().
   - [ ] Consider the proposal to allow explicitly specifying an initial
   value for the accumulators.


Unspecified Values in the Paper

   - discusses the issue of unspecified values in the paper, highlighting
   the large surface area of unspecified behavior.
   - Concerns are raised about the implications of unspecified values at
   run-time and compile-time.
   - questions whether the C standard library functions' behavior regarding
   floating point exceptions should be carried over to statistical functions
   and accumulators.
   - The paper states that a statistic is unspecified if the range is
   consumed by nones or infinities, or if the range has an insufficient number
   of elements.

Handling Infinities and Nans

   - questions the justification for yielding unspecified results when
   inputting infinities or Nans.
   - The C standard precisely specifies what happens in these situations,
   and WG 21 has expressed a preference for Nans and infinities down.
   - raises the issue of whether Fe invalid should be raised when feeding
   in infinities or Nans.
   - The discussion includes the case of insufficient elements and the need
   for a broader design space discussion.

State of the Art and Boost Accumulators

   - mentions the broken link in the boost accumulators and the need for
   more detail for readers of 1708.
   - The performance charts could be improved by including error bars or
   stating if errors are too small to be metricable.
   - notes that the merged accumulator is inferior for computing the mean
   and variance and suggests exploring this further.
   - The discussion includes the need for a broader discussion about the
   design space and trade-offs in 1708.

Accuracy and Sorting Ranges

   - discusses the trade-off between accuracy and speed, suggesting
   sorting ranges from smallest to largest magnitude before feeding to
   statistical functions.
   - There are no guarantees on how statistical functions would process
   sorted ranges, and this needs to be specified better.
   - The question arises whether free functions and accumulators should
   give the same results, and the current reference implementation does not
   satisfy this property.
   - The discussion includes the need to explore how accumulators work with
   parallel acceleration and the trade-offs involved.

API Concerns and Design Space Considerations

   - raises concerns about defaulted Booleans and return types, suggesting
   more expressive alternatives.
   - proposes using designated initializations to make the code more
   reasonable.
   - suggests that accumulators should support a constructor that takes a
   range or a single element.
   - The discussion includes the need to explicitly specify initial values
   for templates and the potential benefits of this approach.



>From Phil: There are updates to the P3126 Overview and P3127 Background and
> Terminology papers for the Graph Library. They haven’t been published yet,
> but it would be helpful to get input on them before they’re published.
>
>
>
> Since the changes are a response to Oliver’s concerns, I think Oliver and
> Andrew would need to attend to make it useful to have a session for the
> Graph Library. Unless they want to do that, I think we can send draft
> versions to the reflector, unless there’s a better idea.
>
>
> Review BSI Graph feedback:
> As Oliver (Rosten) said "The basic premise is important, and it would be
> fantastic to have support for graphs in the standard."
>
> The main items identified were:
> Oliver:
> - This paper is long and incomplete, it has lots of details which I think
> to be irrelevant, however things that are definitely relevant are missing
> from the paper - for example definition of graph - since people have
> different ideas. We need to add a mathematical perspective to the paper.
>
> - The structure of the paper completely changed in the new revision, so now
> it’s hard to understand what and why they have done
>
> - Another missing part is discussion of graph invariants
>
> Tom (Deakin): There’s a big missing part in “Prior art” part, GraphBLAS (
> https://graphblas.org) eminently.
>
> Some other things to add:
>
> 1. The electrical circuit example needs more explanation, and I think this
> will highlight some deep issues around representing things which are
> seemingly trivially graphs, as graphs in practice. In what sense is a
> bog-standard resistor directed? I assume the reason that the graph is
> directed is because current has a sign and in an undirected graph it
> becomes ambiguous which way the current is flowing (also you may want
> components like diodes). But the directed representation also has issues:
> "can current flow from 'Vdd' to 'n0'?" should be immediately answerable
> from the properties of Vdd and its edges. There are other ways to represent
> an electrical circuit. One is as a directed graph but with incident edges
> recorded - but iiuc, this is excluded from the latest version of the paper.
> Alternatively, one could have a mathematical object, the name of which I
> actually don't know: it looks like an undirected graph, but where each
> partial edge has additional, unique, end-point data, as well as the common
> weight. Things like this are the reason why I think we need a broader group
> to look at this proposal (i.e. beyond SG19) and if we possibly can we
> should involve someone from the mathematics community. Otherwise there's a
> real danger we end up missing important insights.
>
> 2. My comment about the structure of the paper changing was a reference to
> previous comparisons with boost::graph. I'm sure these were in an earlier
> version, or am I misremembering? Either way, it would be very helpful to
> have a proper discussion of e.g. the move away from visitors.
>
> 3. Re. the definition of a graph, there needs to be a proper discussion
> about whether the paper's definition of graph is what some authors call a
> multigraph and whether it does/does not include loops. These things are
> mentioned, in passing, when introducing algorithms, but terminology needs
> to be properly established.
>
> 4. I think we're trying to do too much in one go in this paper. I think a
> great first step would be to build on mdspan and try to standardize (or at
> least understand) what might reasonably be called an unstructured span.
> This could be represented as a vector of vectors or as a vector with some
> auxiliary storage indicating where the partitions fall. The point is that
> an unstructured span, with the right invariants, is an adjacency list. If
> we can understand unstructured span and its desirable api, I think this
> will be incredibly valuable guidance for what a standardized graph
> container might look like.
>
> 5. IIUC, this paper excludes pure connectivity graphs. These are incredibly
> helpful and, if I've understood correctly that they are not supported,
> would be a major omission. Another good reason, imo, to start with
> unstructured span!
>
> 6. I'm not convinced by the load api. We don't have a load api for vector
> etc. Moreover, would it not be preferable to have appropriate constructors?
>
>
> 2.2.1: ML topics
>
> 2.2.1.1 Graph Proposal Phil Ratsloff et al
>
> Latest paper:
>
> Here’s a link to the paper (different than the previous paper reviewed).
> There are some additional updates I’m planning on making before the
> meeting.
>
>
> https://docs.google.com/document/d/1OpH-xxRri7tJTtJJIZTYmSHkkrZJkdBwm9zJ7LqolfQ/edit?usp=sharing
>
>
>
>
> 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
> *>*
>
> Array copy semantics:
> array copy-semantics paper P1997 "Relaxing Restrictions on Arrays",
> https://wg21.link/p1997
>
> 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
>
> P2681R0
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2681r0.pdf>
> More
> Stats Functions Richard Dosselmann, Michael Wong
> 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
>
> PXXXX: combinatorics: 1st Review
>
> *> std.org/jtc1/sc22/wg21/docs/papers/2020/p1708r2
> <http://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
> <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
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2119r0.html>*
>
>
> 2.2.1.4: Matrix paper
>
> 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
>
>
> 5.2 Future meeting
> * Jan 11, 2024 02:00 PM ET: Graph DONE
> * Feb 8, 2024 02:00 PM ET: Graph DONE
> * Mar 14, 2024 02:00 PM ET: Cancelled due to Tokyo 3-18-23
> * Apr 11, 2024 02:00 PM ET: Stats/Graph DONE
> * May 9, 2024 02:00 PM ET: Graph DONE
> * June 13, 2024 02:00 PM ET: Graph; St.louis 6-24-29 DONE
> * July 11, 2024 02:00 PM ET: Stats
> * Aug 15, 2024 02:00 PM ET: Graph
> * Sep 12, 2024 02:00 PM ET: CPPCON Sept 15-20 so cancelled
> * Oct 10, 2024 02:00 PM ET: Stats
> * Nov 14, 2024 02:00 PM ET: Wroclaw F2F
> * Dec 12, 2024 02:00 PM ET: Graph
>
> On Tue, Nov 12, 2024 at 11:54 AM Oliver Rosten via SG19 <
> sg19_at_[hidden]> wrote:
>
>> I'm happy to take a look at the drafts offline, after Poland.
>>
>> O.
>>
>> On Mon, 11 Nov 2024 at 19:21, Phil Ratzloff via SG19 <
>> sg19_at_[hidden]> wrote:
>>
>>> There are updates to the P3126 Overview and P3127 Background and
>>> Terminology papers for the Graph Library. They haven’t been published yet,
>>> but it would be helpful to get input on them before they’re published.
>>>
>>>
>>>
>>> Since the changes are a response to Oliver’s concerns, I think Oliver
>>> and Andrew would need to attend to make it useful to have a session for the
>>> Graph Library. Unless they want to do that, I think we can send draft
>>> versions to the reflector, unless there’s a better idea.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* SG19 <sg19-bounces_at_[hidden]> *On Behalf Of *Michael
>>> Wong via SG19
>>> *Sent:* Monday, November 11, 2024 1:14 PM
>>> *To:* sg19_at_[hidden]
>>> *Cc:* Michael Wong <fraggamuffin_at_[hidden]>
>>> *Subject:* [isocpp-sg19] SG19 Nov call
>>>
>>>
>>>
>>> *EXTERNAL*
>>>
>>> Hi all,
>>>
>>>
>>>
>>> I will unfortunately be travelling. I am still trying to figure out if I
>>> can manage the call from the opposite timezone around 2 am. Even if I were
>>> to get a volunteer to chair in my absence, I would still need to start the
>>> Zoom call which can only be done from my account.
>>>
>>>
>>>
>>> But first thing first, any subject matters and any volunteer chair?
>>> Thank you. Regards
>>> --
>>> SG19 mailing list
>>> SG19_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
>>>
>> --
>> SG19 mailing list
>> SG19_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
>>
>