Date: Fri, 21 Jun 2024 18:25:18 +0000
You are welcome.
A while you are at it, you may also want to investigate how you can address indirect ways of falling into the exact same trap.
Ex.
quantity<si::degree_Celsius, double> Temperature = quantity<si::degree_Celsius, double>::zero() + 28 * quantity<si::kelvin, double>::one();
std::cout << Temperature << std::endl;
std::cout << Temperature.in(si::kelvin) << std::endl;
Br,
Tiago
From: Charles R Hogg <charles.r.hogg_at_[hidden]>
Sent: Friday, June 21, 2024 19:03
To: Tiago Freire <tmiguelf_at_hotmail.com>
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
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]<mailto: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]<mailto:charles.r.hogg_at_[hidden]>>
Sent: Thursday, June 20, 2024 21:43
To: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>
Cc: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>; Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>>; Chip Hogg <chogg_at_[hidden]<mailto:chogg_at_[hidden]>>; Anthony Williams <anthony_at_[hidden]<mailto:anthony_at_[hidden]>>; Johel Ernesto Guerrero Peña <johelegp_at_[hidden]<mailto: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]<mailto: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?
A while you are at it, you may also want to investigate how you can address indirect ways of falling into the exact same trap.
Ex.
quantity<si::degree_Celsius, double> Temperature = quantity<si::degree_Celsius, double>::zero() + 28 * quantity<si::kelvin, double>::one();
std::cout << Temperature << std::endl;
std::cout << Temperature.in(si::kelvin) << std::endl;
Br,
Tiago
From: Charles R Hogg <charles.r.hogg_at_[hidden]>
Sent: Friday, June 21, 2024 19:03
To: Tiago Freire <tmiguelf_at_hotmail.com>
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
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]<mailto: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]<mailto:charles.r.hogg_at_[hidden]>>
Sent: Thursday, June 20, 2024 21:43
To: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>
Cc: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>; Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>>; Chip Hogg <chogg_at_[hidden]<mailto:chogg_at_[hidden]>>; Anthony Williams <anthony_at_[hidden]<mailto:anthony_at_[hidden]>>; Johel Ernesto Guerrero Peña <johelegp_at_[hidden]<mailto: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]<mailto: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?
Received on 2024-06-21 18:25:35