Re: Missing functions in "Mapping package"

[Nicholas Jankowski]

On Fri, Mar 24, 2017 at 2:34 PM, Mithil <address@hidden> 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.

Nick Jankowski