roystgnr

Ah, I see; the markdown formatting turned those gradient indices into hyperlinks before. I'd still want to know the type of those arguments; the exact compiler error message you get...

Oh, I misunderstood, then - I thought you'd had some difficulty compiling that line so you tried to get away without it (taking the raw_type, say). If that line compiled...

I do hope you've got another way out of this. ```DualNumber``` should be workable in theory, but ```std::complex``` isn't; C++ says that [Specializing the template std::complex for any type other...

Looks like even boost might have run into this problem? They at least try to specialize ```complex```, but when you can help it they recommend you use ```boost::multiprecision::complex128``` instead, and...

> So the answer would be to roll our own moose::complex number type?! I absolutely hate this, but: yes, probably. It would be a shim to std::complex for float/double/long double,...

> I am curious what that comment really means? Me too! I wrote it in 2013, and digging through the svn logs (none of this was in git back then)...

We don't have a macro for it, but we ought to add one.

I'm not sure it's going to be possible to tell users which size to resize to. We hit that error and exit the first time we try to resize to...

We definitely don't want to automatically convert any higher-order inputs to first-order if they're going to be used for stitching; that's a good place to throw an error. It looks...

My vote would be for a single ConversionGenerator, with parameters to select the new order; that's just more flexible than the current mesh class parameter. We may have a mix...