April 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] various dot products messed up for complex numbers?
by Barry Smith 15 Apr '12

15 Apr '12

Sure it is and arbitrary convention that isn't universal. My original email comment "real mathematicians" was just a wise-crack Barry On Apr 15, 2012, at 1:49 PM, Jed Brown wrote: > On Sun, Apr 15, 2012 at 13:32, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > (ax,y) = a(x,y) > > This is an arbitrary convention that isn't universal. You occasionally see a(x,y) = (x,Ay). You certainly see <x|H|y> which is equal to <x|H y>. I like to write things like > > v^H J(u) w \sim J[u](v,w) = (v,J[u] w) = \int_\Omega v^* \cdot J(u) w > > where the left side of the \sim is discrete with v,u,w vectors and J(u) the Jacobian; and versions to the right are all continuous (with J[u] an operator and J(u) the tensor-valued field). > > If I had to use that screwy inner product notation, this would become > > v^H J(u) w \sim J[u](w,v) = (J[u] w,v) = \int_\Omega v^* \cdot J(u) w > > which is needlessly error-prone.

1 0

Re: [petsc-dev] various dot products messed up for complex numbers?
by Jed Brown 15 Apr '12

15 Apr '12

On Sun, Apr 15, 2012 at 13:32, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > (ax,y) = a(x,y) This is an arbitrary convention that isn't universal. You occasionally see a(x,y) = (x,Ay). You certainly see <x|H|y> which is equal to <x|H y>. I like to write things like v^H J(u) w \sim J[u](v,w) = (v,J[u] w) = \int_\Omega v^* \cdot J(u) w where the left side of the \sim is discrete with v,u,w vectors and J(u) the Jacobian; and versions to the right are all continuous (with J[u] an operator and J(u) the tensor-valued field). If I had to use that screwy inner product notation, this would become v^H J(u) w \sim J[u](w,v) = (J[u] w,v) = \int_\Omega v^* \cdot J(u) w which is needlessly error-prone.

1 0

Re: [petsc-dev] various dot products messed up for complex numbers?
by Barry Smith 15 Apr '12

15 Apr '12

On Apr 15, 2012, at 1:09 PM, Jed Brown wrote: > On Sun, Apr 15, 2012 at 12:55, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Real mathematicians conjugate the second one :-) > > I never unrderstood that choice. I like vectors to be column vectors, one forms to be row vectors, and operations to have standard fixity. How some mathematicians ended up with infix operators and postfix inner products is beyond me. I checked a couple of analysis books I have at home and they all conjugate the second argument. For inner products over a real field one has (x,y) = (y,x) (x+w,y) = (x,y) + (w,y) (ax,y) = a(x,y) (x,x) \ge 0 (x,x) = 0 only if x = 0 Now extend to complex fields, if the only change you make is (x,y) = complex conjugate ((y,x)) but keep everything else the same then the conjugate has to be done on the second argument. If you did it on the first you would get (ax,y) = conjugate(a) (x,y). Of course this is arbitrary and it would be fine to also change the (ax,y) = a(x,y) to conjugate(a) (x,y). but it just isn't done :-) Barry > > > The code to check is PETSc's conjugate gradient, there the conjugate does mater :-). > > Looks right to me. > > ierr = KSP_MatMult(ksp,Amat,P,W);CHKERRQ(ierr); /* w <- Ap */ > ierr = VecXDot(P,W,&dpi);CHKERRQ(ierr); /* dpi <- p'w */ >

1 0

Re: [petsc-dev] Reminder: *every* symbol with extern linkage *must* be namespaced
by Jed Brown 15 Apr '12

15 Apr '12

On Sun, Apr 15, 2012 at 13:09, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > So MPIPetsc_xxx() for functions and MPIPETSC_XXX for "macro-like" all > caps names? > > Not particularly appealing but I guess it is the right thing to do. > I agree. I'll use this for anything new and rename the old ones when my tree emerges from turmoil, unless someone else beats me to it.

1 0

Re: [petsc-dev] various dot products messed up for complex numbers?
by Jed Brown 15 Apr '12

15 Apr '12

On Sun, Apr 15, 2012 at 12:55, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Real mathematicians conjugate the second one :-) > I never unrderstood that choice. I like vectors to be column vectors, one forms to be row vectors, and operations to have standard fixity. How some mathematicians ended up with infix operators and postfix inner products is beyond me. > > The code to check is PETSc's conjugate gradient, there the conjugate > does mater :-). > Looks right to me. ierr = KSP_MatMult(ksp,Amat,P,W);CHKERRQ(ierr); /* w <- Ap */ ierr = VecXDot(P,W,&dpi);CHKERRQ(ierr); /* dpi <- p'w */

1 0

Re: [petsc-dev] Reminder: *every* symbol with extern linkage *must* be namespaced
by Barry Smith 15 Apr '12

15 Apr '12

