Add set of full-precision UDL

[esseivaju]

Following-up discussions in #2235

This update should improve the previously introduced UDL to meet the requirements stated in Constants.hh. floating-point udl will now by default perform operation in, and return real_type, avoiding accidental promotion such as in 2.5_cm * float which would previously promote to double.

For cases where we'd still like full-precision, introduce an extra set of udl with a _fp suffix returning a Constant. This setup should meet the two requirements, preventing accidental promotion, while still allowing explicit full-precision as needed with minimal boilerplate in user code.

Note that there is a small difference compared to before, where 2.5 * units::cm * runtime_float was performed in, and returned double precision regardless of CELERITAS_REAL_TYPE, now 2.5_cm * runtime_float matches real_type

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.87%. Comparing base (599cdbc) to head (9fee262).

Additional details and impacted files

@@            Coverage Diff            @@
##           develop    #2243    +/-   ##
=========================================
  Coverage    86.87%   86.87%            
=========================================
  Files         1331     1331            
  Lines        42102    42102            
  Branches     12951    13405   +454     
=========================================
  Hits         36578    36578            
- Misses        4319     4508   +189     
+ Partials      1205     1016   -189     

Files with missing lines	Coverage Δ
src/celeritas/Units.hh	100.00% <ø> (ø)

... and 118 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Test summary

 5 913 files   9 451 suites   18m 26s ⏱️
 2 151 tests  2 123 ✅  28 💤 0 ❌
32 338 runs  32 180 ✅ 158 💤 0 ❌

Results for commit 9fee262.

[sethrj]

I think we're in danger of overcomplicating the macros: especially because fp could be "full precision" or "floating point" (more common abbreviation for fp right?)

And honestly, we should have everyone prefer Quantity and its conversions...

[sethrj]

This should be EXPECT_EQ if fp is "full precision" right?

[sethrj]

@esseivaju Any more thoughts on this one? Is there a way to simplify/un-complicate things by defining a _C to make a Constant from a literal? I think we could use a little table of use cases and desired behaviors/undesirable gotchas.

Is this correct as implemented:

CELER_REAL_TYPE	expression	result
double	1.2_cm	double
double	3 * 1.2_cm	double
float	1.2_cm	double
float	3 * 1.2_cm	double
float	3.1 * 1.2_cm	double
float	3.1f * 1.2_cm	double
either	123_cm	Constant
double	UniformZField{3.4_T}	ok
float	UniformZField{3.4_T}	ok
either	UniformZField{3_T}	error: can't implicitly cast Constant to real_type

And if we returned Constant:

CELER_REAL_TYPE	expression	result type
either	1.2_cm	Constant
either	3 * 1.2_cm	Constant
float	3.1 * 1.2_cm	double
float	3.1f* 1.2_cm	float
either	123_cm	Constant
either	UniformZField{3.4_T}	error (implicit cast)
either	UniformZField{3_T}	error (implicit)

[esseivaju]

Apologize for the late reply. The behavior you listed is matching what is current in develop. What I was trying to do with the PR was to follow the Constant design's goal of avoiding accidental promotions. In your table, this scenario

CELER_REAL_TYPE	expression	result
float	3.1f * 1.2_cm	double

has unexpected promotion compared to the Constant API. I don't have a strong opinion on what would be the best behavior as I don't work on the physics part of Celeritas. So, if you want a specific behavior I'll let you choose.