Hi feedback is always welcome. I have included the SG19 reflector and the author.

Procedurally, the right way to do this now, because this paper has already been voted out of SG19 several years ago (when Oliver was not there) and is now at LEWG or beyond, is to write a counter paper and offer it either as a friendly (as in I can go along with what is there but is offering these suggested changes to make it better) or hostile (as in I will oppose the paper and favor my direction ) amendment. 

It looks to me that some of the objections are technical, so it really should be handled in the SG19 and not in LEWG(these are not naming or library specific issues), so I would say still write a D paper listing the objections and proposed alternatives for improvement or rejection, but because Prof Dosselman has been  super responsive, I am sure he will catch on to this, and we will still be able to address this in the next SG19 call on Nov 14. If at that time we can't resolve this and have an update ready for Wroclaw we will inform LEWG to hold. 


So Oliver, can you write a D paper on this objection pretty much saying what you have in the email ( I and Guy can help you structure the paper)- reason being that we can post it as a P paper post meeting whether you are satisfied with the resolution or not and everyone come on Nov 14 to be prepare to discuss it. 

P.S. I will be away in the opposite time zone on Nov 14 so I might get Phil or Guy to chair it.

On Tue, Oct 29, 2024 at 8:24 AM Oliver Rosten <oliver.rosten@googlemail.com> wrote:
@Michael Wong what are your thoughts?

On Tue, 29 Oct 2024 at 12:18, <guy.davidson@hatcat.com> wrote:

I think this warrants a brief paper to ensure it is discussed in session, but unfortunately the deadline for Wroclaw has passed. I find it unlikely that the paper will leave SG19 this time though, so it is still worthwhile. Even then, I could request that the paper be brought as a late consideration when reviewing the stats paper. Reflectors are becoming busy places, even to the most dedicated of followers.

 

Cheers,
G

 

From: Oliver Rosten <oliver.rosten@googlemail.com>
Sent: 29 October 2024 12:13
To: guy.davidson@hatcat.com; cxxpanel@accu.org
Subject: Re: [Cxxpanel] Basic Statistics P1708R9

 

Procedurally, what's the best thing to do here?

 

Raise it on a reflector? If so SG19, SG6 or LEWG?

 

Or something else?

 

On Tue, 29 Oct 2024 at 12:07, <guy.davidson@hatcat.com> wrote:

I concur.

 

I believe there is a SG19 session scheduled for Wroclaw, and if not, this will also have to go through SG6. I believe there is still time to catch this.

 

Cheers,
G

 

From: Oliver Rosten <oliver.rosten@googlemail.com>
Sent: 28 October 2024 15:28
To: cxxpanel@accu.org
Subject: [Cxxpanel] Basic Statistics P1708R9

 

Hi folks,

 

I have some concerns about the stats paper. We didn't have time to get to it today, but I'd like to share my thoughts here to see what others think, before deciding how to proceed.

 

Previously, I expressed to the group the BSI my worries about these functions potentially exposing a pretty big "Unspecified Behaviour" surface. Many of the functions have preconditions that the range they consume has at least some minimum number of elements. For example, the mean needs a range with at least one element. If the range has no elements, an unspecified value is returned.

 

IIRC correctly, various options were mentioned when we talked about this at the BSI which I communicated to the author: leaving as-is, throwing, returning std:expected... The point being that the paper needs a proper discussion of the design space and a justification for the choice made. Unfortunately, the author seems to have interpreted the subsequent communication as an exhortation to use std::expected and has added section 4.7, which I do not think properly addresses the actual issue.

 

Additionally, in this section the paper then makes what I think is a dubious comparison between ranges with insufficient elements and feeding NaNs into the statistical functions. Which brings me to the next point.

 

The C-math functions are generally very well specified if you feed them NaNs/infs and so I think there needs to be some justification for why this isn't the case here. Furthermore, the paper is completely silent on whether e.g. FE_INVLAID is ever raised; again, a gap which needs to be filled.

 

Finally, there is the related question of what happens during constant evaluation if the preconditions are violated. As far as I can tell, the paper is silent on this. Should compilers just return whatever unspecified value they like? Or actually are we expecting FE_INVALID to be raised meaning it's not a core constant expression? Or...

 

My feeling is that the paper leaves some important questions unanswered. Do people concur?

 

Oliver

_______________________________________________
Cxxpanel mailing list -- cxxpanel@accu.org
To unsubscribe send an email to cxxpanel-leave@accu.org