On Apr 15, 2012, at 12:59 PM, Jed Brown wrote: > On Sun, Apr 15, 2012 at 12:52, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Curse it, these are all cases of MPI didn't do something right or some MPI implementor got lazy and didn't include something they should have. They should really start with MPI. Maybe MPILazyBastards_xxxx() it doesn't seem right to name space any of them with PETSc!!!! MPImissing_, MPIFU_ (for MPI fuck up). > > MPIPetsc_xxx so it's at least clear who is providing the "fixed" version (and which package's configure it may depend on). MPIU_INT, for example, is intimately bound to the way PETSc was configured, so maybe it should be MPIPETSC_INT? So MPIPetsc_xxx() for functions and MPIPETSC_XXX for "macro-like" all caps names? Not particularly appealing but I guess it is the right thing to do. Barry > > > > PetscMPI_Iallreduce(), Petsc_MPI_Iallreduce(), > > This is a clash between two naming conventions, the silly MPI one with _ and the reasonable Petsc one without a million _. You know the one I like. > > Are you sure we shouldn't continue to use MPIU? We have squatters rights to that prefix since we've used it for 18 years. It looks good and makes clear what those functions are for. > > It's true, but it would be a shame for some version of PETSc to become incompatible with some version of MPICH due to a symbol collision (though they use visibility on many platforms, so the symbol can be used within the library, but not visible outside).

1 0

Re: [petsc-dev] Reminder: *every* symbol with extern linkage *must* be namespaced
by Jed Brown 15 Apr '12

15 Apr '12

On Sun, Apr 15, 2012 at 12:52, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Curse it, these are all cases of MPI didn't do something right or some > MPI implementor got lazy and didn't include something they should have. > They should really start with MPI. Maybe MPILazyBastards_xxxx() it doesn't > seem right to name space any of them with PETSc!!!! MPImissing_, MPIFU_ > (for MPI fuck up). > MPIPetsc_xxx so it's at least clear who is providing the "fixed" version (and which package's configure it may depend on). MPIU_INT, for example, is intimately bound to the way PETSc was configured, so maybe it should be MPIPETSC_INT? > > > PetscMPI_Iallreduce(), Petsc_MPI_Iallreduce(), > > This is a clash between two naming conventions, the silly MPI one with _ > and the reasonable Petsc one without a million _. You know the one I like. > > Are you sure we shouldn't continue to use MPIU? We have squatters > rights to that prefix since we've used it for 18 years. It looks good and > makes clear what those functions are for. > It's true, but it would be a shame for some version of PETSc to become incompatible with some version of MPICH due to a symbol collision (though they use visibility on many platforms, so the symbol can be used within the library, but not visible outside).

1 0

Re: [petsc-dev] various dot products messed up for complex numbers?
by Barry Smith 15 Apr '12

15 Apr '12

On Apr 15, 2012, at 12:45 PM, Jed Brown wrote: > On Sun, Apr 15, 2012 at 12:42, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > uses the complex conjugate of the FIRST argument. > > So it looks like everything is major broken for the complex case. > > Is this more than a documentation error in PETSc? I.e. is VecDot() _used_ in such a way that the second argument is actually conjugate, or does it use the standard convention that the first is conjugate? Real mathematicians conjugate the second one :-) The code to check is PETSc's conjugate gradient, there the conjugate does mater :-). Barry

1 0

Re: [petsc-dev] Reminder: *every* symbol with extern linkage *must* be namespaced
by Barry Smith 15 Apr '12

15 Apr '12

On Apr 15, 2012, at 12:42 PM, Jed Brown wrote: > On Sun, Apr 15, 2012 at 12:17, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > We use MPIU_XXX as a replacement for missing/broken/... MPI_XXX > > The reason they start with MPI is to indicate their very close relationship with their "true" MPI cousins. > > I think the natural replacement is PETSC_MPI_XXX, if we make this change then the "obvious" connection to MPI_XXX is weaker. But proper naming spacing does dictate we make this change. > > Note that there are also functions, e.g. MPIU_File_read_all(), Oh yeah, I got bored with my etags search before I came upon any of those functions so forgot about them. > which could become Petsc_MPI_File_read_all() or PetscMPI_File_read_all() as you prefer. > > I'm providing other implementations of MPIX_Iallreduce() which I'd like to namespace consistently. Is it PetscMPI_Iallreduce(), Petsc_MPI_Iallreduce(), or something else? Curse it, these are all cases of MPI didn't do something right or some MPI implementor got lazy and didn't include something they should have. They should really start with MPI. Maybe MPILazyBastards_xxxx() it doesn't seem right to name space any of them with PETSc!!!! MPImissing_, MPIFU_ (for MPI fuck up). > PetscMPI_Iallreduce(), Petsc_MPI_Iallreduce(), This is a clash between two naming conventions, the silly MPI one with _ and the reasonable Petsc one without a million _. You know the one I like. Are you sure we shouldn't continue to use MPIU? We have squatters rights to that prefix since we've used it for 18 years. It looks good and makes clear what those functions are for. Barry

1 0

Re: [petsc-dev] various dot products messed up for complex numbers?
by Jed Brown 15 Apr '12

15 Apr '12

On Sun, Apr 15, 2012 at 12:42, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > uses the complex conjugate of the FIRST argument. > > So it looks like everything is major broken for the complex case. > Is this more than a documentation error in PETSc? I.e. is VecDot() _used_ in such a way that the second argument is actually conjugate, or does it use the standard convention that the first is conjugate?

1 0