Degrees celsius get converted to Kelvin in operations

[jl-wynen]

Given auto u = llnl::units::unit_from_string("degC");, both u*u and pow(u, 2) produce Kelvin squared. It seems that the e-flag gets lost in these operations.
I didn't test other units because I am unsure when the e-flag gets used and how.

[phlptp]

Both the iflag and eflag act like an imaginary number. When you square them they go away. iflag*iflag=one

The units those flags are used on fall into a couple categories. The first is where the unit itself has some sort of directionality to it, like VAR, which nominally is identical to Watts but represent the imaginary power component of phasor. In which case squaring it and having the flag go away is exactly what you want it to do. The other is a slight hack to discriminate units that otherwise cannot be discriminated. In this case squaring them would produce the otherwise equivalent unit squared which is still valid but doesn't work as well for display purposes I suppose.

[SimonHeybrock]

Are you implying that a different mechanism is needed to handle, e.g., degree Celsius correctly?

[phlptp]

My understanding of mathematical operations involving temperature units is that they should be carried out in Kelvins (or Rankine). Thus when developing the temperature handling mechanism. The fact that degC*degC produced K^2 was an acceptable feature and didn't impact common uses of temperature conversion. And I couldn't find any use case where the units using the flag intersected in common use case. Obviously you can come up with one, but I am curious what practical cases you are using where this is an issue.

[jl-wynen]

It didn't come up in any practical case. We were just extending our units support and ran some tests.

What you are saying sounds like we should not even allow multiplication with degree Celsius. Is there an easy way of doing that? Either in LLNL/Units or user code.

[SimonHeybrock]

And I couldn't find any use case where the units using the flag intersected in common use case. Obviously you can come up with one, but I am curious what practical cases you are using where this is an issue.

I comes up when dealing with uncertainties: A measurement in units degC has a standard deviation in degC, but a variance of degC^2. One could argue that we can store it in Kelvin, but then we would need to make sure that operations between degC and K work and give the expected results.

[phlptp]

I tweaked the eflag so it works differently than the iflag now. So degC can be raised to a power and still maintain the unit.