Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 14 01:33
    poulson closed #276
  • May 14 01:33
    poulson commented #276
  • May 14 01:30

    poulson on master

    Update README.md (compare)

  • May 14 01:24

    poulson on master

    added logo (compare)

  • May 10 21:37
    jedbrown commented #276
  • May 10 21:25
    poulson commented #276
  • May 10 21:21
    jedbrown commented #276
  • May 10 17:08
    poulson commented #276
  • May 10 17:03
    tesch1 opened #276
  • Apr 10 13:18
    JM1 commented #275
  • Apr 10 13:16
    JM1 synchronize #275
  • Apr 10 08:56
    JM1 opened #275
  • Mar 06 03:47
    Raviteja1996 closed #274
  • Mar 05 05:46
    Raviteja1996 opened #274
  • Feb 11 21:53
    BenBrock commented #228
  • Feb 11 21:52
    BenBrock commented #228
  • Feb 11 21:51
    poulson commented #228
  • Feb 11 21:50
    poulson commented #228
  • Feb 11 21:45
    BenBrock commented #228
  • Jan 23 23:57
    adambaskerville commented #273
Jack Poulson
@poulson
Since several people have voiced objections to private chat via Slack, it's probably a good idea that we have a public gitter as well
Jack Poulson
@poulson
I have been thinking that it would be worthwhile to change the README to give a tour of some of the unique functionality in the library (e.g., computing and displaying pseudospectra, fast computation of nonsymmetric eigenvectors, lattice reduction of complex bases via BKZ, and arbitrary-precision sparse Second-Order Cone Programs)
Jeff Hammond
@jeffhammond
I don't care about Gitter vs Slack but support the idea of using what the community wants. It's hard for me to keep track of all these different channels, but if you (Jack) can do it, more power to you.
Jed Brown
@jedbrown
I also don't particularly care about Gitter vs Slack, though I find Gitter to be a bit lighter weight and like openness. But I do think that having too many mechanisms just causes dilution, reducing the chance that people will connect and find the community vibrant and supportive. But I'm not very active with Elemental so this comment shouldn't carry much weight.
Jack Poulson
@poulson
Sayan was very opposed (and there have been numerous blog posts lamenting open source projects going publicly dark because of internal slack comms)
So don't feel like you need to poll this medium; it is targeted at people perusing github that have a question
Jack Poulson
@poulson
TIL about HBR and the Chatham House Rules
There is a lot to be said for HBR avoiding a sense of "us" vs. "them"
Jeff Hammond
@jeffhammond
Does HBR require Jack to log his internal monologue while developing Elemental? The "no private (substantive) discussions" clause of HBR may place an undue burden upon projects that have a small number (especially one) of contributors. Specific to me, do Sayan and I have to publicly document every substantive design discussion we had about RMAxpy for a related pull request to be in compliance with HBR?
Jack Poulson
@poulson
I think HBR is meant to be more of a guiding principle than a hard rule.
Jed Brown
@jedbrown
Yeah, I think it's a very rare project for which a strict HBR is necessary/desirable. But the principle that not just decisions but also the data used to justify the decisions take place in a public forum is important if you want a community to feel open and a meritocracy in which anyone can influence decisions to the extent they bring solid data and rationale to the discussion. If you want community members (that may be developers or future developers) to feel disenfranchised, just make decisions in private and wave your hands about private information. Note that many users may be fine with this approach; they need only trust that you know what you're doing and have all the information. But it stifles the kind of thinking and curiosity that fuels an active and enticing developer community.
Jack Poulson
@poulson
In the spirit of HBR, the next major step that I'm planning in finishing the development of the Aggressive Early Deflation Schur decomposition in https://github.com/elemental/Elemental/blob/47489373a0f632e48935af81ab4533b4ee08ccce/tests/lapack_like/HessenbergEig.cpp
Jack Poulson
@poulson
The callstack maintenance has just been greatly improved and simplified via the usage of a macro DEBUG_CSE which creates a CallStackEntry via DEBUG_ONLY(CallStackEntry cse(EL_FUNCTION)), where EL_FUNCTION maps to __PRETTY_FUNCTION__ if it is available and __func__ otherwise: elemental/Elemental@bc0cb4a
Jack Poulson
@poulson
Aggressive Early Deflation is now very nearly working for real matrices: elemental/Elemental@14a7d57
Jack Poulson
@poulson
Functioning and merged: elemental/Elemental#148
Jack Poulson
@poulson
Control structures were just introduced for the Hessenberg QR algorithm implementations and the source code for it is now pretty well organized: elemental/Elemental@1fc9c94
Jack Poulson
@poulson
Both real and complex AED now give correct answers (but are not yet optimized): elemental/Elemental@7cddfc7
Jack Poulson
@poulson
The real and complex sequential AED implementations are now incorporated under the name HessenbergSchur in the library: elemental/Elemental@a95d621
Jack Poulson
@poulson
A generic implementation of QL/QR iteration for the real symmetric tridiagonal EVP is now also well underway: elemental/Elemental@7919c6f
Jack Poulson
@poulson
the generic/arbitrary-precision symmetric tridiagonal QR algorithm is now functioning: elemental/Elemental@9f6a95d
Jack Poulson
@poulson
The interfaces to HermitianEig and HermitianGenDefEig now support all of El's datatypes: elemental/Elemental@9d29be3
Jeff Hammond
@jeffhammond
Jack: If you want to automate testing with the Intel toolchain, https://github.com/nemequ/icc-travis (https://github.com/jeffhammond/icc-travis) has details. I will try to work up a PR...
Jack Poulson
@poulson
That would be awesome. It has been a common point of failure recently
Jack Poulson
@poulson
The SVD implementation was just significantly extended: elemental/Elemental@1390194
(there is now sequential and distributed arbitrary-precision SVD via a custom bidiagonal QR algorithm implementation in the style of Demmel and Kahan's hybrid zero-shift approach)
Yves Ineichen
@iff
Hi all. In order to facilitate our libSkylark build process we were looking into ways to provide an Elemental deb package. One very simple way is to let CMake/CPack take care of that and Travis to build different variations (MPI flavours etc).
One issue that arises is wrt to the external dependencies, i.e. the patched ParMETIS. The Elemental package depends on this specific version but it would not be proper to just ship the lib in the Elemental package (conflict with i.e. Ubuntu provided ParMETIS package). The cleanest approach would be to package all the dependencies as well and put the constraints for that in the Elemental deb information. All these packages could be pushed to ppa. Any opinions/suggestions how this issue can be resolved?
Jack Poulson
@poulson
Thanks Yves!