On Tuesday 18 June 2024 14:39:44 GMT-7 Lorand Szollosi via Std-Proposals
wrote:
> Also, I find it perfectly understandable to multiply a quantity_point: if
> you tell a 6th grade student, “y’day it was 30C, today 10% more, how much
> is it today?”, they’ll likely be able to answer. And yes, the amswer
> depends on unit, it’s different if you tell this in C or F (let alone K),
> but that’s still understandable I think (and it’s in-line with real-world
> expressions of the same concept). Way less confusing I think than 30 *
> deg_C not meaning 30C on the thermometer.

And yet it would be the wrong answer *because* it's the wrong math. You can
multiply 30 by 1.1 but that's not 10% higher temperature where it counts. If
you take a volume of ideal gas at 30°C at a given pressure and perform an
isobaric transformation reducing its volume by 10%, it will not be at 33°C.
That might be a common-place answer a layman says, but no scientist or
engineer or anyone writing a program will write in an application.

The problem is multiplying or dividing a non-absolute quantity. So, would it
suffice to deny multiplication and divisions of °C and °F quantity points,
allowing only additions and subtractions to other deltas? Looking at
std::chrono, you can add two durations together, subtract one from the other,
you can multiply a duration by a scalar, add a duration to a time_point, or
subtract one from another (resulting in a duration) but you can't multiply a
time_point by a scalar or add two time_points together.

The only place I know of where °C or °F are used anywhere but temperature
points and in deltas is in talking about specific heat capacity, which is
usually written in J/(kg °C) even though that's the same as J kg⁻¹ K⁻¹. There
may be some other weird units (like the aforementioned ns/√km or kWh/1000h),
but nothing that would be as widespread.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Fleet Systems Engineering