User:Josiah425:TISEAN Package: Difference between revisions

From Octave
Jump to navigation Jump to search
 
(19 intermediate revisions by the same user not shown)
Line 1: Line 1:


= TISEAN Package Porting Project  =
= TISEAN Package Porting Project  =
== General division and time estimation ==
== Goal of the project ==
Porting of the TISEAN package has a couple parts. First part is making the FORTRAN and c programs accessible to Octave. Second part would be creating makefiles and putting all that code in a neat package.  
The goal of this project is not to port the entire TISEAN package to octave. That would be a desired outcome though it might not be feasible within the time constraints. The goal of this project is to give the TISEAN package a solid start and to port as many functions as possible to create a solid foundation for the future.
I have divided the first part into three sub-parts:
# FORTRAN ones that can be re-implemented easily in m-files (a good example of such a program is 'henon')
# the FORTRAN ones that need to be linked to oct files (an example of such a program is 'project')
# c programs which also need to be linked to oct files.
As linking FORTRAN code to oct code is most difficult of those three tasks I assume in my estimates that it will take me around 3 hours for each program, there are 28 in this category. Thus I assume it will take me about 2-3 to complete this task.  


Next there are the programs in the Tisean package which can be ported to m-files easily. As this is not as difficult a task as linking FORTRAN code to oct files I have allotted 2 hr for each program. I have put 5 programs in this category thus it should only take me about 2 days to complete this task.
== General division ==
Last but not least, I have 41 programs in C that need to be linked to Oct files. As this task seems fairly straightforward I have allotted 2 hours for each program. There are 41 programs in this category, therefore this task should also take me 2-3 weeks.  
As the TISEAN package consists of 74 programs I have divided the first part into three sub-parts:
# FORTRAN ones that can be re-implemented easily in m-files (a good example of such a program is 'henon') -- there are 5 programs in this class
# C programs which also need to be linked to oct files (an example is 'ghkss') -- there are 41 programs in this class
# FORTRAN ones that need to be linked to oct files (an example of such a program is 'project') -- there are 28 programs in this class
They are ordered so that according to my estimates the difficulty rises with the number. This is because typecasting and implicit typing (which is included in most of the FORTRAN files in the TISEAN library) can be problematic sometimes.


