|Re: [eigen] Bugs on bugzilla|
[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]
Hi all!I think for both we should introduce some modus operandi that helps us dropping bugs (or somehow mark them as "known issues" but filter them out in the "open bug" list). E.g., I would say that we limit "full support" to compilers still in use (or at least available) by some (core-) developer. Of course, we should (as much as possible) stay standard compatible and do not rely on features that just happen to be achievable in the "main compilers" (e.g., vectorization and alignment shall always be optional). But I would not like to maintain workarounds for every buggy compiler which is available somewhere.
On 29.05.2014 19:30, Mark Borgerding wrote:
I agree with JItse's characterization that bugzilla has many "feature
requests that no developer is really interested in", and "bugs on
Nonetheless, we should make it easier for people using "esoteric" compilers/systems to fix Eigen and make it compatible -- preferably the goal should be to have them supply patches and run unit-tests on a regular schedule.
As for feature requests, I think some kind of voting system would be nice. Does someone with access to our bugzilla-server know how to set this up?
For most core-feature requests (e.g., input-stream support (bug 622), matlab-style submatrices (bug 329)) we require some discussion first, because here multiple contradicting approaches exist.I would not focus too much on adding new rarely needed features at first. Most likely this ends up with more work of the core team supporting the implementer than it will help anyone.
Adding to Kolja's ideas: How about a tutorial aimed at Eigen *internal*
developers? e.g. Walk a user through a truly simple, developer task in
the span of a half-hour. Maybe create a algorithm for something that is
understandable and easy to code. Gram-Schmidt or Power Iteration come to
mind. I'd stress that the cmake test environment is not necessary, at
least for beginners.
Also, many algorithms look very simple if implemented completely textbook-style, but are rather complicated to make numerically stable and handle degenerated cases well. I think this is the case for both Gram-Schmidt and the Power-Method (and I also think, both are rarely required).
We already have a bunch of semi-complete modules in our unsupported category, that might help people who require exactly the parts which are implemented but there is neither any guarantee how well these work and the burdun for people who want to enhance these modules is still quite high -- and I don't think it will get much better by only simplifying the process to make further new modules.
Furthermore, I do think it is important, especially for new features, to have them properly documented and unit-tested!
Actually, adding unit-tests and enhancing the (external) documentation might be the task with the smoothest learning curve.
Musing on the "Drake Equation"-type probabilities -- the intersection of1. desire to help
circumstance, knowledge, and skills needed to be a truly effective Eigen
contributor (a set in which I am not an element) is very small indeed..
2. time to help ( this is my greatest obstacle in the last few years )
3. Linear Algebra skill : high to expert
4. C++ skill: expert level ( comfort with metaprogramming, partial5. amenability to (possibly new) tools: CMake, mercurial, and
specialization, etc) <-- I suspect this shrinks the most!
I guess that should be the very first task, to get an overview of "resources", i.e., who is capable and willing to implement or review patches? Or even just wants to take part in discussions about API enhancements (such as the above mentioned bugs 622, 329).
For that matter, I don't even have an overview who else has write access to our main repository, i.e., who would technically be able to accept patches and pull-requests.
After that, I think the next important step is to prioritize (or delete) and delegate existing feature requests.
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Tel: +49 (421) 218-64252
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|