Re: [OctDev] Functions in the core

[Daniel J Sebald]

Soren 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 address@hidden list before they are moved into Octave core.  
From a previous email in this thread:

> On Mon, Apr 6, 2009 at 11:13 AM, Soren Hauberg <address@hidden> 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