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

[Matthew Knepley]

On Wed, Jun 1, 2011 at 3:48 AM, Jed Brown <jed at 59a2.org> wrote:

> On Wed, Jun 1, 2011 at 04:56, Matthew Knepley <knepley at gmail.com> wrote:
>
>> I did not want to downcast because PetscPow() works for (Scalar, Int) and
>> (Scalar, Real) so automatically casting to (int) is not right.
>
>
> 1. There is no PetscPow()  :-)
>
> 2. In C, PetscPowScalar *always* has arguments (PetscScalar, PetscScalar),
> *not* (PetscScalar,PetscReal), (PetscScalar, int), or other variants. The
> fact that it "works" with other combinations is only because of C's
> automatic promotion rules. C++ has different promotion rules and overloads
> the name for (PetscScalar, int).
>

Yes, C was not producing a problem.


> This still isn't (PetscScalar, PetscInt). Indeed, if PetscInt is int64_t,
> then PetscPowScalar(some_scalar, some_int) fails. That is the problem you
> fixed by introducing PowInt. But PowInt is always defined to be int, either
> by explicit typedef (with PETC_USE_64BIT_INDICES) or indirectly (because
> PetscInt was already typedef'd to int). So "typedef int PowInt" will always
> be equivalent to what you have.
>

BUT that cast is explicit so the user knows. I do not see a way to do it
implicitly. If they really wanted a Scalar, it would
get cast to an int. Alternatively, If they really wanted and int, it would
get cast to a Scalar.

   Matt

-- 
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/20110601/0e19a5e9/attachment.html>