<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">> May I draw your attention how Kitware did it in VTK - avoiding templates, but using C++:<br>
><br>
> <a href="http://www.vtk.org/doc/release/5.8/html/a00466.html" target="_blank">http://www.vtk.org/doc/release/5.8/html/a00466.html</a><br>
<br>
</div>With all due respect to VTK folks, if you diff these files<br>
<br>
(vtkDoubleArray) <a href="http://www.vtk.org/doc/release/5.8/html/a04652.html" target="_blank">http://www.vtk.org/doc/release/5.8/html/a04652.html</a><br>
(vtkFloatArray) <a href="http://www.vtk.org/doc/release/5.8/html/a04661.html" target="_blank">http://www.vtk.org/doc/release/5.8/html/a04661.html</a><br>
<br>
you'll see that they used 'sed' and not C++. ;)<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>Yes, these are custom parsing templates to avoid native C++ templates, yet they work all right.</div><div><br></div><div>Dominik</div><div><br></div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
Chetan<br>
</font><div><div></div><div class="h5"><br>
> Regards, Dominik<br>
> On Tue, Oct 18, 2011 at 6:11 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><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>
> The issue is handling objects that have different internal precision representations in C. Do we even try it? Or do we do it in<br>
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<br>
precision representation determined at compile time.<br>
><br>
> Barry<br>
><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<br>
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<br>
code that just uses integers) the overhead of shipping around a few integers stored as doubles is not going to kill the overall<br>
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<br>
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.<br>
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<br>
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>
><br>
<br>
</div></div></blockquote></div><br>