Thanks, Michael! I appreciate your kind words.

I was worried it would take me a few days or at worst a few weeks to get to
the paper. So it looks like my worries were unfounded.

I'll put something together as soon as I am able.



On Tue, 29 Oct 2024 at 16:48, Michael Wong <fraggamuffin_at_[hidden]> wrote:

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