octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OF and packages (devs please read)


From: Juan Pablo Carbajal
Subject: Re: OF and packages (devs please read)
Date: Fri, 8 May 2015 08:00:11 +0200

On Fri, May 8, 2015 at 2:21 AM, Jordi Gutiérrez Hermoso
<address@hidden> wrote:
> On Thu, 2015-05-07 at 22:52 +0100, Colin Macdonald wrote:
>> On 07/05/15 22:09, Carnë Draug wrote:
>> >   Packages have a category, they provide extra functionality
>> > for a specific aim.  The language core provides general functionalities.
>> > This makes having a package for general stuff pointless
>>
>> +1  I wrote my own dirac.m and heaviside.m and proposed them for core
>> because it honestly never occurred to me to look in something called
>> "general" or "specfun" or "miscellaneous"!
>
> At risk of preaching to the choir, I will agreee general and
> miscellaneous are kind of silly, but "special functions" is a term of
> art with a couple centuries of history, a history which doesn't
> include functions such as multinomial coefficients nor the Dirac delta
> function:
>
>     https://en.wikipedia.org/wiki/List_of_special_functions_and_eponyms
>
> Then again, since most Matlab or Octave users seem unaware of what
> are usually considered special functions, and since the term itself is
> loosely defined, I suppose it's no better than "general".
>
>
>
The history of multinom is complex, indeed. I think you were involved
and, if I am not wrong, combinatorics (now disappeared) was a better
place for it, but we ended up in specfun (due to comments about not
using general) ... I was quite frustrated by the lack of a converged
criteria about this ... if we do not know where functions go (mind the
*we*, everybody has its own criteria, of that I am sure) ...

I must say that I am convinced by Carnë's arguments, the criteria to
deprecate a package is whether it is maintained or not (by the
announced maintainer). However the whole discussion brings the usual
issues up:

1. *OF to provide domain specific functions*. Searching OF is
currently a pain and what is most visible to the user is the package
name, from which they try to guess what the package contains (things
like bim, ocs, tsa. Easy, right?). Being the name a big part of what
indicates where to put a function creates already a problem (the same
function can used in different fields, so it is image? or is it a
spcefun? or is it kriging? or filtering?). If there is a source for
unmaintained functions it should also be easy to search. This is the
best service we can offer to our users, let them find things easily.
Not being currently the case, that things can be found easily, putting
functions deep within a package called symbolic (e.g. in the case of
multinom) will just reduce the usability and visibility of the
function, because people who might need its functionality will not
look into a package that is about (apparently from the name) about
symbolic computations[1]. Not to mention the lots of dependencies and
functions name added to the user workspace. I said this as a user that
has been through this problem. I am sure they will be very clever
(developer friendly) solutions to this "search" issue, we got to put
ourselves in the shoes of the users, and release a little bit the
developer perspective.

2. *Time of commit as a measure of maintenance*. At some point, if the
functions provided by a package are well established, the commits to a
package will necessarily dim out and converge to commits only to solve
compatibility problems. How often do these problems emerge? I guess
better than the time or number of commits, is to check(as suggested by
Carnë): first whether the package installs or not, second whether
there are bug reports that are not being take care of. I think we need
to settled on a criteria (group one, not just one of the current OF
head) so that we can collaborate more effectively as a group and
develop automatized admin tools (like the Makefiles that have appear
lately). This also helps new users or potential package contributors.

3. *Searchable function repository*. We need to get developers for
Agora! Seriously.

[1] With time this brings the question whether the function is
popular...is it not being use because it sucks or not needed, or is it
unfindable?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]