May I draw your attention how Kitware did it in VTK - avoiding templates, but using C++:<div><br></div><div><a href="http://www.vtk.org/doc/release/5.8/html/a00466.html">http://www.vtk.org/doc/release/5.8/html/a00466.html</a></div>
<div><br></div><div>Regards, Dominik<br><br><div class="gmail_quote">On Tue, Oct 18, 2011 at 6:11 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Oct 18, 2011, at 11:04 AM, Ethan Coon wrote:<br>
<br>
> Seems to me that the better argument for this would be that arbitrary<br>
> precision scatters (done right) would be an important step on the path<br>
> toward single-precision preconditioning. Surely this would make a<br>
> measurable difference...<br>
<br>
</div> The issue is handling objects that have different internal precision representations in C. Do we even try it? Or do we do it in C++ via templates yuck or some other way?<br>
<br>
So far, despite a few aborted attempts, we've punted on do this at all and the objects can only have a single internal precision representation determined at compile time.<br>
<font color="#888888"><br>
Barry<br>
</font><div><div></div><div class="h5"><br>
><br>
> Ethan<br>
><br>
> On Mon, 2011-10-17 at 20:49 -0500, Barry Smith wrote:<br>
>> On Oct 17, 2011, at 5:46 PM, Jed Brown wrote:<br>
>><br>
>>> On Mon, Oct 17, 2011 at 17:29, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>>> An IS is NOT a Vec for integers, it is a very different best.<br>
>>><br>
>>> Besides immutability, an IS is contravariant. Although ISGeneral is implemented with a similar data structure, it isn't meant to be used as "a Vec for integers".<br>
>>><br>
>>><br>
>>>><br>
>>>> 2) How about arbitrary parallel vectors of integers?<br>
>>><br>
>>> You can put the integers in a Vec. Unless your code is all integers (which is unlikely because why are you using PETSc for a code that just uses integers) the overhead of shipping around a few integers stored as doubles is not going to kill the overall performance of the code. In fact, I will faint away if you can even measure the difference. This is likely a case of premature over optimization.<br>
>>><br>
>>> The downside of this is that single precision is useless because the mantissa isn't big enough to hold useful integer sizes. If you always have at least double precision, then you can still solve big problems this way (2^53 is a big number), but I still find it aesthetically displeasing.<br>
>><br>
>> So let's increase the complexity of PETSc exponentially JUST so one little thing won't be "aesthetically displeasing"?<br>
>><br>
><br>
> --<br>
> ------------------------------------<br>
> Ethan Coon<br>
> Post-Doctoral Researcher<br>
> Applied Mathematics - T-5<br>
> Los Alamos National Laboratory<br>
> 505-665-8289<br>
><br>
> <a href="http://www.ldeo.columbia.edu/~ecoon/" target="_blank">http://www.ldeo.columbia.edu/~ecoon/</a><br>
> ------------------------------------<br>
><br>
<br>
</div></div></blockquote></div><br></div>