Tue 09 Aug 2016 03:52:25 PM UTC, comment #10:
Yes, I understand. But the beginning of this thread suggests that the two functions might be easily confused and mahalanobis does not look all that useful to warrant keeping it alive. So in my opinion it would be better to have mahalanobis deprecated in core and not keep it alive indefinitely in the statistics package.

Tue 09 Aug 2016 03:03:29 PM UTC, comment #9:
Hi Arno. Maybe it was not obvious but mahal and mahalanobis compute two different things.

Tue 09 Aug 2016 02:48:06 PM UTC, comment #8:
Thanks, Carnë,
I think it would be quite confusing to have both mahal and mahalanobis in the statistics package. For compatibility reasons mahal is the better option of the two, so it is good as it is now.

Sun 07 Aug 2016 12:35:19 AM UTC, comment #7:
Lachlan, I added your implementation of mahal to the statistics package:
http://hg.code.sf.net/p/octave/statistics/rev/b63b78a1c3e8
as well as your improvement to core's mahalanobis.
That function is now deprecated in core, so I'm adding Arno so he can decide about what better way to have it the statistics package if he wants to.
Arno, the way I have handled this type of stuff the image and mapping package is with a configure check and renaming the functions with the extension ".m.in" . If the functions already exists, then it does nothing and pkg ignores the .in files. Otherwise it removes the .in file extension, and pkg will install them.

Fri 25 Sep 2015 06:44:05 PM UTC, comment #6:
Lachlan, thank you for the explanation about what the function ought to be doing. You don't have to do anything for now, I will take care of adding mahal to Octave Forge.
When I submitted this bug report, I sent an email to Peter John Acklam asking for permission to use his implementation which also has some extra features. I will compare them and take care of the tests.
About the current one, I guess it would move to the statistics package too. Arno Onken will weight on that. For me it makes more sense to have only one function that does this.

Fri 25 Sep 2015 05:30:24 PM UTC, comment #5:
The reason for deprecation is the maintenance burden. Every function, no matter how small, has some associated maintenance. We update the copyrights every year, we migrate it as we change build systems and build directories, we may recode parts to be more efficient as the Octave language itself changes, etc.
Since mahalanobis is not a core Matlab function we would prefer someone who has a motivation to maintain the function to perform that duty. That person could be the maintainer of the statistics package in OctaveForge, but if they also don't need this function then it needs to go to an unmaintained code repository like Matlab Central.
Carnë can guide you through submitting mahal.m to the statistics package. That is an OctaveForge package, rather than core, so I am less familiar with the approach.

Thu 24 Sep 2015 06:32:49 AM UTC, comment #4:
Thanks, Rik,
Is the mahal.m that I sent satisfactory? Is there anything else I need to do?
Out of interest, what was the rationale for deprecating mahalanobis? As I pointed out, it is a different function from mahal.
Since it isn't a common function, and isn't in Matlab, it is likely that nobody was using it, but I don't understand the motivation for removing it. If there was an existing log10 but not log, would you remove log10 when log was implemented? This is much worse than that, because log10 can easily be calculated from log, but mahalanobis can't (as?) easily be calculated from mahal.

Tue 22 Sep 2015 12:57:53 PM UTC, comment #3:
I deprecated mahalonobis on the development branch in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/afdb856e44f1). Next step will be to add mahal to the OctaveForge package.

Tue 08 Sep 2015 07:13:52 AM UTC, comment #2:
Greetings Carnë,
The function seem to do what it claims to do: it calculates the (single) distance between the points in X and the points in Y, assuming both are drawn from a Gaussian whose mean and variance is a fit to [X;Y].
This function has both a different name and different behaviour from Matlab's mahal function; was the issues that you thought it was mahal?
Attached are both an implementation of a Matlabcompatible mahal function, and a patch to Octave's mahalanobis function to improve its efficiency. I'm still not familiar with Octave's test mechanism, so could somebody please check that the new test of mahal passes.
(file #34832, file #34833)

Fri 04 Sep 2015 07:28:21 PM UTC, comment #1:
Seems like this has been broken for a while. I tried versions 4.0.0, 3.8.3, 3.6.4, and 3.4.3 and it's always wrong.
I would kick the function out of the core to the statistics package and if somebody wants to make it work there they can.

Fri 04 Sep 2015 06:19:20 PM UTC, original submission:
The function mahalanobis doesn't seem to work at all (note that it should return one value for each row of X).
I'm unsure since when it stopped working but the 7 tests it has, only check that it returns an error when input is complete garbage.
In a separate note, this function actually belongs to the statistics package named mahal.
