On Wed, Jun 1, 2011 at 7:29 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On May 31, 2011, at 9:56 PM, Matthew Knepley wrote:<br>
<br>
> On Tue, May 31, 2011 at 9:45 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
>><br>
>> Man that PowInt is one ugly mo-fo. � Since an int is an int is an int why<br>
>> do you need the PowInt? Why not just caste with (int)? Instead of increasing<br>
>> the complexity of PETSc with PowInt? �int is acceptable in PETSc when passed<br>
>> to appropriate system calls that do take an int. �The cases PetscMPIInt and<br>
>> PetscBLASInt are marked with special names to make the code clear but I<br>
>> don't think PowInt is needed.<br>
><br>
><br>
> I did not want to downcast because PetscPow() works for (Scalar, Int) and<br>
> (Scalar, Real) so automatically casting to (int) is not right.<br>
<br>
</div> � But that is exactly what the code does, isn't it?<br>
<br>
#if defined(PETSC_USE_64BIT_INDICES)<br>
typedef int PowInt;<br>
#else<br>
typedef PetscInt PowInt;<br>
#endif<br>
<br>
static PetscScalar CPowF(PetscScalar c,PetscInt p)<br>
{<br>
 �return PetscPowScalar(c,(PowInt)p)/Factorial(p);<br>
}<br>
<br>
Isn't it casting to PowInt which is int?</blockquote><div><br></div><div>Not exactly. If I define</div><div><br></div><div>� #define PetscPowScalar(a, b) std::pow(a, (int) b)</div><div><br></div><div>then this call</div>
<div><br></div><div>� PetscPowScalar(2.0, 0.333)</div><div><br></div><div>will not work correctly. If I do not, then</div><div><br></div><div>� PetscPowScalar(2.0, 3)</div><div><br></div><div>will fail when using --with-64-bit-indices. The only solution I saw was for the user</div>
<div>to do the cast explicitly</div><div><br></div><div>� � Matt</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888"><br>
<br>
 � Barry<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
><br>
> � Matt<br>
><br>
><br>
>><br>
>><br>
>> �Barry<br>
>><br>
>><br>
>><br>
>> On May 30, 2011, at 9:53 AM, Jed Brown wrote:<br>
>><br>
>>> On Mon, May 30, 2011 at 16:38, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>><br>
>> wrote:<br>
>>> You wrote the code that takes PetscInt p!!! If you do not want that,<br>
>> change it to PetscReal.<br>
>>><br>
>>> Right, I was relying on standard promotion rules and forgot about<br>
>> std::pow(scalar, int). The exponent is a loop counter, so it can't<br>
>> reasonably be made a scalar. This whole thing could be implemented without<br>
>> calling pow() in any form, just multiplication, but it's not in a<br>
>> performance-sensitive place and I thought the code would be easier to read<br>
>> this way.<br>
>>><br>
>>> The reason I brought this up is that I thought it was worth standardizing<br>
>> a way to get an integer power (this is a common thing to need in adaptive<br>
>> controllers). Should we add a function like PetscPowRealInt()? This seems<br>
>> ugly, but it's also ugly and confusing to deal with these functions<br>
>> resolving to quite different things on C versus C++ builds (with the usual<br>
>> variability in C++ compilers). This code is over a year old so it shouldn't<br>
>> have new portability issues. The existence of a new ticket seems like a<br>
>> defect in the process, but I'm not sure what the best fix is.<br>
>><br>
>><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments<br>
> is infinitely more interesting than any results to which their experiments<br>
> lead.<br>
> -- Norbert Wiener<br>
><br>
> On Tue, May 31, 2011 at 9:45 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> �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.<br>

><br>
> I did not want to downcast because PetscPow() works for (Scalar, Int) and (Scalar, Real) so automatically casting to (int) is not right.<br>
><br>
> � �Matt<br>
><br>
><br>
><br>
> � Barry<br>
><br>
><br>
><br>
> On May 30, 2011, at 9:53 AM, Jed Brown wrote:<br>
><br>
> > On Mon, May 30, 2011 at 16:38, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> > You wrote the code that takes PetscInt p!!! If you do not want that, change it to PetscReal.<br>
> ><br>
> > 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.<br>

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

><br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>