Man that PowInt is one ugly mo-fo. Since an int is an int is an int why do you need the PowInt? Why not just caste with (int)? Instead of increasing the complexity of PETSc with PowInt? int is acceptable in PETSc when passed to appropriate system calls that do take an int. The cases PetscMPIInt and PetscBLASInt are marked with special names to make the code clear but I don't think PowInt is needed.
Barry On May 30, 2011, at 9:53 AM, Jed Brown wrote: > On Mon, May 30, 2011 at 16:38, Matthew Knepley <knepley at gmail.com> wrote: > You wrote the code that takes PetscInt p!!! If you do not want that, change > it to PetscReal. > > Right, I was relying on standard promotion rules and forgot about > std::pow(scalar, int). The exponent is a loop counter, so it can't reasonably > be made a scalar. This whole thing could be implemented without calling pow() > in any form, just multiplication, but it's not in a performance-sensitive > place and I thought the code would be easier to read this way. > > The reason I brought this up is that I thought it was worth standardizing a > way to get an integer power (this is a common thing to need in adaptive > controllers). Should we add a function like PetscPowRealInt()? This seems > ugly, but it's also ugly and confusing to deal with these functions resolving > to quite different things on C versus C++ builds (with the usual variability > in C++ compilers). This code is over a year old so it shouldn't have new > portability issues. The existence of a new ticket seems like a defect in the > process, but I'm not sure what the best fix is.
