No worries, this is a pretty normal process. Remember, we are always
grateful for ways to improve the paper at any stage. Our biggest fear is
that it goes out with insufficient voice.

The reason for the paper is to maintain full transparency, so that we can
point to it later and say, we saw the written feedback and this is how we
addressed it, whereas if we hid it inside Sg19, then people might question
our transparency. The written paper is also important to make sure we don't
have a constantly moving goal post - where there are further requirements
such that it is never satisfied. Of course more feedback is always welcome,
just not keep changing the same feedback once its been satisfied.

But I trust you and we worked together before where you have demonstrated
your hardwork and honour, so I am quite easy on this though other chairs
may be much more of strict and demand the paper before the next SG19
meeting of Nov 14. I think as long as you have a paper in the post Poland
mailing of Dec 15, it will be fine. We can take this email as the feedback.
In the Post Poland mailing, you can even say how we handled it and what
else is still missing.


On Tue, Oct 29, 2024 at 12:05 PM Oliver Rosten <oliver.rosten_at_[hidden]>
wrote:

> Hi Michael,
>
> Thanks for your input. What's the latest I can get away with writing this
> paper?
>
> I know the paper will be short, but I am currently rammed.
>
> Oh, and to dispel any worries: the paper will be a friendly one :)
>
> I want to see the stats functions standardized. I just think they are
> under-spec'd as it stands.
>
> O.
>
> On Tue, 29 Oct 2024 at 15:02, Michael Wong <fraggamuffin_at_[hidden]> wrote:
>
>> 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_at_[hidden]> wrote:
>>
>>> @Michael Wong <fraggamuffin_at_[hidden]> what are your thoughts?
>>>
>>> On Tue, 29 Oct 2024 at 12:18, <guy.davidson_at_[hidden]> 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_at_[hidden]>
>>>> *Sent:* 29 October 2024 12:13
>>>> *To:* guy.davidson_at_[hidden]; cxxpanel_at_[hidden]
>>>> *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_at_[hidden]> 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_at_[hidden]>
>>>> *Sent:* 28 October 2024 15:28
>>>> *To:* cxxpanel_at_[hidden]
>>>> *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_at_[hidden]
>>>> To unsubscribe send an email to cxxpanel-leave_at_[hidden]
>>>>
>>>