help-octave
[Top][All Lists]
Advanced

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

Re: kernel density smoother?


From: Søren Hauberg
Subject: Re: kernel density smoother?
Date: Sat, 13 Mar 2010 14:08:46 -0800

lør, 13 03 2010 kl. 16:10 +0000, skrev forkandwait:
> > a good indication that people shouldn't
> > declare me the Octave-Forge leader). Concrete ideas on how to improve
> > the situation are, however, most welcome as it is a problem that
> > concerns me.
> 
> I guess I may have been a little "flip" in my comments.  I am not sure strong 
> leadership is necessarily the answer, though it might help.  What is great 
> about Python is that there is a SINGLE, documented, well defined standard 
> library.  This library grows steadily, but there is a discussion process 
> before 
> something makes it into the library, there are votes on where it goes, and 
> then 
> it is documented/ enforced / distributed at the same level as the language 
> itself.  And whenever there is no clear consensus or the process gets bogged 
> down, Guido reserves the right to declare by fiat what should happen.

I don't think it is quite reasonable to compare Octave to Python. First
of all, Python have a lot more contributors. The lack of contributors to
Octave does make the development process a bit more ad hoc, I guess.
Secondly, we have to be concerned about Matlab compatibility; Python
does not have such a legacy (although they do seem to be struggling to
be compatible with Python). It seems people expect us to come with the
same set of basic functions as Matlab does, so we're kinda stuck there. 

> In this particular example, I would NOT have voted to have the kernel density 
> smoother function in the econometrics package, but rather in either 
> statistics 
> or core.

I don't think it belongs in the core of Octave (that's just my opinion)
as Octave is used for so many different things that most users wouldn't
be using such a function. Here you have to remember that it is not free
to include a function in the core, as the inclusion implies maintenance.

It could be that these functions are more suited for the 'statistics'
package than the 'econometrics' package. Personally, I have a hard time
telling statistics apart from econometrics (or machine learning for that
matter), so I don't know what belongs where. In practice, this decision
has been made by the actual developer of the functions.

I guess you have a point in the sense that it is hard for a user to
figure out what to install. This is a place where we could do better. If
you have concrete suggestions of functions that should be moved from one
package to another, then do feel free to bring it up on the Octave-Forge
mailing list.

> And I would have statistics ALWAYS distributed with the main package.  

You being a bit too selfish here :-)  You have to remember that most
users probably never will touch the statistics functions. And as I said
before, inclusion in the core is not free.

We could consider giving some packages recommendations. That is, we
could promote a few selected packages that are of more general use than
others ('optim' and 'statistics' comes to mind).

> THere are several "levels" of library -- planet python (or whatever it is 
> called) is where random people put up their scripts.   Then scripts that get 
> used regularly get adopted into the inner circle and tracked with the main 
> source.

I guess we have two levels: Octave core and Octave-Forge.

> I don't have a surplus of time or skill, but I have a LOT of free soft karma 
> to 
> repay if I can help.

All help is always welcome :-)  If you are not much of a coder, then we
could use help figuring out how to communicate with new users. It seems
like we have documentation that is either never read or simply isn't
written in a language new users can understand. If this can be improved
then we might be able to help more people.

Søren



reply via email to

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