I plan to allot another 2 weeks for cleaning the code up. Therefore, the a grand total is about 7 weeks.  
This number can be brought down significantly. This is because some programs are deprecated, others are just C/FORTRAN copies of each other, others are not important in GNU Octave (such as 'compare' and choose'). After taking the factors above into consideration the number of functions that need to be ported drops to 49. I have prepared a detailed discussion of all of those functions [[User:Josiah425:TISEAN_Package:Table_of_functions| here]]. This number will further drop once certain programs are confirmed to have similar programs in GNU Octave or some packages in Octave Forge.


My plan is to tackle the hardest task first, that is to work on the FORTRAN programs that need to be linked to oct files.  
Apart from the qualitative division I propose a work oriented division. In it each subpart can be tackled separately and create an entity in-and-of-itself. I chose to work along the lines of the articles about implementations of nonlinear timeseries included in the documentation. This article discusses various algorithms and what certain programs mean. It can be found [http://www.mpipks-dresden.mpg.de/~tisean/Tisean_3.0.1/docs/chaospaper/TiseanHTML.html here]. I will discuss in which order I would like to port various topics from this article and where my work currently stands.
==== Nonlinear noise reduction ====
This is the first topic I chose. It is because it contains programs from all three categories. It is also relatively small -- it contains 3 programs: project, lazy, ghkss. I have chosen to further implement addnoise and henon, to demonstrate how project and ghkss work. Thus this topic contains programs from each category:
* Re-implementable in mfile (henon)
* Linkable to FORTRAN (project, addnoise, lazy)
* Linkable to c (ghkss)
I have already started working on this stage. My progress can be viewed at [https://bitbucket.org/josiah425/tisean https://bitbucket.org/josiah425/tisean]. So far I have implemented addnoise, project and re-implemented henon as an mfile. As most work on this topic has been completed I estimate that finishing it up will take around 2 days -- throughout my outline I estimate about 1 day per program (that includes documentation and testing).


There are 9 weeks designated for GSoC so I hope the extra room will allow me easily finish on time.
==== Phase space representation ====
== Explanation of what I want to do with each file ==
This is the next topic that needs to be implemented. This is because it contains programs (especially 'delay') that are used to visualize data. Whenever an example is given in the package the resulting data is routed through 'delay' before it is plotted. Apart from delay it also contains other functions that can divided into the following categories:
Each FORTRAN file that need to be linked to an Oct file needs work done on it. I plan to take the following steps with each FORTRAN program:
* Linkable to c (delay, corr, mutual, false_nearest, pca)
# Change the FORTRAN program into a subroutine. The arguments of this subroutine will be the parameters that this program would have normally read from the user during execution.
There are two more programs in this section of the article they are: 'autocorr' and 'pc', both implemented in FORTRAN. There is no need to port them as according to the documentation ([http://www.mpipks-dresden.mpg.de/~tisean/Tisean_3.0.1/docs/contents.html here]) they are redundant with other functions. Further more, it is likely 'corr' does not need to be implemented, because 'xcorr' in signal package seems to have similar functionality. This has not been confirmed yet, once that occurs, a definite answer can be given.
# Move input parsing and validation from the FORTRAN files to the .cc file which will link the respective fortran file to it. This will make the fortran subroutines 'dumb' and unable to distinguish between good and bad data.  
Assuming around a day for each function (with testing and documenting the usage) I assume this stage will take a little under a week.
# Eliminate all file inputs and outputs. The fortran programs write and read data to/from files. This is unnecessary in Octave, as data can be supplied and retrieved to/from these subroutines directly via oct files.
==== Nonlinear prediction ====
# Test the oct file against the original library to ensure I didn't make mistakes.
This seems like a reasonable next step. It consists of the following programs:
* Linkable to FORTRAN (predict, upo)
* Linkable to C (lzo-test, lzo-gm, lzo-run, lfo-ar, lfo-gm, lfo-run, rbf, polynom, xzero)
Again assuming around a day for each program (with testing, documenting usage and writing examples) I assume this stage will take about two weeks.
==== Lyapunov exponents ====
This stage will include:
* Linkable to C (lyap_r, lyap_k, lyap_spec)
It will take about 2-3 days to complete.
==== Dimensions and entropies ====
This topic is next on the list. Programs it include are as follows:
* Linkable to FORTRAN (c2, c2t, c2d, c2g, c1)
* Linkable to C (d2, boxcount)
This part of the article also mentions 'c2naive' which is implemented in FORTRAN, but it is also described as redundant by the documentation ([http://www.mpipks-dresden.mpg.de/~tisean/Tisean_3.0.1/docs/contents.html here])
This stage should take little over a week. I expect this stage and the previous one to take about two weeks.
==== Testing for nonlinearity ====
This is the last topic I intend to tackle. The following programs are included here:
* Linkable to FORTAN (surrogates, randomize , timerev)
This stage should take me about 3 days to complete.
==== Tutorial ====
I also plan to port all of the functions needed for the four exercises described in the 'Tutorial' section of the documentation. The programs that need to be ported additionally are as follows:
* Linkable to FORTRAN (stp)
* Linkable to C (ar-model, d2, poincare, recurr, nstat_z)
The programs: 'spectrum', 'historgram', 'extrema', 'corr' need to have a confirmed equivalent function in GNU Octave.
This stage should take me about a week.
=== Notes on time estimates ===
Totaling up the above estimates it should take me 6-7 weeks to complete my task as outlined above.  


I plan to do similar steps for the c files. I believe this stage will be easier as the c code is much better organized and eliminating input validation & parsing, file inputs and outputs should be a much easier task.
My estimates might be high, but I believe it is more important to complete the task thoroughly than to port more programs haphazardly.


== Where I intend to start ==
== Details of work on each program ==
 
* FORTRAN linking
I will start with a small step of porting all of the functions needed for [http://www.mpipks-dresden.mpg.de/~tisean/Tisean_3.0.1/index.html| Nonlinear noise reduction]. The functions I will need is: henon (for generating data), addnoise, ghkss and project. They cover all of the three categories I talked about in the first section. I have already reimplemented henon in m-file, it is accessible [http://agora.octave.org/snippet/hOzw/ here]. Both addnoise and project are in FORTRAN and need to be linked to C++ files and compiled into oct files. Lastly, ghkss is implemented in c and needs to be linked to a C++ oct file.
For each FORTRAN program that I intend to link to a oct-file I intend to:  
# Strip the program of its input validation and transform it into a subroutine
# Create a .cc program (compiled into an oct-file) that will launch the stripped FORTRAN subroutine; this .cc program will also not contain input validation, it will be for internal use only
# Create a m-file that will perform input validation and launch the .cc and contain usage documentation
* C linking
I intend to do here something similar to the FORTRAN programs, although, it might be better to not create any extra m-files and incorporate the program's existing input validation into the .cc file. This might be a desired course of action. I will make a decision once I complete one such linking program.  
* Reimplementing in mfile
This is quite straightforward, although it is important not to make a mistake while taking this approach.

Latest revision as of 01:58, 11 April 2015

TISEAN Package Porting Project[edit]

Goal of the project[edit]

The goal of this project is not to port the entire TISEAN package to octave. That would be a desired outcome though it might not be feasible within the time constraints. The goal of this project is to give the TISEAN package a solid start and to port as many functions as possible to create a solid foundation for the future.

General division[edit]

As the TISEAN package consists of 74 programs I have divided the first part into three sub-parts:

  1. FORTRAN ones that can be re-implemented easily in m-files (a good example of such a program is 'henon') -- there are 5 programs in this class
  2. C programs which also need to be linked to oct files (an example is 'ghkss') -- there are 41 programs in this class
  3. FORTRAN ones that need to be linked to oct files (an example of such a program is 'project') -- there are 28 programs in this class

They are ordered so that according to my estimates the difficulty rises with the number. This is because typecasting and implicit typing (which is included in most of the FORTRAN files in the TISEAN library) can be problematic sometimes.

This number can be brought down significantly. This is because some programs are deprecated, others are just C/FORTRAN copies of each other, others are not important in GNU Octave (such as 'compare' and choose'). After taking the factors above into consideration the number of functions that need to be ported drops to 49. I have prepared a detailed discussion of all of those functions here. This number will further drop once certain programs are confirmed to have similar programs in GNU Octave or some packages in Octave Forge.

Apart from the qualitative division I propose a work oriented division. In it each subpart can be tackled separately and create an entity in-and-of-itself. I chose to work along the lines of the articles about implementations of nonlinear timeseries included in the documentation. This article discusses various algorithms and what certain programs mean. It can be found here. I will discuss in which order I would like to port various topics from this article and where my work currently stands.

Nonlinear noise reduction[edit]

This is the first topic I chose. It is because it contains programs from all three categories. It is also relatively small -- it contains 3 programs: project, lazy, ghkss. I have chosen to further implement addnoise and henon, to demonstrate how project and ghkss work. Thus this topic contains programs from each category:

  • Re-implementable in mfile (henon)
  • Linkable to FORTRAN (project, addnoise, lazy)
  • Linkable to c (ghkss)

I have already started working on this stage. My progress can be viewed at https://bitbucket.org/josiah425/tisean. So far I have implemented addnoise, project and re-implemented henon as an mfile. As most work on this topic has been completed I estimate that finishing it up will take around 2 days -- throughout my outline I estimate about 1 day per program (that includes documentation and testing).

Phase space representation[edit]

This is the next topic that needs to be implemented. This is because it contains programs (especially 'delay') that are used to visualize data. Whenever an example is given in the package the resulting data is routed through 'delay' before it is plotted. Apart from delay it also contains other functions that can divided into the following categories:

  • Linkable to c (delay, corr, mutual, false_nearest, pca)

There are two more programs in this section of the article they are: 'autocorr' and 'pc', both implemented in FORTRAN. There is no need to port them as according to the documentation (here) they are redundant with other functions. Further more, it is likely 'corr' does not need to be implemented, because 'xcorr' in signal package seems to have similar functionality. This has not been confirmed yet, once that occurs, a definite answer can be given. Assuming around a day for each function (with testing and documenting the usage) I assume this stage will take a little under a week.

Nonlinear prediction[edit]

This seems like a reasonable next step. It consists of the following programs:

  • Linkable to FORTRAN (predict, upo)
  • Linkable to C (lzo-test, lzo-gm, lzo-run, lfo-ar, lfo-gm, lfo-run, rbf, polynom, xzero)

Again assuming around a day for each program (with testing, documenting usage and writing examples) I assume this stage will take about two weeks.

Lyapunov exponents[edit]

This stage will include:

  • Linkable to C (lyap_r, lyap_k, lyap_spec)

It will take about 2-3 days to complete.

Dimensions and entropies[edit]

This topic is next on the list. Programs it include are as follows:

  • Linkable to FORTRAN (c2, c2t, c2d, c2g, c1)
  • Linkable to C (d2, boxcount)

This part of the article also mentions 'c2naive' which is implemented in FORTRAN, but it is also described as redundant by the documentation (here) This stage should take little over a week. I expect this stage and the previous one to take about two weeks.

Testing for nonlinearity[edit]

This is the last topic I intend to tackle. The following programs are included here:

  • Linkable to FORTAN (surrogates, randomize , timerev)

This stage should take me about 3 days to complete.

Tutorial[edit]

I also plan to port all of the functions needed for the four exercises described in the 'Tutorial' section of the documentation. The programs that need to be ported additionally are as follows:

  • Linkable to FORTRAN (stp)
  • Linkable to C (ar-model, d2, poincare, recurr, nstat_z)

The programs: 'spectrum', 'historgram', 'extrema', 'corr' need to have a confirmed equivalent function in GNU Octave. This stage should take me about a week.

Notes on time estimates[edit]

Totaling up the above estimates it should take me 6-7 weeks to complete my task as outlined above.

My estimates might be high, but I believe it is more important to complete the task thoroughly than to port more programs haphazardly.

Details of work on each program[edit]

  • FORTRAN linking

For each FORTRAN program that I intend to link to a oct-file I intend to:

  1. Strip the program of its input validation and transform it into a subroutine
  2. Create a .cc program (compiled into an oct-file) that will launch the stripped FORTRAN subroutine; this .cc program will also not contain input validation, it will be for internal use only
  3. Create a m-file that will perform input validation and launch the .cc and contain usage documentation
  • C linking

I intend to do here something similar to the FORTRAN programs, although, it might be better to not create any extra m-files and incorporate the program's existing input validation into the .cc file. This might be a desired course of action. I will make a decision once I complete one such linking program.

  • Reimplementing in mfile

This is quite straightforward, although it is important not to make a mistake while taking this approach.