Thanks all! Sorry I had to leave early!
mfh

On Thu, Nov 14, 2024 at 2:14 PM Michael Wong <fraggamuffin_at_[hidden]> wrote:
>
>
> 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
> 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