On Thursday, 29 May 2025 22:06:49 Brasilia Standard Time Jan Schultke wrote:
> > One common case of needing both are time unit conversions: converting from
> > a
> > seconds counter to hours, minutes and seconds. Or converting to struct
> > timespec.
>
> Yeah fair point, these things happen. You only commonly need both for
> specific rounding modes though. In your time unit example, that would
> presumably involve rounding towards zero, and getting the remainder for
> that is built into the language. If it used rounding towards negative
> infinity, that's also covered with std::rem_divisor_sign.

One thing that wasn't clear to me in reading your paper is why the remainder
functions don't have the same name as the quotient ones. Whenever I want both,
I want both of the same mathematical division. In other words, how would I
know that I need rem_divisor_sign for div_towards_neg_infinity? Why aren't both
functions suffixed the same way?

And for timestamp conversions, that is very likely. A time stamp of -64s as in
"64 seconds before midnight" is "-1 23:58:56".

> Once you get into the more exotic modes like std::div_ties_, it's unclear
> what you actually need the remainder for, and the adjustments to the result
> of (x / y) made are so complex that you're better off computing the
> remainder using the quotient afterwards than to make matching adjustments.

I don't buy this. There is exactly one remainder associated with a particular
division that satisfies the equation
   dividend = divisor * quotient + remainder

If the argument is to make it easy for people not to get things wrong, then
"they're better off computing" is not the answer.

> Yeah fair point, there's a possibility of introducing a dilemma of choice.
> I'm not really convinced it would be a big problem though. The user can
> just not call std::div_to_odd if they don't need it.

You did confuse me, because the paper does talk about homogeneising the
distribution. So which one should I choose if I want that?

> I'm also worried about creating some swiss cheese of a function set where
> some rounding modes are there top-level, some only for tie breaking, and
> you'll never hear the end of the bikeshedding which ones should be included
> or not. It's quite simple to just include all of them since they're all
> small and easy to implement.

I understand the challenge, but that's chickening out. Your job and that of
the committee is to come up with an API that is consistent, usable and as
intuitive as can be for both lay people and those with more knowledge of the
issue but who couldn't write the implementations themselves. Therefore, if
it's worth doing, it's worth doing right, and therefore you and they should
spend the time to select the most appropriate ones. Don't just add all of
them, because then that will not be intuitive and you'll confuse the users.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Platform & System Engineering