On Wed, Jun 1, 2011 at 04:56, Matthew Knepley 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, PetscSca
On Wed, Jun 1, 2011 at 3:48 AM, Jed Brown wrote:
> On Wed, Jun 1, 2011 at 04:56, Matthew Knepley 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
On Tue, May 31, 2011 at 9:45 PM, Barry Smith 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 app
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 Petsc
On Mon, May 30, 2011 at 16:38, Matthew Knepley 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
On Mon, May 30, 2011 at 16:16, Matthew Knepley wrote:
> On Sun, May 29, 2011 at 2:19 PM, Jed Brown wrote:
>
>> http://petsc.cs.iit.edu/petsc/petsc-dev/rev/f7baf28c7a57
>>
>> The second argument to pow() and variants that might be called through
>> PetscPowScalar() has scalar type. Int should be
