Re: [OctDev] Functions in the core

[Jaroslav Hajek]

On Tue, Apr 7, 2009 at 4:33 AM, Daniel J Sebald <address@hidden> wrote:
> 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 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, Søren 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.
>

Maybe we differ slightly in the view of the development archive. IMO
these are just patches that can easily be reverted. I didn't even yet
add the functions to the build process, so that they won't be
installed if someone uses a snapshot - they're just there for
development testing. So I don't really regard my act as true addition.
The discussion you call for has just started :)

I don't basically object to a policy that the main archive should be
regarded as a more sacred place. But as I have explained earlier, IMO
this significantly clashes with the policy of having a linear archive,
which makes parallel development for a longer time quite difficult.
So, if that's going to happen, I think we should allow merges. I'll
then happily use my experimental repo for most of my development.
For instance, I've added a couple of new functions (and extended some)
without discussing with anyone, mostly for use in other functions. I
hope this is OK, at least nobody complained. Anyone is certainly free
to raise objections to any of my patches.

So, regarding your comments:
1. I agree that polytranslate was too long.
2. The main problem with merging the functions (as you probably
realize yourself) is that polytrans(polyscale(x,a),b) has more obvious
meaning than polyaff(x,a,b). it would be justifiable if polyaff(x,a,b)
did something more smart than just composing the two calls, but that
was not the case.
3. I don't understand the comment about translate being too general.
Can you elaborate? What other (mathematical) meanings "translate" has
other than move by a constant vector (i.e. a constant in 1D)?

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz