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