On Wednesday 19 June 2024 00:12:32 GMT-7 Lorand Szollosi wrote:
> Hi,
>
> > On 19 Jun 2024, at 07:55, Thiago Macieira via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> >
> > 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.
>
> Let’s agree that ‘where it counts’ is up to the user. I completely
> understand the pysics example you gave, but when you’re working in deg_C,
> I’d argue that it’s not the expectation. It were the expectation had we
> been working in K. Also, let’s not forget that K itself is already a
> non-linear unit to measure entropy, the underlying real physical property,
> so by your logic, multiplying K values won’t fly, either. Hence, we can
> either skip defining operator* for temperature points (and leave it up to
> the user), have named multiply functions (e.g., mul_val(double),
> mul_abs(double), mul_underlying(double), …), or provide value
> mutiplicationI think.

Sorry, no, let's not agree that it's acceptable to scale non-absolutes unit
types. If someone really wants to do that, they can always access the value
stored in the unit type and transform however they wish, then put it back. But
this unusual and very likely wrong use of non-absolute quantity points should
not be easy to write in C++. More importantly, it should not be easy to
*accidentally* use.

As any high-schooler who accidentally made the mistake of using temperatures
in Celsius and came up with the incorrect results will tell you that a
reminder would have been very welcome.

Your example of the non-linearity of temperature effects stems from the fact
that our models of the laws of nature is itself imperfect. PV=nRT is an ideal
gas law, meaning it models reality with enough fidelity under certain
conditions, but not at all if you step outside the regime. What store you have
to go to buy ideal gas is up to you :-)

> time_point is not the same as temperature_point, as others have said before.
> We agree that it makes little sense to define operator* for a datetime
> expressed in natural form. It might or might not make sense to define it
> for Julian dates (e.g. to tell where are we, in percentage, to overflow).
> For geospatial, it probably makes sense to say, ‘twice the latitude’, but
> not ‘twice the coordinate’. It surely makes sense to say, ‘twice the
> (absolute) yield’, or ‘commission is ten percent of the (absolute) dollar
> amount’, which is not the same as ‘tax is 30% of the (positive part of)
> dollar amount difference of exit and entry of the position’. Hence,
> usability of operator* is heavily dependent on the unit.

Scaling julian day timepoints makes as much sense as scaling Unix or monotonic
timepoints. Scaling deltas is fine.

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