Use Utilities::fixed_power() where possible.

[bangerth]

This addresses the majority of what #13321 is about. In particular, it replaces the expensive calls to std::pow() by Utilities::pow() if the exponent is known and an integer.

[drwells]

For the record - I think it's reasonable to do this for the sake of uniformity but every version of GCC I tested correctly expands std::pow(x, 2) to x * x at -O1 and higher. It expands higher powers only when -ffast-math is on:

https://www.godbolt.org/z/aEPbMd8ra

[blaisb]

I still think it's a good idea to do this. It does not cost anything on our part and it ensures that it does what we think it should do. I like this PR.

[blaisb]

Other than the comment @drwells pointed out. I think this is a good PR :)!

[blaisb]

@drwells I think this is an example where std::pow and Utilities::fixed_power will be different. std::pow(x,2.) does not expand to x*x as far as I remember trying. You need to have std::pow(x,2) with an integer. I think this PR makes this a lot clearer. I prefer expliciting the fixed_power.
<

[marcfehling]

Here, you could alternatively also use std::hypot (works in 3D since C++17).

[marcfehling]

Also a good candidate for std::hypot.

[marcfehling]

same here

[bangerth]

Good points about the use of std::hypot. I did not know about this function.

[marcfehling]

Technically, with #16455 in mind, we can also write these std::hypot lines as

double norm = nrml[i * d1 + j * d2].norm();

and

const double distance_to_camera = (point - camera_position).norm();

But let's handle that in a follow-up PR.

[marcfehling]

As we decided against the use of hypot in #16455, can you delete the last commit 907d0f0 on this branch?

[bangerth]

None of these are in performance critical places, and since it's easier (and shorter) to read, let's leave these in if you don't mind too much.

[marcfehling]

@drwells If you give your okay for this PR we can merge it

[bangerth]

@drwells Ping?