This note is to clarify the Brown development philosophy. We mirror the
core libraries in three levels: core, brl core , development brl core.
I view this hierarchy as a kind of maturity pipeline. The development
brl core is kept internally at Brown. When an extension or modification
is ready for public disclosure it is put on brl core , e.g. bnl. The
work may lack some elements, such as documentation in the "Book" for
final elevation to core, .e.g. vnl. The intention though is to move
through these stages. We wanted the integration stuff to be used for a
while in other algorithms and improve the test cases before final
insertion to vnl. Admittedly, we are somewhat shy about moving to core
and should be more aggressive in that regard.
On a similar topic: I vote that the RPI robust fitting library, rrel,
be put into core as soon as possible. I have used the library and it is
well-designed. The documentation can be improved and there should be an
interface to the vgl_h_matrix*<T> classes as an alternative to the
linear SVD solution methods there now. Perhaps the implementations can
be integrated so that rrel uses the vgl_h_matrix linear solve methods
internally as these are now duplicated by vgl_h_matrix*::compute and
vgl_norm_trans*. In any case, the homography interfaces should be
[mailto:vxl-maintainers-admin@...] On Behalf Of Amitha
Sent: Friday, January 21, 2005 3:31 PM
To: Gehua Yang
Cc: Kang, Kongbin; vxl-maintainers@...
Subject: Re: [Vxl-maintainers] Netlib in contrib/brl/
On Fri 21 Jan 2005, Gehua Yang wrote:
> The group at Brown committed some Netlib files that are for numerical
> integrals and are not part of current v3p/netlib. I suggest to move
> files into v3p/netlib and the corresponding C++ classes into
I wholeheartedly second that. (In core vnl/algo, of course...)
> I checked with the group and they are willing to move them into core
> there is no objection.
> The reason they did not do it is because they do not know if any
> other group is going to use it.
I think we should be contributing to the core far more than we are
doing now. Especially in the cases where the libraries already exist,
and their scope is relatively well defined. vnl+vnl_algo, for
example, is quite well defined. If you are going to implement some
new numerical algorithm, you should do it in vnl. I don't think
anyone will object, given that all the naming and dependency
guidelines are met. (For example, I recently contributed an
implementation of the Hungarian algorithm, even though probably no-one
else is using it.)
I think it should be very rare, if ever, that groups have internal
extensions to vnl, vil, vgl, etc. Otherwise, we run the risk of vxl
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Vxl-maintainers mailing list