Re: Missing functions in "Mapping package"

[PhilipNienhuis]

NJank wrote
> On Fri, Mar 24, 2017 at 2:34 PM, Mithil <

> mithilleua@

> > wrote:
> 
>> Hello
>>
>> Thanks for your precious reply.
>>
>> As a beginner to open source, I would like to start with some very
>> elementary contributions in the beginning.
>>
>> Function signature which I mentioned in the previous mail meant "Function
>> definition and specification" which includes input-output relation,
>> parameters and their types and return value and their types.
>>
> 
> 
> I haven't worked on this package, but the following is my general
> understanding which may answer some of your questions:
> 
> For function definition as you define it, you will require some knowledge
> of the intended function. Often the expected behavior is defined as
> 'matlab
> compatible input, output, and syntax'. I.e., if a command runs under
> Matlab, ideally Octave could produce the same output from the same
> commands. In those cases the intended functional behavior can usually be
> determined from the Mathworks.com public facing documentation for the
> function you're working on, including expected input/output syntax,
> examples, etc. If you have access to Matlab you can do some trial and
> error
> yourself with function inputs/outputs, but DO NOT open any matlab
> functions
> to see their algorithms. Their code is not free and copying their
> algorithms would be a violation of their copyright.
> 
> If you do not have matlab access and the documentation is insufficient to
> answer certain questions, you can make a test script, post it to the patch
> tracker and/or mailing list, and request someone send you the output from
> matlab.
> 
> For proper form, assuming you're doing m-file coding, you can start by
> opening the Octave editor and selecting File/New/New Function.   It will
> prompt you for a function name and give you a fairly decent starting
> template for the function. The default copyright notice will be at the
> top.  There will be a texinfo block for documentation, Author info will be
> placed after than, and then the function/endfunction block should contain
> the actual code. you can change the input/output form/variable names/etc
> to
> whatever makes the most sense in your case.
> 
> Preferred coding style/conventions can be found here:
> http://wiki.octave.org/Octave_style_guide
> 
> After the endfunction line, built in tests should be added. These are
> tests
> for expected input handling, output, error cases, etc., and can be run by
> others to make sure any other changes don't break this function. Each
> function should have at least one test. Demo's can also be added for
> functions that warrant it. Would recommend peeking at some of the other
> Octave functions to see examples of these and documentation formatting.
> https://www.gnu.org/software/octave/doc/v4.2.1/Test-and-Demo-Functions.html#Test-and-Demo-Functions
> 
> Once you get a handle on coding m-files for octave, contributing would
> follow the guidelines here
> https://octave.sourceforge.io/developers.html
> 
> Philip and others may correct me, especially with regards to this package,
> but that's the understanding of the process I've been operating on. Hope
> it
> helps.

Thanks Nick,

I think that's a pretty accurate write-up.

Philip



--
View this message in context: 
http://octave.1599824.n4.nabble.com/Missing-functions-in-Mapping-package-tp4682599p4682612.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.