Thanks for explaining your personal viewpoint so clearly.

Thanks, too, for the code example in the original post! It was a real
usability trap, and making sure that we address it will make the future
standard units library much stronger by removing sharp edges.

Cheers,
Chip

On Thu, Jun 20, 2024 at 6:35 PM Tiago Freire <tmiguelf_at_[hidden]> wrote:

> This was a deliberate decision, simpler designs are just better.
>
> Because of the weird way their measuring system works they are not at all
> that useful, there’s only a handful of things that you can do with it that
> traditionally makes sense.
>
> By far the most useful thing that you can do with those units is to
> convert them to their better-behaved twin (in this case Celsius to Kelvin,
> or Fahrenheit to Rankine), there really isn't much else that is worth doing
> with them.
>
> In fact, trying to do more than that is what gets you in to trouble, there
> is where people start to ask “what the hell did I actually mean when I did
> this?” and there are multiple interpretations of what they could possibly
> be, and intuitively people don’t actually know what it should mean.
>
>
>
> Of all the units that are used in practice (in my library I have 23
> different categories with each category between 2 to 13 different
> identifiable units), only 2 of them have this weird behavior.
>
>
>
> Only 2!
>
>
>
> They are not SI units, science and engineers mostly don’t work with them
> in practice, they just convert everything to kelvin to do the math and
> their problems are over.
>
>
>
> They are mostly there because some people still work with them, its
> practical utility is mostly because monkeys like to see them printed on
> screens.
>
>
>
>
>
> Because their math works differently, they have their separate type, and
> what you can do with them is purposefully limited, and the designs is very
> oriented to help you take the step that you should be taking… i.e. stop
> using them! just convert it to their well-behaved twin!
>
> I could have provided with a conversion from Celsius to Fahrenheit, and I
> think I could have still done it without it being ambiguous, but I didn’t
> see a use for it. Converting between Celsius and Fahrenheit is almost
> something that is never done in engineering. There is still a path to do
> that conversion if you still really wanted to, why should I provide another
> one that raises questions?
>
>
>
>
>
> And this is what pains with the design of mp_units. It’s only 2 units that
> are not at all that useful in practice, (people use it wrong because its
> weird and unfamiliar, and don’t behave at all like the rest). And most of
> the complexity and problems of mp_units exists only to jump trough hoops
> created by these 2 units, and still get it wrong.
>
> No joke, I believe that had these 2 units not existed, you could have
> easily deleted 80% of the mp_units code and you would not miss it.
>
> Even if you are yet unconvinced by my arguments that your problems are
> actually caused by a misunderstanding of how units works, you still have to
> ask yourself the question if it is really worth it so that you can
> dubiously save 1 cpu instruction to add one number to another, on an
> operation that doesn’t really happen all that often.
>
>
>
> It’s a really weird hill to die on, that you would be willing to
> compromise the entire design and sacrifice the whole project because you
> want to display a superscript ball adjacent to an upper-case letter C when
> subtracting 2 temperatures.
>
>
>
>
>
>
>
>
>
> *From:* Charles R Hogg <charles.r.hogg_at_[hidden]>
> *Sent:* Thursday, June 20, 2024 21:43
> *To:* Tiago Freire <tmiguelf_at_[hidden]>
> *Cc:* std-proposals_at_[hidden]; Mateusz Pusz <mateusz.pusz_at_[hidden]>;
> Chip Hogg <chogg_at_[hidden]>; Anthony Williams <
> anthony_at_[hidden]>; Johel Ernesto Guerrero Peña <
> johelegp_at_[hidden]>
> *Subject:* Re: [std-proposals] On the standardization of mp-units P3045R1
>
>
>
>
>
>
>
> On Tue, Jun 18, 2024 at 6:02 PM Tiago Freire <tmiguelf_at_[hidden]> wrote:
>
> > This makes no sense. The formula to convert from Celsius to Fahrenheit
> is simply T_F = T_C * 9 / 5 + 32. This produces the correct answer in
> every case, and there is nary a Kelvin nor a Rankine to be seen. And it
> *must* be thus, because Celsius and Fahrenheit *predate* the Rankine and
> Kelvin scales by roughly a century!
>
> > Back to the software perspective: it seems as though you propose
> performing additional runtime computational steps compared to the simple
> formula I provided just above. Why should we do that?
>
>
>
>
>
> The difference in cost is just 1 addition in the most extreme case and it
> could be optimized. But now it is really hard to do the wrong thing.
>
> You try to do something that is potentially ambiguous or dangerous, and
> the compiler says “No! fix it!” and it teaches you something, now you
> really have to pay close attention to what is happening and really know
> what you are doing.
>
>
>
> That’s the point, it’s hard to do the wrong thing, if something happens
> it’s obvious.
>
>
>
> I agree that the cost makes no *practical* difference, especially because
> well-written programs do not perform unit conversions in hot loops. I
> apologize for distracting you from the substance of my post.
>
>
>
> Returning now to that substance --- are you saying that converting a
> *temperature* in Celsius to a *temperature* in Fahrenheit is a
> "potentially ambiguous or dangerous" operation? Even in your preferred
> world, where temperature *differences* in Celsius and Fahrenheit are not
> allowed to exist? The latter policy, I can at least understand, even
> though I think it is misguided. But the former, I am at a loss to explain.
>
>
>
> Have I really understood you correctly, that you think we should prevent
> directly converting temperatures between Celsius and Fahrenheit?
>
>
>
>
>