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