[petsc-users] parallel vector of integers

[Chetan Jhurani]

> From: petsc-users-bounces at mcs.anl.gov On Behalf Of Dominik Szczerba
> Sent: Tuesday, October 18, 2011 2:09 PM
> To: PETSc users list
> Subject: Re: [petsc-users] parallel vector of integers
> 
> 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++. ;)

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/
> > ------------------------------------
> >
> 
>