Natalie Beams

> I think qfunction variation is the hardest part. Do we need to support different arguments to the qfunction having different precisions or can they be homogeneous (all arguments in...

I'm not sure I understand what your list is intended to represent. Cases where we use `CeedScalar *` directly as a type? `CeedBasisApply` only takes `CeedVector`s for input/output. E-Vectors are...

Right, I guess this raises another important question: how much do we want to limit the multiprecision functionality to things that happen inside a `CeedOperatorApply`? I guess if `CeedVector` provides...

> I'd think cuda-gen could still propagate the desired (ephemeral) E-vector precisions from the Basis. Yes, it could, I just thought it might be preferable to have more consistency across...

> Do you think it'll be hard to handle consistently if CeedElemRestriction is precision-agnostic (uses its arguments rather than set as state)? I've been thinking about this, and I haven't...

Okay, I'm trying to get a clear picture here of what a "`CeedVector`-centric" approach to multiprecision could look like, based on discussions so far. Some potential "general principles": - `CeedVector`s...

> Yeah, that's about right. I think CeedVectorGetArray (and relatives) can default to CeedVectorGetArray_f64 (or whatever matches CeedScalar) and we can use C11 _Generic to make it automatically match types...

But we'd still have to have separate interfaces, correct? And a way for the user to specify at compile time whether to compile the C11 or C++ interface? And I'm...

Oh! I think "inline" was the crucial thing I was missing for C++. Otherwise, I couldn't figure out how we could use `__cplusplus` if we want to consider the type...

This will make things more complicated, but I've been thinking a lot more about where the precision conversion should take place and whether or not we should limit the input/output...