[petsc-dev] What was the 64-bit problem with pow()?

Matthew Knepley knepley at gmail.com
Tue May 31 21:56:45 CDT 2011


On Tue, May 31, 2011 at 9:45 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>  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.


I did not want to downcast because PetscPow() works for (Scalar, Int) and
(Scalar, Real) so automatically casting to (int) is not right.

   Matt


>
>
>   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.
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110531/1d81da7b/attachment.html>


More information about the petsc-dev mailing list