First, I apologize sincerely for yesterday’s multiple posts. Second, thank you Ian for the kind words.
The decision is above my pay grade of course, but I want to say I’m completely ambivalent on the matter of inclusion in vnl. It would be great if it were to be maintained in vxl. On the other hand it’s a .h and not difficult to carry into the itk-based development I’m working on.
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 core.
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?
Från: Ian Scott <firstname.lastname@example.org>
Till: Peter Vanroose <email@example.com>
Kopia: Vxl-maintainers <firstname.lastname@example.org>; email@example.com
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.
> -- Peter.