[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
>
> With all due respect to VTK folks, if you diff these files
>
> (vtkDoubleArray) http://www.vtk.org/doc/release/5.8/html/a04652.html
> (vtkFloatArray)  http://www.vtk.org/doc/release/5.8/html/a04661.html
>
> you'll see that they used 'sed' and not C++. ;)
>
>
Yes, these are custom parsing templates to avoid native C++ templates, yet
they work all right.

Dominik



> Chetan
>
> > 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/ec98d77f/attachment.htm>