Best practices in writing functions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Best practices in writing functions

Gordon Haverland
Greetings.

I've been programming  since the late 1970's.  Never got into
Octave stuff before now.  Matlab has a function (raPsd.m, from
someone in geophysics?) to do radially averaged power spectra.  I
am not looking for a power spectra, I am looking for a pair
distribution function (materials science, condensed matter
physics).

Same math, different needs.

The matlab function doesn't return anything.  It assumes log-log
plots and km as the X unit.  I need either log-linear or linear-
linear plotting, and I need to return both the radially averaged
function and the 2D matrix of the power spectrum.

It doesn't make sense to have a zillion different functions all
doing about the same thing.  Is there some octave function which
does the "best" job, that I can use for a template?  Can I
contribute my modification to Octave?  Is there guidance on
contributing modified Matlab functions?

I would have expected some of this to be FAQ, but maybe I didn't
have enough coffee.  I didn't see it.  Sorry if I missed it.

Gord
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Best practices in writing functions

c.-2

On 4 Sep 2013, at 05:08, Gordon Haverland <[hidden email]> wrote:

> Greetings.
>
> I've been programming  since the late 1970's.  Never got into
> Octave stuff before now.  Matlab has a function (raPsd.m, from
> someone in geophysics?) to do radially averaged power spectra.  I
> am not looking for a power spectra, I am looking for a pair
> distribution function (materials science, condensed matter
> physics).
>
> Same math, different needs.
>
> The matlab function doesn't return anything.  It assumes log-log
> plots and km as the X unit.  I need either log-linear or linear-
> linear plotting, and I need to return both the radially averaged
> function and the 2D matrix of the power spectrum.
>
> It doesn't make sense to have a zillion different functions all
> doing about the same thing.  Is there some octave function which
> does the "best" job, that I can use for a template?  Can I
> contribute my modification to Octave?  Is there guidance on
> contributing modified Matlab functions?

> I would have expected some of this to be FAQ, but maybe I didn't
> have enough coffee.  I didn't see it.  Sorry if I missed it.

There is a section in the FAQ about contributing:

  http://wiki.octave.org/FAQ#How_can_I_get_involved_in_Octave_development.3F

and one about porting Matlab code to Octave:

  http://wiki.octave.org/FAQ#Porting_programs_from_Matlab_to_Octave

I'd say if you want to contribute a function to Octave or Octave Forge
it doesn't matter whether it was originally written for Matlab or Octave as
long as it has a license that allows you to share modifications, in particular
you should take care taht your function does not come from the matworks File Exchange
website as explained in yet one more FAQ:

  http://wiki.octave.org/FAQ#Why_can.27t_I_use_code_from_File_Exchange_in_Octave.3F_It.27s_released_under_a_BSD_license.21

> Gord

Thanks for your interest in contributing to Octave,
HTH,
c.

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Best practices in writing functions

Richard Kirk
Hi.

I have also wanted a guide for writing oct-file .cpp code. Most of my
stuff is rushed up to fulfil a particular need, and so is unlikely to be
of use to anyone else. However, I would like to think I could write
something that could last and be used by anyone if I needed to.

Perhaps I am going about this the wrong way. There are many ways of
writing 'good code' and there are endless arguments about style. Perhaps
we should have a Hall of Fame of Good Examples nominated from the
existing database. The actual functions in the examples is not
important, though something simple and easy to understand is better than
something complicated, advanced, or obscure. The main thing is to have a
neat and solid parsing of the inputs, and a helpful reaction to errors.

I have no good suggestions, but maybe someone else has.

Cheers.
Richard Kirk

--
FilmLight Ltd.   Tel: +44 (0)20 7292 0400 or 0409 224 (direct)
Artists House, Fax: +44 (0)20 7292 0401
14-15 Manette Street
London W1D 4AP


_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Best practices in writing functions

c.-2

On 4 Sep 2013, at 11:18, Richard Kirk <[hidden email]> wrote:

> Hi.
>
> I have also wanted a guide for writing oct-file .cpp code.

well, let's start standardization from here, we usually prefer the extension .cc for C++ files in Octave (and we use .h rather than .hpp for headers)

> Most of my stuff is rushed up to fulfil a particular need, and so is unlikely to be of use to anyone else. However, I would like to think I could write something that could last and be used by anyone if I needed to.

We are working on a site where such code could be "dumped" just in case someone ever needs it at any later time:

  http://agora.octave.org/

It is not yet functional and I have no idea when or if it will ever be, though ...

> Perhaps I am going about this the wrong way. There are many ways of writing 'good code' and there are endless arguments about style.

indeed arguments about style are usually going nowhere, many things are just a matter of taste.
Using a consistent coding style, though, greatly improves readability and speeds up understanding the code,
so we do have some general guidelines:

  http://www.gnu.org/software/octave/doc/interpreter/General-Guidelines.html#General-Guidelines

does are actually an adapted version of the GNU coding style guidelines, which makes a lot of sense Octave being part of GNU.

> Perhaps we should have a Hall of Fame of Good Examples nominated from the existing database. The actual functions in the examples is not important, though something simple and easy to understand is better than something complicated, advanced, or obscure. The main thing is to have a neat and solid parsing of the inputs, and a helpful reaction to errors.

input parsing is mainly left to the function implementors but most type checking and related errors are handled reasonably well by the the *_value() methods of the class octave_value.

> I have no good suggestions, but maybe someone else has.

If it will be ever completed, Agora is expected to include the possibility to comment and vote on uploaded code snippets, that seems something similar to what you propose.

> Cheers.
> Richard Kirk

c.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave