[petsc-users] parallel vector of integers

[Dominik Szczerba]

May I draw your attention how Kitware did it in VTK - avoiding templates,
but using C++:

http://www.vtk.org/doc/release/5.8/html/a00466.html

Regards, Dominik

On Tue, Oct 18, 2011 at 6:11 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Oct 18, 2011, at 11:04 AM, Ethan Coon wrote:
>
> > Seems to me that the better argument for this would be that arbitrary
> > precision scatters (done right) would be an important step on the path
> > toward single-precision preconditioning.  Surely this would make a
> > measurable difference...
>
>     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?
>
>    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.
>
>    Barry
>
> >
> > Ethan
> >
> > On Mon, 2011-10-17 at 20:49 -0500, Barry Smith wrote:
> >> On Oct 17, 2011, at 5:46 PM, Jed Brown wrote:
> >>
> >>> On Mon, Oct 17, 2011 at 17:29, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >>> An IS is NOT a Vec for integers, it is a very different best.
> >>>
> >>> 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".
> >>>
> >>>
> >>>>
> >>>> 2) How about arbitrary parallel vectors of integers?
> >>>
> >>>  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.
> >>>
> >>> 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.
> >>
> >>   So let's increase the complexity of PETSc exponentially  JUST so one
> little thing won't be "aesthetically displeasing"?
> >>
> >
> > --
> > ------------------------------------
> > Ethan Coon
> > Post-Doctoral Researcher
> > Applied Mathematics - T-5
> > Los Alamos National Laboratory
> > 505-665-8289
> >
> > http://www.ldeo.columbia.edu/~ecoon/
> > ------------------------------------
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20111018/fb080ab4/attachment.htm>