Date: Tue, 18 Jun 2024 22:55:05 -0700

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.

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

Received on 2024-06-19 05:55:13