Indeed, STL-like functionality (including sorting of std::vectors and the like) belongs rather in vbl than in vnl.
But there is an important vnl-specific aspect to sorting a vnl_matrix since one does not want to sort the raw container (which is 1-dimensional) but rather the conceptually two-dimensional raster (e.g. by column).
Also, irrespective of the storage choices, there should be a similar interface for e.g. vnl_matrix, vnl_sparse_matrix, and vnl_matrix_fixed.
Från: Ian Scott <scottim@...>
Till: Peter Vanroose <peter_vanroose@...>; Vxl-maintainers <vxl-maintainers@...>
Skickat: onsdag, 5 oktober 2011 16:17
Ämne: Re: vnl_vector sort with index
Here is what I propose. I'll stop objecting to this thing staying in vnl
(since at least some of the vnl_matrix sorting code is slightly
non-trivial), so long as we don't set a precedent for putting something
in vnl rather than somewhere more appropriate, just because it is easier
for some users of ITK.
BTW, I think that pretty much every other ITK-inspired improvement to
vnl has been fantastic.
You make a fair point about the incompleteness and need-driven contents
of vnl, however all the operations you listed were, to my mind,
obviously numeric ones.
I've got no problem moving mbl_index_sort (or something better) into vbl
where it can operate on vcl_vectors, vcl_deques, vnl_vectors, C arrays,
vbl_array_1ds, etc. Doesn't ITK have a similar library for such generic
On 05/10/2011 13:23, Peter Vanroose wrote:
> OK, I agree with your argument, Ian.
> On the other hand, the same argument also applies to "convenience"
> functions and/or classes like
> * vnl_bessel, gamma,beta,erf: why just these four?
> * vnl_double_3x4 etc: why aliases for just the chosen specialisations?
> * vnl_matlab_read and _write: why this specific I/O-type of classes in
> core vnl?
> * vnl_det, vnl_inverse: why just the (up to) 4x4 cases in vnl, the rest
> in vnl_algo?
> * vnl_chi_squared, vnl_cholesky,
> What I want to say: very often some functionality is implemented just
> because someone needed it, and lots of other functionality will be
> missing forever.
> And I believe that sorting matrices certainly belongs in vxl, and in the
> The only decision to make at this point is (1) is it vnl, vnl_algo, or
> maybe a new vnl_plus; and (2) what is the most useful name for that
> class or function?
> -- Peter.
> *Från:* Ian Scott <scottim@...>
> *Till:* Peter Vanroose <peter_vanroose@...>
> *Kopia:* Vxl-maintainers <vxl-maintainers@...>;
> *Skickat:* onsdag, 5 oktober 2011 10:28
> *Ämne:* Re: vnl_vector sort with index
> I don't think functionality like this should go into vnl. Index-sorting
> is a non-numerical algorithm (or at best only slightly numerical).
> Certainly sorting a vnl_vector is not a mathematically valid linear
> -algebra operation (I know that sorting can be used in some numerical
> algorithms, but that isn't the same thing.) There are thousands of
> useful but non-numerical algorithms operating on array-like data. If we
> stick even a small fraction of them in VNL, then it will no longer be a
> numerics library.
> From the VXL point-of-view there are sensible places for index_sorting,
> permutations, element-wise interpolation, etc. and they aren't VNL. ITK
> are welcome to pick and choose from the rest of them to build a VNLplus
> or VXLminus library.
> And I don't think we should compromise the core design philosophy of
> limited-scope base libraries. I have experience in our private
> repository of colleagues adding "just one extra bit of 'useful'
> functionality" to a previously well-defined library because they didn't
> think clearly about the best way to divide up their code. Those
> libraries are now much the hardest bits of our code to maintain and the
> most time-consuming in which to find stuff.
> PS moving this to vxl-maintainers.
> PPS Mike, Thanks for the code. I think it is great. I just don't want it
> in VNL.
> On 05/10/2011 08:38, Peter Vanroose wrote:
> > OK, thanks Michael and Ian.
> > I have integrated the two files in vnl & SVN committed, so it should
> > make it to ITK eventually;
> > I also adapted the test program to the "testlib" style, but I kept the
> > standalone version (with getopt), to be activated with a compile switch.