[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OctDev] Functions in the core
From: |
Daniel J Sebald |
Subject: |
Re: [OctDev] Functions in the core |
Date: |
Mon, 06 Apr 2009 21:33:52 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 |
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
- Functions in the core (was: Re: [OctDev] New polynomial functions (Resubmission)), Søren Hauberg, 2009/04/06
- Re: [OctDev] Functions in the core,
Daniel J Sebald <=
- Re: [OctDev] Functions in the core, Jaroslav Hajek, 2009/04/07
- Re: [OctDev] Functions in the core, Daniel J Sebald, 2009/04/07
- Re: [OctDev] Functions in the core, Thorsten Meyer, 2009/04/10
- Re: [OctDev] Functions in the core, Jaroslav Hajek, 2009/04/10
- Re: [OctDev] Functions in the core, Daniel J Sebald, 2009/04/12
- Re: [OctDev] Functions in the core, Thomas Weber, 2009/04/13
- Re: [OctDev] Functions in the core, Jaroslav Hajek, 2009/04/13
- Re: [OctDev] Functions in the core, Daniel J Sebald, 2009/04/13
- Re: [OctDev] Functions in the core, John W. Eaton, 2009/04/15
- Re: [OctDev] Functions in the core, John W. Eaton, 2009/04/15