Søren Hauberg wrote: > man, 06 04 2009 kl. 21:30 +0200, skrev Jaroslav Hajek: > >>OK, I pushed both functions. I made a few other changes: > > > For the record: I do not object to these functions being added to core > Octave. > > For those not following the Octave-Forge mailing list: > Tony Richardson posted a few functions for polynomial manipulation to > the Octave-Forge maling list. Jaroslav cleaned these functions up a bit, > to make them match Octave style better, and pushed them to core Octave. > > My questions is: do we have a policy about what goes in Octave core, and > what goes in separate packages?
One main policy, I would think, is that the functions added get a good discussion on the [email protected] list before they are moved into Octave core. From a previous email in this thread: > On Mon, Apr 6, 2009 at 11:13 AM, Søren Hauberg <[email protected]> wrote: > > >> man, 06 04 2009 kl. 10:49 +0200, skrev Jaroslav Hajek: > > > >>>> 2. The coding style needs some adjustments to fit Octave's coding > >>>> styke. In particular, there should be a space between a function name > >>>> and parens, space after commas separating arguments, > > > >> > >> I don't think we enforce the Octave coding style in Octave-Forge > >> packages. I love it when people use the Octave coding style, but I don't > >> think it should be a show-stopper. Or are you intending to put these > >> functions in Octave core? > >> > > > Yes, that was my intention. Given that there's no polynomial package > or something like that. And I think the operations are very general > and not quite uncommon. But if you have a better suggestion for a > forge package to put them into... Because there is no package currently that seems appropriate for the routine isn't a persuasive reason that routines should be in the core. Before routines move into the core, I'd suggest a bit of winnowing. (That's what I imagined OctaveForge was for, among other things.) Allowing the routines to be used lets others make suggestions. For example, there is the name polytranslate(). It's too long for a routine in the core, and was appropriately trimmed. But is "translate" correct? Translate is fairly broad. More specifically, the routines appear to implement an affine translate. Perhaps "polyaff"? Also, is there some way that this can be made into a single routine? For example, polyaff(f, a) polyaff(f, a, b) where there is no ambiguity? It may not work without ambiguity, but the point is to get some concensus. Otherwise, routines move in and if later need change, they'll need to be deprecated. Dan ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
