https://wiki.octave.org/wiki/api.php?action=feedcontributions&user=Siko1056&feedformat=atomOctave - User contributions [en]2020-09-28T19:16:44ZUser contributionsMediaWiki 1.35.0https://wiki.octave.org/wiki/index.php?title=Code_sprint_Zurich&diff=13355Code sprint Zurich2020-09-28T06:22:16Z<p>Siko1056: Fix double redirect.</p>
<hr />
<div>#REDIRECT [[Code Sprint (2016-04-17)]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Building&diff=13339Building2020-09-17T01:09:31Z<p>Siko1056: Overhaul head section.</p>
<hr />
<div>:''This article provides general information about '''building GNU Octave''' from source (on Unix-like systems).''<br />
<br />
:*''If you just want to '''install GNU Octave''', see [[:Category:Installation]].''<br />
:*''For '''MS Windows''', read [[Building on Microsoft Windows]] and [[Windows Installer]].''<br />
:*''For '''macOS''', read [[Octave for macOS]].''<br />
<br />
== General steps ==<br />
<br />
# Install all [[#Dependencies|build dependencies]] (see below).<br />
# Getting the Octave sources ...<br />
#* ... from the development repository (requires also [https://www.mercurial-scm.org/ Mercurial])<br />
<div style="margin-left:5em;"><br />
hg clone https://www.octave.org/hg/octave && \<br />
cd octave && \<br />
./bootstrap<br />
</div><br />
::* ... from a release<br />
<div style="margin-left:5em;"><br />
wget https://ftpmirror.gnu.org/octave/octave-{{Release}}.tar.gz && \<br />
tar -xzf octave-{{Release}}.tar.gz && \<br />
cd octave-{{Release}}<br />
</div><br />
: 3. Configure, build, check, and install Octave<br />
<div style="margin-left:3em;"><br />
mkdir .build && \<br />
cd .build && \<br />
./../configure --prefix=$HOME/my_octave && \ <ref><code>--prefix</code> determines the installation location, see the [[#Install Octave in home directory|Tweaks section]] for details. For more information about configuration options, type <code>./../configure --help</code>.</ref><br />
make -j2 && \ <ref>Depending on your system and processor count, use a larger number of parallel jobs, e.g. <code>-j8</code>.</ref><br />
make check && \<br />
make install<br />
</div><br />
<br />
== Dependencies ==<br />
<br />
Most of the dependencies given in this section can be very conveniently installed on many [[Octave for GNU/Linux|GNU/Linux]] systems.<br />
<br />
{{Note|For a quick way to install the required dependencies, see:<br />
* [[Octave for Debian systems#The right way|Debian / Ubuntu]]<br />
* [[Octave for Arch Linux|Arch Linux]]<br />
* [[Octave for Red Hat Linux systems|Fedora / RedHat / CentOS]]}}<br />
<br />
Dependencies marked with <span style="background:lightgreen">green background</span> are '''required''' for building Octave. All other tools and libraries are recommended/optional, but very useful features (like the GUI, plotting, etc.) are likely to be disabled.<br />
<br />
=== Build tools ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Dependency<br />
! Description<br />
! License / Copyright<br />
|-style="background:lightgreen"<br />
| [https://www.gnu.org/software/autoconf Autoconf]<br />
| Software configuration<br />
| GNU GPL v3.0<br />
|-style="background:lightgreen"<br />
| [https://www.gnu.org/software/automake Automake]<br />
| Makefile generator<br />
| GNU GPL v3.0<br />
|-style="background:lightgreen"<br />
| [https://gcc.gnu.org C++, C, and Fortran compilers]<br />
| Compiling the source code<br />
| GNU GPL v3.0<br />
|-style="background:lightgreen"<br />
| [https://www.gnu.org/software/make GNU Make]<br />
| Makefile processor<br />
| GNU GPL v3.0<br />
|-style="background:lightgreen"<br />
| [https://www.gnu.org/software/libtool Libtool]<br />
| Dependency of automake<br />
| Free Software Foundation<br />
|-style="background:lightgreen"<br />
| Unix utilities: gawk, gperf, less, ncurses<br />
| Miscellaneous tasks<br />
| GNU GPL v3.0<br />
|-<br />
| [https://www.gnu.org/software/bison Bison]<br />
| Parser generator<br />
| GNU GPL v3.0<br />
|-<br />
| [https://www.gnu.org/software/flex Flex]<br />
| Lexical analyzer<br />
| The Flex project<br />
|}<br />
<br />
=== Documentation tools ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Dependency<br />
! Description<br />
! License / Copyright<br />
|-<br />
| [http://www.ghostgum.com.au/software/epstool.htm epstool]<br />
| Epstool is a utility to create or extract preview images in EPS files, fix bounding boxes and convert to bitmaps.<br />
| GNU GPL v2.0<br />
|-<br />
| [https://www.freetype.org FTGL]<br />
| Portable font engine to perform font rendering for Octave’s OpenGL-based graphics functions.<br />
| GNU GPL v2.0<br />
|-<br />
| [http://geuz.org/gl2ps GL2PS]<br />
| GL2PS is a C library providing high quality vector output for any OpenGL application.<br />
| GNU LGPL v2.0<br />
|-<br />
| [https://www.nongnu.org/texi2html Texi2HTML]<br />
| Perl script which converts Texinfo source files to HTML output.<br />
| GNU GPL v3.0<br />
|-<br />
| [https://www.gnu.org/software/texinfo Texinfo]<br />
| Documentation system that uses a single source to produce both on-line information and printed output.<br />
| GNU GPL v3.0<br />
|-<br />
| [https://www.tug.org/texlive/ TeX Live]<br />
| TeX document production system including all the major TeX-related programs, macro packages, and fonts that are free software.<br />
| Freely redistributable as defined by the Free Software Foundation<br />
|}<br />
<br />
=== External tools and libraries ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Dependency<br />
! Description<br />
! License / Copyright<br />
|-style="background:lightgreen"<br />
| [https://www.netlib.org/blas BLAS]<br />
| Basic Linear Algebra Subroutine library<br />
| Free - proper attribution request<br />
|-style="background:lightgreen"<br />
| [https://netlib.org/lapack LAPACK]<br />
| Linear Algebra Package<br />
| Free - proper attribution request<br />
|-style="background:lightgreen"<br />
| [https://www.pcre.org PCRE]<br />
| Perl Compatible Regular Expression library<br />
| Free<br />
|-style="background:lightgreen"<br />
| [https://www.gnu.org/software/readline GNU Readline]<br />
| Command-line editing library<br />
| GNU GPL v3.0<br />
|-<br />
| [https://github.com/opencollab/arpack-ng ARPACK-NG]<br />
| Solution of large-scale eigenvalue problems<br />
| BSD like - various authors<br />
|-<br />
| [https://curl.haxx.se cURL]<br />
| Library for transferring data with URL syntax<br />
| Free Software -- main author<br />
|-<br />
| [http://www.fftw.org FFTW3]<br />
| Library for computing discrete Fourier transforms<br />
| MIT -- GNU GPL v2.0<br />
|-<br />
| [https://www.fltk.org FLTK]<br />
| Portable GUI toolkit<br />
| GNU GPL v2.0 with static linking exception<br />
|-<br />
| [https://www.freedesktop.org/wiki/Software/fontconfig fontconfig]<br />
| Library for configuring and customizing font access<br />
| Provided "as is" -- various authors<br />
|-<br />
| [https://www.freetype.org FreeType]<br />
| Portable font engine<br />
| compatible with GNU GPL v3.0<br />
|-<br />
| [https://www.gnu.org/software/glpk GLPK]<br />
| GNU Linear Programming Kit<br />
| GNU GPL v3.0<br />
|-<br />
| [http://www.gnuplot.info gnuplot]<br />
| Interactive graphics program<br />
| Provided "as is" -- various authors<br />
|-<br />
| [http://www.graphicsmagick.org GraphicsMagick++]<br />
| Image processing library<br />
| various -- integrates many third-party libs<br />
|-<br />
| [https://www.hdfgroup.org/solutions/hdf5 HDF5]<br />
| Library for manipulating portable data files<br />
| BSD - like<br />
|-<br />
| [https://www.opengl.org OpenGL]<br />
| API for portable 2D and 3D graphics<br />
| Free specs -- license is driver dependent<br />
|-<br />
| [http://www.qhull.org Qhull]<br />
| Computational geometry library<br />
| Free software -- specific<br />
|-<br />
| [http://sourceforge.net/projects/qrupdate QRUPDATE]<br />
| QR factorization updating library<br />
| GNU GPL v3.0<br />
|-<br />
| [http://faculty.cse.tamu.edu/davis/suitesparse.html SuiteSparse]<br />
| Sparse matrix factorization library<br />
| Main author<br />
|-<br />
| [https://zlib.net zlib]<br />
| Data compression library<br />
| Provided "as is" -- various authors<br />
|}<br />
<br />
== Tweaks ==<br />
<br />
=== Install Octave in home directory ===<br />
<br />
To install multiple versions of GNU Octave on one system, it is recommended to use the <code>--prefix</code> option of the <code>configure</code> script. With this option one can determine a custom installation directory, preferably within your user's home directory, to avoid elevated installation privileges. One does not "clutter" the system by running <code>sudo make install</code> and the custom build Octave can coexist with, for example, your Linux distribution installation of Octave.<br />
<br />
In order to start the custom build of Octave almost as convenient as the Linux distribution installation of Octave, one can create an alias within {{Path|.bashrc}}:<br />
<br />
echo "alias myoctave='$HOME/my_octave/bin/octave'" >> ~/.bashrc<br />
<br />
Then update your {{Path|.bashrc}} without doing logout and login:<br />
<br />
source $HOME/.bashrc<br />
<br />
If you simply enter <code>octave</code>, you'll start your Linux distribution installation of Octave. But when you enter <code>myoctave</code>, you'll start your custom build of Octave inside your home directory.<br />
<br />
=== Uninstall ===<br />
<br />
# If you still have the {{Path|.build}} folder, just run <code>make uninstall</code> from it.<br />
# Just delete the install folder, e.g. <code>rm -rf $HOME/my_octave</code>.<br />
<br />
In any case, don't forget to remove any created ''alias'' entries in {{Path|~/.bashrc}}.<br />
<br />
=== Large array support ===<br />
<br />
: ''Main article: [[Enable large arrays: Build octave such that it can use arrays larger than 2Gb.]]''<br />
<br />
== See also ==<br />
<br />
* [https://hg.savannah.gnu.org/hgweb/octave/file/tip/README <code>README</code>] and [https://hg.savannah.gnu.org/hgweb/octave/file/tip/etc/HACKING.md <code>/etc/HACKING.md</code>] in the development repository. <br />
* https://octave.org/doc/interpreter/Installation.html<br />
* [[MXE]] -- a more customized Octave build including many self-compiled tools.<br />
<br />
== Footnotes ==<br />
<br />
<references/><br />
<br />
[[Category:Building]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Projects&diff=13336Projects2020-09-16T01:31:38Z<p>Siko1056: /* Marketing and Community */</p>
<hr />
<div>The list below summarizes features or bug fixes we would like to see in Octave. This list is not exclusive -- there are many other things that might be good projects, but it might instead be something we already have. Also, some of the following items may not actually be considered good ideas now.<br />
<br />
{{Note|If you never contributed to Octave before, we suggest to start with our [[Developer FAQ]].}}<br />
<br />
* Summer of Code students, please also see [[Summer of Code - Getting Started]].<br />
* If you're looking for small project, see [[short projects]].<br />
<br />
=Numerical=<br />
<br />
* Use C++11 <random> libraries for random number generation. Write link between Octave functions (rand, randi, randn, rande) and C++ API. Implement RandStream objects as Matlab does.<br />
<br />
*Improve logm, and sqrtm (see this thread: http://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html)<br />
<br />
*Use pairwise addition in sum() to mitigate against numerical errors without substantial performance penalty (https://en.wikipedia.org/wiki/Pairwise_summation).<br />
<br />
*Review implementing algorithm in this 2009 paper (https://epubs.siam.org/doi/pdf/10.1137/080738490) for xsum (sum with extra accuracy). The existing implementation uses a 2005 paper.<br />
<br />
*Improve complex mapper functions. See W. Kahan, ``Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit (in The State of the Art in Numerical Analysis, eds. Iserles and Powell, Clarendon Press, Oxford, 1987) for explicit trigonometric formulae. See {{patch|8172}} for a previous attempt.<br />
<br />
*Make functions like gamma() return the right IEEE Inf or NaN values for extreme args or other undefined cases.<br />
<br />
*Improve sqp.<br />
<br />
*Fix CollocWt? to handle Laguerre polynomials. Make it easy to extend it to other polynomial types.<br />
<br />
*Add optional arguments to colloc so that it's not restricted to Legendre polynomials.<br />
<br />
*Move rand, eye, xpow, xdiv, etc., functions to the matrix classes.<br />
<br />
*Improve design of ODE, DAE, classes.<br />
<br />
*Make QR more memory efficient for large matrices when not all the columns of Q are required (apparently this is not handled by the lapack code yet).<br />
<br />
*Evaluate harmonics and cross-correlations of unevenly sampled and nonstationary time series, as in http://www.jstatsoft.org/v11/i02 (which has C code with interface to R). (This is now partly implemented in the [http://octave.sourceforge.net/lssa/index.html lssa] package.)<br />
<br />
<!-- == General purpose Finite Element library ==<br />
<br />
Octave-Forge already has a set of packages for discretizing Partial Differential operators by Finite Elements and/or Finite Volumes,<br />
namely the [[bim package]] which relies on the [http://octave.sf.net/msh msh package] (which is in turn based on [http://geuz.org/gmsh/ gmsh]) for creating and managing 2D triangular and 3D tetrahedral meshes and on the [http://octave.sf.net/fpl fpl package] for visualizing 2D results within Octave or exporting 2D or 3D results in a format compatible with [http://www.paraview.org Paraview] or [https://wci.llnl.gov/codes/visit/ VisIT]. These packages, though, offer only a limited choice of spatial discretization methods which are based on low degree polynomials and therefore have a low order of accuracy even for problems with extremely smooth solutions.<br />
The [http://geopdes.sf.net GeoPDEs] project, on the other hand, offers a complete suite of functions for discretizing a wide range of<br />
differential operators related to important physical problems and uses basis functions of arbitrary polynomial degree that allow the construction of methods of high accuracy. These latter, though, are based on the IsoGeometric Analysis Method which, although very powerful and often better performing, is less widely known and adopted than the Finite Elements Method. The implementation of a general purpose library of Finite Elements seems therefore a valuable addition to Octave-Forge. Two possible interesting choices for implementing this package exist, the first consists of implementing the most common Finite Element spaces in the [http://geopdes.sf.net GeoPDEs] framework, which is possible as IsoGeometric Analysis can be viewed as a superset of the Finite Element Method, the other is to construct Octave language bindings for the free software library [http://fenicsproject.org/documentation/ FEniCS] based on the existing C++ or Python interfaces. This second approach has been developed during the GSOC 2013 and the Octave-Forge package [http://octave.sf.net/fem-fenics fem-fenics] is now available. However, fem-fenics could be extended in many different ways:<br />
* implement the bindings for the UFL language inside Octave<br />
* add new functions already available with Fenics but not yet in Octave<br />
* create new functions specifically suited for Octave<br />
* improve the efficiency of the code<br />
The main goal for the fem-fenics package is ultimately to be merged with the FEnics project itself, so that it can remain in-sync with the main library development. --><br />
<br />
== Implement solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D ==<br />
<br />
The project will deliver a solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D similar to Matlab's function <tt>pdepe</tt>. A good starting point is the [http://en.wikipedia.org/wiki/Method_of_lines method of lines] for which you can find more details [http://en.wikibooks.org/wiki/Partial_Differential_Equations/Method_of_Lines here] and [http://www.scholarpedia.org/article/Method_of_lines here], whereas an example implementation can be found [http://www.scholarpedia.org/article/Method_of_Lines/Example_Implementation here]. In addition, [http://www.pdecomp.net/ this page] provides some useful material.<br />
<br />
== Implement solver for 1D nonlinear boundary value problems ==<br />
<br />
The project will complete the implementation of the bvp4c solver that is already available in an initial version in the odepkg package<br />
by adding a proper error estimator and will implement a matlab-compatible version of the bvp5c solver.<br />
Details on the methods to be implemented can be found in [http://dx.doi.org/10.1145/502800.502801 this paper] on bvp4c and [http://www.jnaiam.net/new/uploads/files/014dde86eef73328e7ab674d1a32aa9c.pdf this paper] on bvp5c. Further details are available in [http://books.google.it/books/about/Nonlinear_two_point_boundary_value_probl.html?id=s_pQAAAAMAAJ&redir_esc=y this book].<br />
<br />
<!-- == Geometric integrators for Hamiltonian Systems ==<br />
<br />
[http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration Geometric (AKA Symplectic) integrators] are useful for <br />
multi-dimensional classical mechanics problems and for molecular dynamics simulations.<br />
The odepkg package has a number of solvers for ODE, DAE and DDE problems but none of them is currently<br />
specifically suited for second order problems in general and Hamiltonian systems in particular.<br />
Therefore a new package for geometric integrators would be a useful contribution.<br />
This could be created as new package or added as a set of new functions for odepkg.<br />
The function interface should be consistent throughout the package and should be modeled to follow <br />
that of other functions in odepkg (or that of DASPK and LSODE) but will need specific extensions to accommodate for specific options that only make sense for this specific class of solvers.<br />
An initial list of methods to be implemented includes (but is not limited to)<br />
* Symplectic Euler methods, see [http://en.wikipedia.org/wiki/Semi-implicit_Euler_method here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Störmer-Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Velocity Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Symplectic partitioned Runge-Kutta methods, see [http://reference.wolfram.com/mathematica/tutorial/NDSolveSPRK.html here] or [http://dx.doi.org/10.1137/0733019 here]<br />
* Spectral Variational Integrator methods, see [http://www3.nd.edu/~izaguirr/papers/acta_numerica.pdf here] or [http://www.math.ucsd.edu/~mleok/pdf/HaLe2012_SVI.pdf here]<br />
<br />
For this latter there is an existing code which is already working but needs to be improved, posted on the patch tracker.<br />
Furthermore, methods to implement solutions of problems with rigid constraints should be implemented, e.g.<br />
* SHAKE, see [http://en.wikipedia.org/wiki/Constraint_algorithm here] or [http://dx.doi.org/10.1016/0021-9991(77)90098-5 here]<br />
* RATTLE, see [http://dx.doi.org/10.1016/0021-9991(83)90014-1 here] or [http://dx.doi.org/10.1002/jcc.540161003 here]<br />
--><br />
<br />
== Matlab-compatible ODE solvers in core-Octave ==<br />
<br />
* Improve handling of sparse Jacobians in IDE/DAE solvers<br />
** Currently, in the IDA wrapper function __ode15__ an over conservative guess for the amount of memory to be allocated when assembling a sparse jacobian is used, essentially allocating enough space for a full jacobian then freeing the excess memory, an initial patch for fixing this has been posted on the tracker, for integrating this into Octave it must be generalized to support prior versions of SUNDIALS<br />
** Currently Jacobians passed by the user in Octave's sparse matrix format are copied into SUNDIALS own sparse matrix format. Newer versions of SUNDIALS (5.x or higher) support letting the user take care of the linear algebra data structures and methods thus removing the need for the copy. Taking advantage of this feature would improve the solver performance both in terms of memory footprint and speed.<br />
** References<br />
***[https://savannah.gnu.org/bugs/?func=detailitem&item_id=55905 tracker post about memory allocation] <br />
***[https://computing.llnl.gov/projects/sundials/release-history SUNDIALS release history]<br />
* Implement Matlab compatible versions of "deval".<br />
* Complete transition of ode23s into core Octave<br />
** [https://savannah.gnu.org/bugs/?57309 Bug tracker entry discussing ode23s]<br />
<br />
== High Precision Arithmetic Computation ==<br />
<br />
The Linear Algebra Fortran libraries used by Octave make use of of single (32 bits) and double (64 bits) precision floating point numbers. Many operations are stopped when matrices condition number goes below 1e-16: such matrices are considered as ill-conditioned. There are cases where this is not enough, for instance simulations implying chemical concentrations covering the range 10^4 up to 10^34. There are a number of ways to increase the numerical resolution, like f.i. make use of 128 bits quadruple precision numbers available in GFortran. A simpler option is to build an interface over Gnu MPL arbitrary precision library, which is used internally by gcc and should be available on any platform where gcc runs. Such approach has been made available for MatLab under the name mptoolbox and is licensed under a BSD license. The author kindly provided a copy of the latest version and agreed to have it ported under Octave and re-distributed under GPL v3.0<br />
<br />
The architecture consists of an Octave class interface implementing "mp" (multi-precision) objects. Arithmetic operations are forwarded to MPL using MEX files. This is totally transparent to the end user, except when displaying numbers. This implementation needs to be ported and tested under Octave.<br />
<br />
=GUI/IDE=<br />
<br />
*Søren Hauberg has suggested that we need C++ code that can:<br />
**Determine if a line of code could be fully parsed, i.e. it would return true for "plot (x, y);", but false for "while (true)".<br />
**Evaluate a line of code and return the output as a string (it would be best if it could provide three strings: output, warnings and errors).<br />
**Query defined variables, i.e. get a list of currently defined variables. Bonus points if it could tell you if anything had changed since the last time you checked the variables (could also be done with signals).<br />
* Create a better (G)UI for the {{manual|profile|profiler}}. This may be done with Qt, but not necessarily.<br />
<br />
== GUI Variable Editor and Property Inspector ==<br />
<br />
Octave has a preliminary implementation of a Variable Editor: a spreadsheet-like tool for quickly editing and visualizing variables. The initial phase of the project will be learning how the implementation was done.<br />
<br />
With the knowledge gained, the second part of the project will be to implement a Property Inspector. This is a spreadsheet like interface to the many, many graphics properties that exist and are different on a per-object basis. The goal would be not only the concise-display of the existing properties, but a reasonable user interface to change them. As examples, Boolean properties should be able to be toggled with a double-click; Radio properties should have a drop-down list of only the supported options; Other properties that can be modified should have the constraints built-in (for example, Linewidth must be a scalar, while Position must be a 1x4 vector). It would also be important to have easy access to the documentation of a property.<br />
<br />
For reference, Matlab has a similar Property Inspector (https://www.mathworks.com/help/matlab/ref/inspect.html).<br />
<br />
== Sisotool. Create a graphical design tool for tuning closed loop control system ([[Control package]])==<br />
<br />
When tuning a SISO feedback system it is very helpful to be able to grab a pole or a zero and move them by dragging them with the mouse. As they are moving the software must update all the plotted lines. There should be the ability to display various graphs rlocuse, bode, step, impulse etc. and have them all change dynamically as the mouse is moving. The parameters of the compensator must be displayed and updated.<br />
Recently, some implementation was done during [[Summer_of_Code#GSoC_2018|GSoC 2018]], see https://eriveltongualter.github.io/GSoC2018/final.html for details.<br />
<br />
=Sparse Matrices=<br />
<br />
The paper by [http://arxiv.org/abs/cs.MS/0604006 Bateman & Adler] is good reading for understanding the sparse matrix implementation.<br />
<br />
*Improve Matlab compatibility for {{manual|sprandsym}}.<br />
<br />
*Sparse logical indexing in idx_vector class so that something like <code>a = sprandn (1e6, 1e6, 1e-6); a(a<1) = 0;</code> won't cause a memory overflow.<br />
<br />
*Other missing Functions<br />
**lsqr<br />
**minres<br />
**symmlq<br />
<br />
== SPQR Interface ==<br />
<br />
Octave implements QR factorization for sparse matrices, but it does so with an older "CXSPARSE" library. This has caused fundamental issues, including segfaults as recorded here (bugs {{bug|51950}} and {{bug|57033}}). The goal of this project is to program an interface to the API for the SQPR library (http://faculty.cse.tamu.edu/davis/suitesparse.html). This is the same library that Matlab uses for this purpose.<br />
<br />
*Improve QR factorization functions, using idea based on CSPARSE cs_dmsol.m<br />
<br />
*Improve QR factorization by replacing CXSPARSE code with SPQR code, and make the linear solve return 2-norm solutions for ill-conditioned matrices based on this new code<br />
<br />
=Strings=<br />
<br />
*Consider making octave_print_internal() print some sort of text representation for unprintable characters instead of sending them directly to the terminal. (But don't do this for fprintf!)<br />
<br />
*Consider changing the default value of `string_fill_char' from SPC to NUL.<br />
<br />
=Other Data Types=<br />
<br />
*Template functions for mixed-type ops.<br />
<br />
*Convert other functions for use with the floating point type including quad, dasrt, daspk, etc.<br />
<br />
=Input/Output=<br />
<br />
*Make fread and fwrite work for complex data. Iostreams based versions of these functions would also be nice, and if you are working on them, it would be good to support other size specifications (integer*2, etc.).<br />
<br />
*Move some pr-output stuff to liboctave.<br />
<br />
*Make the cutoff point for changing to packed storage a user-preference variable with default value 8192.<br />
<br />
*Complain if there is not enough disk space available (I think there is simply not enough error checking in the code that handles writing data).<br />
<br />
*Make it possible to tie arbitrary input and output streams together, similar to the way iostreams can be tied together.<br />
<br />
*Expand {{codeline|imwrite}} options. This shouldn't be too hard to implement, since it's wrapped around GraphicsMagick.<br />
<br />
*Extend Octave functions to work on stored arrays that are too big to fit in RAM, similar to available R [http://www.bigmemory.org/ packages.]<br />
<br />
* write {{codeline|xmlread}} and {{codeline|xmlwrite}}. This could be done using [http://xerces.apache.org/xerces-c/ Xerces C++ interface] which apparently is what [http://octave.1599824.n4.nabble.com/xml-in-octave-td4663034.html Matlab uses].<br />
<br />
* Implement hdf5 for .mat files (see [http://octave.1599824.n4.nabble.com/Reading-Matlab-td4650158.html this thread]).<br />
<br />
=Interpreter=<br />
<br />
The interpreter is written in C++, undocumented. There are many possible projects associated with it.<br />
<br />
'''Required skills''': ''Very good'' C and C++ knowledge, possibly also understanding of [http://en.wikipedia.org/wiki/Gnu_bison GNU bison] and [http://en.wikipedia.org/wiki/Flex_lexical_analyser flex]. Understanding how compilers and interpreters are made plus being able to understand how to use a profiler and a debugger will probably be essential skills.<br />
<br />
*Allow customization of the debug prompt.<br />
<br />
*Fix the parser so that<br />
<br />
if (expr) 'this is a string' end<br />
<br />
is parsed as IF expr STRING END. ''(see [https://lists.gnu.org/archive/html/octave-maintainers/2014-03/msg00087.html this] post on the mailing list)''<br />
<br />
*Clean up functions in input.cc that handle user input (there currently seems to be some unnecessary duplication of code and it seems overly complex).<br />
<br />
*Consider allowing an arbitrary property list to be attached to any variable. This could be a more general way to handle the help string that can currently be added with `document'.<br />
<br />
*Allow more command line options to be accessible as built-in variables (--echo-commands, etc.).<br />
<br />
*Make the interpreter run faster.<br />
<br />
*Allow arbitrary lower bounds for array indexing.<br />
<br />
*Improve performance of recursive function calls.<br />
<br />
*Improve the way ignore_function_time_stamp works to allow selecting by individual directories or functions.<br />
<br />
*Add a command-line option to tell Octave to just do syntax checking and not execute statements.<br />
<br />
*Clean up symtab and variable stuff.<br />
<br />
*Input stream class for parser files -- must manage buffers for flex and context for global variable settings.<br />
<br />
*make parser do more semantic checking, continue after errors when compiling functions, etc.<br />
<br />
*Make LEXICAL_ERROR have a value that is the error message for parse_error() to print?<br />
<br />
*Add a run-time alias mechanism that would allow things like alias fun function_with_a_very_long_name so that `function_with_a_very_long_name' could be invoked as `fun'.<br />
<br />
*Allow local changes to variables to be written more compactly than is currently possible with unwind_protect. For example, <br />
<br />
function f ()<br />
local prefer_column_vectors = something;<br />
...<br />
endfunction<br />
<br />
<br />
would be equivalent to<br />
<br />
function f ()<br />
save_prefer_column_vectors = prefer_column_vectors;<br />
unwind_protect<br />
prefer_column_vectors = something;<br />
...<br />
unwind_protect_cleanup<br />
prefer_column_vectors = save_prefer_column_vectors;<br />
end_unwind_protect<br />
endfunction<br />
<br />
<br />
*Fix all function files to check for bogus inputs (wrong number or types of input arguments, wrong number of output arguments).<br />
<br />
*Handle options for built-in functions more consistently.<br />
<br />
*Too much time is spent allocating and freeing memory. What can be done to improve performance?<br />
<br />
Use move constructors rather than copy constructors for things like dim_vectors which are repeatedly created just to initialize Array or Matrix objects.<br />
<br />
*Error output from Fortran code is ugly. Something should be done to make it look better.<br />
<br />
*It would be nice if output from the Fortran routines could be passed through the pager.<br />
<br />
*Attempt to recognize common subexpressions in the parser.<br />
<br />
*Consider making it possible to specify an empty matrix with a syntax like [](e1, e2). Of course at least one of the expressions must be zero...<br />
<br />
*Is Matrix::fortran_vec() really necessary?<br />
<br />
*Rewrite whos and the symbol_record_info class. Write a built-in function that gives all the basic information, then write who and whos as M-files.<br />
<br />
*On systems that support matherr(), make it possible for users to enable the printing of warning messages.<br />
<br />
*Make it possible to mark variables and functions as read-only.<br />
<br />
*Make it possible to write a function that gets a reference to a matrix in memory and change one or more elements without generating a second copy of the data.<br />
<br />
*Use nanosleep instead of usleep if it is available? Apparently nanosleep is to be preferred over usleep on Solaris systems.<br />
<br />
== Improve JIT compiling ==<br />
<br />
Octave's interpreter is ''very'' slow on some loops. Recently, thanks to Max Brister's work, an initial implementation of a just-in-time compiler (JITC) in [http://llvm.org LLVM] for GSoC 2012. This project consists in understanding Max's current implementation and extending it so that functions and exponents (e.g. 2^z) compile with the JITC. This requires knowledge of compilers, C++, LLVM, and the Octave or Matlab languages. A capable student who demonstrates the ability to acquire this knowledge quickly may also be considered. Max himself will mentor this project. [http://planet.octave.org/octconf2012/jit.pdf Here] is Max's OctConf 2012 presentation about his current implementation. See also [[JIT]].<br />
<br />
== Improve memory management ==<br />
<br />
From profiling the interpreter, it appears that a lot of time is spending allocating and deallocating memory. A better memory management algorithm might provide some improvement.<br />
<br />
== Implement classdef classes ==<br />
<br />
Matlab has two kinds of classes: old style @classes and new style classdef. Octave has only fully implemented the old style. There is partial support for classdef classes in version 4.0, refer to the [[Classdef|classdef status page]] for what is not yet implemented. There is irregular work here, and classdef is [http://www.mathworks.com/help/matlab/matlab_oop/method-attributes.html a very] [http://www.mathworks.com/help/matlab/events-sending-and-responding-to-messages.html complicated] [http://www.mathworks.com/help/matlab/enumeration-classes.html thing] to fully implement. A successful project would be to implement enough of classdef for most basic usages. Familiarity with Matlab's current classdef support would be a huge plus. Michael Goffioul and jwe can mentor this.<br />
<br />
Although there's already a substantial classdef support in current octave code base, there are still many areas that are unimplemented or need improvements. The main ones that come to my mind are:<br />
* support for events<br />
* support for enums<br />
* support for "import" (this requires good understanding of octave internals, especially the symbol table)<br />
* improving multiple inheritance and method resolution<br />
* honoring and computing "Sealed" attribute<br />
* support for function handle to methods<br />
<br />
== Improve MPI package ==<br />
<br />
Octave Forge's [http://octave.sourceforge.net/mpi/index.html MPI package] <br />
is a wrapper for basic MPI functions for parallel computing. It is implemented <br />
by wrapping MPI function calls in simple DLD functions that map Octave's Datataypes to <br />
MPI Derived Datatypes. <br />
The proposed project deals with improving and extending the Octave MPI package, for example:<br />
* Octave MPI applications can currently be only run in batch mode, add the ability to launch parallel jobs and collect their output in an interactive Octave session.<br />
* Implement functions for non-blocking communication (MPI_Isend, MPI_Irecv)<br />
* Implement one-to-many (Broadcast, Scatter), many-to-one (Reduce, Gather), and many-to-many (All Reduce, Allgather) communication routines<br />
<br />
= Graphics =<br />
<br />
* Correctly handle case where DISPLAY is unset. Provide --no-window-system or --nodisplay (?) option. Provide --display=DISPLAY option? How will this work with gnuplot (i.e., how do we know whether gnuplot requires an X display to display graphics)?<br />
<br />
* Implement a Cairo-based renderer for 2D-only graphics, with support for PS/PDF/SVG output (for printing).<br />
<br />
* On 'imagesc' plots, report the matrix values also based on the mouse position, updating on mouse moving.<br />
<br />
* Add map-creating capabilities similar to the Matlab [https://www.mathworks.com/help/map/functionlist.html Mapping toolbox] for inclusion in the Octave Forge [https://sourceforge.net/p/octave/mapping mapping package].<br />
<br />
* Add data cursor to trace data values in figure.<br />
<br />
== Non-OpenGL renderer ==<br />
<br />
Besides the original gnuplot backend, Octave also contains an OpenGL-based renderer for advanced and more powerful 3D plots. However, OpenGL is not perfectly suited for 2D-only plots where other methods could result in better graphics. The purpose of this project is to implement an alternate graphics renderer for 2D only plots (although 3D is definitely not the focus, extending the new graphics renderer to support basic 3D features should also be taken into account). There is no particular toolkit/library that must be used, but natural candidates are:<br />
* [http://qt.nokia.com Qt]: the GUI is currently written in Qt<br />
* [http://en.wikipedia.org/wiki/Cairo_%28software%29 Cairo]: this library is widely used and known to provides high-quality graphics with support for PS/PDF/SVG output.<br />
<br />
== LaTeX markup ==<br />
<br />
Text objects in plots (like titles, labels, texts...) in the OpenGL renderer only support plain text and TeX. The latter consists of a very limited subset of the TeX language. On the other hand, the LaTeX formatting support is expected to provide full LaTeX capabilities. There are various approaches that can be used:<br />
* Use an external LaTeX engine: this is the most straightforward, but it requires users to install a LaTeX distribution and setup Octave to use it.<br />
* Use an external library that supports LaTeX syntax, e.g. [https://github.com/opencollab/jlatexmath JLaTeXMath] a Java API to display LaTeX code, [https://github.com/nathancarter/qtmathjax qtmathjax] a Qt based library that executes MathJax in a background web page.<br />
* Implement our own LaTeX parser and renderer. The matplotlib project [http://matplotlib.sourceforge.net/users/usetex.html has already done this in Python] and might be used as an example of how to do this in Octave. There is also [https://github.com/jkriege2/JKQtPlotter JKQtPlotter], a Qt based plotting application which implements its own LaTeX parser/renderer in C++.<br />
<br />
=History=<br />
<br />
*Add an option to allow saving input from script files in the history list.<br />
<br />
*The history command should accept two numeric arguments to indicate a range of history entries to display, save or read.<br />
<br />
*Avoid writing the history file if the history list has not changed.<br />
<br />
*Avoid permission errors if the history file cannot be opened for writing.<br />
<br />
*Fix history problems — core dump if multiple processes are writing to the same history file?<br />
<br />
= Configuration and Installation =<br />
<br />
* Makefile changes:<br />
** eliminate for loops<br />
** define shell commands or eliminate them<br />
** consolidate targets<br />
<br />
* Create a docs-only distribution?<br />
<br />
=Documentation=<br />
:''See [[Project - Documentation]].''<br />
<br />
=Tests=<br />
*Improved set of tests: [http://octave.1599824.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=370633]<br />
**Tests for various functions. Would be nice to have a test file corresponding to every function (see below)<br />
**Tests for element by element operators: + - .* ./ .\ .^ | & < <= == >= > != !<br />
*** thorough tests for power operator including corner cases and strange combinations such as complex .^ range.<br />
**Tests for boolean operators: && ||<br />
**Tests for other operators: * / \ ' .'<br />
**Tests from bug reports.<br />
**Tests for indexed assignment. Need to consider the following:<br />
***fortran-style indexing<br />
***zero-one indexing<br />
***assignment of empty matrix as well as values resizing<br />
**Tests for all internal functions.<br />
<br />
* Implement a coverage tool for collecting coverage data and generating code coverage reports on m-file functions and scripts. This would be very useful for Octave development as well as for users who want a code coverage report for their own functions and scripts.<br />
<br />
We are far from even having one test for every function, so focus should be on getting the breadth of coverage first before trying to get the depth of 100% statement coverage. As of Dec 2015, 202 of 1020 m-files have no tests. Some of these will be plotting functions which have demos instead, but that leaves enough functions to be an interesting project. As of Dec 2015, there are 485 instances of C++ functions which need tests.<br />
<br />
After Octave is compiled, running the {{Codeline|make check}} build target will run the full test suite and generate a file called test/fntests.log in the build directory with a summary of the results. At the end of the file is a list of all functions for which no tests were found. An extract is posted in the [[files missing tests]] page. If you are not building Octave yourself, the test suite can be run on an installed binary copy by executing the {{Codeline|__run_test_suite__}} command at the Octave prompt. The fntests.log file will be written in the current directory in this case.<br />
<br />
There also need to be tests for functions written in the C++ files. See [[Add_BIST_tests_for_octave_functions_written_in_C%2B%2B]] for instructions and a list of instances.<br />
<br />
See also [[Continuous Build#Coverage Report]].<br />
<br />
=Programming=<br />
<br />
*Better error messages for missing operators?<br />
<br />
*Eliminate duplicate enums in pt-exp.cc, pt-const.cc, and ov.cc.<br />
<br />
*Handle octave_print_internal() stuff at the liboctave level. Then the octave_value classes could just call on the print() methods for the underlying classes.<br />
<br />
*As much as possible, eliminate explicit checks for the types of octave_value objects so that user-defined types will automatically do the right thing in more cases.<br />
<br />
*Only include config.h in files that actually need it, instead of including it in every .cc file. Unfortunately, this might not be so easy to figure out.<br />
<br />
*GNU coding standards:<br />
**Add a `Makefile' target to the Makefiles.<br />
**Comments on #else and #endif preprocessor commands.<br />
**Change error message format to match standards everywhere.<br />
<br />
*Eliminate more global variables.<br />
<br />
*Move procstream to liboctave.<br />
<br />
*Use references and classes in more places.<br />
<br />
*Share more code among the various _options functions.<br />
<br />
*Use non-empty identifiers in all warnings and errors issued by Octave, see [[Easy projects#Miscellaneous]].<br />
<br />
*Reduce the amount of datatypes in liboctave.<br />
<br />
*Re-implement operators using templates and modern C++. Current system evolved before templates and makes extensive use of macros to define interactions between scalar<->scalar, scalar<->matrix, scalar<->float, etc., etc.<br />
**In liboctave, the directory to work on is liboctave/operators<br />
**In libinterp, the directory to work on is libinterp/operators<br />
**In libinterp, there is also xpow.cc, xdiv.cc in libinterp/corefcn<br />
<br />
=Miscellaneous=<br />
<br />
*Implement some functions for interprocess communication: bind, accept, connect, gethostbyname, etc. (This functionality is already available in the octave sockets package, what is the purpose of moving it to core octave?)<br />
<br />
*The ability to transparently handle very large files: Juhana K Kouhia <kouhia@nic.funet.fi> wrote:<br />
*: If I have a one-dimensional signal data with the size 400 Mbytes, then what are my choices to operate with it:<br />
*:*I have to split the data<br />
*:*Octave has a virtual memory on its own and I don't have to worry about the splitting.<br />
*:If I split the data, then my easily programmed processing programs will become hard to program.<br />
*:If possible, I would like to have the virtual memory system in Octave i.e., the all big files, the user see as one big array or such. There could be several user selectable models to do the virtual memory depending on what kind of data the user have (1d, 2d) and in what order they are processed (stream or random access).<br />
<br />
*An interface to gdb. Michael Smolsky <fnsiguc@weizmann.weizmann.ac.il> wrote:<br />
*:I was thinking about a tool, which could be very useful for me in my numerical simulation work. It is an interconnection between gdb and octave. We are often managing very large arrays of data in our fortran or c codes, which might be studied with the help of octave at the algorithm development stages. Assume you're coding, say, wave equation. And want to debug the code. It would be great to pick some array from the memory of the code you're developing, fft it and see the image as a log-log plot of the spectral density. I'm facing similar problems now. To avoid high c-development cost, I develop in matlab/octave, and then rewrite into c. It might be so much easier, if I could off-load a c array right from the debugger into octave, study it, and, perhaps, change some [many] values with a convenient matlab/octave syntax, similar to <code>a(:,51:250)=zeros(100,200)</code>, and then store it back into the memory of my c code.<br />
<br />
*Implement gdb extensions for Octave types. Octave has the <code>etc/gdbinit</code> file, which has some basic support for displaying the contents of Octave types. Add more extensions to make it easier to debug octave_values and other Octave types.<br />
<br />
*Add a definition to lgrind so that it supports Octave. (See http://www.tex.ac.uk/tex-archive/support/lgrind/ for more information about lgrind.)<br />
<br />
*Spatial statistics, including covariogram estimation and kriging -- perhaps via an interface to [http://www.gstat.org/ gstat]?<br />
<br />
* the [http://octave.sourceforge.net/miscellaneous/function/units.html units] function from the miscellaneous package works by parsing the output of from a call to GNU units. This can be made much more robust by writing it in C++ and including its library "units.h"<br />
<br />
=Marketing and Community=<br />
<br />
* Make the Octave website/[[Project Infrastructure]] easier to maintain.<br />
<br />
* Make it easier for newcomers to contribute.<br />
<br />
* For marketing ideas, see the [https://openoffice.apache.org/orientation/intro-marketing.html Apache Open Office Introduction to Marketing]<br />
<br />
* Help design a user or a [https://www.openoffice.org/marketing/ooocon2006/presentations/wednesday_c10.pdf developer survey]<br />
<br />
* Help prepare and deliver presentations and [[Publications about Octave]] at colleges and universities.<br />
<br />
== Improve Windows binary packaging ==<br />
<br />
We are currently able to build and provide a [[Windows Installer|installer for Windows]]. The build process involves cross-compiling on a Linux system using a fork of the [http://mxe.cc/ MXE] project to build Octave and all of its dependencies. Any ideas for improving this process to make it easier or faster, or to improve the installer itself or the installation experience for Windows users would be appreciated.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
== Improve macOS binary packaging ==<br />
<br />
We would like to be able to easily generate binary packages for macOS. Right now, it's difficult and tedious to do so. Most OS X users install Octave using one of the source-based package managers such as Homebrew or MacPorts. Any way to help us build a binary package would be appreciated. Required knowledge is understanding how building binaries in macOS works. Our current approach to building binaries for Windows is to cross-compile from a GNU system using [http://mxe.cc/ MXE], something similar may be possible for OS X ([http://lilypond.org/gub/ GUB]?).<br />
<br />
There is a third-party project called [http://octave-app.org "Octave.app"] that creates and distributes macOS builds of Octave as a Mac app bundle. It is built on top of Homebrew and a set of custom Octave-related Homebrew formuale.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. If you choose to work on GUB, Python will be required. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
=Performance=<br />
<br />
* A profiler for Octave would be a very useful tool. And now we have one! But it really needs a better interface.<br />
* Having {{Codeline|parfor}} functioning would speed code development and execution now that multicore architectures are widespread. See [http://octave.1599824.n4.nabble.com/Parfor-td4630575.html here] and [http://stackoverflow.com/questions/24970519/how-to-use-parallel-for-loop-in-octave-or-scilab here]. Existing code from the [[Parallel package | parallel]] and [http://octave.sourceforge.net/mpi/index.html mpi] packages could perhaps be adapted for this.<br />
* Develop a performance benchmark for Octave (interpreter, load/save, plotting, etc., but not simply tests of underlying libraries such as BLAS or LAPACK). This benchmark could be run periodically to make sure that changes during development do not introduce regressions in performance.<br />
<br />
=Packaging=<br />
<br />
* create a system that allows packages to deprecate functions as in core. Possibilities are:<br />
** get pkg to accept a deprecated directory inside the package and add it to the search path. Functions in those directories would have to be treated the same as the ones inside the core deprecated<br />
** PKG_ADD can be used to hack this. Package developers would still have to actually write the warnings on the function code but this would allow to have the functions in a separate directory so they don't foget to remove them on the next release<br />
** the package developer can also use something like Make to create a ''normal'' package from something that actually had a more complex structure, inclusive deprecated directories<br />
* get pkg to resolve dependencies automatically by downloading and installing them too<br />
* allow to download and install multiple versions of the same package<br />
* make the package just a bit more verbose by default (specifics?)<br />
* make pkg a little more like apt-get (what specific features of apt-get is this referring to?)<br />
* make pkg support more than one src directory<br />
** subdirectories with makefiles and top level make command of: cd <subdir> && ${MAKE}... ok as a substitute?<br />
* make pkg able to supply extra configure and make flags, useful for distributions, including -j for make (pkg now passes --jobs=N automatically, CFLAGS and CXXFLAGS environment variables are already respected, what's missing?)<br />
<br />
=Preferences=<br />
<br />
Octave has several functions for managing user preferences. Many function use persistent variables instead of relying upon the preference features.<br />
* The function {{Codeline|edit ()}} contains a persistent structure used as its personal set of preferences. These can all be moved to the user preference group for the editor.<br />
** "EDITOR"<br />
** "HOME"<br />
** "AUTHOR"<br />
** "EMAIL"<br />
** "LICENSE"<br />
** "MODE"<br />
** "EDITINPLACE"<br />
* The {{Codeline|savepath ()}} function modifies the startup script (rcfile), {{Codeline|~/.octaverc}} and inserts commands to allow the next session to begin with the same path. Instead user preference can be created for startup items and a preference for the user specified path can be added. Perhaps two path preferences should be used. One for the elements that should precede the core path and those that should follow. A start up directory preference might also be added to allow the user to specify where Octave should begin the next session.<br />
** "PREPATH"<br />
** "POSTPATH"<br />
** "STARTUPDIR"<br />
* A preference group for plotting can also be added. A preference for the default terminal would be useful for those who want to override the default. Preferences for the default {{Codeline|graphicstoolkit}} can also be added.<br />
** GNUPLOTTERM<br />
** GRAPHICSTOOLKIT<br />
* A preference group for printing can include preferences for the default printer, the ghostscript command, and possibly other parameters like orientation, and resolution.<br />
** PRINTER<br />
** GHOSTSCRIPTCOMMAND<br />
** ORIENTATION<br />
** RESOLUTION<br />
* Searching the m-files for use of {{Codeline|persistent}} should turn up other opportunities to use preferences.<br />
<br />
=Bugs=<br />
<br />
There are always bugs to fix. The [https://savannah.gnu.org/bugs/?group=octave bug tracker] is a good place to find tasks needing a hand. See also [[Short projects#Bugs]].<br />
<br />
= Matlab compatibility =<br />
<br />
== Missing functions ==<br />
<br />
There are certain functions present in MATLAB known to be missing in Octave.<br />
<br />
One list is provided on the source for function __unimplemented.m__, subfunction missing_functions; it can be edited in the Octave GUI or browsed at [http://hg.savannah.gnu.org/hgweb/octave/file/default/scripts/help/__unimplemented__.m#l547].<br />
<br />
Lists are also kept for [[:Category:Missing functions|several packages]].<br />
<br />
It is also possible to look at existing [[Wikipedia:Free and open-source software|FOSS]] implementations, from FreeMat and Scilab (for more closely compatible languages) to R or Scipy or Julia (for less compatible versions). Obviously, it is NOT OK to look at the Matlab implementation since this is not [[Wikipedia:Free software|free software]]!<br />
<br />
== Functions under different name ==<br />
<br />
Many Octave Forge functions perform the same as functions from matlab packages. However, they often exist under a different name or have incompatible API's. Often fixing this is a matter of changing their names, swap the order of their input arguments. At least, a list of this functions would be helpful.<br />
<br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Project Ideas]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Projects&diff=13335Projects2020-09-16T01:30:37Z<p>Siko1056: /* Non-OpenGL renderer */</p>
<hr />
<div>The list below summarizes features or bug fixes we would like to see in Octave. This list is not exclusive -- there are many other things that might be good projects, but it might instead be something we already have. Also, some of the following items may not actually be considered good ideas now.<br />
<br />
{{Note|If you never contributed to Octave before, we suggest to start with our [[Developer FAQ]].}}<br />
<br />
* Summer of Code students, please also see [[Summer of Code - Getting Started]].<br />
* If you're looking for small project, see [[short projects]].<br />
<br />
=Numerical=<br />
<br />
* Use C++11 <random> libraries for random number generation. Write link between Octave functions (rand, randi, randn, rande) and C++ API. Implement RandStream objects as Matlab does.<br />
<br />
*Improve logm, and sqrtm (see this thread: http://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html)<br />
<br />
*Use pairwise addition in sum() to mitigate against numerical errors without substantial performance penalty (https://en.wikipedia.org/wiki/Pairwise_summation).<br />
<br />
*Review implementing algorithm in this 2009 paper (https://epubs.siam.org/doi/pdf/10.1137/080738490) for xsum (sum with extra accuracy). The existing implementation uses a 2005 paper.<br />
<br />
*Improve complex mapper functions. See W. Kahan, ``Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit (in The State of the Art in Numerical Analysis, eds. Iserles and Powell, Clarendon Press, Oxford, 1987) for explicit trigonometric formulae. See {{patch|8172}} for a previous attempt.<br />
<br />
*Make functions like gamma() return the right IEEE Inf or NaN values for extreme args or other undefined cases.<br />
<br />
*Improve sqp.<br />
<br />
*Fix CollocWt? to handle Laguerre polynomials. Make it easy to extend it to other polynomial types.<br />
<br />
*Add optional arguments to colloc so that it's not restricted to Legendre polynomials.<br />
<br />
*Move rand, eye, xpow, xdiv, etc., functions to the matrix classes.<br />
<br />
*Improve design of ODE, DAE, classes.<br />
<br />
*Make QR more memory efficient for large matrices when not all the columns of Q are required (apparently this is not handled by the lapack code yet).<br />
<br />
*Evaluate harmonics and cross-correlations of unevenly sampled and nonstationary time series, as in http://www.jstatsoft.org/v11/i02 (which has C code with interface to R). (This is now partly implemented in the [http://octave.sourceforge.net/lssa/index.html lssa] package.)<br />
<br />
<!-- == General purpose Finite Element library ==<br />
<br />
Octave-Forge already has a set of packages for discretizing Partial Differential operators by Finite Elements and/or Finite Volumes,<br />
namely the [[bim package]] which relies on the [http://octave.sf.net/msh msh package] (which is in turn based on [http://geuz.org/gmsh/ gmsh]) for creating and managing 2D triangular and 3D tetrahedral meshes and on the [http://octave.sf.net/fpl fpl package] for visualizing 2D results within Octave or exporting 2D or 3D results in a format compatible with [http://www.paraview.org Paraview] or [https://wci.llnl.gov/codes/visit/ VisIT]. These packages, though, offer only a limited choice of spatial discretization methods which are based on low degree polynomials and therefore have a low order of accuracy even for problems with extremely smooth solutions.<br />
The [http://geopdes.sf.net GeoPDEs] project, on the other hand, offers a complete suite of functions for discretizing a wide range of<br />
differential operators related to important physical problems and uses basis functions of arbitrary polynomial degree that allow the construction of methods of high accuracy. These latter, though, are based on the IsoGeometric Analysis Method which, although very powerful and often better performing, is less widely known and adopted than the Finite Elements Method. The implementation of a general purpose library of Finite Elements seems therefore a valuable addition to Octave-Forge. Two possible interesting choices for implementing this package exist, the first consists of implementing the most common Finite Element spaces in the [http://geopdes.sf.net GeoPDEs] framework, which is possible as IsoGeometric Analysis can be viewed as a superset of the Finite Element Method, the other is to construct Octave language bindings for the free software library [http://fenicsproject.org/documentation/ FEniCS] based on the existing C++ or Python interfaces. This second approach has been developed during the GSOC 2013 and the Octave-Forge package [http://octave.sf.net/fem-fenics fem-fenics] is now available. However, fem-fenics could be extended in many different ways:<br />
* implement the bindings for the UFL language inside Octave<br />
* add new functions already available with Fenics but not yet in Octave<br />
* create new functions specifically suited for Octave<br />
* improve the efficiency of the code<br />
The main goal for the fem-fenics package is ultimately to be merged with the FEnics project itself, so that it can remain in-sync with the main library development. --><br />
<br />
== Implement solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D ==<br />
<br />
The project will deliver a solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D similar to Matlab's function <tt>pdepe</tt>. A good starting point is the [http://en.wikipedia.org/wiki/Method_of_lines method of lines] for which you can find more details [http://en.wikibooks.org/wiki/Partial_Differential_Equations/Method_of_Lines here] and [http://www.scholarpedia.org/article/Method_of_lines here], whereas an example implementation can be found [http://www.scholarpedia.org/article/Method_of_Lines/Example_Implementation here]. In addition, [http://www.pdecomp.net/ this page] provides some useful material.<br />
<br />
== Implement solver for 1D nonlinear boundary value problems ==<br />
<br />
The project will complete the implementation of the bvp4c solver that is already available in an initial version in the odepkg package<br />
by adding a proper error estimator and will implement a matlab-compatible version of the bvp5c solver.<br />
Details on the methods to be implemented can be found in [http://dx.doi.org/10.1145/502800.502801 this paper] on bvp4c and [http://www.jnaiam.net/new/uploads/files/014dde86eef73328e7ab674d1a32aa9c.pdf this paper] on bvp5c. Further details are available in [http://books.google.it/books/about/Nonlinear_two_point_boundary_value_probl.html?id=s_pQAAAAMAAJ&redir_esc=y this book].<br />
<br />
<!-- == Geometric integrators for Hamiltonian Systems ==<br />
<br />
[http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration Geometric (AKA Symplectic) integrators] are useful for <br />
multi-dimensional classical mechanics problems and for molecular dynamics simulations.<br />
The odepkg package has a number of solvers for ODE, DAE and DDE problems but none of them is currently<br />
specifically suited for second order problems in general and Hamiltonian systems in particular.<br />
Therefore a new package for geometric integrators would be a useful contribution.<br />
This could be created as new package or added as a set of new functions for odepkg.<br />
The function interface should be consistent throughout the package and should be modeled to follow <br />
that of other functions in odepkg (or that of DASPK and LSODE) but will need specific extensions to accommodate for specific options that only make sense for this specific class of solvers.<br />
An initial list of methods to be implemented includes (but is not limited to)<br />
* Symplectic Euler methods, see [http://en.wikipedia.org/wiki/Semi-implicit_Euler_method here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Störmer-Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Velocity Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Symplectic partitioned Runge-Kutta methods, see [http://reference.wolfram.com/mathematica/tutorial/NDSolveSPRK.html here] or [http://dx.doi.org/10.1137/0733019 here]<br />
* Spectral Variational Integrator methods, see [http://www3.nd.edu/~izaguirr/papers/acta_numerica.pdf here] or [http://www.math.ucsd.edu/~mleok/pdf/HaLe2012_SVI.pdf here]<br />
<br />
For this latter there is an existing code which is already working but needs to be improved, posted on the patch tracker.<br />
Furthermore, methods to implement solutions of problems with rigid constraints should be implemented, e.g.<br />
* SHAKE, see [http://en.wikipedia.org/wiki/Constraint_algorithm here] or [http://dx.doi.org/10.1016/0021-9991(77)90098-5 here]<br />
* RATTLE, see [http://dx.doi.org/10.1016/0021-9991(83)90014-1 here] or [http://dx.doi.org/10.1002/jcc.540161003 here]<br />
--><br />
<br />
== Matlab-compatible ODE solvers in core-Octave ==<br />
<br />
* Improve handling of sparse Jacobians in IDE/DAE solvers<br />
** Currently, in the IDA wrapper function __ode15__ an over conservative guess for the amount of memory to be allocated when assembling a sparse jacobian is used, essentially allocating enough space for a full jacobian then freeing the excess memory, an initial patch for fixing this has been posted on the tracker, for integrating this into Octave it must be generalized to support prior versions of SUNDIALS<br />
** Currently Jacobians passed by the user in Octave's sparse matrix format are copied into SUNDIALS own sparse matrix format. Newer versions of SUNDIALS (5.x or higher) support letting the user take care of the linear algebra data structures and methods thus removing the need for the copy. Taking advantage of this feature would improve the solver performance both in terms of memory footprint and speed.<br />
** References<br />
***[https://savannah.gnu.org/bugs/?func=detailitem&item_id=55905 tracker post about memory allocation] <br />
***[https://computing.llnl.gov/projects/sundials/release-history SUNDIALS release history]<br />
* Implement Matlab compatible versions of "deval".<br />
* Complete transition of ode23s into core Octave<br />
** [https://savannah.gnu.org/bugs/?57309 Bug tracker entry discussing ode23s]<br />
<br />
== High Precision Arithmetic Computation ==<br />
<br />
The Linear Algebra Fortran libraries used by Octave make use of of single (32 bits) and double (64 bits) precision floating point numbers. Many operations are stopped when matrices condition number goes below 1e-16: such matrices are considered as ill-conditioned. There are cases where this is not enough, for instance simulations implying chemical concentrations covering the range 10^4 up to 10^34. There are a number of ways to increase the numerical resolution, like f.i. make use of 128 bits quadruple precision numbers available in GFortran. A simpler option is to build an interface over Gnu MPL arbitrary precision library, which is used internally by gcc and should be available on any platform where gcc runs. Such approach has been made available for MatLab under the name mptoolbox and is licensed under a BSD license. The author kindly provided a copy of the latest version and agreed to have it ported under Octave and re-distributed under GPL v3.0<br />
<br />
The architecture consists of an Octave class interface implementing "mp" (multi-precision) objects. Arithmetic operations are forwarded to MPL using MEX files. This is totally transparent to the end user, except when displaying numbers. This implementation needs to be ported and tested under Octave.<br />
<br />
=GUI/IDE=<br />
<br />
*Søren Hauberg has suggested that we need C++ code that can:<br />
**Determine if a line of code could be fully parsed, i.e. it would return true for "plot (x, y);", but false for "while (true)".<br />
**Evaluate a line of code and return the output as a string (it would be best if it could provide three strings: output, warnings and errors).<br />
**Query defined variables, i.e. get a list of currently defined variables. Bonus points if it could tell you if anything had changed since the last time you checked the variables (could also be done with signals).<br />
* Create a better (G)UI for the {{manual|profile|profiler}}. This may be done with Qt, but not necessarily.<br />
<br />
== GUI Variable Editor and Property Inspector ==<br />
<br />
Octave has a preliminary implementation of a Variable Editor: a spreadsheet-like tool for quickly editing and visualizing variables. The initial phase of the project will be learning how the implementation was done.<br />
<br />
With the knowledge gained, the second part of the project will be to implement a Property Inspector. This is a spreadsheet like interface to the many, many graphics properties that exist and are different on a per-object basis. The goal would be not only the concise-display of the existing properties, but a reasonable user interface to change them. As examples, Boolean properties should be able to be toggled with a double-click; Radio properties should have a drop-down list of only the supported options; Other properties that can be modified should have the constraints built-in (for example, Linewidth must be a scalar, while Position must be a 1x4 vector). It would also be important to have easy access to the documentation of a property.<br />
<br />
For reference, Matlab has a similar Property Inspector (https://www.mathworks.com/help/matlab/ref/inspect.html).<br />
<br />
== Sisotool. Create a graphical design tool for tuning closed loop control system ([[Control package]])==<br />
<br />
When tuning a SISO feedback system it is very helpful to be able to grab a pole or a zero and move them by dragging them with the mouse. As they are moving the software must update all the plotted lines. There should be the ability to display various graphs rlocuse, bode, step, impulse etc. and have them all change dynamically as the mouse is moving. The parameters of the compensator must be displayed and updated.<br />
Recently, some implementation was done during [[Summer_of_Code#GSoC_2018|GSoC 2018]], see https://eriveltongualter.github.io/GSoC2018/final.html for details.<br />
<br />
=Sparse Matrices=<br />
<br />
The paper by [http://arxiv.org/abs/cs.MS/0604006 Bateman & Adler] is good reading for understanding the sparse matrix implementation.<br />
<br />
*Improve Matlab compatibility for {{manual|sprandsym}}.<br />
<br />
*Sparse logical indexing in idx_vector class so that something like <code>a = sprandn (1e6, 1e6, 1e-6); a(a<1) = 0;</code> won't cause a memory overflow.<br />
<br />
*Other missing Functions<br />
**lsqr<br />
**minres<br />
**symmlq<br />
<br />
== SPQR Interface ==<br />
<br />
Octave implements QR factorization for sparse matrices, but it does so with an older "CXSPARSE" library. This has caused fundamental issues, including segfaults as recorded here (bugs {{bug|51950}} and {{bug|57033}}). The goal of this project is to program an interface to the API for the SQPR library (http://faculty.cse.tamu.edu/davis/suitesparse.html). This is the same library that Matlab uses for this purpose.<br />
<br />
*Improve QR factorization functions, using idea based on CSPARSE cs_dmsol.m<br />
<br />
*Improve QR factorization by replacing CXSPARSE code with SPQR code, and make the linear solve return 2-norm solutions for ill-conditioned matrices based on this new code<br />
<br />
=Strings=<br />
<br />
*Consider making octave_print_internal() print some sort of text representation for unprintable characters instead of sending them directly to the terminal. (But don't do this for fprintf!)<br />
<br />
*Consider changing the default value of `string_fill_char' from SPC to NUL.<br />
<br />
=Other Data Types=<br />
<br />
*Template functions for mixed-type ops.<br />
<br />
*Convert other functions for use with the floating point type including quad, dasrt, daspk, etc.<br />
<br />
=Input/Output=<br />
<br />
*Make fread and fwrite work for complex data. Iostreams based versions of these functions would also be nice, and if you are working on them, it would be good to support other size specifications (integer*2, etc.).<br />
<br />
*Move some pr-output stuff to liboctave.<br />
<br />
*Make the cutoff point for changing to packed storage a user-preference variable with default value 8192.<br />
<br />
*Complain if there is not enough disk space available (I think there is simply not enough error checking in the code that handles writing data).<br />
<br />
*Make it possible to tie arbitrary input and output streams together, similar to the way iostreams can be tied together.<br />
<br />
*Expand {{codeline|imwrite}} options. This shouldn't be too hard to implement, since it's wrapped around GraphicsMagick.<br />
<br />
*Extend Octave functions to work on stored arrays that are too big to fit in RAM, similar to available R [http://www.bigmemory.org/ packages.]<br />
<br />
* write {{codeline|xmlread}} and {{codeline|xmlwrite}}. This could be done using [http://xerces.apache.org/xerces-c/ Xerces C++ interface] which apparently is what [http://octave.1599824.n4.nabble.com/xml-in-octave-td4663034.html Matlab uses].<br />
<br />
* Implement hdf5 for .mat files (see [http://octave.1599824.n4.nabble.com/Reading-Matlab-td4650158.html this thread]).<br />
<br />
=Interpreter=<br />
<br />
The interpreter is written in C++, undocumented. There are many possible projects associated with it.<br />
<br />
'''Required skills''': ''Very good'' C and C++ knowledge, possibly also understanding of [http://en.wikipedia.org/wiki/Gnu_bison GNU bison] and [http://en.wikipedia.org/wiki/Flex_lexical_analyser flex]. Understanding how compilers and interpreters are made plus being able to understand how to use a profiler and a debugger will probably be essential skills.<br />
<br />
*Allow customization of the debug prompt.<br />
<br />
*Fix the parser so that<br />
<br />
if (expr) 'this is a string' end<br />
<br />
is parsed as IF expr STRING END. ''(see [https://lists.gnu.org/archive/html/octave-maintainers/2014-03/msg00087.html this] post on the mailing list)''<br />
<br />
*Clean up functions in input.cc that handle user input (there currently seems to be some unnecessary duplication of code and it seems overly complex).<br />
<br />
*Consider allowing an arbitrary property list to be attached to any variable. This could be a more general way to handle the help string that can currently be added with `document'.<br />
<br />
*Allow more command line options to be accessible as built-in variables (--echo-commands, etc.).<br />
<br />
*Make the interpreter run faster.<br />
<br />
*Allow arbitrary lower bounds for array indexing.<br />
<br />
*Improve performance of recursive function calls.<br />
<br />
*Improve the way ignore_function_time_stamp works to allow selecting by individual directories or functions.<br />
<br />
*Add a command-line option to tell Octave to just do syntax checking and not execute statements.<br />
<br />
*Clean up symtab and variable stuff.<br />
<br />
*Input stream class for parser files -- must manage buffers for flex and context for global variable settings.<br />
<br />
*make parser do more semantic checking, continue after errors when compiling functions, etc.<br />
<br />
*Make LEXICAL_ERROR have a value that is the error message for parse_error() to print?<br />
<br />
*Add a run-time alias mechanism that would allow things like alias fun function_with_a_very_long_name so that `function_with_a_very_long_name' could be invoked as `fun'.<br />
<br />
*Allow local changes to variables to be written more compactly than is currently possible with unwind_protect. For example, <br />
<br />
function f ()<br />
local prefer_column_vectors = something;<br />
...<br />
endfunction<br />
<br />
<br />
would be equivalent to<br />
<br />
function f ()<br />
save_prefer_column_vectors = prefer_column_vectors;<br />
unwind_protect<br />
prefer_column_vectors = something;<br />
...<br />
unwind_protect_cleanup<br />
prefer_column_vectors = save_prefer_column_vectors;<br />
end_unwind_protect<br />
endfunction<br />
<br />
<br />
*Fix all function files to check for bogus inputs (wrong number or types of input arguments, wrong number of output arguments).<br />
<br />
*Handle options for built-in functions more consistently.<br />
<br />
*Too much time is spent allocating and freeing memory. What can be done to improve performance?<br />
<br />
Use move constructors rather than copy constructors for things like dim_vectors which are repeatedly created just to initialize Array or Matrix objects.<br />
<br />
*Error output from Fortran code is ugly. Something should be done to make it look better.<br />
<br />
*It would be nice if output from the Fortran routines could be passed through the pager.<br />
<br />
*Attempt to recognize common subexpressions in the parser.<br />
<br />
*Consider making it possible to specify an empty matrix with a syntax like [](e1, e2). Of course at least one of the expressions must be zero...<br />
<br />
*Is Matrix::fortran_vec() really necessary?<br />
<br />
*Rewrite whos and the symbol_record_info class. Write a built-in function that gives all the basic information, then write who and whos as M-files.<br />
<br />
*On systems that support matherr(), make it possible for users to enable the printing of warning messages.<br />
<br />
*Make it possible to mark variables and functions as read-only.<br />
<br />
*Make it possible to write a function that gets a reference to a matrix in memory and change one or more elements without generating a second copy of the data.<br />
<br />
*Use nanosleep instead of usleep if it is available? Apparently nanosleep is to be preferred over usleep on Solaris systems.<br />
<br />
== Improve JIT compiling ==<br />
<br />
Octave's interpreter is ''very'' slow on some loops. Recently, thanks to Max Brister's work, an initial implementation of a just-in-time compiler (JITC) in [http://llvm.org LLVM] for GSoC 2012. This project consists in understanding Max's current implementation and extending it so that functions and exponents (e.g. 2^z) compile with the JITC. This requires knowledge of compilers, C++, LLVM, and the Octave or Matlab languages. A capable student who demonstrates the ability to acquire this knowledge quickly may also be considered. Max himself will mentor this project. [http://planet.octave.org/octconf2012/jit.pdf Here] is Max's OctConf 2012 presentation about his current implementation. See also [[JIT]].<br />
<br />
== Improve memory management ==<br />
<br />
From profiling the interpreter, it appears that a lot of time is spending allocating and deallocating memory. A better memory management algorithm might provide some improvement.<br />
<br />
== Implement classdef classes ==<br />
<br />
Matlab has two kinds of classes: old style @classes and new style classdef. Octave has only fully implemented the old style. There is partial support for classdef classes in version 4.0, refer to the [[Classdef|classdef status page]] for what is not yet implemented. There is irregular work here, and classdef is [http://www.mathworks.com/help/matlab/matlab_oop/method-attributes.html a very] [http://www.mathworks.com/help/matlab/events-sending-and-responding-to-messages.html complicated] [http://www.mathworks.com/help/matlab/enumeration-classes.html thing] to fully implement. A successful project would be to implement enough of classdef for most basic usages. Familiarity with Matlab's current classdef support would be a huge plus. Michael Goffioul and jwe can mentor this.<br />
<br />
Although there's already a substantial classdef support in current octave code base, there are still many areas that are unimplemented or need improvements. The main ones that come to my mind are:<br />
* support for events<br />
* support for enums<br />
* support for "import" (this requires good understanding of octave internals, especially the symbol table)<br />
* improving multiple inheritance and method resolution<br />
* honoring and computing "Sealed" attribute<br />
* support for function handle to methods<br />
<br />
== Improve MPI package ==<br />
<br />
Octave Forge's [http://octave.sourceforge.net/mpi/index.html MPI package] <br />
is a wrapper for basic MPI functions for parallel computing. It is implemented <br />
by wrapping MPI function calls in simple DLD functions that map Octave's Datataypes to <br />
MPI Derived Datatypes. <br />
The proposed project deals with improving and extending the Octave MPI package, for example:<br />
* Octave MPI applications can currently be only run in batch mode, add the ability to launch parallel jobs and collect their output in an interactive Octave session.<br />
* Implement functions for non-blocking communication (MPI_Isend, MPI_Irecv)<br />
* Implement one-to-many (Broadcast, Scatter), many-to-one (Reduce, Gather), and many-to-many (All Reduce, Allgather) communication routines<br />
<br />
= Graphics =<br />
<br />
* Correctly handle case where DISPLAY is unset. Provide --no-window-system or --nodisplay (?) option. Provide --display=DISPLAY option? How will this work with gnuplot (i.e., how do we know whether gnuplot requires an X display to display graphics)?<br />
<br />
* Implement a Cairo-based renderer for 2D-only graphics, with support for PS/PDF/SVG output (for printing).<br />
<br />
* On 'imagesc' plots, report the matrix values also based on the mouse position, updating on mouse moving.<br />
<br />
* Add map-creating capabilities similar to the Matlab [https://www.mathworks.com/help/map/functionlist.html Mapping toolbox] for inclusion in the Octave Forge [https://sourceforge.net/p/octave/mapping mapping package].<br />
<br />
* Add data cursor to trace data values in figure.<br />
<br />
== Non-OpenGL renderer ==<br />
<br />
Besides the original gnuplot backend, Octave also contains an OpenGL-based renderer for advanced and more powerful 3D plots. However, OpenGL is not perfectly suited for 2D-only plots where other methods could result in better graphics. The purpose of this project is to implement an alternate graphics renderer for 2D only plots (although 3D is definitely not the focus, extending the new graphics renderer to support basic 3D features should also be taken into account). There is no particular toolkit/library that must be used, but natural candidates are:<br />
* [http://qt.nokia.com Qt]: the GUI is currently written in Qt<br />
* [http://en.wikipedia.org/wiki/Cairo_%28software%29 Cairo]: this library is widely used and known to provides high-quality graphics with support for PS/PDF/SVG output.<br />
<br />
== LaTeX markup ==<br />
<br />
Text objects in plots (like titles, labels, texts...) in the OpenGL renderer only support plain text and TeX. The latter consists of a very limited subset of the TeX language. On the other hand, the LaTeX formatting support is expected to provide full LaTeX capabilities. There are various approaches that can be used:<br />
* Use an external LaTeX engine: this is the most straightforward, but it requires users to install a LaTeX distribution and setup Octave to use it.<br />
* Use an external library that supports LaTeX syntax, e.g. [https://github.com/opencollab/jlatexmath JLaTeXMath] a Java API to display LaTeX code, [https://github.com/nathancarter/qtmathjax qtmathjax] a Qt based library that executes MathJax in a background web page.<br />
* Implement our own LaTeX parser and renderer. The matplotlib project [http://matplotlib.sourceforge.net/users/usetex.html has already done this in Python] and might be used as an example of how to do this in Octave. There is also [https://github.com/jkriege2/JKQtPlotter JKQtPlotter], a Qt based plotting application which implements its own LaTeX parser/renderer in C++.<br />
<br />
=History=<br />
<br />
*Add an option to allow saving input from script files in the history list.<br />
<br />
*The history command should accept two numeric arguments to indicate a range of history entries to display, save or read.<br />
<br />
*Avoid writing the history file if the history list has not changed.<br />
<br />
*Avoid permission errors if the history file cannot be opened for writing.<br />
<br />
*Fix history problems — core dump if multiple processes are writing to the same history file?<br />
<br />
= Configuration and Installation =<br />
<br />
* Makefile changes:<br />
** eliminate for loops<br />
** define shell commands or eliminate them<br />
** consolidate targets<br />
<br />
* Create a docs-only distribution?<br />
<br />
=Documentation=<br />
:''See [[Project - Documentation]].''<br />
<br />
=Tests=<br />
*Improved set of tests: [http://octave.1599824.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=370633]<br />
**Tests for various functions. Would be nice to have a test file corresponding to every function (see below)<br />
**Tests for element by element operators: + - .* ./ .\ .^ | & < <= == >= > != !<br />
*** thorough tests for power operator including corner cases and strange combinations such as complex .^ range.<br />
**Tests for boolean operators: && ||<br />
**Tests for other operators: * / \ ' .'<br />
**Tests from bug reports.<br />
**Tests for indexed assignment. Need to consider the following:<br />
***fortran-style indexing<br />
***zero-one indexing<br />
***assignment of empty matrix as well as values resizing<br />
**Tests for all internal functions.<br />
<br />
* Implement a coverage tool for collecting coverage data and generating code coverage reports on m-file functions and scripts. This would be very useful for Octave development as well as for users who want a code coverage report for their own functions and scripts.<br />
<br />
We are far from even having one test for every function, so focus should be on getting the breadth of coverage first before trying to get the depth of 100% statement coverage. As of Dec 2015, 202 of 1020 m-files have no tests. Some of these will be plotting functions which have demos instead, but that leaves enough functions to be an interesting project. As of Dec 2015, there are 485 instances of C++ functions which need tests.<br />
<br />
After Octave is compiled, running the {{Codeline|make check}} build target will run the full test suite and generate a file called test/fntests.log in the build directory with a summary of the results. At the end of the file is a list of all functions for which no tests were found. An extract is posted in the [[files missing tests]] page. If you are not building Octave yourself, the test suite can be run on an installed binary copy by executing the {{Codeline|__run_test_suite__}} command at the Octave prompt. The fntests.log file will be written in the current directory in this case.<br />
<br />
There also need to be tests for functions written in the C++ files. See [[Add_BIST_tests_for_octave_functions_written_in_C%2B%2B]] for instructions and a list of instances.<br />
<br />
See also [[Continuous Build#Coverage Report]].<br />
<br />
=Programming=<br />
<br />
*Better error messages for missing operators?<br />
<br />
*Eliminate duplicate enums in pt-exp.cc, pt-const.cc, and ov.cc.<br />
<br />
*Handle octave_print_internal() stuff at the liboctave level. Then the octave_value classes could just call on the print() methods for the underlying classes.<br />
<br />
*As much as possible, eliminate explicit checks for the types of octave_value objects so that user-defined types will automatically do the right thing in more cases.<br />
<br />
*Only include config.h in files that actually need it, instead of including it in every .cc file. Unfortunately, this might not be so easy to figure out.<br />
<br />
*GNU coding standards:<br />
**Add a `Makefile' target to the Makefiles.<br />
**Comments on #else and #endif preprocessor commands.<br />
**Change error message format to match standards everywhere.<br />
<br />
*Eliminate more global variables.<br />
<br />
*Move procstream to liboctave.<br />
<br />
*Use references and classes in more places.<br />
<br />
*Share more code among the various _options functions.<br />
<br />
*Use non-empty identifiers in all warnings and errors issued by Octave, see [[Easy projects#Miscellaneous]].<br />
<br />
*Reduce the amount of datatypes in liboctave.<br />
<br />
*Re-implement operators using templates and modern C++. Current system evolved before templates and makes extensive use of macros to define interactions between scalar<->scalar, scalar<->matrix, scalar<->float, etc., etc.<br />
**In liboctave, the directory to work on is liboctave/operators<br />
**In libinterp, the directory to work on is libinterp/operators<br />
**In libinterp, there is also xpow.cc, xdiv.cc in libinterp/corefcn<br />
<br />
=Miscellaneous=<br />
<br />
*Implement some functions for interprocess communication: bind, accept, connect, gethostbyname, etc. (This functionality is already available in the octave sockets package, what is the purpose of moving it to core octave?)<br />
<br />
*The ability to transparently handle very large files: Juhana K Kouhia <kouhia@nic.funet.fi> wrote:<br />
*: If I have a one-dimensional signal data with the size 400 Mbytes, then what are my choices to operate with it:<br />
*:*I have to split the data<br />
*:*Octave has a virtual memory on its own and I don't have to worry about the splitting.<br />
*:If I split the data, then my easily programmed processing programs will become hard to program.<br />
*:If possible, I would like to have the virtual memory system in Octave i.e., the all big files, the user see as one big array or such. There could be several user selectable models to do the virtual memory depending on what kind of data the user have (1d, 2d) and in what order they are processed (stream or random access).<br />
<br />
*An interface to gdb. Michael Smolsky <fnsiguc@weizmann.weizmann.ac.il> wrote:<br />
*:I was thinking about a tool, which could be very useful for me in my numerical simulation work. It is an interconnection between gdb and octave. We are often managing very large arrays of data in our fortran or c codes, which might be studied with the help of octave at the algorithm development stages. Assume you're coding, say, wave equation. And want to debug the code. It would be great to pick some array from the memory of the code you're developing, fft it and see the image as a log-log plot of the spectral density. I'm facing similar problems now. To avoid high c-development cost, I develop in matlab/octave, and then rewrite into c. It might be so much easier, if I could off-load a c array right from the debugger into octave, study it, and, perhaps, change some [many] values with a convenient matlab/octave syntax, similar to <code>a(:,51:250)=zeros(100,200)</code>, and then store it back into the memory of my c code.<br />
<br />
*Implement gdb extensions for Octave types. Octave has the <code>etc/gdbinit</code> file, which has some basic support for displaying the contents of Octave types. Add more extensions to make it easier to debug octave_values and other Octave types.<br />
<br />
*Add a definition to lgrind so that it supports Octave. (See http://www.tex.ac.uk/tex-archive/support/lgrind/ for more information about lgrind.)<br />
<br />
*Spatial statistics, including covariogram estimation and kriging -- perhaps via an interface to [http://www.gstat.org/ gstat]?<br />
<br />
* the [http://octave.sourceforge.net/miscellaneous/function/units.html units] function from the miscellaneous package works by parsing the output of from a call to GNU units. This can be made much more robust by writing it in C++ and including its library "units.h"<br />
<br />
=Marketing and Community=<br />
<br />
* Make the Octave website/[[Project Infrastructure]] easier to maintain.<br />
<br />
* Make it easier for newcomers to contribute.<br />
<br />
* For marketing ideas, see the [https://openoffice.apache.org/orientation/intro-marketing.html Apache Open Office Introduction to Marketing]<br />
<br />
* Help design a user or a [https://www.openoffice.org/marketing/ooocon2006/presentations/wednesday_c10.pdf developer survey]<br />
<br />
* Help prepare and deliver presentations and [[Publications about Octave]] at colleges and universities.<br />
<br />
* Create a [[Forum for GNU Octave]].<br />
<br />
== Improve Windows binary packaging ==<br />
<br />
We are currently able to build and provide a [[Windows Installer|installer for Windows]]. The build process involves cross-compiling on a Linux system using a fork of the [http://mxe.cc/ MXE] project to build Octave and all of its dependencies. Any ideas for improving this process to make it easier or faster, or to improve the installer itself or the installation experience for Windows users would be appreciated.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
== Improve macOS binary packaging ==<br />
<br />
We would like to be able to easily generate binary packages for macOS. Right now, it's difficult and tedious to do so. Most OS X users install Octave using one of the source-based package managers such as Homebrew or MacPorts. Any way to help us build a binary package would be appreciated. Required knowledge is understanding how building binaries in macOS works. Our current approach to building binaries for Windows is to cross-compile from a GNU system using [http://mxe.cc/ MXE], something similar may be possible for OS X ([http://lilypond.org/gub/ GUB]?).<br />
<br />
There is a third-party project called [http://octave-app.org "Octave.app"] that creates and distributes macOS builds of Octave as a Mac app bundle. It is built on top of Homebrew and a set of custom Octave-related Homebrew formuale.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. If you choose to work on GUB, Python will be required. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
=Performance=<br />
<br />
* A profiler for Octave would be a very useful tool. And now we have one! But it really needs a better interface.<br />
* Having {{Codeline|parfor}} functioning would speed code development and execution now that multicore architectures are widespread. See [http://octave.1599824.n4.nabble.com/Parfor-td4630575.html here] and [http://stackoverflow.com/questions/24970519/how-to-use-parallel-for-loop-in-octave-or-scilab here]. Existing code from the [[Parallel package | parallel]] and [http://octave.sourceforge.net/mpi/index.html mpi] packages could perhaps be adapted for this.<br />
* Develop a performance benchmark for Octave (interpreter, load/save, plotting, etc., but not simply tests of underlying libraries such as BLAS or LAPACK). This benchmark could be run periodically to make sure that changes during development do not introduce regressions in performance.<br />
<br />
=Packaging=<br />
<br />
* create a system that allows packages to deprecate functions as in core. Possibilities are:<br />
** get pkg to accept a deprecated directory inside the package and add it to the search path. Functions in those directories would have to be treated the same as the ones inside the core deprecated<br />
** PKG_ADD can be used to hack this. Package developers would still have to actually write the warnings on the function code but this would allow to have the functions in a separate directory so they don't foget to remove them on the next release<br />
** the package developer can also use something like Make to create a ''normal'' package from something that actually had a more complex structure, inclusive deprecated directories<br />
* get pkg to resolve dependencies automatically by downloading and installing them too<br />
* allow to download and install multiple versions of the same package<br />
* make the package just a bit more verbose by default (specifics?)<br />
* make pkg a little more like apt-get (what specific features of apt-get is this referring to?)<br />
* make pkg support more than one src directory<br />
** subdirectories with makefiles and top level make command of: cd <subdir> && ${MAKE}... ok as a substitute?<br />
* make pkg able to supply extra configure and make flags, useful for distributions, including -j for make (pkg now passes --jobs=N automatically, CFLAGS and CXXFLAGS environment variables are already respected, what's missing?)<br />
<br />
=Preferences=<br />
<br />
Octave has several functions for managing user preferences. Many function use persistent variables instead of relying upon the preference features.<br />
* The function {{Codeline|edit ()}} contains a persistent structure used as its personal set of preferences. These can all be moved to the user preference group for the editor.<br />
** "EDITOR"<br />
** "HOME"<br />
** "AUTHOR"<br />
** "EMAIL"<br />
** "LICENSE"<br />
** "MODE"<br />
** "EDITINPLACE"<br />
* The {{Codeline|savepath ()}} function modifies the startup script (rcfile), {{Codeline|~/.octaverc}} and inserts commands to allow the next session to begin with the same path. Instead user preference can be created for startup items and a preference for the user specified path can be added. Perhaps two path preferences should be used. One for the elements that should precede the core path and those that should follow. A start up directory preference might also be added to allow the user to specify where Octave should begin the next session.<br />
** "PREPATH"<br />
** "POSTPATH"<br />
** "STARTUPDIR"<br />
* A preference group for plotting can also be added. A preference for the default terminal would be useful for those who want to override the default. Preferences for the default {{Codeline|graphicstoolkit}} can also be added.<br />
** GNUPLOTTERM<br />
** GRAPHICSTOOLKIT<br />
* A preference group for printing can include preferences for the default printer, the ghostscript command, and possibly other parameters like orientation, and resolution.<br />
** PRINTER<br />
** GHOSTSCRIPTCOMMAND<br />
** ORIENTATION<br />
** RESOLUTION<br />
* Searching the m-files for use of {{Codeline|persistent}} should turn up other opportunities to use preferences.<br />
<br />
=Bugs=<br />
<br />
There are always bugs to fix. The [https://savannah.gnu.org/bugs/?group=octave bug tracker] is a good place to find tasks needing a hand. See also [[Short projects#Bugs]].<br />
<br />
= Matlab compatibility =<br />
<br />
== Missing functions ==<br />
<br />
There are certain functions present in MATLAB known to be missing in Octave.<br />
<br />
One list is provided on the source for function __unimplemented.m__, subfunction missing_functions; it can be edited in the Octave GUI or browsed at [http://hg.savannah.gnu.org/hgweb/octave/file/default/scripts/help/__unimplemented__.m#l547].<br />
<br />
Lists are also kept for [[:Category:Missing functions|several packages]].<br />
<br />
It is also possible to look at existing [[Wikipedia:Free and open-source software|FOSS]] implementations, from FreeMat and Scilab (for more closely compatible languages) to R or Scipy or Julia (for less compatible versions). Obviously, it is NOT OK to look at the Matlab implementation since this is not [[Wikipedia:Free software|free software]]!<br />
<br />
== Functions under different name ==<br />
<br />
Many Octave Forge functions perform the same as functions from matlab packages. However, they often exist under a different name or have incompatible API's. Often fixing this is a matter of changing their names, swap the order of their input arguments. At least, a list of this functions would be helpful.<br />
<br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Project Ideas]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Projects&diff=13334Projects2020-09-16T01:29:59Z<p>Siko1056: /* Configuration and Installation */ Strip finished items.</p>
<hr />
<div>The list below summarizes features or bug fixes we would like to see in Octave. This list is not exclusive -- there are many other things that might be good projects, but it might instead be something we already have. Also, some of the following items may not actually be considered good ideas now.<br />
<br />
{{Note|If you never contributed to Octave before, we suggest to start with our [[Developer FAQ]].}}<br />
<br />
* Summer of Code students, please also see [[Summer of Code - Getting Started]].<br />
* If you're looking for small project, see [[short projects]].<br />
<br />
=Numerical=<br />
<br />
* Use C++11 <random> libraries for random number generation. Write link between Octave functions (rand, randi, randn, rande) and C++ API. Implement RandStream objects as Matlab does.<br />
<br />
*Improve logm, and sqrtm (see this thread: http://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html)<br />
<br />
*Use pairwise addition in sum() to mitigate against numerical errors without substantial performance penalty (https://en.wikipedia.org/wiki/Pairwise_summation).<br />
<br />
*Review implementing algorithm in this 2009 paper (https://epubs.siam.org/doi/pdf/10.1137/080738490) for xsum (sum with extra accuracy). The existing implementation uses a 2005 paper.<br />
<br />
*Improve complex mapper functions. See W. Kahan, ``Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit (in The State of the Art in Numerical Analysis, eds. Iserles and Powell, Clarendon Press, Oxford, 1987) for explicit trigonometric formulae. See {{patch|8172}} for a previous attempt.<br />
<br />
*Make functions like gamma() return the right IEEE Inf or NaN values for extreme args or other undefined cases.<br />
<br />
*Improve sqp.<br />
<br />
*Fix CollocWt? to handle Laguerre polynomials. Make it easy to extend it to other polynomial types.<br />
<br />
*Add optional arguments to colloc so that it's not restricted to Legendre polynomials.<br />
<br />
*Move rand, eye, xpow, xdiv, etc., functions to the matrix classes.<br />
<br />
*Improve design of ODE, DAE, classes.<br />
<br />
*Make QR more memory efficient for large matrices when not all the columns of Q are required (apparently this is not handled by the lapack code yet).<br />
<br />
*Evaluate harmonics and cross-correlations of unevenly sampled and nonstationary time series, as in http://www.jstatsoft.org/v11/i02 (which has C code with interface to R). (This is now partly implemented in the [http://octave.sourceforge.net/lssa/index.html lssa] package.)<br />
<br />
<!-- == General purpose Finite Element library ==<br />
<br />
Octave-Forge already has a set of packages for discretizing Partial Differential operators by Finite Elements and/or Finite Volumes,<br />
namely the [[bim package]] which relies on the [http://octave.sf.net/msh msh package] (which is in turn based on [http://geuz.org/gmsh/ gmsh]) for creating and managing 2D triangular and 3D tetrahedral meshes and on the [http://octave.sf.net/fpl fpl package] for visualizing 2D results within Octave or exporting 2D or 3D results in a format compatible with [http://www.paraview.org Paraview] or [https://wci.llnl.gov/codes/visit/ VisIT]. These packages, though, offer only a limited choice of spatial discretization methods which are based on low degree polynomials and therefore have a low order of accuracy even for problems with extremely smooth solutions.<br />
The [http://geopdes.sf.net GeoPDEs] project, on the other hand, offers a complete suite of functions for discretizing a wide range of<br />
differential operators related to important physical problems and uses basis functions of arbitrary polynomial degree that allow the construction of methods of high accuracy. These latter, though, are based on the IsoGeometric Analysis Method which, although very powerful and often better performing, is less widely known and adopted than the Finite Elements Method. The implementation of a general purpose library of Finite Elements seems therefore a valuable addition to Octave-Forge. Two possible interesting choices for implementing this package exist, the first consists of implementing the most common Finite Element spaces in the [http://geopdes.sf.net GeoPDEs] framework, which is possible as IsoGeometric Analysis can be viewed as a superset of the Finite Element Method, the other is to construct Octave language bindings for the free software library [http://fenicsproject.org/documentation/ FEniCS] based on the existing C++ or Python interfaces. This second approach has been developed during the GSOC 2013 and the Octave-Forge package [http://octave.sf.net/fem-fenics fem-fenics] is now available. However, fem-fenics could be extended in many different ways:<br />
* implement the bindings for the UFL language inside Octave<br />
* add new functions already available with Fenics but not yet in Octave<br />
* create new functions specifically suited for Octave<br />
* improve the efficiency of the code<br />
The main goal for the fem-fenics package is ultimately to be merged with the FEnics project itself, so that it can remain in-sync with the main library development. --><br />
<br />
== Implement solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D ==<br />
<br />
The project will deliver a solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D similar to Matlab's function <tt>pdepe</tt>. A good starting point is the [http://en.wikipedia.org/wiki/Method_of_lines method of lines] for which you can find more details [http://en.wikibooks.org/wiki/Partial_Differential_Equations/Method_of_Lines here] and [http://www.scholarpedia.org/article/Method_of_lines here], whereas an example implementation can be found [http://www.scholarpedia.org/article/Method_of_Lines/Example_Implementation here]. In addition, [http://www.pdecomp.net/ this page] provides some useful material.<br />
<br />
== Implement solver for 1D nonlinear boundary value problems ==<br />
<br />
The project will complete the implementation of the bvp4c solver that is already available in an initial version in the odepkg package<br />
by adding a proper error estimator and will implement a matlab-compatible version of the bvp5c solver.<br />
Details on the methods to be implemented can be found in [http://dx.doi.org/10.1145/502800.502801 this paper] on bvp4c and [http://www.jnaiam.net/new/uploads/files/014dde86eef73328e7ab674d1a32aa9c.pdf this paper] on bvp5c. Further details are available in [http://books.google.it/books/about/Nonlinear_two_point_boundary_value_probl.html?id=s_pQAAAAMAAJ&redir_esc=y this book].<br />
<br />
<!-- == Geometric integrators for Hamiltonian Systems ==<br />
<br />
[http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration Geometric (AKA Symplectic) integrators] are useful for <br />
multi-dimensional classical mechanics problems and for molecular dynamics simulations.<br />
The odepkg package has a number of solvers for ODE, DAE and DDE problems but none of them is currently<br />
specifically suited for second order problems in general and Hamiltonian systems in particular.<br />
Therefore a new package for geometric integrators would be a useful contribution.<br />
This could be created as new package or added as a set of new functions for odepkg.<br />
The function interface should be consistent throughout the package and should be modeled to follow <br />
that of other functions in odepkg (or that of DASPK and LSODE) but will need specific extensions to accommodate for specific options that only make sense for this specific class of solvers.<br />
An initial list of methods to be implemented includes (but is not limited to)<br />
* Symplectic Euler methods, see [http://en.wikipedia.org/wiki/Semi-implicit_Euler_method here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Störmer-Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Velocity Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Symplectic partitioned Runge-Kutta methods, see [http://reference.wolfram.com/mathematica/tutorial/NDSolveSPRK.html here] or [http://dx.doi.org/10.1137/0733019 here]<br />
* Spectral Variational Integrator methods, see [http://www3.nd.edu/~izaguirr/papers/acta_numerica.pdf here] or [http://www.math.ucsd.edu/~mleok/pdf/HaLe2012_SVI.pdf here]<br />
<br />
For this latter there is an existing code which is already working but needs to be improved, posted on the patch tracker.<br />
Furthermore, methods to implement solutions of problems with rigid constraints should be implemented, e.g.<br />
* SHAKE, see [http://en.wikipedia.org/wiki/Constraint_algorithm here] or [http://dx.doi.org/10.1016/0021-9991(77)90098-5 here]<br />
* RATTLE, see [http://dx.doi.org/10.1016/0021-9991(83)90014-1 here] or [http://dx.doi.org/10.1002/jcc.540161003 here]<br />
--><br />
<br />
== Matlab-compatible ODE solvers in core-Octave ==<br />
<br />
* Improve handling of sparse Jacobians in IDE/DAE solvers<br />
** Currently, in the IDA wrapper function __ode15__ an over conservative guess for the amount of memory to be allocated when assembling a sparse jacobian is used, essentially allocating enough space for a full jacobian then freeing the excess memory, an initial patch for fixing this has been posted on the tracker, for integrating this into Octave it must be generalized to support prior versions of SUNDIALS<br />
** Currently Jacobians passed by the user in Octave's sparse matrix format are copied into SUNDIALS own sparse matrix format. Newer versions of SUNDIALS (5.x or higher) support letting the user take care of the linear algebra data structures and methods thus removing the need for the copy. Taking advantage of this feature would improve the solver performance both in terms of memory footprint and speed.<br />
** References<br />
***[https://savannah.gnu.org/bugs/?func=detailitem&item_id=55905 tracker post about memory allocation] <br />
***[https://computing.llnl.gov/projects/sundials/release-history SUNDIALS release history]<br />
* Implement Matlab compatible versions of "deval".<br />
* Complete transition of ode23s into core Octave<br />
** [https://savannah.gnu.org/bugs/?57309 Bug tracker entry discussing ode23s]<br />
<br />
== High Precision Arithmetic Computation ==<br />
<br />
The Linear Algebra Fortran libraries used by Octave make use of of single (32 bits) and double (64 bits) precision floating point numbers. Many operations are stopped when matrices condition number goes below 1e-16: such matrices are considered as ill-conditioned. There are cases where this is not enough, for instance simulations implying chemical concentrations covering the range 10^4 up to 10^34. There are a number of ways to increase the numerical resolution, like f.i. make use of 128 bits quadruple precision numbers available in GFortran. A simpler option is to build an interface over Gnu MPL arbitrary precision library, which is used internally by gcc and should be available on any platform where gcc runs. Such approach has been made available for MatLab under the name mptoolbox and is licensed under a BSD license. The author kindly provided a copy of the latest version and agreed to have it ported under Octave and re-distributed under GPL v3.0<br />
<br />
The architecture consists of an Octave class interface implementing "mp" (multi-precision) objects. Arithmetic operations are forwarded to MPL using MEX files. This is totally transparent to the end user, except when displaying numbers. This implementation needs to be ported and tested under Octave.<br />
<br />
=GUI/IDE=<br />
<br />
*Søren Hauberg has suggested that we need C++ code that can:<br />
**Determine if a line of code could be fully parsed, i.e. it would return true for "plot (x, y);", but false for "while (true)".<br />
**Evaluate a line of code and return the output as a string (it would be best if it could provide three strings: output, warnings and errors).<br />
**Query defined variables, i.e. get a list of currently defined variables. Bonus points if it could tell you if anything had changed since the last time you checked the variables (could also be done with signals).<br />
* Create a better (G)UI for the {{manual|profile|profiler}}. This may be done with Qt, but not necessarily.<br />
<br />
== GUI Variable Editor and Property Inspector ==<br />
<br />
Octave has a preliminary implementation of a Variable Editor: a spreadsheet-like tool for quickly editing and visualizing variables. The initial phase of the project will be learning how the implementation was done.<br />
<br />
With the knowledge gained, the second part of the project will be to implement a Property Inspector. This is a spreadsheet like interface to the many, many graphics properties that exist and are different on a per-object basis. The goal would be not only the concise-display of the existing properties, but a reasonable user interface to change them. As examples, Boolean properties should be able to be toggled with a double-click; Radio properties should have a drop-down list of only the supported options; Other properties that can be modified should have the constraints built-in (for example, Linewidth must be a scalar, while Position must be a 1x4 vector). It would also be important to have easy access to the documentation of a property.<br />
<br />
For reference, Matlab has a similar Property Inspector (https://www.mathworks.com/help/matlab/ref/inspect.html).<br />
<br />
== Sisotool. Create a graphical design tool for tuning closed loop control system ([[Control package]])==<br />
<br />
When tuning a SISO feedback system it is very helpful to be able to grab a pole or a zero and move them by dragging them with the mouse. As they are moving the software must update all the plotted lines. There should be the ability to display various graphs rlocuse, bode, step, impulse etc. and have them all change dynamically as the mouse is moving. The parameters of the compensator must be displayed and updated.<br />
Recently, some implementation was done during [[Summer_of_Code#GSoC_2018|GSoC 2018]], see https://eriveltongualter.github.io/GSoC2018/final.html for details.<br />
<br />
=Sparse Matrices=<br />
<br />
The paper by [http://arxiv.org/abs/cs.MS/0604006 Bateman & Adler] is good reading for understanding the sparse matrix implementation.<br />
<br />
*Improve Matlab compatibility for {{manual|sprandsym}}.<br />
<br />
*Sparse logical indexing in idx_vector class so that something like <code>a = sprandn (1e6, 1e6, 1e-6); a(a<1) = 0;</code> won't cause a memory overflow.<br />
<br />
*Other missing Functions<br />
**lsqr<br />
**minres<br />
**symmlq<br />
<br />
== SPQR Interface ==<br />
<br />
Octave implements QR factorization for sparse matrices, but it does so with an older "CXSPARSE" library. This has caused fundamental issues, including segfaults as recorded here (bugs {{bug|51950}} and {{bug|57033}}). The goal of this project is to program an interface to the API for the SQPR library (http://faculty.cse.tamu.edu/davis/suitesparse.html). This is the same library that Matlab uses for this purpose.<br />
<br />
*Improve QR factorization functions, using idea based on CSPARSE cs_dmsol.m<br />
<br />
*Improve QR factorization by replacing CXSPARSE code with SPQR code, and make the linear solve return 2-norm solutions for ill-conditioned matrices based on this new code<br />
<br />
=Strings=<br />
<br />
*Consider making octave_print_internal() print some sort of text representation for unprintable characters instead of sending them directly to the terminal. (But don't do this for fprintf!)<br />
<br />
*Consider changing the default value of `string_fill_char' from SPC to NUL.<br />
<br />
=Other Data Types=<br />
<br />
*Template functions for mixed-type ops.<br />
<br />
*Convert other functions for use with the floating point type including quad, dasrt, daspk, etc.<br />
<br />
=Input/Output=<br />
<br />
*Make fread and fwrite work for complex data. Iostreams based versions of these functions would also be nice, and if you are working on them, it would be good to support other size specifications (integer*2, etc.).<br />
<br />
*Move some pr-output stuff to liboctave.<br />
<br />
*Make the cutoff point for changing to packed storage a user-preference variable with default value 8192.<br />
<br />
*Complain if there is not enough disk space available (I think there is simply not enough error checking in the code that handles writing data).<br />
<br />
*Make it possible to tie arbitrary input and output streams together, similar to the way iostreams can be tied together.<br />
<br />
*Expand {{codeline|imwrite}} options. This shouldn't be too hard to implement, since it's wrapped around GraphicsMagick.<br />
<br />
*Extend Octave functions to work on stored arrays that are too big to fit in RAM, similar to available R [http://www.bigmemory.org/ packages.]<br />
<br />
* write {{codeline|xmlread}} and {{codeline|xmlwrite}}. This could be done using [http://xerces.apache.org/xerces-c/ Xerces C++ interface] which apparently is what [http://octave.1599824.n4.nabble.com/xml-in-octave-td4663034.html Matlab uses].<br />
<br />
* Implement hdf5 for .mat files (see [http://octave.1599824.n4.nabble.com/Reading-Matlab-td4650158.html this thread]).<br />
<br />
=Interpreter=<br />
<br />
The interpreter is written in C++, undocumented. There are many possible projects associated with it.<br />
<br />
'''Required skills''': ''Very good'' C and C++ knowledge, possibly also understanding of [http://en.wikipedia.org/wiki/Gnu_bison GNU bison] and [http://en.wikipedia.org/wiki/Flex_lexical_analyser flex]. Understanding how compilers and interpreters are made plus being able to understand how to use a profiler and a debugger will probably be essential skills.<br />
<br />
*Allow customization of the debug prompt.<br />
<br />
*Fix the parser so that<br />
<br />
if (expr) 'this is a string' end<br />
<br />
is parsed as IF expr STRING END. ''(see [https://lists.gnu.org/archive/html/octave-maintainers/2014-03/msg00087.html this] post on the mailing list)''<br />
<br />
*Clean up functions in input.cc that handle user input (there currently seems to be some unnecessary duplication of code and it seems overly complex).<br />
<br />
*Consider allowing an arbitrary property list to be attached to any variable. This could be a more general way to handle the help string that can currently be added with `document'.<br />
<br />
*Allow more command line options to be accessible as built-in variables (--echo-commands, etc.).<br />
<br />
*Make the interpreter run faster.<br />
<br />
*Allow arbitrary lower bounds for array indexing.<br />
<br />
*Improve performance of recursive function calls.<br />
<br />
*Improve the way ignore_function_time_stamp works to allow selecting by individual directories or functions.<br />
<br />
*Add a command-line option to tell Octave to just do syntax checking and not execute statements.<br />
<br />
*Clean up symtab and variable stuff.<br />
<br />
*Input stream class for parser files -- must manage buffers for flex and context for global variable settings.<br />
<br />
*make parser do more semantic checking, continue after errors when compiling functions, etc.<br />
<br />
*Make LEXICAL_ERROR have a value that is the error message for parse_error() to print?<br />
<br />
*Add a run-time alias mechanism that would allow things like alias fun function_with_a_very_long_name so that `function_with_a_very_long_name' could be invoked as `fun'.<br />
<br />
*Allow local changes to variables to be written more compactly than is currently possible with unwind_protect. For example, <br />
<br />
function f ()<br />
local prefer_column_vectors = something;<br />
...<br />
endfunction<br />
<br />
<br />
would be equivalent to<br />
<br />
function f ()<br />
save_prefer_column_vectors = prefer_column_vectors;<br />
unwind_protect<br />
prefer_column_vectors = something;<br />
...<br />
unwind_protect_cleanup<br />
prefer_column_vectors = save_prefer_column_vectors;<br />
end_unwind_protect<br />
endfunction<br />
<br />
<br />
*Fix all function files to check for bogus inputs (wrong number or types of input arguments, wrong number of output arguments).<br />
<br />
*Handle options for built-in functions more consistently.<br />
<br />
*Too much time is spent allocating and freeing memory. What can be done to improve performance?<br />
<br />
Use move constructors rather than copy constructors for things like dim_vectors which are repeatedly created just to initialize Array or Matrix objects.<br />
<br />
*Error output from Fortran code is ugly. Something should be done to make it look better.<br />
<br />
*It would be nice if output from the Fortran routines could be passed through the pager.<br />
<br />
*Attempt to recognize common subexpressions in the parser.<br />
<br />
*Consider making it possible to specify an empty matrix with a syntax like [](e1, e2). Of course at least one of the expressions must be zero...<br />
<br />
*Is Matrix::fortran_vec() really necessary?<br />
<br />
*Rewrite whos and the symbol_record_info class. Write a built-in function that gives all the basic information, then write who and whos as M-files.<br />
<br />
*On systems that support matherr(), make it possible for users to enable the printing of warning messages.<br />
<br />
*Make it possible to mark variables and functions as read-only.<br />
<br />
*Make it possible to write a function that gets a reference to a matrix in memory and change one or more elements without generating a second copy of the data.<br />
<br />
*Use nanosleep instead of usleep if it is available? Apparently nanosleep is to be preferred over usleep on Solaris systems.<br />
<br />
== Improve JIT compiling ==<br />
<br />
Octave's interpreter is ''very'' slow on some loops. Recently, thanks to Max Brister's work, an initial implementation of a just-in-time compiler (JITC) in [http://llvm.org LLVM] for GSoC 2012. This project consists in understanding Max's current implementation and extending it so that functions and exponents (e.g. 2^z) compile with the JITC. This requires knowledge of compilers, C++, LLVM, and the Octave or Matlab languages. A capable student who demonstrates the ability to acquire this knowledge quickly may also be considered. Max himself will mentor this project. [http://planet.octave.org/octconf2012/jit.pdf Here] is Max's OctConf 2012 presentation about his current implementation. See also [[JIT]].<br />
<br />
== Improve memory management ==<br />
<br />
From profiling the interpreter, it appears that a lot of time is spending allocating and deallocating memory. A better memory management algorithm might provide some improvement.<br />
<br />
== Implement classdef classes ==<br />
<br />
Matlab has two kinds of classes: old style @classes and new style classdef. Octave has only fully implemented the old style. There is partial support for classdef classes in version 4.0, refer to the [[Classdef|classdef status page]] for what is not yet implemented. There is irregular work here, and classdef is [http://www.mathworks.com/help/matlab/matlab_oop/method-attributes.html a very] [http://www.mathworks.com/help/matlab/events-sending-and-responding-to-messages.html complicated] [http://www.mathworks.com/help/matlab/enumeration-classes.html thing] to fully implement. A successful project would be to implement enough of classdef for most basic usages. Familiarity with Matlab's current classdef support would be a huge plus. Michael Goffioul and jwe can mentor this.<br />
<br />
Although there's already a substantial classdef support in current octave code base, there are still many areas that are unimplemented or need improvements. The main ones that come to my mind are:<br />
* support for events<br />
* support for enums<br />
* support for "import" (this requires good understanding of octave internals, especially the symbol table)<br />
* improving multiple inheritance and method resolution<br />
* honoring and computing "Sealed" attribute<br />
* support for function handle to methods<br />
<br />
== Improve MPI package ==<br />
<br />
Octave Forge's [http://octave.sourceforge.net/mpi/index.html MPI package] <br />
is a wrapper for basic MPI functions for parallel computing. It is implemented <br />
by wrapping MPI function calls in simple DLD functions that map Octave's Datataypes to <br />
MPI Derived Datatypes. <br />
The proposed project deals with improving and extending the Octave MPI package, for example:<br />
* Octave MPI applications can currently be only run in batch mode, add the ability to launch parallel jobs and collect their output in an interactive Octave session.<br />
* Implement functions for non-blocking communication (MPI_Isend, MPI_Irecv)<br />
* Implement one-to-many (Broadcast, Scatter), many-to-one (Reduce, Gather), and many-to-many (All Reduce, Allgather) communication routines<br />
<br />
= Graphics =<br />
<br />
* Correctly handle case where DISPLAY is unset. Provide --no-window-system or --nodisplay (?) option. Provide --display=DISPLAY option? How will this work with gnuplot (i.e., how do we know whether gnuplot requires an X display to display graphics)?<br />
<br />
* Implement a Cairo-based renderer for 2D-only graphics, with support for PS/PDF/SVG output (for printing).<br />
<br />
* On 'imagesc' plots, report the matrix values also based on the mouse position, updating on mouse moving.<br />
<br />
* Add map-creating capabilities similar to the Matlab [https://www.mathworks.com/help/map/functionlist.html Mapping toolbox] for inclusion in the Octave Forge [https://sourceforge.net/p/octave/mapping mapping package].<br />
<br />
* Add data cursor to trace data values in figure.<br />
<br />
== Non-OpenGL renderer ==<br />
<br />
Besides the original gnuplot backend, Octave also contains an OpenGL-based renderer for advanced and more powerful 3D plots. However, OpenGL is not perfectly suited for 2D-only plots where other methods could result in better graphics. The purpose of this project is to implement an alternate graphics renderer for 2D only plots (although 3D is definitely not the focus, extending the new graphics renderer to support basic 3D features should also be taken into account). There is no particular toolkit/library that must be used, but natural candidates are:<br />
* [http://qt.nokia.com Qt]: the GUI is currently written in Qt <strike>and work is also in progress to provide a Qt/OpenGL based backend [https://github.com/goffioul/QtHandles]</strike><br />
* [http://en.wikipedia.org/wiki/Cairo_%28software%29 Cairo]: this library is widely used and known to provides high-quality graphics with support for PS/PDF/SVG output.<br />
<br />
== LaTeX markup ==<br />
<br />
Text objects in plots (like titles, labels, texts...) in the OpenGL renderer only support plain text and TeX. The latter consists of a very limited subset of the TeX language. On the other hand, the LaTeX formatting support is expected to provide full LaTeX capabilities. There are various approaches that can be used:<br />
* Use an external LaTeX engine: this is the most straightforward, but it requires users to install a LaTeX distribution and setup Octave to use it.<br />
* Use an external library that supports LaTeX syntax, e.g. [https://github.com/opencollab/jlatexmath JLaTeXMath] a Java API to display LaTeX code, [https://github.com/nathancarter/qtmathjax qtmathjax] a Qt based library that executes MathJax in a background web page.<br />
* Implement our own LaTeX parser and renderer. The matplotlib project [http://matplotlib.sourceforge.net/users/usetex.html has already done this in Python] and might be used as an example of how to do this in Octave. There is also [https://github.com/jkriege2/JKQtPlotter JKQtPlotter], a Qt based plotting application which implements its own LaTeX parser/renderer in C++.<br />
<br />
=History=<br />
<br />
*Add an option to allow saving input from script files in the history list.<br />
<br />
*The history command should accept two numeric arguments to indicate a range of history entries to display, save or read.<br />
<br />
*Avoid writing the history file if the history list has not changed.<br />
<br />
*Avoid permission errors if the history file cannot be opened for writing.<br />
<br />
*Fix history problems — core dump if multiple processes are writing to the same history file?<br />
<br />
= Configuration and Installation =<br />
<br />
* Makefile changes:<br />
** eliminate for loops<br />
** define shell commands or eliminate them<br />
** consolidate targets<br />
<br />
* Create a docs-only distribution?<br />
<br />
=Documentation=<br />
:''See [[Project - Documentation]].''<br />
<br />
=Tests=<br />
*Improved set of tests: [http://octave.1599824.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=370633]<br />
**Tests for various functions. Would be nice to have a test file corresponding to every function (see below)<br />
**Tests for element by element operators: + - .* ./ .\ .^ | & < <= == >= > != !<br />
*** thorough tests for power operator including corner cases and strange combinations such as complex .^ range.<br />
**Tests for boolean operators: && ||<br />
**Tests for other operators: * / \ ' .'<br />
**Tests from bug reports.<br />
**Tests for indexed assignment. Need to consider the following:<br />
***fortran-style indexing<br />
***zero-one indexing<br />
***assignment of empty matrix as well as values resizing<br />
**Tests for all internal functions.<br />
<br />
* Implement a coverage tool for collecting coverage data and generating code coverage reports on m-file functions and scripts. This would be very useful for Octave development as well as for users who want a code coverage report for their own functions and scripts.<br />
<br />
We are far from even having one test for every function, so focus should be on getting the breadth of coverage first before trying to get the depth of 100% statement coverage. As of Dec 2015, 202 of 1020 m-files have no tests. Some of these will be plotting functions which have demos instead, but that leaves enough functions to be an interesting project. As of Dec 2015, there are 485 instances of C++ functions which need tests.<br />
<br />
After Octave is compiled, running the {{Codeline|make check}} build target will run the full test suite and generate a file called test/fntests.log in the build directory with a summary of the results. At the end of the file is a list of all functions for which no tests were found. An extract is posted in the [[files missing tests]] page. If you are not building Octave yourself, the test suite can be run on an installed binary copy by executing the {{Codeline|__run_test_suite__}} command at the Octave prompt. The fntests.log file will be written in the current directory in this case.<br />
<br />
There also need to be tests for functions written in the C++ files. See [[Add_BIST_tests_for_octave_functions_written_in_C%2B%2B]] for instructions and a list of instances.<br />
<br />
See also [[Continuous Build#Coverage Report]].<br />
<br />
=Programming=<br />
<br />
*Better error messages for missing operators?<br />
<br />
*Eliminate duplicate enums in pt-exp.cc, pt-const.cc, and ov.cc.<br />
<br />
*Handle octave_print_internal() stuff at the liboctave level. Then the octave_value classes could just call on the print() methods for the underlying classes.<br />
<br />
*As much as possible, eliminate explicit checks for the types of octave_value objects so that user-defined types will automatically do the right thing in more cases.<br />
<br />
*Only include config.h in files that actually need it, instead of including it in every .cc file. Unfortunately, this might not be so easy to figure out.<br />
<br />
*GNU coding standards:<br />
**Add a `Makefile' target to the Makefiles.<br />
**Comments on #else and #endif preprocessor commands.<br />
**Change error message format to match standards everywhere.<br />
<br />
*Eliminate more global variables.<br />
<br />
*Move procstream to liboctave.<br />
<br />
*Use references and classes in more places.<br />
<br />
*Share more code among the various _options functions.<br />
<br />
*Use non-empty identifiers in all warnings and errors issued by Octave, see [[Easy projects#Miscellaneous]].<br />
<br />
*Reduce the amount of datatypes in liboctave.<br />
<br />
*Re-implement operators using templates and modern C++. Current system evolved before templates and makes extensive use of macros to define interactions between scalar<->scalar, scalar<->matrix, scalar<->float, etc., etc.<br />
**In liboctave, the directory to work on is liboctave/operators<br />
**In libinterp, the directory to work on is libinterp/operators<br />
**In libinterp, there is also xpow.cc, xdiv.cc in libinterp/corefcn<br />
<br />
=Miscellaneous=<br />
<br />
*Implement some functions for interprocess communication: bind, accept, connect, gethostbyname, etc. (This functionality is already available in the octave sockets package, what is the purpose of moving it to core octave?)<br />
<br />
*The ability to transparently handle very large files: Juhana K Kouhia <kouhia@nic.funet.fi> wrote:<br />
*: If I have a one-dimensional signal data with the size 400 Mbytes, then what are my choices to operate with it:<br />
*:*I have to split the data<br />
*:*Octave has a virtual memory on its own and I don't have to worry about the splitting.<br />
*:If I split the data, then my easily programmed processing programs will become hard to program.<br />
*:If possible, I would like to have the virtual memory system in Octave i.e., the all big files, the user see as one big array or such. There could be several user selectable models to do the virtual memory depending on what kind of data the user have (1d, 2d) and in what order they are processed (stream or random access).<br />
<br />
*An interface to gdb. Michael Smolsky <fnsiguc@weizmann.weizmann.ac.il> wrote:<br />
*:I was thinking about a tool, which could be very useful for me in my numerical simulation work. It is an interconnection between gdb and octave. We are often managing very large arrays of data in our fortran or c codes, which might be studied with the help of octave at the algorithm development stages. Assume you're coding, say, wave equation. And want to debug the code. It would be great to pick some array from the memory of the code you're developing, fft it and see the image as a log-log plot of the spectral density. I'm facing similar problems now. To avoid high c-development cost, I develop in matlab/octave, and then rewrite into c. It might be so much easier, if I could off-load a c array right from the debugger into octave, study it, and, perhaps, change some [many] values with a convenient matlab/octave syntax, similar to <code>a(:,51:250)=zeros(100,200)</code>, and then store it back into the memory of my c code.<br />
<br />
*Implement gdb extensions for Octave types. Octave has the <code>etc/gdbinit</code> file, which has some basic support for displaying the contents of Octave types. Add more extensions to make it easier to debug octave_values and other Octave types.<br />
<br />
*Add a definition to lgrind so that it supports Octave. (See http://www.tex.ac.uk/tex-archive/support/lgrind/ for more information about lgrind.)<br />
<br />
*Spatial statistics, including covariogram estimation and kriging -- perhaps via an interface to [http://www.gstat.org/ gstat]?<br />
<br />
* the [http://octave.sourceforge.net/miscellaneous/function/units.html units] function from the miscellaneous package works by parsing the output of from a call to GNU units. This can be made much more robust by writing it in C++ and including its library "units.h"<br />
<br />
=Marketing and Community=<br />
<br />
* Make the Octave website/[[Project Infrastructure]] easier to maintain.<br />
<br />
* Make it easier for newcomers to contribute.<br />
<br />
* For marketing ideas, see the [https://openoffice.apache.org/orientation/intro-marketing.html Apache Open Office Introduction to Marketing]<br />
<br />
* Help design a user or a [https://www.openoffice.org/marketing/ooocon2006/presentations/wednesday_c10.pdf developer survey]<br />
<br />
* Help prepare and deliver presentations and [[Publications about Octave]] at colleges and universities.<br />
<br />
* Create a [[Forum for GNU Octave]].<br />
<br />
== Improve Windows binary packaging ==<br />
<br />
We are currently able to build and provide a [[Windows Installer|installer for Windows]]. The build process involves cross-compiling on a Linux system using a fork of the [http://mxe.cc/ MXE] project to build Octave and all of its dependencies. Any ideas for improving this process to make it easier or faster, or to improve the installer itself or the installation experience for Windows users would be appreciated.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
== Improve macOS binary packaging ==<br />
<br />
We would like to be able to easily generate binary packages for macOS. Right now, it's difficult and tedious to do so. Most OS X users install Octave using one of the source-based package managers such as Homebrew or MacPorts. Any way to help us build a binary package would be appreciated. Required knowledge is understanding how building binaries in macOS works. Our current approach to building binaries for Windows is to cross-compile from a GNU system using [http://mxe.cc/ MXE], something similar may be possible for OS X ([http://lilypond.org/gub/ GUB]?).<br />
<br />
There is a third-party project called [http://octave-app.org "Octave.app"] that creates and distributes macOS builds of Octave as a Mac app bundle. It is built on top of Homebrew and a set of custom Octave-related Homebrew formuale.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. If you choose to work on GUB, Python will be required. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
=Performance=<br />
<br />
* A profiler for Octave would be a very useful tool. And now we have one! But it really needs a better interface.<br />
* Having {{Codeline|parfor}} functioning would speed code development and execution now that multicore architectures are widespread. See [http://octave.1599824.n4.nabble.com/Parfor-td4630575.html here] and [http://stackoverflow.com/questions/24970519/how-to-use-parallel-for-loop-in-octave-or-scilab here]. Existing code from the [[Parallel package | parallel]] and [http://octave.sourceforge.net/mpi/index.html mpi] packages could perhaps be adapted for this.<br />
* Develop a performance benchmark for Octave (interpreter, load/save, plotting, etc., but not simply tests of underlying libraries such as BLAS or LAPACK). This benchmark could be run periodically to make sure that changes during development do not introduce regressions in performance.<br />
<br />
=Packaging=<br />
<br />
* create a system that allows packages to deprecate functions as in core. Possibilities are:<br />
** get pkg to accept a deprecated directory inside the package and add it to the search path. Functions in those directories would have to be treated the same as the ones inside the core deprecated<br />
** PKG_ADD can be used to hack this. Package developers would still have to actually write the warnings on the function code but this would allow to have the functions in a separate directory so they don't foget to remove them on the next release<br />
** the package developer can also use something like Make to create a ''normal'' package from something that actually had a more complex structure, inclusive deprecated directories<br />
* get pkg to resolve dependencies automatically by downloading and installing them too<br />
* allow to download and install multiple versions of the same package<br />
* make the package just a bit more verbose by default (specifics?)<br />
* make pkg a little more like apt-get (what specific features of apt-get is this referring to?)<br />
* make pkg support more than one src directory<br />
** subdirectories with makefiles and top level make command of: cd <subdir> && ${MAKE}... ok as a substitute?<br />
* make pkg able to supply extra configure and make flags, useful for distributions, including -j for make (pkg now passes --jobs=N automatically, CFLAGS and CXXFLAGS environment variables are already respected, what's missing?)<br />
<br />
=Preferences=<br />
<br />
Octave has several functions for managing user preferences. Many function use persistent variables instead of relying upon the preference features.<br />
* The function {{Codeline|edit ()}} contains a persistent structure used as its personal set of preferences. These can all be moved to the user preference group for the editor.<br />
** "EDITOR"<br />
** "HOME"<br />
** "AUTHOR"<br />
** "EMAIL"<br />
** "LICENSE"<br />
** "MODE"<br />
** "EDITINPLACE"<br />
* The {{Codeline|savepath ()}} function modifies the startup script (rcfile), {{Codeline|~/.octaverc}} and inserts commands to allow the next session to begin with the same path. Instead user preference can be created for startup items and a preference for the user specified path can be added. Perhaps two path preferences should be used. One for the elements that should precede the core path and those that should follow. A start up directory preference might also be added to allow the user to specify where Octave should begin the next session.<br />
** "PREPATH"<br />
** "POSTPATH"<br />
** "STARTUPDIR"<br />
* A preference group for plotting can also be added. A preference for the default terminal would be useful for those who want to override the default. Preferences for the default {{Codeline|graphicstoolkit}} can also be added.<br />
** GNUPLOTTERM<br />
** GRAPHICSTOOLKIT<br />
* A preference group for printing can include preferences for the default printer, the ghostscript command, and possibly other parameters like orientation, and resolution.<br />
** PRINTER<br />
** GHOSTSCRIPTCOMMAND<br />
** ORIENTATION<br />
** RESOLUTION<br />
* Searching the m-files for use of {{Codeline|persistent}} should turn up other opportunities to use preferences.<br />
<br />
=Bugs=<br />
<br />
There are always bugs to fix. The [https://savannah.gnu.org/bugs/?group=octave bug tracker] is a good place to find tasks needing a hand. See also [[Short projects#Bugs]].<br />
<br />
= Matlab compatibility =<br />
<br />
== Missing functions ==<br />
<br />
There are certain functions present in MATLAB known to be missing in Octave.<br />
<br />
One list is provided on the source for function __unimplemented.m__, subfunction missing_functions; it can be edited in the Octave GUI or browsed at [http://hg.savannah.gnu.org/hgweb/octave/file/default/scripts/help/__unimplemented__.m#l547].<br />
<br />
Lists are also kept for [[:Category:Missing functions|several packages]].<br />
<br />
It is also possible to look at existing [[Wikipedia:Free and open-source software|FOSS]] implementations, from FreeMat and Scilab (for more closely compatible languages) to R or Scipy or Julia (for less compatible versions). Obviously, it is NOT OK to look at the Matlab implementation since this is not [[Wikipedia:Free software|free software]]!<br />
<br />
== Functions under different name ==<br />
<br />
Many Octave Forge functions perform the same as functions from matlab packages. However, they often exist under a different name or have incompatible API's. Often fixing this is a matter of changing their names, swap the order of their input arguments. At least, a list of this functions would be helpful.<br />
<br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Project Ideas]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Projects&diff=13333Projects2020-09-16T01:29:03Z<p>Siko1056: /* Graphics */ Strip finished items, update links.</p>
<hr />
<div>The list below summarizes features or bug fixes we would like to see in Octave. This list is not exclusive -- there are many other things that might be good projects, but it might instead be something we already have. Also, some of the following items may not actually be considered good ideas now.<br />
<br />
{{Note|If you never contributed to Octave before, we suggest to start with our [[Developer FAQ]].}}<br />
<br />
* Summer of Code students, please also see [[Summer of Code - Getting Started]].<br />
* If you're looking for small project, see [[short projects]].<br />
<br />
=Numerical=<br />
<br />
* Use C++11 <random> libraries for random number generation. Write link between Octave functions (rand, randi, randn, rande) and C++ API. Implement RandStream objects as Matlab does.<br />
<br />
*Improve logm, and sqrtm (see this thread: http://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html)<br />
<br />
*Use pairwise addition in sum() to mitigate against numerical errors without substantial performance penalty (https://en.wikipedia.org/wiki/Pairwise_summation).<br />
<br />
*Review implementing algorithm in this 2009 paper (https://epubs.siam.org/doi/pdf/10.1137/080738490) for xsum (sum with extra accuracy). The existing implementation uses a 2005 paper.<br />
<br />
*Improve complex mapper functions. See W. Kahan, ``Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit (in The State of the Art in Numerical Analysis, eds. Iserles and Powell, Clarendon Press, Oxford, 1987) for explicit trigonometric formulae. See {{patch|8172}} for a previous attempt.<br />
<br />
*Make functions like gamma() return the right IEEE Inf or NaN values for extreme args or other undefined cases.<br />
<br />
*Improve sqp.<br />
<br />
*Fix CollocWt? to handle Laguerre polynomials. Make it easy to extend it to other polynomial types.<br />
<br />
*Add optional arguments to colloc so that it's not restricted to Legendre polynomials.<br />
<br />
*Move rand, eye, xpow, xdiv, etc., functions to the matrix classes.<br />
<br />
*Improve design of ODE, DAE, classes.<br />
<br />
*Make QR more memory efficient for large matrices when not all the columns of Q are required (apparently this is not handled by the lapack code yet).<br />
<br />
*Evaluate harmonics and cross-correlations of unevenly sampled and nonstationary time series, as in http://www.jstatsoft.org/v11/i02 (which has C code with interface to R). (This is now partly implemented in the [http://octave.sourceforge.net/lssa/index.html lssa] package.)<br />
<br />
<!-- == General purpose Finite Element library ==<br />
<br />
Octave-Forge already has a set of packages for discretizing Partial Differential operators by Finite Elements and/or Finite Volumes,<br />
namely the [[bim package]] which relies on the [http://octave.sf.net/msh msh package] (which is in turn based on [http://geuz.org/gmsh/ gmsh]) for creating and managing 2D triangular and 3D tetrahedral meshes and on the [http://octave.sf.net/fpl fpl package] for visualizing 2D results within Octave or exporting 2D or 3D results in a format compatible with [http://www.paraview.org Paraview] or [https://wci.llnl.gov/codes/visit/ VisIT]. These packages, though, offer only a limited choice of spatial discretization methods which are based on low degree polynomials and therefore have a low order of accuracy even for problems with extremely smooth solutions.<br />
The [http://geopdes.sf.net GeoPDEs] project, on the other hand, offers a complete suite of functions for discretizing a wide range of<br />
differential operators related to important physical problems and uses basis functions of arbitrary polynomial degree that allow the construction of methods of high accuracy. These latter, though, are based on the IsoGeometric Analysis Method which, although very powerful and often better performing, is less widely known and adopted than the Finite Elements Method. The implementation of a general purpose library of Finite Elements seems therefore a valuable addition to Octave-Forge. Two possible interesting choices for implementing this package exist, the first consists of implementing the most common Finite Element spaces in the [http://geopdes.sf.net GeoPDEs] framework, which is possible as IsoGeometric Analysis can be viewed as a superset of the Finite Element Method, the other is to construct Octave language bindings for the free software library [http://fenicsproject.org/documentation/ FEniCS] based on the existing C++ or Python interfaces. This second approach has been developed during the GSOC 2013 and the Octave-Forge package [http://octave.sf.net/fem-fenics fem-fenics] is now available. However, fem-fenics could be extended in many different ways:<br />
* implement the bindings for the UFL language inside Octave<br />
* add new functions already available with Fenics but not yet in Octave<br />
* create new functions specifically suited for Octave<br />
* improve the efficiency of the code<br />
The main goal for the fem-fenics package is ultimately to be merged with the FEnics project itself, so that it can remain in-sync with the main library development. --><br />
<br />
== Implement solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D ==<br />
<br />
The project will deliver a solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D similar to Matlab's function <tt>pdepe</tt>. A good starting point is the [http://en.wikipedia.org/wiki/Method_of_lines method of lines] for which you can find more details [http://en.wikibooks.org/wiki/Partial_Differential_Equations/Method_of_Lines here] and [http://www.scholarpedia.org/article/Method_of_lines here], whereas an example implementation can be found [http://www.scholarpedia.org/article/Method_of_Lines/Example_Implementation here]. In addition, [http://www.pdecomp.net/ this page] provides some useful material.<br />
<br />
== Implement solver for 1D nonlinear boundary value problems ==<br />
<br />
The project will complete the implementation of the bvp4c solver that is already available in an initial version in the odepkg package<br />
by adding a proper error estimator and will implement a matlab-compatible version of the bvp5c solver.<br />
Details on the methods to be implemented can be found in [http://dx.doi.org/10.1145/502800.502801 this paper] on bvp4c and [http://www.jnaiam.net/new/uploads/files/014dde86eef73328e7ab674d1a32aa9c.pdf this paper] on bvp5c. Further details are available in [http://books.google.it/books/about/Nonlinear_two_point_boundary_value_probl.html?id=s_pQAAAAMAAJ&redir_esc=y this book].<br />
<br />
<!-- == Geometric integrators for Hamiltonian Systems ==<br />
<br />
[http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration Geometric (AKA Symplectic) integrators] are useful for <br />
multi-dimensional classical mechanics problems and for molecular dynamics simulations.<br />
The odepkg package has a number of solvers for ODE, DAE and DDE problems but none of them is currently<br />
specifically suited for second order problems in general and Hamiltonian systems in particular.<br />
Therefore a new package for geometric integrators would be a useful contribution.<br />
This could be created as new package or added as a set of new functions for odepkg.<br />
The function interface should be consistent throughout the package and should be modeled to follow <br />
that of other functions in odepkg (or that of DASPK and LSODE) but will need specific extensions to accommodate for specific options that only make sense for this specific class of solvers.<br />
An initial list of methods to be implemented includes (but is not limited to)<br />
* Symplectic Euler methods, see [http://en.wikipedia.org/wiki/Semi-implicit_Euler_method here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Störmer-Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Velocity Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Symplectic partitioned Runge-Kutta methods, see [http://reference.wolfram.com/mathematica/tutorial/NDSolveSPRK.html here] or [http://dx.doi.org/10.1137/0733019 here]<br />
* Spectral Variational Integrator methods, see [http://www3.nd.edu/~izaguirr/papers/acta_numerica.pdf here] or [http://www.math.ucsd.edu/~mleok/pdf/HaLe2012_SVI.pdf here]<br />
<br />
For this latter there is an existing code which is already working but needs to be improved, posted on the patch tracker.<br />
Furthermore, methods to implement solutions of problems with rigid constraints should be implemented, e.g.<br />
* SHAKE, see [http://en.wikipedia.org/wiki/Constraint_algorithm here] or [http://dx.doi.org/10.1016/0021-9991(77)90098-5 here]<br />
* RATTLE, see [http://dx.doi.org/10.1016/0021-9991(83)90014-1 here] or [http://dx.doi.org/10.1002/jcc.540161003 here]<br />
--><br />
<br />
== Matlab-compatible ODE solvers in core-Octave ==<br />
<br />
* Improve handling of sparse Jacobians in IDE/DAE solvers<br />
** Currently, in the IDA wrapper function __ode15__ an over conservative guess for the amount of memory to be allocated when assembling a sparse jacobian is used, essentially allocating enough space for a full jacobian then freeing the excess memory, an initial patch for fixing this has been posted on the tracker, for integrating this into Octave it must be generalized to support prior versions of SUNDIALS<br />
** Currently Jacobians passed by the user in Octave's sparse matrix format are copied into SUNDIALS own sparse matrix format. Newer versions of SUNDIALS (5.x or higher) support letting the user take care of the linear algebra data structures and methods thus removing the need for the copy. Taking advantage of this feature would improve the solver performance both in terms of memory footprint and speed.<br />
** References<br />
***[https://savannah.gnu.org/bugs/?func=detailitem&item_id=55905 tracker post about memory allocation] <br />
***[https://computing.llnl.gov/projects/sundials/release-history SUNDIALS release history]<br />
* Implement Matlab compatible versions of "deval".<br />
* Complete transition of ode23s into core Octave<br />
** [https://savannah.gnu.org/bugs/?57309 Bug tracker entry discussing ode23s]<br />
<br />
== High Precision Arithmetic Computation ==<br />
<br />
The Linear Algebra Fortran libraries used by Octave make use of of single (32 bits) and double (64 bits) precision floating point numbers. Many operations are stopped when matrices condition number goes below 1e-16: such matrices are considered as ill-conditioned. There are cases where this is not enough, for instance simulations implying chemical concentrations covering the range 10^4 up to 10^34. There are a number of ways to increase the numerical resolution, like f.i. make use of 128 bits quadruple precision numbers available in GFortran. A simpler option is to build an interface over Gnu MPL arbitrary precision library, which is used internally by gcc and should be available on any platform where gcc runs. Such approach has been made available for MatLab under the name mptoolbox and is licensed under a BSD license. The author kindly provided a copy of the latest version and agreed to have it ported under Octave and re-distributed under GPL v3.0<br />
<br />
The architecture consists of an Octave class interface implementing "mp" (multi-precision) objects. Arithmetic operations are forwarded to MPL using MEX files. This is totally transparent to the end user, except when displaying numbers. This implementation needs to be ported and tested under Octave.<br />
<br />
=GUI/IDE=<br />
<br />
*Søren Hauberg has suggested that we need C++ code that can:<br />
**Determine if a line of code could be fully parsed, i.e. it would return true for "plot (x, y);", but false for "while (true)".<br />
**Evaluate a line of code and return the output as a string (it would be best if it could provide three strings: output, warnings and errors).<br />
**Query defined variables, i.e. get a list of currently defined variables. Bonus points if it could tell you if anything had changed since the last time you checked the variables (could also be done with signals).<br />
* Create a better (G)UI for the {{manual|profile|profiler}}. This may be done with Qt, but not necessarily.<br />
<br />
== GUI Variable Editor and Property Inspector ==<br />
<br />
Octave has a preliminary implementation of a Variable Editor: a spreadsheet-like tool for quickly editing and visualizing variables. The initial phase of the project will be learning how the implementation was done.<br />
<br />
With the knowledge gained, the second part of the project will be to implement a Property Inspector. This is a spreadsheet like interface to the many, many graphics properties that exist and are different on a per-object basis. The goal would be not only the concise-display of the existing properties, but a reasonable user interface to change them. As examples, Boolean properties should be able to be toggled with a double-click; Radio properties should have a drop-down list of only the supported options; Other properties that can be modified should have the constraints built-in (for example, Linewidth must be a scalar, while Position must be a 1x4 vector). It would also be important to have easy access to the documentation of a property.<br />
<br />
For reference, Matlab has a similar Property Inspector (https://www.mathworks.com/help/matlab/ref/inspect.html).<br />
<br />
== Sisotool. Create a graphical design tool for tuning closed loop control system ([[Control package]])==<br />
<br />
When tuning a SISO feedback system it is very helpful to be able to grab a pole or a zero and move them by dragging them with the mouse. As they are moving the software must update all the plotted lines. There should be the ability to display various graphs rlocuse, bode, step, impulse etc. and have them all change dynamically as the mouse is moving. The parameters of the compensator must be displayed and updated.<br />
Recently, some implementation was done during [[Summer_of_Code#GSoC_2018|GSoC 2018]], see https://eriveltongualter.github.io/GSoC2018/final.html for details.<br />
<br />
=Sparse Matrices=<br />
<br />
The paper by [http://arxiv.org/abs/cs.MS/0604006 Bateman & Adler] is good reading for understanding the sparse matrix implementation.<br />
<br />
*Improve Matlab compatibility for {{manual|sprandsym}}.<br />
<br />
*Sparse logical indexing in idx_vector class so that something like <code>a = sprandn (1e6, 1e6, 1e-6); a(a<1) = 0;</code> won't cause a memory overflow.<br />
<br />
*Other missing Functions<br />
**lsqr<br />
**minres<br />
**symmlq<br />
<br />
== SPQR Interface ==<br />
<br />
Octave implements QR factorization for sparse matrices, but it does so with an older "CXSPARSE" library. This has caused fundamental issues, including segfaults as recorded here (bugs {{bug|51950}} and {{bug|57033}}). The goal of this project is to program an interface to the API for the SQPR library (http://faculty.cse.tamu.edu/davis/suitesparse.html). This is the same library that Matlab uses for this purpose.<br />
<br />
*Improve QR factorization functions, using idea based on CSPARSE cs_dmsol.m<br />
<br />
*Improve QR factorization by replacing CXSPARSE code with SPQR code, and make the linear solve return 2-norm solutions for ill-conditioned matrices based on this new code<br />
<br />
=Strings=<br />
<br />
*Consider making octave_print_internal() print some sort of text representation for unprintable characters instead of sending them directly to the terminal. (But don't do this for fprintf!)<br />
<br />
*Consider changing the default value of `string_fill_char' from SPC to NUL.<br />
<br />
=Other Data Types=<br />
<br />
*Template functions for mixed-type ops.<br />
<br />
*Convert other functions for use with the floating point type including quad, dasrt, daspk, etc.<br />
<br />
=Input/Output=<br />
<br />
*Make fread and fwrite work for complex data. Iostreams based versions of these functions would also be nice, and if you are working on them, it would be good to support other size specifications (integer*2, etc.).<br />
<br />
*Move some pr-output stuff to liboctave.<br />
<br />
*Make the cutoff point for changing to packed storage a user-preference variable with default value 8192.<br />
<br />
*Complain if there is not enough disk space available (I think there is simply not enough error checking in the code that handles writing data).<br />
<br />
*Make it possible to tie arbitrary input and output streams together, similar to the way iostreams can be tied together.<br />
<br />
*Expand {{codeline|imwrite}} options. This shouldn't be too hard to implement, since it's wrapped around GraphicsMagick.<br />
<br />
*Extend Octave functions to work on stored arrays that are too big to fit in RAM, similar to available R [http://www.bigmemory.org/ packages.]<br />
<br />
* write {{codeline|xmlread}} and {{codeline|xmlwrite}}. This could be done using [http://xerces.apache.org/xerces-c/ Xerces C++ interface] which apparently is what [http://octave.1599824.n4.nabble.com/xml-in-octave-td4663034.html Matlab uses].<br />
<br />
* Implement hdf5 for .mat files (see [http://octave.1599824.n4.nabble.com/Reading-Matlab-td4650158.html this thread]).<br />
<br />
=Interpreter=<br />
<br />
The interpreter is written in C++, undocumented. There are many possible projects associated with it.<br />
<br />
'''Required skills''': ''Very good'' C and C++ knowledge, possibly also understanding of [http://en.wikipedia.org/wiki/Gnu_bison GNU bison] and [http://en.wikipedia.org/wiki/Flex_lexical_analyser flex]. Understanding how compilers and interpreters are made plus being able to understand how to use a profiler and a debugger will probably be essential skills.<br />
<br />
*Allow customization of the debug prompt.<br />
<br />
*Fix the parser so that<br />
<br />
if (expr) 'this is a string' end<br />
<br />
is parsed as IF expr STRING END. ''(see [https://lists.gnu.org/archive/html/octave-maintainers/2014-03/msg00087.html this] post on the mailing list)''<br />
<br />
*Clean up functions in input.cc that handle user input (there currently seems to be some unnecessary duplication of code and it seems overly complex).<br />
<br />
*Consider allowing an arbitrary property list to be attached to any variable. This could be a more general way to handle the help string that can currently be added with `document'.<br />
<br />
*Allow more command line options to be accessible as built-in variables (--echo-commands, etc.).<br />
<br />
*Make the interpreter run faster.<br />
<br />
*Allow arbitrary lower bounds for array indexing.<br />
<br />
*Improve performance of recursive function calls.<br />
<br />
*Improve the way ignore_function_time_stamp works to allow selecting by individual directories or functions.<br />
<br />
*Add a command-line option to tell Octave to just do syntax checking and not execute statements.<br />
<br />
*Clean up symtab and variable stuff.<br />
<br />
*Input stream class for parser files -- must manage buffers for flex and context for global variable settings.<br />
<br />
*make parser do more semantic checking, continue after errors when compiling functions, etc.<br />
<br />
*Make LEXICAL_ERROR have a value that is the error message for parse_error() to print?<br />
<br />
*Add a run-time alias mechanism that would allow things like alias fun function_with_a_very_long_name so that `function_with_a_very_long_name' could be invoked as `fun'.<br />
<br />
*Allow local changes to variables to be written more compactly than is currently possible with unwind_protect. For example, <br />
<br />
function f ()<br />
local prefer_column_vectors = something;<br />
...<br />
endfunction<br />
<br />
<br />
would be equivalent to<br />
<br />
function f ()<br />
save_prefer_column_vectors = prefer_column_vectors;<br />
unwind_protect<br />
prefer_column_vectors = something;<br />
...<br />
unwind_protect_cleanup<br />
prefer_column_vectors = save_prefer_column_vectors;<br />
end_unwind_protect<br />
endfunction<br />
<br />
<br />
*Fix all function files to check for bogus inputs (wrong number or types of input arguments, wrong number of output arguments).<br />
<br />
*Handle options for built-in functions more consistently.<br />
<br />
*Too much time is spent allocating and freeing memory. What can be done to improve performance?<br />
<br />
Use move constructors rather than copy constructors for things like dim_vectors which are repeatedly created just to initialize Array or Matrix objects.<br />
<br />
*Error output from Fortran code is ugly. Something should be done to make it look better.<br />
<br />
*It would be nice if output from the Fortran routines could be passed through the pager.<br />
<br />
*Attempt to recognize common subexpressions in the parser.<br />
<br />
*Consider making it possible to specify an empty matrix with a syntax like [](e1, e2). Of course at least one of the expressions must be zero...<br />
<br />
*Is Matrix::fortran_vec() really necessary?<br />
<br />
*Rewrite whos and the symbol_record_info class. Write a built-in function that gives all the basic information, then write who and whos as M-files.<br />
<br />
*On systems that support matherr(), make it possible for users to enable the printing of warning messages.<br />
<br />
*Make it possible to mark variables and functions as read-only.<br />
<br />
*Make it possible to write a function that gets a reference to a matrix in memory and change one or more elements without generating a second copy of the data.<br />
<br />
*Use nanosleep instead of usleep if it is available? Apparently nanosleep is to be preferred over usleep on Solaris systems.<br />
<br />
== Improve JIT compiling ==<br />
<br />
Octave's interpreter is ''very'' slow on some loops. Recently, thanks to Max Brister's work, an initial implementation of a just-in-time compiler (JITC) in [http://llvm.org LLVM] for GSoC 2012. This project consists in understanding Max's current implementation and extending it so that functions and exponents (e.g. 2^z) compile with the JITC. This requires knowledge of compilers, C++, LLVM, and the Octave or Matlab languages. A capable student who demonstrates the ability to acquire this knowledge quickly may also be considered. Max himself will mentor this project. [http://planet.octave.org/octconf2012/jit.pdf Here] is Max's OctConf 2012 presentation about his current implementation. See also [[JIT]].<br />
<br />
== Improve memory management ==<br />
<br />
From profiling the interpreter, it appears that a lot of time is spending allocating and deallocating memory. A better memory management algorithm might provide some improvement.<br />
<br />
== Implement classdef classes ==<br />
<br />
Matlab has two kinds of classes: old style @classes and new style classdef. Octave has only fully implemented the old style. There is partial support for classdef classes in version 4.0, refer to the [[Classdef|classdef status page]] for what is not yet implemented. There is irregular work here, and classdef is [http://www.mathworks.com/help/matlab/matlab_oop/method-attributes.html a very] [http://www.mathworks.com/help/matlab/events-sending-and-responding-to-messages.html complicated] [http://www.mathworks.com/help/matlab/enumeration-classes.html thing] to fully implement. A successful project would be to implement enough of classdef for most basic usages. Familiarity with Matlab's current classdef support would be a huge plus. Michael Goffioul and jwe can mentor this.<br />
<br />
Although there's already a substantial classdef support in current octave code base, there are still many areas that are unimplemented or need improvements. The main ones that come to my mind are:<br />
* support for events<br />
* support for enums<br />
* support for "import" (this requires good understanding of octave internals, especially the symbol table)<br />
* improving multiple inheritance and method resolution<br />
* honoring and computing "Sealed" attribute<br />
* support for function handle to methods<br />
<br />
== Improve MPI package ==<br />
<br />
Octave Forge's [http://octave.sourceforge.net/mpi/index.html MPI package] <br />
is a wrapper for basic MPI functions for parallel computing. It is implemented <br />
by wrapping MPI function calls in simple DLD functions that map Octave's Datataypes to <br />
MPI Derived Datatypes. <br />
The proposed project deals with improving and extending the Octave MPI package, for example:<br />
* Octave MPI applications can currently be only run in batch mode, add the ability to launch parallel jobs and collect their output in an interactive Octave session.<br />
* Implement functions for non-blocking communication (MPI_Isend, MPI_Irecv)<br />
* Implement one-to-many (Broadcast, Scatter), many-to-one (Reduce, Gather), and many-to-many (All Reduce, Allgather) communication routines<br />
<br />
= Graphics =<br />
<br />
* Correctly handle case where DISPLAY is unset. Provide --no-window-system or --nodisplay (?) option. Provide --display=DISPLAY option? How will this work with gnuplot (i.e., how do we know whether gnuplot requires an X display to display graphics)?<br />
<br />
* Implement a Cairo-based renderer for 2D-only graphics, with support for PS/PDF/SVG output (for printing).<br />
<br />
* On 'imagesc' plots, report the matrix values also based on the mouse position, updating on mouse moving.<br />
<br />
* Add map-creating capabilities similar to the Matlab [https://www.mathworks.com/help/map/functionlist.html Mapping toolbox] for inclusion in the Octave Forge [https://sourceforge.net/p/octave/mapping mapping package].<br />
<br />
* Add data cursor to trace data values in figure.<br />
<br />
== Non-OpenGL renderer ==<br />
<br />
Besides the original gnuplot backend, Octave also contains an OpenGL-based renderer for advanced and more powerful 3D plots. However, OpenGL is not perfectly suited for 2D-only plots where other methods could result in better graphics. The purpose of this project is to implement an alternate graphics renderer for 2D only plots (although 3D is definitely not the focus, extending the new graphics renderer to support basic 3D features should also be taken into account). There is no particular toolkit/library that must be used, but natural candidates are:<br />
* [http://qt.nokia.com Qt]: the GUI is currently written in Qt <strike>and work is also in progress to provide a Qt/OpenGL based backend [https://github.com/goffioul/QtHandles]</strike><br />
* [http://en.wikipedia.org/wiki/Cairo_%28software%29 Cairo]: this library is widely used and known to provides high-quality graphics with support for PS/PDF/SVG output.<br />
<br />
== LaTeX markup ==<br />
<br />
Text objects in plots (like titles, labels, texts...) in the OpenGL renderer only support plain text and TeX. The latter consists of a very limited subset of the TeX language. On the other hand, the LaTeX formatting support is expected to provide full LaTeX capabilities. There are various approaches that can be used:<br />
* Use an external LaTeX engine: this is the most straightforward, but it requires users to install a LaTeX distribution and setup Octave to use it.<br />
* Use an external library that supports LaTeX syntax, e.g. [https://github.com/opencollab/jlatexmath JLaTeXMath] a Java API to display LaTeX code, [https://github.com/nathancarter/qtmathjax qtmathjax] a Qt based library that executes MathJax in a background web page.<br />
* Implement our own LaTeX parser and renderer. The matplotlib project [http://matplotlib.sourceforge.net/users/usetex.html has already done this in Python] and might be used as an example of how to do this in Octave. There is also [https://github.com/jkriege2/JKQtPlotter JKQtPlotter], a Qt based plotting application which implements its own LaTeX parser/renderer in C++.<br />
<br />
=History=<br />
<br />
*Add an option to allow saving input from script files in the history list.<br />
<br />
*The history command should accept two numeric arguments to indicate a range of history entries to display, save or read.<br />
<br />
*Avoid writing the history file if the history list has not changed.<br />
<br />
*Avoid permission errors if the history file cannot be opened for writing.<br />
<br />
*Fix history problems — core dump if multiple processes are writing to the same history file?<br />
<br />
=Configuration and Installation=<br />
<br />
*Makefile changes:<br />
**eliminate for loops<br />
**define shell commands or eliminate them<br />
**consolidate targets<br />
<br />
*Create a docs-only distribution?<br />
<br />
*<strike> Convert build system to a non-recursive Automake setup. See how Makefile.am files currently include module.mk files in subdirectories, extend this concept to the entire project so there is only one top-level Makefile.am. </strike> Done, except for special dir libgnu which is the only SUBDIRS listed in configure.ac.<br />
<br />
=Documentation=<br />
:''See [[Project - Documentation]].''<br />
<br />
=Tests=<br />
*Improved set of tests: [http://octave.1599824.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=370633]<br />
**Tests for various functions. Would be nice to have a test file corresponding to every function (see below)<br />
**Tests for element by element operators: + - .* ./ .\ .^ | & < <= == >= > != !<br />
*** thorough tests for power operator including corner cases and strange combinations such as complex .^ range.<br />
**Tests for boolean operators: && ||<br />
**Tests for other operators: * / \ ' .'<br />
**Tests from bug reports.<br />
**Tests for indexed assignment. Need to consider the following:<br />
***fortran-style indexing<br />
***zero-one indexing<br />
***assignment of empty matrix as well as values resizing<br />
**Tests for all internal functions.<br />
<br />
* Implement a coverage tool for collecting coverage data and generating code coverage reports on m-file functions and scripts. This would be very useful for Octave development as well as for users who want a code coverage report for their own functions and scripts.<br />
<br />
We are far from even having one test for every function, so focus should be on getting the breadth of coverage first before trying to get the depth of 100% statement coverage. As of Dec 2015, 202 of 1020 m-files have no tests. Some of these will be plotting functions which have demos instead, but that leaves enough functions to be an interesting project. As of Dec 2015, there are 485 instances of C++ functions which need tests.<br />
<br />
After Octave is compiled, running the {{Codeline|make check}} build target will run the full test suite and generate a file called test/fntests.log in the build directory with a summary of the results. At the end of the file is a list of all functions for which no tests were found. An extract is posted in the [[files missing tests]] page. If you are not building Octave yourself, the test suite can be run on an installed binary copy by executing the {{Codeline|__run_test_suite__}} command at the Octave prompt. The fntests.log file will be written in the current directory in this case.<br />
<br />
There also need to be tests for functions written in the C++ files. See [[Add_BIST_tests_for_octave_functions_written_in_C%2B%2B]] for instructions and a list of instances.<br />
<br />
See also [[Continuous Build#Coverage Report]].<br />
<br />
=Programming=<br />
<br />
*Better error messages for missing operators?<br />
<br />
*Eliminate duplicate enums in pt-exp.cc, pt-const.cc, and ov.cc.<br />
<br />
*Handle octave_print_internal() stuff at the liboctave level. Then the octave_value classes could just call on the print() methods for the underlying classes.<br />
<br />
*As much as possible, eliminate explicit checks for the types of octave_value objects so that user-defined types will automatically do the right thing in more cases.<br />
<br />
*Only include config.h in files that actually need it, instead of including it in every .cc file. Unfortunately, this might not be so easy to figure out.<br />
<br />
*GNU coding standards:<br />
**Add a `Makefile' target to the Makefiles.<br />
**Comments on #else and #endif preprocessor commands.<br />
**Change error message format to match standards everywhere.<br />
<br />
*Eliminate more global variables.<br />
<br />
*Move procstream to liboctave.<br />
<br />
*Use references and classes in more places.<br />
<br />
*Share more code among the various _options functions.<br />
<br />
*Use non-empty identifiers in all warnings and errors issued by Octave, see [[Easy projects#Miscellaneous]].<br />
<br />
*Reduce the amount of datatypes in liboctave.<br />
<br />
*Re-implement operators using templates and modern C++. Current system evolved before templates and makes extensive use of macros to define interactions between scalar<->scalar, scalar<->matrix, scalar<->float, etc., etc.<br />
**In liboctave, the directory to work on is liboctave/operators<br />
**In libinterp, the directory to work on is libinterp/operators<br />
**In libinterp, there is also xpow.cc, xdiv.cc in libinterp/corefcn<br />
<br />
=Miscellaneous=<br />
<br />
*Implement some functions for interprocess communication: bind, accept, connect, gethostbyname, etc. (This functionality is already available in the octave sockets package, what is the purpose of moving it to core octave?)<br />
<br />
*The ability to transparently handle very large files: Juhana K Kouhia <kouhia@nic.funet.fi> wrote:<br />
*: If I have a one-dimensional signal data with the size 400 Mbytes, then what are my choices to operate with it:<br />
*:*I have to split the data<br />
*:*Octave has a virtual memory on its own and I don't have to worry about the splitting.<br />
*:If I split the data, then my easily programmed processing programs will become hard to program.<br />
*:If possible, I would like to have the virtual memory system in Octave i.e., the all big files, the user see as one big array or such. There could be several user selectable models to do the virtual memory depending on what kind of data the user have (1d, 2d) and in what order they are processed (stream or random access).<br />
<br />
*An interface to gdb. Michael Smolsky <fnsiguc@weizmann.weizmann.ac.il> wrote:<br />
*:I was thinking about a tool, which could be very useful for me in my numerical simulation work. It is an interconnection between gdb and octave. We are often managing very large arrays of data in our fortran or c codes, which might be studied with the help of octave at the algorithm development stages. Assume you're coding, say, wave equation. And want to debug the code. It would be great to pick some array from the memory of the code you're developing, fft it and see the image as a log-log plot of the spectral density. I'm facing similar problems now. To avoid high c-development cost, I develop in matlab/octave, and then rewrite into c. It might be so much easier, if I could off-load a c array right from the debugger into octave, study it, and, perhaps, change some [many] values with a convenient matlab/octave syntax, similar to <code>a(:,51:250)=zeros(100,200)</code>, and then store it back into the memory of my c code.<br />
<br />
*Implement gdb extensions for Octave types. Octave has the <code>etc/gdbinit</code> file, which has some basic support for displaying the contents of Octave types. Add more extensions to make it easier to debug octave_values and other Octave types.<br />
<br />
*Add a definition to lgrind so that it supports Octave. (See http://www.tex.ac.uk/tex-archive/support/lgrind/ for more information about lgrind.)<br />
<br />
*Spatial statistics, including covariogram estimation and kriging -- perhaps via an interface to [http://www.gstat.org/ gstat]?<br />
<br />
* the [http://octave.sourceforge.net/miscellaneous/function/units.html units] function from the miscellaneous package works by parsing the output of from a call to GNU units. This can be made much more robust by writing it in C++ and including its library "units.h"<br />
<br />
=Marketing and Community=<br />
<br />
* Make the Octave website/[[Project Infrastructure]] easier to maintain.<br />
<br />
* Make it easier for newcomers to contribute.<br />
<br />
* For marketing ideas, see the [https://openoffice.apache.org/orientation/intro-marketing.html Apache Open Office Introduction to Marketing]<br />
<br />
* Help design a user or a [https://www.openoffice.org/marketing/ooocon2006/presentations/wednesday_c10.pdf developer survey]<br />
<br />
* Help prepare and deliver presentations and [[Publications about Octave]] at colleges and universities.<br />
<br />
* Create a [[Forum for GNU Octave]].<br />
<br />
== Improve Windows binary packaging ==<br />
<br />
We are currently able to build and provide a [[Windows Installer|installer for Windows]]. The build process involves cross-compiling on a Linux system using a fork of the [http://mxe.cc/ MXE] project to build Octave and all of its dependencies. Any ideas for improving this process to make it easier or faster, or to improve the installer itself or the installation experience for Windows users would be appreciated.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
== Improve macOS binary packaging ==<br />
<br />
We would like to be able to easily generate binary packages for macOS. Right now, it's difficult and tedious to do so. Most OS X users install Octave using one of the source-based package managers such as Homebrew or MacPorts. Any way to help us build a binary package would be appreciated. Required knowledge is understanding how building binaries in macOS works. Our current approach to building binaries for Windows is to cross-compile from a GNU system using [http://mxe.cc/ MXE], something similar may be possible for OS X ([http://lilypond.org/gub/ GUB]?).<br />
<br />
There is a third-party project called [http://octave-app.org "Octave.app"] that creates and distributes macOS builds of Octave as a Mac app bundle. It is built on top of Homebrew and a set of custom Octave-related Homebrew formuale.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. If you choose to work on GUB, Python will be required. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
=Performance=<br />
<br />
* A profiler for Octave would be a very useful tool. And now we have one! But it really needs a better interface.<br />
* Having {{Codeline|parfor}} functioning would speed code development and execution now that multicore architectures are widespread. See [http://octave.1599824.n4.nabble.com/Parfor-td4630575.html here] and [http://stackoverflow.com/questions/24970519/how-to-use-parallel-for-loop-in-octave-or-scilab here]. Existing code from the [[Parallel package | parallel]] and [http://octave.sourceforge.net/mpi/index.html mpi] packages could perhaps be adapted for this.<br />
* Develop a performance benchmark for Octave (interpreter, load/save, plotting, etc., but not simply tests of underlying libraries such as BLAS or LAPACK). This benchmark could be run periodically to make sure that changes during development do not introduce regressions in performance.<br />
<br />
=Packaging=<br />
<br />
* create a system that allows packages to deprecate functions as in core. Possibilities are:<br />
** get pkg to accept a deprecated directory inside the package and add it to the search path. Functions in those directories would have to be treated the same as the ones inside the core deprecated<br />
** PKG_ADD can be used to hack this. Package developers would still have to actually write the warnings on the function code but this would allow to have the functions in a separate directory so they don't foget to remove them on the next release<br />
** the package developer can also use something like Make to create a ''normal'' package from something that actually had a more complex structure, inclusive deprecated directories<br />
* get pkg to resolve dependencies automatically by downloading and installing them too<br />
* allow to download and install multiple versions of the same package<br />
* make the package just a bit more verbose by default (specifics?)<br />
* make pkg a little more like apt-get (what specific features of apt-get is this referring to?)<br />
* make pkg support more than one src directory<br />
** subdirectories with makefiles and top level make command of: cd <subdir> && ${MAKE}... ok as a substitute?<br />
* make pkg able to supply extra configure and make flags, useful for distributions, including -j for make (pkg now passes --jobs=N automatically, CFLAGS and CXXFLAGS environment variables are already respected, what's missing?)<br />
<br />
=Preferences=<br />
<br />
Octave has several functions for managing user preferences. Many function use persistent variables instead of relying upon the preference features.<br />
* The function {{Codeline|edit ()}} contains a persistent structure used as its personal set of preferences. These can all be moved to the user preference group for the editor.<br />
** "EDITOR"<br />
** "HOME"<br />
** "AUTHOR"<br />
** "EMAIL"<br />
** "LICENSE"<br />
** "MODE"<br />
** "EDITINPLACE"<br />
* The {{Codeline|savepath ()}} function modifies the startup script (rcfile), {{Codeline|~/.octaverc}} and inserts commands to allow the next session to begin with the same path. Instead user preference can be created for startup items and a preference for the user specified path can be added. Perhaps two path preferences should be used. One for the elements that should precede the core path and those that should follow. A start up directory preference might also be added to allow the user to specify where Octave should begin the next session.<br />
** "PREPATH"<br />
** "POSTPATH"<br />
** "STARTUPDIR"<br />
* A preference group for plotting can also be added. A preference for the default terminal would be useful for those who want to override the default. Preferences for the default {{Codeline|graphicstoolkit}} can also be added.<br />
** GNUPLOTTERM<br />
** GRAPHICSTOOLKIT<br />
* A preference group for printing can include preferences for the default printer, the ghostscript command, and possibly other parameters like orientation, and resolution.<br />
** PRINTER<br />
** GHOSTSCRIPTCOMMAND<br />
** ORIENTATION<br />
** RESOLUTION<br />
* Searching the m-files for use of {{Codeline|persistent}} should turn up other opportunities to use preferences.<br />
<br />
=Bugs=<br />
<br />
There are always bugs to fix. The [https://savannah.gnu.org/bugs/?group=octave bug tracker] is a good place to find tasks needing a hand. See also [[Short projects#Bugs]].<br />
<br />
= Matlab compatibility =<br />
<br />
== Missing functions ==<br />
<br />
There are certain functions present in MATLAB known to be missing in Octave.<br />
<br />
One list is provided on the source for function __unimplemented.m__, subfunction missing_functions; it can be edited in the Octave GUI or browsed at [http://hg.savannah.gnu.org/hgweb/octave/file/default/scripts/help/__unimplemented__.m#l547].<br />
<br />
Lists are also kept for [[:Category:Missing functions|several packages]].<br />
<br />
It is also possible to look at existing [[Wikipedia:Free and open-source software|FOSS]] implementations, from FreeMat and Scilab (for more closely compatible languages) to R or Scipy or Julia (for less compatible versions). Obviously, it is NOT OK to look at the Matlab implementation since this is not [[Wikipedia:Free software|free software]]!<br />
<br />
== Functions under different name ==<br />
<br />
Many Octave Forge functions perform the same as functions from matlab packages. However, they often exist under a different name or have incompatible API's. Often fixing this is a matter of changing their names, swap the order of their input arguments. At least, a list of this functions would be helpful.<br />
<br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Project Ideas]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Projects&diff=13332Projects2020-09-16T01:25:26Z<p>Siko1056: /* Interpreter */ Strip finished items.</p>
<hr />
<div>The list below summarizes features or bug fixes we would like to see in Octave. This list is not exclusive -- there are many other things that might be good projects, but it might instead be something we already have. Also, some of the following items may not actually be considered good ideas now.<br />
<br />
{{Note|If you never contributed to Octave before, we suggest to start with our [[Developer FAQ]].}}<br />
<br />
* Summer of Code students, please also see [[Summer of Code - Getting Started]].<br />
* If you're looking for small project, see [[short projects]].<br />
<br />
=Numerical=<br />
<br />
* Use C++11 <random> libraries for random number generation. Write link between Octave functions (rand, randi, randn, rande) and C++ API. Implement RandStream objects as Matlab does.<br />
<br />
*Improve logm, and sqrtm (see this thread: http://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html)<br />
<br />
*Use pairwise addition in sum() to mitigate against numerical errors without substantial performance penalty (https://en.wikipedia.org/wiki/Pairwise_summation).<br />
<br />
*Review implementing algorithm in this 2009 paper (https://epubs.siam.org/doi/pdf/10.1137/080738490) for xsum (sum with extra accuracy). The existing implementation uses a 2005 paper.<br />
<br />
*Improve complex mapper functions. See W. Kahan, ``Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit (in The State of the Art in Numerical Analysis, eds. Iserles and Powell, Clarendon Press, Oxford, 1987) for explicit trigonometric formulae. See {{patch|8172}} for a previous attempt.<br />
<br />
*Make functions like gamma() return the right IEEE Inf or NaN values for extreme args or other undefined cases.<br />
<br />
*Improve sqp.<br />
<br />
*Fix CollocWt? to handle Laguerre polynomials. Make it easy to extend it to other polynomial types.<br />
<br />
*Add optional arguments to colloc so that it's not restricted to Legendre polynomials.<br />
<br />
*Move rand, eye, xpow, xdiv, etc., functions to the matrix classes.<br />
<br />
*Improve design of ODE, DAE, classes.<br />
<br />
*Make QR more memory efficient for large matrices when not all the columns of Q are required (apparently this is not handled by the lapack code yet).<br />
<br />
*Evaluate harmonics and cross-correlations of unevenly sampled and nonstationary time series, as in http://www.jstatsoft.org/v11/i02 (which has C code with interface to R). (This is now partly implemented in the [http://octave.sourceforge.net/lssa/index.html lssa] package.)<br />
<br />
<!-- == General purpose Finite Element library ==<br />
<br />
Octave-Forge already has a set of packages for discretizing Partial Differential operators by Finite Elements and/or Finite Volumes,<br />
namely the [[bim package]] which relies on the [http://octave.sf.net/msh msh package] (which is in turn based on [http://geuz.org/gmsh/ gmsh]) for creating and managing 2D triangular and 3D tetrahedral meshes and on the [http://octave.sf.net/fpl fpl package] for visualizing 2D results within Octave or exporting 2D or 3D results in a format compatible with [http://www.paraview.org Paraview] or [https://wci.llnl.gov/codes/visit/ VisIT]. These packages, though, offer only a limited choice of spatial discretization methods which are based on low degree polynomials and therefore have a low order of accuracy even for problems with extremely smooth solutions.<br />
The [http://geopdes.sf.net GeoPDEs] project, on the other hand, offers a complete suite of functions for discretizing a wide range of<br />
differential operators related to important physical problems and uses basis functions of arbitrary polynomial degree that allow the construction of methods of high accuracy. These latter, though, are based on the IsoGeometric Analysis Method which, although very powerful and often better performing, is less widely known and adopted than the Finite Elements Method. The implementation of a general purpose library of Finite Elements seems therefore a valuable addition to Octave-Forge. Two possible interesting choices for implementing this package exist, the first consists of implementing the most common Finite Element spaces in the [http://geopdes.sf.net GeoPDEs] framework, which is possible as IsoGeometric Analysis can be viewed as a superset of the Finite Element Method, the other is to construct Octave language bindings for the free software library [http://fenicsproject.org/documentation/ FEniCS] based on the existing C++ or Python interfaces. This second approach has been developed during the GSOC 2013 and the Octave-Forge package [http://octave.sf.net/fem-fenics fem-fenics] is now available. However, fem-fenics could be extended in many different ways:<br />
* implement the bindings for the UFL language inside Octave<br />
* add new functions already available with Fenics but not yet in Octave<br />
* create new functions specifically suited for Octave<br />
* improve the efficiency of the code<br />
The main goal for the fem-fenics package is ultimately to be merged with the FEnics project itself, so that it can remain in-sync with the main library development. --><br />
<br />
== Implement solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D ==<br />
<br />
The project will deliver a solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D similar to Matlab's function <tt>pdepe</tt>. A good starting point is the [http://en.wikipedia.org/wiki/Method_of_lines method of lines] for which you can find more details [http://en.wikibooks.org/wiki/Partial_Differential_Equations/Method_of_Lines here] and [http://www.scholarpedia.org/article/Method_of_lines here], whereas an example implementation can be found [http://www.scholarpedia.org/article/Method_of_Lines/Example_Implementation here]. In addition, [http://www.pdecomp.net/ this page] provides some useful material.<br />
<br />
== Implement solver for 1D nonlinear boundary value problems ==<br />
<br />
The project will complete the implementation of the bvp4c solver that is already available in an initial version in the odepkg package<br />
by adding a proper error estimator and will implement a matlab-compatible version of the bvp5c solver.<br />
Details on the methods to be implemented can be found in [http://dx.doi.org/10.1145/502800.502801 this paper] on bvp4c and [http://www.jnaiam.net/new/uploads/files/014dde86eef73328e7ab674d1a32aa9c.pdf this paper] on bvp5c. Further details are available in [http://books.google.it/books/about/Nonlinear_two_point_boundary_value_probl.html?id=s_pQAAAAMAAJ&redir_esc=y this book].<br />
<br />
<!-- == Geometric integrators for Hamiltonian Systems ==<br />
<br />
[http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration Geometric (AKA Symplectic) integrators] are useful for <br />
multi-dimensional classical mechanics problems and for molecular dynamics simulations.<br />
The odepkg package has a number of solvers for ODE, DAE and DDE problems but none of them is currently<br />
specifically suited for second order problems in general and Hamiltonian systems in particular.<br />
Therefore a new package for geometric integrators would be a useful contribution.<br />
This could be created as new package or added as a set of new functions for odepkg.<br />
The function interface should be consistent throughout the package and should be modeled to follow <br />
that of other functions in odepkg (or that of DASPK and LSODE) but will need specific extensions to accommodate for specific options that only make sense for this specific class of solvers.<br />
An initial list of methods to be implemented includes (but is not limited to)<br />
* Symplectic Euler methods, see [http://en.wikipedia.org/wiki/Semi-implicit_Euler_method here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Störmer-Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Velocity Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Symplectic partitioned Runge-Kutta methods, see [http://reference.wolfram.com/mathematica/tutorial/NDSolveSPRK.html here] or [http://dx.doi.org/10.1137/0733019 here]<br />
* Spectral Variational Integrator methods, see [http://www3.nd.edu/~izaguirr/papers/acta_numerica.pdf here] or [http://www.math.ucsd.edu/~mleok/pdf/HaLe2012_SVI.pdf here]<br />
<br />
For this latter there is an existing code which is already working but needs to be improved, posted on the patch tracker.<br />
Furthermore, methods to implement solutions of problems with rigid constraints should be implemented, e.g.<br />
* SHAKE, see [http://en.wikipedia.org/wiki/Constraint_algorithm here] or [http://dx.doi.org/10.1016/0021-9991(77)90098-5 here]<br />
* RATTLE, see [http://dx.doi.org/10.1016/0021-9991(83)90014-1 here] or [http://dx.doi.org/10.1002/jcc.540161003 here]<br />
--><br />
<br />
== Matlab-compatible ODE solvers in core-Octave ==<br />
<br />
* Improve handling of sparse Jacobians in IDE/DAE solvers<br />
** Currently, in the IDA wrapper function __ode15__ an over conservative guess for the amount of memory to be allocated when assembling a sparse jacobian is used, essentially allocating enough space for a full jacobian then freeing the excess memory, an initial patch for fixing this has been posted on the tracker, for integrating this into Octave it must be generalized to support prior versions of SUNDIALS<br />
** Currently Jacobians passed by the user in Octave's sparse matrix format are copied into SUNDIALS own sparse matrix format. Newer versions of SUNDIALS (5.x or higher) support letting the user take care of the linear algebra data structures and methods thus removing the need for the copy. Taking advantage of this feature would improve the solver performance both in terms of memory footprint and speed.<br />
** References<br />
***[https://savannah.gnu.org/bugs/?func=detailitem&item_id=55905 tracker post about memory allocation] <br />
***[https://computing.llnl.gov/projects/sundials/release-history SUNDIALS release history]<br />
* Implement Matlab compatible versions of "deval".<br />
* Complete transition of ode23s into core Octave<br />
** [https://savannah.gnu.org/bugs/?57309 Bug tracker entry discussing ode23s]<br />
<br />
== High Precision Arithmetic Computation ==<br />
<br />
The Linear Algebra Fortran libraries used by Octave make use of of single (32 bits) and double (64 bits) precision floating point numbers. Many operations are stopped when matrices condition number goes below 1e-16: such matrices are considered as ill-conditioned. There are cases where this is not enough, for instance simulations implying chemical concentrations covering the range 10^4 up to 10^34. There are a number of ways to increase the numerical resolution, like f.i. make use of 128 bits quadruple precision numbers available in GFortran. A simpler option is to build an interface over Gnu MPL arbitrary precision library, which is used internally by gcc and should be available on any platform where gcc runs. Such approach has been made available for MatLab under the name mptoolbox and is licensed under a BSD license. The author kindly provided a copy of the latest version and agreed to have it ported under Octave and re-distributed under GPL v3.0<br />
<br />
The architecture consists of an Octave class interface implementing "mp" (multi-precision) objects. Arithmetic operations are forwarded to MPL using MEX files. This is totally transparent to the end user, except when displaying numbers. This implementation needs to be ported and tested under Octave.<br />
<br />
=GUI/IDE=<br />
<br />
*Søren Hauberg has suggested that we need C++ code that can:<br />
**Determine if a line of code could be fully parsed, i.e. it would return true for "plot (x, y);", but false for "while (true)".<br />
**Evaluate a line of code and return the output as a string (it would be best if it could provide three strings: output, warnings and errors).<br />
**Query defined variables, i.e. get a list of currently defined variables. Bonus points if it could tell you if anything had changed since the last time you checked the variables (could also be done with signals).<br />
* Create a better (G)UI for the {{manual|profile|profiler}}. This may be done with Qt, but not necessarily.<br />
<br />
== GUI Variable Editor and Property Inspector ==<br />
<br />
Octave has a preliminary implementation of a Variable Editor: a spreadsheet-like tool for quickly editing and visualizing variables. The initial phase of the project will be learning how the implementation was done.<br />
<br />
With the knowledge gained, the second part of the project will be to implement a Property Inspector. This is a spreadsheet like interface to the many, many graphics properties that exist and are different on a per-object basis. The goal would be not only the concise-display of the existing properties, but a reasonable user interface to change them. As examples, Boolean properties should be able to be toggled with a double-click; Radio properties should have a drop-down list of only the supported options; Other properties that can be modified should have the constraints built-in (for example, Linewidth must be a scalar, while Position must be a 1x4 vector). It would also be important to have easy access to the documentation of a property.<br />
<br />
For reference, Matlab has a similar Property Inspector (https://www.mathworks.com/help/matlab/ref/inspect.html).<br />
<br />
== Sisotool. Create a graphical design tool for tuning closed loop control system ([[Control package]])==<br />
<br />
When tuning a SISO feedback system it is very helpful to be able to grab a pole or a zero and move them by dragging them with the mouse. As they are moving the software must update all the plotted lines. There should be the ability to display various graphs rlocuse, bode, step, impulse etc. and have them all change dynamically as the mouse is moving. The parameters of the compensator must be displayed and updated.<br />
Recently, some implementation was done during [[Summer_of_Code#GSoC_2018|GSoC 2018]], see https://eriveltongualter.github.io/GSoC2018/final.html for details.<br />
<br />
=Sparse Matrices=<br />
<br />
The paper by [http://arxiv.org/abs/cs.MS/0604006 Bateman & Adler] is good reading for understanding the sparse matrix implementation.<br />
<br />
*Improve Matlab compatibility for {{manual|sprandsym}}.<br />
<br />
*Sparse logical indexing in idx_vector class so that something like <code>a = sprandn (1e6, 1e6, 1e-6); a(a<1) = 0;</code> won't cause a memory overflow.<br />
<br />
*Other missing Functions<br />
**lsqr<br />
**minres<br />
**symmlq<br />
<br />
== SPQR Interface ==<br />
<br />
Octave implements QR factorization for sparse matrices, but it does so with an older "CXSPARSE" library. This has caused fundamental issues, including segfaults as recorded here (bugs {{bug|51950}} and {{bug|57033}}). The goal of this project is to program an interface to the API for the SQPR library (http://faculty.cse.tamu.edu/davis/suitesparse.html). This is the same library that Matlab uses for this purpose.<br />
<br />
*Improve QR factorization functions, using idea based on CSPARSE cs_dmsol.m<br />
<br />
*Improve QR factorization by replacing CXSPARSE code with SPQR code, and make the linear solve return 2-norm solutions for ill-conditioned matrices based on this new code<br />
<br />
=Strings=<br />
<br />
*Consider making octave_print_internal() print some sort of text representation for unprintable characters instead of sending them directly to the terminal. (But don't do this for fprintf!)<br />
<br />
*Consider changing the default value of `string_fill_char' from SPC to NUL.<br />
<br />
=Other Data Types=<br />
<br />
*Template functions for mixed-type ops.<br />
<br />
*Convert other functions for use with the floating point type including quad, dasrt, daspk, etc.<br />
<br />
=Input/Output=<br />
<br />
*Make fread and fwrite work for complex data. Iostreams based versions of these functions would also be nice, and if you are working on them, it would be good to support other size specifications (integer*2, etc.).<br />
<br />
*Move some pr-output stuff to liboctave.<br />
<br />
*Make the cutoff point for changing to packed storage a user-preference variable with default value 8192.<br />
<br />
*Complain if there is not enough disk space available (I think there is simply not enough error checking in the code that handles writing data).<br />
<br />
*Make it possible to tie arbitrary input and output streams together, similar to the way iostreams can be tied together.<br />
<br />
*Expand {{codeline|imwrite}} options. This shouldn't be too hard to implement, since it's wrapped around GraphicsMagick.<br />
<br />
*Extend Octave functions to work on stored arrays that are too big to fit in RAM, similar to available R [http://www.bigmemory.org/ packages.]<br />
<br />
* write {{codeline|xmlread}} and {{codeline|xmlwrite}}. This could be done using [http://xerces.apache.org/xerces-c/ Xerces C++ interface] which apparently is what [http://octave.1599824.n4.nabble.com/xml-in-octave-td4663034.html Matlab uses].<br />
<br />
* Implement hdf5 for .mat files (see [http://octave.1599824.n4.nabble.com/Reading-Matlab-td4650158.html this thread]).<br />
<br />
=Interpreter=<br />
<br />
The interpreter is written in C++, undocumented. There are many possible projects associated with it.<br />
<br />
'''Required skills''': ''Very good'' C and C++ knowledge, possibly also understanding of [http://en.wikipedia.org/wiki/Gnu_bison GNU bison] and [http://en.wikipedia.org/wiki/Flex_lexical_analyser flex]. Understanding how compilers and interpreters are made plus being able to understand how to use a profiler and a debugger will probably be essential skills.<br />
<br />
*Allow customization of the debug prompt.<br />
<br />
*Fix the parser so that<br />
<br />
if (expr) 'this is a string' end<br />
<br />
is parsed as IF expr STRING END. ''(see [https://lists.gnu.org/archive/html/octave-maintainers/2014-03/msg00087.html this] post on the mailing list)''<br />
<br />
*Clean up functions in input.cc that handle user input (there currently seems to be some unnecessary duplication of code and it seems overly complex).<br />
<br />
*Consider allowing an arbitrary property list to be attached to any variable. This could be a more general way to handle the help string that can currently be added with `document'.<br />
<br />
*Allow more command line options to be accessible as built-in variables (--echo-commands, etc.).<br />
<br />
*Make the interpreter run faster.<br />
<br />
*Allow arbitrary lower bounds for array indexing.<br />
<br />
*Improve performance of recursive function calls.<br />
<br />
*Improve the way ignore_function_time_stamp works to allow selecting by individual directories or functions.<br />
<br />
*Add a command-line option to tell Octave to just do syntax checking and not execute statements.<br />
<br />
*Clean up symtab and variable stuff.<br />
<br />
*Input stream class for parser files -- must manage buffers for flex and context for global variable settings.<br />
<br />
*make parser do more semantic checking, continue after errors when compiling functions, etc.<br />
<br />
*Make LEXICAL_ERROR have a value that is the error message for parse_error() to print?<br />
<br />
*Add a run-time alias mechanism that would allow things like alias fun function_with_a_very_long_name so that `function_with_a_very_long_name' could be invoked as `fun'.<br />
<br />
*Allow local changes to variables to be written more compactly than is currently possible with unwind_protect. For example, <br />
<br />
function f ()<br />
local prefer_column_vectors = something;<br />
...<br />
endfunction<br />
<br />
<br />
would be equivalent to<br />
<br />
function f ()<br />
save_prefer_column_vectors = prefer_column_vectors;<br />
unwind_protect<br />
prefer_column_vectors = something;<br />
...<br />
unwind_protect_cleanup<br />
prefer_column_vectors = save_prefer_column_vectors;<br />
end_unwind_protect<br />
endfunction<br />
<br />
<br />
*Fix all function files to check for bogus inputs (wrong number or types of input arguments, wrong number of output arguments).<br />
<br />
*Handle options for built-in functions more consistently.<br />
<br />
*Too much time is spent allocating and freeing memory. What can be done to improve performance?<br />
<br />
Use move constructors rather than copy constructors for things like dim_vectors which are repeatedly created just to initialize Array or Matrix objects.<br />
<br />
*Error output from Fortran code is ugly. Something should be done to make it look better.<br />
<br />
*It would be nice if output from the Fortran routines could be passed through the pager.<br />
<br />
*Attempt to recognize common subexpressions in the parser.<br />
<br />
*Consider making it possible to specify an empty matrix with a syntax like [](e1, e2). Of course at least one of the expressions must be zero...<br />
<br />
*Is Matrix::fortran_vec() really necessary?<br />
<br />
*Rewrite whos and the symbol_record_info class. Write a built-in function that gives all the basic information, then write who and whos as M-files.<br />
<br />
*On systems that support matherr(), make it possible for users to enable the printing of warning messages.<br />
<br />
*Make it possible to mark variables and functions as read-only.<br />
<br />
*Make it possible to write a function that gets a reference to a matrix in memory and change one or more elements without generating a second copy of the data.<br />
<br />
*Use nanosleep instead of usleep if it is available? Apparently nanosleep is to be preferred over usleep on Solaris systems.<br />
<br />
== Improve JIT compiling ==<br />
<br />
Octave's interpreter is ''very'' slow on some loops. Recently, thanks to Max Brister's work, an initial implementation of a just-in-time compiler (JITC) in [http://llvm.org LLVM] for GSoC 2012. This project consists in understanding Max's current implementation and extending it so that functions and exponents (e.g. 2^z) compile with the JITC. This requires knowledge of compilers, C++, LLVM, and the Octave or Matlab languages. A capable student who demonstrates the ability to acquire this knowledge quickly may also be considered. Max himself will mentor this project. [http://planet.octave.org/octconf2012/jit.pdf Here] is Max's OctConf 2012 presentation about his current implementation. See also [[JIT]].<br />
<br />
== Improve memory management ==<br />
<br />
From profiling the interpreter, it appears that a lot of time is spending allocating and deallocating memory. A better memory management algorithm might provide some improvement.<br />
<br />
== Implement classdef classes ==<br />
<br />
Matlab has two kinds of classes: old style @classes and new style classdef. Octave has only fully implemented the old style. There is partial support for classdef classes in version 4.0, refer to the [[Classdef|classdef status page]] for what is not yet implemented. There is irregular work here, and classdef is [http://www.mathworks.com/help/matlab/matlab_oop/method-attributes.html a very] [http://www.mathworks.com/help/matlab/events-sending-and-responding-to-messages.html complicated] [http://www.mathworks.com/help/matlab/enumeration-classes.html thing] to fully implement. A successful project would be to implement enough of classdef for most basic usages. Familiarity with Matlab's current classdef support would be a huge plus. Michael Goffioul and jwe can mentor this.<br />
<br />
Although there's already a substantial classdef support in current octave code base, there are still many areas that are unimplemented or need improvements. The main ones that come to my mind are:<br />
* support for events<br />
* support for enums<br />
* support for "import" (this requires good understanding of octave internals, especially the symbol table)<br />
* improving multiple inheritance and method resolution<br />
* honoring and computing "Sealed" attribute<br />
* support for function handle to methods<br />
<br />
== Improve MPI package ==<br />
<br />
Octave Forge's [http://octave.sourceforge.net/mpi/index.html MPI package] <br />
is a wrapper for basic MPI functions for parallel computing. It is implemented <br />
by wrapping MPI function calls in simple DLD functions that map Octave's Datataypes to <br />
MPI Derived Datatypes. <br />
The proposed project deals with improving and extending the Octave MPI package, for example:<br />
* Octave MPI applications can currently be only run in batch mode, add the ability to launch parallel jobs and collect their output in an interactive Octave session.<br />
* Implement functions for non-blocking communication (MPI_Isend, MPI_Irecv)<br />
* Implement one-to-many (Broadcast, Scatter), many-to-one (Reduce, Gather), and many-to-many (All Reduce, Allgather) communication routines<br />
<br />
=Graphics=<br />
<br />
*Correctly handle case where DISPLAY is unset. Provide --no-window-system or --nodisplay (?) option. Provide --display=DISPLAY option? How will this work with gnuplot (i.e., how do we know whether gnuplot requires an X display to display graphics)?<br />
<br />
* <strike>Implement transparency and lighting in OpenGL backend(s). A basic implementation was available in [http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/jhandles/ JHandles]. This needs to be ported/re-implement/re-engineered/optimized in the C++ OpenGL renderer of octave</strike>.<br />
<br />
* Implement a Cairo-based renderer for 2D-only graphics, with support for PS/PDF/SVG output (for printing).<br />
<br />
* On 'imagesc' plots, report the matrix values also based on the mouse position, updating on mouse moving.<br />
<br />
* Add map-creating capabilities similar to the Matlab [http://www.mathworks.com/help/map/functionlist.html Mapping toolbox] for inclusion in the Octave Forge [https://sourceforge.net/p/octave/mapping mapping package].<br />
<br />
* Add data cursor to trace data values in figure.<br />
<br />
== Lighting ==<br />
<br />
<strike>Implement transparency and lighting in OpenGL backend(s). A basic implementation is available in [http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/jhandles/ JHandles]. This needs to be ported/re-implement/re-engineered/optimized in the C++ OpenGL renderer of Octave.</strike><br />
<br />
== Object selection in OpenGL renderer ==<br />
<br />
<strike>This project is about the implementation of a selection method of graphics elements within the OpenGL renderer [http://glprogramming.com/red/chapter13.html]</strike><br />
<br />
== Non-OpenGL renderer ==<br />
<br />
Besides the original gnuplot backend, Octave also contains an OpenGL-based renderer for advanced and more powerful 3D plots. However, OpenGL is not perfectly suited for 2D-only plots where other methods could result in better graphics. The purpose of this project is to implement an alternate graphics renderer for 2D only plots (although 3D is definitely not the focus, extending the new graphics renderer to support basic 3D features should also be taken into account). There is no particular toolkit/library that must be used, but natural candidates are:<br />
* [http://qt.nokia.com Qt]: the GUI is currently written in Qt <strike>and work is also in progress to provide a Qt/OpenGL based backend [https://github.com/goffioul/QtHandles]</strike><br />
* [http://en.wikipedia.org/wiki/Cairo_%28software%29 Cairo]: this library is widely used and known to provides high-quality graphics with support for PS/PDF/SVG output.<br />
<br />
== LaTeX markup ==<br />
<br />
Text objects in plots (like titles, labels, texts...) in the OpenGL renderer only support plain text and TeX. The latter consists of a very limited subset of the TeX language. On the other hand, the LaTeX formatting support is expected to provide full LaTeX capabilities. There are various approaches that can be used:<br />
* Use an external LaTeX engine: this is the most straightforward, but it requires users to install a LaTeX distribution and setup Octave to use it.<br />
* Use an external library that supports LaTeX syntax, e.g. [http://forge.scilab.org/index.php/p/jlatexmath/ JLaTeXMath] a Java API to display LaTeX code, [https://github.com/nathancarter/qtmathjax qtmathjax] a Qt based library that executes MathJax in a background web page.<br />
* Implement our own LaTeX parser and renderer. The matplotlib project [http://matplotlib.sourceforge.net/users/usetex.html has already done this in Python] and might be used as an example of how to do this in Octave. There is also [https://github.com/jkriege2/JKQtPlotter JKQtPlotter], a Qt based plotting application which implements its own LaTeX parser/renderer in C++.<br />
<br />
=History=<br />
<br />
*Add an option to allow saving input from script files in the history list.<br />
<br />
*The history command should accept two numeric arguments to indicate a range of history entries to display, save or read.<br />
<br />
*Avoid writing the history file if the history list has not changed.<br />
<br />
*Avoid permission errors if the history file cannot be opened for writing.<br />
<br />
*Fix history problems — core dump if multiple processes are writing to the same history file?<br />
<br />
=Configuration and Installation=<br />
<br />
*Makefile changes:<br />
**eliminate for loops<br />
**define shell commands or eliminate them<br />
**consolidate targets<br />
<br />
*Create a docs-only distribution?<br />
<br />
*<strike> Convert build system to a non-recursive Automake setup. See how Makefile.am files currently include module.mk files in subdirectories, extend this concept to the entire project so there is only one top-level Makefile.am. </strike> Done, except for special dir libgnu which is the only SUBDIRS listed in configure.ac.<br />
<br />
=Documentation=<br />
:''See [[Project - Documentation]].''<br />
<br />
=Tests=<br />
*Improved set of tests: [http://octave.1599824.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=370633]<br />
**Tests for various functions. Would be nice to have a test file corresponding to every function (see below)<br />
**Tests for element by element operators: + - .* ./ .\ .^ | & < <= == >= > != !<br />
*** thorough tests for power operator including corner cases and strange combinations such as complex .^ range.<br />
**Tests for boolean operators: && ||<br />
**Tests for other operators: * / \ ' .'<br />
**Tests from bug reports.<br />
**Tests for indexed assignment. Need to consider the following:<br />
***fortran-style indexing<br />
***zero-one indexing<br />
***assignment of empty matrix as well as values resizing<br />
**Tests for all internal functions.<br />
<br />
* Implement a coverage tool for collecting coverage data and generating code coverage reports on m-file functions and scripts. This would be very useful for Octave development as well as for users who want a code coverage report for their own functions and scripts.<br />
<br />
We are far from even having one test for every function, so focus should be on getting the breadth of coverage first before trying to get the depth of 100% statement coverage. As of Dec 2015, 202 of 1020 m-files have no tests. Some of these will be plotting functions which have demos instead, but that leaves enough functions to be an interesting project. As of Dec 2015, there are 485 instances of C++ functions which need tests.<br />
<br />
After Octave is compiled, running the {{Codeline|make check}} build target will run the full test suite and generate a file called test/fntests.log in the build directory with a summary of the results. At the end of the file is a list of all functions for which no tests were found. An extract is posted in the [[files missing tests]] page. If you are not building Octave yourself, the test suite can be run on an installed binary copy by executing the {{Codeline|__run_test_suite__}} command at the Octave prompt. The fntests.log file will be written in the current directory in this case.<br />
<br />
There also need to be tests for functions written in the C++ files. See [[Add_BIST_tests_for_octave_functions_written_in_C%2B%2B]] for instructions and a list of instances.<br />
<br />
See also [[Continuous Build#Coverage Report]].<br />
<br />
=Programming=<br />
<br />
*Better error messages for missing operators?<br />
<br />
*Eliminate duplicate enums in pt-exp.cc, pt-const.cc, and ov.cc.<br />
<br />
*Handle octave_print_internal() stuff at the liboctave level. Then the octave_value classes could just call on the print() methods for the underlying classes.<br />
<br />
*As much as possible, eliminate explicit checks for the types of octave_value objects so that user-defined types will automatically do the right thing in more cases.<br />
<br />
*Only include config.h in files that actually need it, instead of including it in every .cc file. Unfortunately, this might not be so easy to figure out.<br />
<br />
*GNU coding standards:<br />
**Add a `Makefile' target to the Makefiles.<br />
**Comments on #else and #endif preprocessor commands.<br />
**Change error message format to match standards everywhere.<br />
<br />
*Eliminate more global variables.<br />
<br />
*Move procstream to liboctave.<br />
<br />
*Use references and classes in more places.<br />
<br />
*Share more code among the various _options functions.<br />
<br />
*Use non-empty identifiers in all warnings and errors issued by Octave, see [[Easy projects#Miscellaneous]].<br />
<br />
*Reduce the amount of datatypes in liboctave.<br />
<br />
*Re-implement operators using templates and modern C++. Current system evolved before templates and makes extensive use of macros to define interactions between scalar<->scalar, scalar<->matrix, scalar<->float, etc., etc.<br />
**In liboctave, the directory to work on is liboctave/operators<br />
**In libinterp, the directory to work on is libinterp/operators<br />
**In libinterp, there is also xpow.cc, xdiv.cc in libinterp/corefcn<br />
<br />
=Miscellaneous=<br />
<br />
*Implement some functions for interprocess communication: bind, accept, connect, gethostbyname, etc. (This functionality is already available in the octave sockets package, what is the purpose of moving it to core octave?)<br />
<br />
*The ability to transparently handle very large files: Juhana K Kouhia <kouhia@nic.funet.fi> wrote:<br />
*: If I have a one-dimensional signal data with the size 400 Mbytes, then what are my choices to operate with it:<br />
*:*I have to split the data<br />
*:*Octave has a virtual memory on its own and I don't have to worry about the splitting.<br />
*:If I split the data, then my easily programmed processing programs will become hard to program.<br />
*:If possible, I would like to have the virtual memory system in Octave i.e., the all big files, the user see as one big array or such. There could be several user selectable models to do the virtual memory depending on what kind of data the user have (1d, 2d) and in what order they are processed (stream or random access).<br />
<br />
*An interface to gdb. Michael Smolsky <fnsiguc@weizmann.weizmann.ac.il> wrote:<br />
*:I was thinking about a tool, which could be very useful for me in my numerical simulation work. It is an interconnection between gdb and octave. We are often managing very large arrays of data in our fortran or c codes, which might be studied with the help of octave at the algorithm development stages. Assume you're coding, say, wave equation. And want to debug the code. It would be great to pick some array from the memory of the code you're developing, fft it and see the image as a log-log plot of the spectral density. I'm facing similar problems now. To avoid high c-development cost, I develop in matlab/octave, and then rewrite into c. It might be so much easier, if I could off-load a c array right from the debugger into octave, study it, and, perhaps, change some [many] values with a convenient matlab/octave syntax, similar to <code>a(:,51:250)=zeros(100,200)</code>, and then store it back into the memory of my c code.<br />
<br />
*Implement gdb extensions for Octave types. Octave has the <code>etc/gdbinit</code> file, which has some basic support for displaying the contents of Octave types. Add more extensions to make it easier to debug octave_values and other Octave types.<br />
<br />
*Add a definition to lgrind so that it supports Octave. (See http://www.tex.ac.uk/tex-archive/support/lgrind/ for more information about lgrind.)<br />
<br />
*Spatial statistics, including covariogram estimation and kriging -- perhaps via an interface to [http://www.gstat.org/ gstat]?<br />
<br />
* the [http://octave.sourceforge.net/miscellaneous/function/units.html units] function from the miscellaneous package works by parsing the output of from a call to GNU units. This can be made much more robust by writing it in C++ and including its library "units.h"<br />
<br />
=Marketing and Community=<br />
<br />
* Make the Octave website/[[Project Infrastructure]] easier to maintain.<br />
<br />
* Make it easier for newcomers to contribute.<br />
<br />
* For marketing ideas, see the [https://openoffice.apache.org/orientation/intro-marketing.html Apache Open Office Introduction to Marketing]<br />
<br />
* Help design a user or a [https://www.openoffice.org/marketing/ooocon2006/presentations/wednesday_c10.pdf developer survey]<br />
<br />
* Help prepare and deliver presentations and [[Publications about Octave]] at colleges and universities.<br />
<br />
* Create a [[Forum for GNU Octave]].<br />
<br />
== Improve Windows binary packaging ==<br />
<br />
We are currently able to build and provide a [[Windows Installer|installer for Windows]]. The build process involves cross-compiling on a Linux system using a fork of the [http://mxe.cc/ MXE] project to build Octave and all of its dependencies. Any ideas for improving this process to make it easier or faster, or to improve the installer itself or the installation experience for Windows users would be appreciated.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
== Improve macOS binary packaging ==<br />
<br />
We would like to be able to easily generate binary packages for macOS. Right now, it's difficult and tedious to do so. Most OS X users install Octave using one of the source-based package managers such as Homebrew or MacPorts. Any way to help us build a binary package would be appreciated. Required knowledge is understanding how building binaries in macOS works. Our current approach to building binaries for Windows is to cross-compile from a GNU system using [http://mxe.cc/ MXE], something similar may be possible for OS X ([http://lilypond.org/gub/ GUB]?).<br />
<br />
There is a third-party project called [http://octave-app.org "Octave.app"] that creates and distributes macOS builds of Octave as a Mac app bundle. It is built on top of Homebrew and a set of custom Octave-related Homebrew formuale.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. If you choose to work on GUB, Python will be required. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
=Performance=<br />
<br />
* A profiler for Octave would be a very useful tool. And now we have one! But it really needs a better interface.<br />
* Having {{Codeline|parfor}} functioning would speed code development and execution now that multicore architectures are widespread. See [http://octave.1599824.n4.nabble.com/Parfor-td4630575.html here] and [http://stackoverflow.com/questions/24970519/how-to-use-parallel-for-loop-in-octave-or-scilab here]. Existing code from the [[Parallel package | parallel]] and [http://octave.sourceforge.net/mpi/index.html mpi] packages could perhaps be adapted for this.<br />
* Develop a performance benchmark for Octave (interpreter, load/save, plotting, etc., but not simply tests of underlying libraries such as BLAS or LAPACK). This benchmark could be run periodically to make sure that changes during development do not introduce regressions in performance.<br />
<br />
=Packaging=<br />
<br />
* create a system that allows packages to deprecate functions as in core. Possibilities are:<br />
** get pkg to accept a deprecated directory inside the package and add it to the search path. Functions in those directories would have to be treated the same as the ones inside the core deprecated<br />
** PKG_ADD can be used to hack this. Package developers would still have to actually write the warnings on the function code but this would allow to have the functions in a separate directory so they don't foget to remove them on the next release<br />
** the package developer can also use something like Make to create a ''normal'' package from something that actually had a more complex structure, inclusive deprecated directories<br />
* get pkg to resolve dependencies automatically by downloading and installing them too<br />
* allow to download and install multiple versions of the same package<br />
* make the package just a bit more verbose by default (specifics?)<br />
* make pkg a little more like apt-get (what specific features of apt-get is this referring to?)<br />
* make pkg support more than one src directory<br />
** subdirectories with makefiles and top level make command of: cd <subdir> && ${MAKE}... ok as a substitute?<br />
* make pkg able to supply extra configure and make flags, useful for distributions, including -j for make (pkg now passes --jobs=N automatically, CFLAGS and CXXFLAGS environment variables are already respected, what's missing?)<br />
<br />
=Preferences=<br />
<br />
Octave has several functions for managing user preferences. Many function use persistent variables instead of relying upon the preference features.<br />
* The function {{Codeline|edit ()}} contains a persistent structure used as its personal set of preferences. These can all be moved to the user preference group for the editor.<br />
** "EDITOR"<br />
** "HOME"<br />
** "AUTHOR"<br />
** "EMAIL"<br />
** "LICENSE"<br />
** "MODE"<br />
** "EDITINPLACE"<br />
* The {{Codeline|savepath ()}} function modifies the startup script (rcfile), {{Codeline|~/.octaverc}} and inserts commands to allow the next session to begin with the same path. Instead user preference can be created for startup items and a preference for the user specified path can be added. Perhaps two path preferences should be used. One for the elements that should precede the core path and those that should follow. A start up directory preference might also be added to allow the user to specify where Octave should begin the next session.<br />
** "PREPATH"<br />
** "POSTPATH"<br />
** "STARTUPDIR"<br />
* A preference group for plotting can also be added. A preference for the default terminal would be useful for those who want to override the default. Preferences for the default {{Codeline|graphicstoolkit}} can also be added.<br />
** GNUPLOTTERM<br />
** GRAPHICSTOOLKIT<br />
* A preference group for printing can include preferences for the default printer, the ghostscript command, and possibly other parameters like orientation, and resolution.<br />
** PRINTER<br />
** GHOSTSCRIPTCOMMAND<br />
** ORIENTATION<br />
** RESOLUTION<br />
* Searching the m-files for use of {{Codeline|persistent}} should turn up other opportunities to use preferences.<br />
<br />
=Bugs=<br />
<br />
There are always bugs to fix. The [https://savannah.gnu.org/bugs/?group=octave bug tracker] is a good place to find tasks needing a hand. See also [[Short projects#Bugs]].<br />
<br />
= Matlab compatibility =<br />
<br />
== Missing functions ==<br />
<br />
There are certain functions present in MATLAB known to be missing in Octave.<br />
<br />
One list is provided on the source for function __unimplemented.m__, subfunction missing_functions; it can be edited in the Octave GUI or browsed at [http://hg.savannah.gnu.org/hgweb/octave/file/default/scripts/help/__unimplemented__.m#l547].<br />
<br />
Lists are also kept for [[:Category:Missing functions|several packages]].<br />
<br />
It is also possible to look at existing [[Wikipedia:Free and open-source software|FOSS]] implementations, from FreeMat and Scilab (for more closely compatible languages) to R or Scipy or Julia (for less compatible versions). Obviously, it is NOT OK to look at the Matlab implementation since this is not [[Wikipedia:Free software|free software]]!<br />
<br />
== Functions under different name ==<br />
<br />
Many Octave Forge functions perform the same as functions from matlab packages. However, they often exist under a different name or have incompatible API's. Often fixing this is a matter of changing their names, swap the order of their input arguments. At least, a list of this functions would be helpful.<br />
<br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Project Ideas]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Projects&diff=13331Projects2020-09-16T01:24:23Z<p>Siko1056: /* Matlab-compatible ODE solvers in core-Octave */ Strip finished items.</p>
<hr />
<div>The list below summarizes features or bug fixes we would like to see in Octave. This list is not exclusive -- there are many other things that might be good projects, but it might instead be something we already have. Also, some of the following items may not actually be considered good ideas now.<br />
<br />
{{Note|If you never contributed to Octave before, we suggest to start with our [[Developer FAQ]].}}<br />
<br />
* Summer of Code students, please also see [[Summer of Code - Getting Started]].<br />
* If you're looking for small project, see [[short projects]].<br />
<br />
=Numerical=<br />
<br />
* Use C++11 <random> libraries for random number generation. Write link between Octave functions (rand, randi, randn, rande) and C++ API. Implement RandStream objects as Matlab does.<br />
<br />
*Improve logm, and sqrtm (see this thread: http://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html)<br />
<br />
*Use pairwise addition in sum() to mitigate against numerical errors without substantial performance penalty (https://en.wikipedia.org/wiki/Pairwise_summation).<br />
<br />
*Review implementing algorithm in this 2009 paper (https://epubs.siam.org/doi/pdf/10.1137/080738490) for xsum (sum with extra accuracy). The existing implementation uses a 2005 paper.<br />
<br />
*Improve complex mapper functions. See W. Kahan, ``Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit (in The State of the Art in Numerical Analysis, eds. Iserles and Powell, Clarendon Press, Oxford, 1987) for explicit trigonometric formulae. See {{patch|8172}} for a previous attempt.<br />
<br />
*Make functions like gamma() return the right IEEE Inf or NaN values for extreme args or other undefined cases.<br />
<br />
*Improve sqp.<br />
<br />
*Fix CollocWt? to handle Laguerre polynomials. Make it easy to extend it to other polynomial types.<br />
<br />
*Add optional arguments to colloc so that it's not restricted to Legendre polynomials.<br />
<br />
*Move rand, eye, xpow, xdiv, etc., functions to the matrix classes.<br />
<br />
*Improve design of ODE, DAE, classes.<br />
<br />
*Make QR more memory efficient for large matrices when not all the columns of Q are required (apparently this is not handled by the lapack code yet).<br />
<br />
*Evaluate harmonics and cross-correlations of unevenly sampled and nonstationary time series, as in http://www.jstatsoft.org/v11/i02 (which has C code with interface to R). (This is now partly implemented in the [http://octave.sourceforge.net/lssa/index.html lssa] package.)<br />
<br />
<!-- == General purpose Finite Element library ==<br />
<br />
Octave-Forge already has a set of packages for discretizing Partial Differential operators by Finite Elements and/or Finite Volumes,<br />
namely the [[bim package]] which relies on the [http://octave.sf.net/msh msh package] (which is in turn based on [http://geuz.org/gmsh/ gmsh]) for creating and managing 2D triangular and 3D tetrahedral meshes and on the [http://octave.sf.net/fpl fpl package] for visualizing 2D results within Octave or exporting 2D or 3D results in a format compatible with [http://www.paraview.org Paraview] or [https://wci.llnl.gov/codes/visit/ VisIT]. These packages, though, offer only a limited choice of spatial discretization methods which are based on low degree polynomials and therefore have a low order of accuracy even for problems with extremely smooth solutions.<br />
The [http://geopdes.sf.net GeoPDEs] project, on the other hand, offers a complete suite of functions for discretizing a wide range of<br />
differential operators related to important physical problems and uses basis functions of arbitrary polynomial degree that allow the construction of methods of high accuracy. These latter, though, are based on the IsoGeometric Analysis Method which, although very powerful and often better performing, is less widely known and adopted than the Finite Elements Method. The implementation of a general purpose library of Finite Elements seems therefore a valuable addition to Octave-Forge. Two possible interesting choices for implementing this package exist, the first consists of implementing the most common Finite Element spaces in the [http://geopdes.sf.net GeoPDEs] framework, which is possible as IsoGeometric Analysis can be viewed as a superset of the Finite Element Method, the other is to construct Octave language bindings for the free software library [http://fenicsproject.org/documentation/ FEniCS] based on the existing C++ or Python interfaces. This second approach has been developed during the GSOC 2013 and the Octave-Forge package [http://octave.sf.net/fem-fenics fem-fenics] is now available. However, fem-fenics could be extended in many different ways:<br />
* implement the bindings for the UFL language inside Octave<br />
* add new functions already available with Fenics but not yet in Octave<br />
* create new functions specifically suited for Octave<br />
* improve the efficiency of the code<br />
The main goal for the fem-fenics package is ultimately to be merged with the FEnics project itself, so that it can remain in-sync with the main library development. --><br />
<br />
== Implement solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D ==<br />
<br />
The project will deliver a solver for initial-boundary value problems for parabolic-elliptic PDEs in 1D similar to Matlab's function <tt>pdepe</tt>. A good starting point is the [http://en.wikipedia.org/wiki/Method_of_lines method of lines] for which you can find more details [http://en.wikibooks.org/wiki/Partial_Differential_Equations/Method_of_Lines here] and [http://www.scholarpedia.org/article/Method_of_lines here], whereas an example implementation can be found [http://www.scholarpedia.org/article/Method_of_Lines/Example_Implementation here]. In addition, [http://www.pdecomp.net/ this page] provides some useful material.<br />
<br />
== Implement solver for 1D nonlinear boundary value problems ==<br />
<br />
The project will complete the implementation of the bvp4c solver that is already available in an initial version in the odepkg package<br />
by adding a proper error estimator and will implement a matlab-compatible version of the bvp5c solver.<br />
Details on the methods to be implemented can be found in [http://dx.doi.org/10.1145/502800.502801 this paper] on bvp4c and [http://www.jnaiam.net/new/uploads/files/014dde86eef73328e7ab674d1a32aa9c.pdf this paper] on bvp5c. Further details are available in [http://books.google.it/books/about/Nonlinear_two_point_boundary_value_probl.html?id=s_pQAAAAMAAJ&redir_esc=y this book].<br />
<br />
<!-- == Geometric integrators for Hamiltonian Systems ==<br />
<br />
[http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration Geometric (AKA Symplectic) integrators] are useful for <br />
multi-dimensional classical mechanics problems and for molecular dynamics simulations.<br />
The odepkg package has a number of solvers for ODE, DAE and DDE problems but none of them is currently<br />
specifically suited for second order problems in general and Hamiltonian systems in particular.<br />
Therefore a new package for geometric integrators would be a useful contribution.<br />
This could be created as new package or added as a set of new functions for odepkg.<br />
The function interface should be consistent throughout the package and should be modeled to follow <br />
that of other functions in odepkg (or that of DASPK and LSODE) but will need specific extensions to accommodate for specific options that only make sense for this specific class of solvers.<br />
An initial list of methods to be implemented includes (but is not limited to)<br />
* Symplectic Euler methods, see [http://en.wikipedia.org/wiki/Semi-implicit_Euler_method here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Störmer-Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Velocity Verlet method, see [http://en.wikipedia.org/wiki/Verlet_integration here] and [http://openlibrary.org/books/OL9056139M/Geometric_Numerical_Integration here]<br />
* Symplectic partitioned Runge-Kutta methods, see [http://reference.wolfram.com/mathematica/tutorial/NDSolveSPRK.html here] or [http://dx.doi.org/10.1137/0733019 here]<br />
* Spectral Variational Integrator methods, see [http://www3.nd.edu/~izaguirr/papers/acta_numerica.pdf here] or [http://www.math.ucsd.edu/~mleok/pdf/HaLe2012_SVI.pdf here]<br />
<br />
For this latter there is an existing code which is already working but needs to be improved, posted on the patch tracker.<br />
Furthermore, methods to implement solutions of problems with rigid constraints should be implemented, e.g.<br />
* SHAKE, see [http://en.wikipedia.org/wiki/Constraint_algorithm here] or [http://dx.doi.org/10.1016/0021-9991(77)90098-5 here]<br />
* RATTLE, see [http://dx.doi.org/10.1016/0021-9991(83)90014-1 here] or [http://dx.doi.org/10.1002/jcc.540161003 here]<br />
--><br />
<br />
== Matlab-compatible ODE solvers in core-Octave ==<br />
<br />
* Improve handling of sparse Jacobians in IDE/DAE solvers<br />
** Currently, in the IDA wrapper function __ode15__ an over conservative guess for the amount of memory to be allocated when assembling a sparse jacobian is used, essentially allocating enough space for a full jacobian then freeing the excess memory, an initial patch for fixing this has been posted on the tracker, for integrating this into Octave it must be generalized to support prior versions of SUNDIALS<br />
** Currently Jacobians passed by the user in Octave's sparse matrix format are copied into SUNDIALS own sparse matrix format. Newer versions of SUNDIALS (5.x or higher) support letting the user take care of the linear algebra data structures and methods thus removing the need for the copy. Taking advantage of this feature would improve the solver performance both in terms of memory footprint and speed.<br />
** References<br />
***[https://savannah.gnu.org/bugs/?func=detailitem&item_id=55905 tracker post about memory allocation] <br />
***[https://computing.llnl.gov/projects/sundials/release-history SUNDIALS release history]<br />
* Implement Matlab compatible versions of "deval".<br />
* Complete transition of ode23s into core Octave<br />
** [https://savannah.gnu.org/bugs/?57309 Bug tracker entry discussing ode23s]<br />
<br />
== High Precision Arithmetic Computation ==<br />
<br />
The Linear Algebra Fortran libraries used by Octave make use of of single (32 bits) and double (64 bits) precision floating point numbers. Many operations are stopped when matrices condition number goes below 1e-16: such matrices are considered as ill-conditioned. There are cases where this is not enough, for instance simulations implying chemical concentrations covering the range 10^4 up to 10^34. There are a number of ways to increase the numerical resolution, like f.i. make use of 128 bits quadruple precision numbers available in GFortran. A simpler option is to build an interface over Gnu MPL arbitrary precision library, which is used internally by gcc and should be available on any platform where gcc runs. Such approach has been made available for MatLab under the name mptoolbox and is licensed under a BSD license. The author kindly provided a copy of the latest version and agreed to have it ported under Octave and re-distributed under GPL v3.0<br />
<br />
The architecture consists of an Octave class interface implementing "mp" (multi-precision) objects. Arithmetic operations are forwarded to MPL using MEX files. This is totally transparent to the end user, except when displaying numbers. This implementation needs to be ported and tested under Octave.<br />
<br />
=GUI/IDE=<br />
<br />
*Søren Hauberg has suggested that we need C++ code that can:<br />
**Determine if a line of code could be fully parsed, i.e. it would return true for "plot (x, y);", but false for "while (true)".<br />
**Evaluate a line of code and return the output as a string (it would be best if it could provide three strings: output, warnings and errors).<br />
**Query defined variables, i.e. get a list of currently defined variables. Bonus points if it could tell you if anything had changed since the last time you checked the variables (could also be done with signals).<br />
* Create a better (G)UI for the {{manual|profile|profiler}}. This may be done with Qt, but not necessarily.<br />
<br />
== GUI Variable Editor and Property Inspector ==<br />
<br />
Octave has a preliminary implementation of a Variable Editor: a spreadsheet-like tool for quickly editing and visualizing variables. The initial phase of the project will be learning how the implementation was done.<br />
<br />
With the knowledge gained, the second part of the project will be to implement a Property Inspector. This is a spreadsheet like interface to the many, many graphics properties that exist and are different on a per-object basis. The goal would be not only the concise-display of the existing properties, but a reasonable user interface to change them. As examples, Boolean properties should be able to be toggled with a double-click; Radio properties should have a drop-down list of only the supported options; Other properties that can be modified should have the constraints built-in (for example, Linewidth must be a scalar, while Position must be a 1x4 vector). It would also be important to have easy access to the documentation of a property.<br />
<br />
For reference, Matlab has a similar Property Inspector (https://www.mathworks.com/help/matlab/ref/inspect.html).<br />
<br />
== Sisotool. Create a graphical design tool for tuning closed loop control system ([[Control package]])==<br />
<br />
When tuning a SISO feedback system it is very helpful to be able to grab a pole or a zero and move them by dragging them with the mouse. As they are moving the software must update all the plotted lines. There should be the ability to display various graphs rlocuse, bode, step, impulse etc. and have them all change dynamically as the mouse is moving. The parameters of the compensator must be displayed and updated.<br />
Recently, some implementation was done during [[Summer_of_Code#GSoC_2018|GSoC 2018]], see https://eriveltongualter.github.io/GSoC2018/final.html for details.<br />
<br />
=Sparse Matrices=<br />
<br />
The paper by [http://arxiv.org/abs/cs.MS/0604006 Bateman & Adler] is good reading for understanding the sparse matrix implementation.<br />
<br />
*Improve Matlab compatibility for {{manual|sprandsym}}.<br />
<br />
*Sparse logical indexing in idx_vector class so that something like <code>a = sprandn (1e6, 1e6, 1e-6); a(a<1) = 0;</code> won't cause a memory overflow.<br />
<br />
*Other missing Functions<br />
**lsqr<br />
**minres<br />
**symmlq<br />
<br />
== SPQR Interface ==<br />
<br />
Octave implements QR factorization for sparse matrices, but it does so with an older "CXSPARSE" library. This has caused fundamental issues, including segfaults as recorded here (bugs {{bug|51950}} and {{bug|57033}}). The goal of this project is to program an interface to the API for the SQPR library (http://faculty.cse.tamu.edu/davis/suitesparse.html). This is the same library that Matlab uses for this purpose.<br />
<br />
*Improve QR factorization functions, using idea based on CSPARSE cs_dmsol.m<br />
<br />
*Improve QR factorization by replacing CXSPARSE code with SPQR code, and make the linear solve return 2-norm solutions for ill-conditioned matrices based on this new code<br />
<br />
=Strings=<br />
<br />
*Consider making octave_print_internal() print some sort of text representation for unprintable characters instead of sending them directly to the terminal. (But don't do this for fprintf!)<br />
<br />
*Consider changing the default value of `string_fill_char' from SPC to NUL.<br />
<br />
=Other Data Types=<br />
<br />
*Template functions for mixed-type ops.<br />
<br />
*Convert other functions for use with the floating point type including quad, dasrt, daspk, etc.<br />
<br />
=Input/Output=<br />
<br />
*Make fread and fwrite work for complex data. Iostreams based versions of these functions would also be nice, and if you are working on them, it would be good to support other size specifications (integer*2, etc.).<br />
<br />
*Move some pr-output stuff to liboctave.<br />
<br />
*Make the cutoff point for changing to packed storage a user-preference variable with default value 8192.<br />
<br />
*Complain if there is not enough disk space available (I think there is simply not enough error checking in the code that handles writing data).<br />
<br />
*Make it possible to tie arbitrary input and output streams together, similar to the way iostreams can be tied together.<br />
<br />
*Expand {{codeline|imwrite}} options. This shouldn't be too hard to implement, since it's wrapped around GraphicsMagick.<br />
<br />
*Extend Octave functions to work on stored arrays that are too big to fit in RAM, similar to available R [http://www.bigmemory.org/ packages.]<br />
<br />
* write {{codeline|xmlread}} and {{codeline|xmlwrite}}. This could be done using [http://xerces.apache.org/xerces-c/ Xerces C++ interface] which apparently is what [http://octave.1599824.n4.nabble.com/xml-in-octave-td4663034.html Matlab uses].<br />
<br />
* Implement hdf5 for .mat files (see [http://octave.1599824.n4.nabble.com/Reading-Matlab-td4650158.html this thread]).<br />
<br />
=Interpreter=<br />
<br />
The interpreter is written in C++, undocumented. There are many possible projects associated with it.<br />
<br />
'''Required skills''': ''Very good'' C and C++ knowledge, possibly also understanding of [http://en.wikipedia.org/wiki/Gnu_bison GNU bison] and [http://en.wikipedia.org/wiki/Flex_lexical_analyser flex]. Understanding how compilers and interpreters are made plus being able to understand how to use a profiler and a debugger will probably be essential skills.<br />
<br />
*Allow customization of the debug prompt.<br />
<br />
*Fix the parser so that<br />
<br />
if (expr) 'this is a string' end<br />
<br />
is parsed as IF expr STRING END. ''(see [https://lists.gnu.org/archive/html/octave-maintainers/2014-03/msg00087.html this] post on the mailing list)''<br />
<br />
*Clean up functions in input.cc that handle user input (there currently seems to be some unnecessary duplication of code and it seems overly complex).<br />
<br />
*Consider allowing an arbitrary property list to be attached to any variable. This could be a more general way to handle the help string that can currently be added with `document'.<br />
<br />
*Allow more command line options to be accessible as built-in variables (--echo-commands, etc.).<br />
<br />
*Make the interpreter run faster.<br />
<br />
*Allow arbitrary lower bounds for array indexing.<br />
<br />
*Improve performance of recursive function calls.<br />
<br />
*Improve the way ignore_function_time_stamp works to allow selecting by individual directories or functions.<br />
<br />
*Add a command-line option to tell Octave to just do syntax checking and not execute statements.<br />
<br />
*Clean up symtab and variable stuff.<br />
<br />
*Input stream class for parser files -- must manage buffers for flex and context for global variable settings.<br />
<br />
*make parser do more semantic checking, continue after errors when compiling functions, etc.<br />
<br />
*Make LEXICAL_ERROR have a value that is the error message for parse_error() to print?<br />
<br />
*Add a run-time alias mechanism that would allow things like alias fun function_with_a_very_long_name so that `function_with_a_very_long_name' could be invoked as `fun'.<br />
<br />
*Allow local changes to variables to be written more compactly than is currently possible with unwind_protect. For example, <br />
<br />
function f ()<br />
local prefer_column_vectors = something;<br />
...<br />
endfunction<br />
<br />
<br />
would be equivalent to<br />
<br />
function f ()<br />
save_prefer_column_vectors = prefer_column_vectors;<br />
unwind_protect<br />
prefer_column_vectors = something;<br />
...<br />
unwind_protect_cleanup<br />
prefer_column_vectors = save_prefer_column_vectors;<br />
end_unwind_protect<br />
endfunction<br />
<br />
<br />
*Fix all function files to check for bogus inputs (wrong number or types of input arguments, wrong number of output arguments).<br />
<br />
*Handle options for built-in functions more consistently.<br />
<br />
*Too much time is spent allocating and freeing memory. What can be done to improve performance?<br />
<br />
Use move constructors rather than copy constructors for things like dim_vectors which are repeatedly created just to initialize Array or Matrix objects.<br />
<br />
*Error output from Fortran code is ugly. Something should be done to make it look better.<br />
<br />
*It would be nice if output from the Fortran routines could be passed through the pager.<br />
<br />
*Attempt to recognize common subexpressions in the parser.<br />
<br />
*Consider making it possible to specify an empty matrix with a syntax like [](e1, e2). Of course at least one of the expressions must be zero...<br />
<br />
*Is Matrix::fortran_vec() really necessary?<br />
<br />
*Rewrite whos and the symbol_record_info class. Write a built-in function that gives all the basic information, then write who and whos as M-files.<br />
<br />
*On systems that support matherr(), make it possible for users to enable the printing of warning messages.<br />
<br />
*Make it possible to mark variables and functions as read-only.<br />
<br />
*Make it possible to write a function that gets a reference to a matrix in memory and change one or more elements without generating a second copy of the data.<br />
<br />
*Use nanosleep instead of usleep if it is available? Apparently nanosleep is to be preferred over usleep on Solaris systems.<br />
<br />
*<strike>Per the following discussion, allow bsxfun style singleton dimension expansion as the default behavior for the builtin element-wise operators: http://octave.1599824.n4.nabble.com/Vector-approach-to-row-margin-frequencies-tp1636361p1636367.html</strike> This is done. <strike>Now [[User:JordiGH|I]] just have to document it.</strike> This is done too!<br />
<br />
== Improve JIT compiling ==<br />
<br />
Octave's interpreter is ''very'' slow on some loops. Recently, thanks to Max Brister's work, an initial implementation of a just-in-time compiler (JITC) in [http://llvm.org LLVM] for GSoC 2012. This project consists in understanding Max's current implementation and extending it so that functions and exponents (e.g. 2^z) compile with the JITC. This requires knowledge of compilers, C++, LLVM, and the Octave or Matlab languages. A capable student who demonstrates the ability to acquire this knowledge quickly may also be considered. Max himself will mentor this project. [http://planet.octave.org/octconf2012/jit.pdf Here] is Max's OctConf 2012 presentation about his current implementation. See also [[JIT]].<br />
<br />
== Improve memory management ==<br />
<br />
From profiling the interpreter, it appears that a lot of time is spending allocating and deallocating memory. A better memory management algorithm might provide some improvement.<br />
<br />
== Implement classdef classes ==<br />
<br />
Matlab has two kinds of classes: old style @classes and new style classdef. Octave has only fully implemented the old style. There is partial support for classdef classes in version 4.0, refer to the [[Classdef|classdef status page]] for what is not yet implemented. There is irregular work here, and classdef is [http://www.mathworks.com/help/matlab/matlab_oop/method-attributes.html a very] [http://www.mathworks.com/help/matlab/events-sending-and-responding-to-messages.html complicated] [http://www.mathworks.com/help/matlab/enumeration-classes.html thing] to fully implement. A successful project would be to implement enough of classdef for most basic usages. Familiarity with Matlab's current classdef support would be a huge plus. Michael Goffioul and jwe can mentor this.<br />
<br />
Although there's already a substantial classdef support in current octave code base, there are still many areas that are unimplemented or need improvements. The main ones that come to my mind are:<br />
* support for events<br />
* support for enums<br />
* support for "import" (this requires good understanding of octave internals, especially the symbol table)<br />
* improving multiple inheritance and method resolution<br />
* honoring and computing "Sealed" attribute<br />
* support for function handle to methods<br />
<br />
== Improve MPI package ==<br />
<br />
Octave Forge's [http://octave.sourceforge.net/mpi/index.html MPI package] <br />
is a wrapper for basic MPI functions for parallel computing. It is implemented <br />
by wrapping MPI function calls in simple DLD functions that map Octave's Datataypes to <br />
MPI Derived Datatypes. <br />
The proposed project deals with improving and extending the Octave MPI package, for example:<br />
* Octave MPI applications can currently be only run in batch mode, add the ability to launch parallel jobs and collect their output in an interactive Octave session.<br />
* Implement functions for non-blocking communication (MPI_Isend, MPI_Irecv)<br />
* Implement one-to-many (Broadcast, Scatter), many-to-one (Reduce, Gather), and many-to-many (All Reduce, Allgather) communication routines<br />
<br />
=Graphics=<br />
<br />
*Correctly handle case where DISPLAY is unset. Provide --no-window-system or --nodisplay (?) option. Provide --display=DISPLAY option? How will this work with gnuplot (i.e., how do we know whether gnuplot requires an X display to display graphics)?<br />
<br />
* <strike>Implement transparency and lighting in OpenGL backend(s). A basic implementation was available in [http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/jhandles/ JHandles]. This needs to be ported/re-implement/re-engineered/optimized in the C++ OpenGL renderer of octave</strike>.<br />
<br />
* Implement a Cairo-based renderer for 2D-only graphics, with support for PS/PDF/SVG output (for printing).<br />
<br />
* On 'imagesc' plots, report the matrix values also based on the mouse position, updating on mouse moving.<br />
<br />
* Add map-creating capabilities similar to the Matlab [http://www.mathworks.com/help/map/functionlist.html Mapping toolbox] for inclusion in the Octave Forge [https://sourceforge.net/p/octave/mapping mapping package].<br />
<br />
* Add data cursor to trace data values in figure.<br />
<br />
== Lighting ==<br />
<br />
<strike>Implement transparency and lighting in OpenGL backend(s). A basic implementation is available in [http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/jhandles/ JHandles]. This needs to be ported/re-implement/re-engineered/optimized in the C++ OpenGL renderer of Octave.</strike><br />
<br />
== Object selection in OpenGL renderer ==<br />
<br />
<strike>This project is about the implementation of a selection method of graphics elements within the OpenGL renderer [http://glprogramming.com/red/chapter13.html]</strike><br />
<br />
== Non-OpenGL renderer ==<br />
<br />
Besides the original gnuplot backend, Octave also contains an OpenGL-based renderer for advanced and more powerful 3D plots. However, OpenGL is not perfectly suited for 2D-only plots where other methods could result in better graphics. The purpose of this project is to implement an alternate graphics renderer for 2D only plots (although 3D is definitely not the focus, extending the new graphics renderer to support basic 3D features should also be taken into account). There is no particular toolkit/library that must be used, but natural candidates are:<br />
* [http://qt.nokia.com Qt]: the GUI is currently written in Qt <strike>and work is also in progress to provide a Qt/OpenGL based backend [https://github.com/goffioul/QtHandles]</strike><br />
* [http://en.wikipedia.org/wiki/Cairo_%28software%29 Cairo]: this library is widely used and known to provides high-quality graphics with support for PS/PDF/SVG output.<br />
<br />
== LaTeX markup ==<br />
<br />
Text objects in plots (like titles, labels, texts...) in the OpenGL renderer only support plain text and TeX. The latter consists of a very limited subset of the TeX language. On the other hand, the LaTeX formatting support is expected to provide full LaTeX capabilities. There are various approaches that can be used:<br />
* Use an external LaTeX engine: this is the most straightforward, but it requires users to install a LaTeX distribution and setup Octave to use it.<br />
* Use an external library that supports LaTeX syntax, e.g. [http://forge.scilab.org/index.php/p/jlatexmath/ JLaTeXMath] a Java API to display LaTeX code, [https://github.com/nathancarter/qtmathjax qtmathjax] a Qt based library that executes MathJax in a background web page.<br />
* Implement our own LaTeX parser and renderer. The matplotlib project [http://matplotlib.sourceforge.net/users/usetex.html has already done this in Python] and might be used as an example of how to do this in Octave. There is also [https://github.com/jkriege2/JKQtPlotter JKQtPlotter], a Qt based plotting application which implements its own LaTeX parser/renderer in C++.<br />
<br />
=History=<br />
<br />
*Add an option to allow saving input from script files in the history list.<br />
<br />
*The history command should accept two numeric arguments to indicate a range of history entries to display, save or read.<br />
<br />
*Avoid writing the history file if the history list has not changed.<br />
<br />
*Avoid permission errors if the history file cannot be opened for writing.<br />
<br />
*Fix history problems — core dump if multiple processes are writing to the same history file?<br />
<br />
=Configuration and Installation=<br />
<br />
*Makefile changes:<br />
**eliminate for loops<br />
**define shell commands or eliminate them<br />
**consolidate targets<br />
<br />
*Create a docs-only distribution?<br />
<br />
*<strike> Convert build system to a non-recursive Automake setup. See how Makefile.am files currently include module.mk files in subdirectories, extend this concept to the entire project so there is only one top-level Makefile.am. </strike> Done, except for special dir libgnu which is the only SUBDIRS listed in configure.ac.<br />
<br />
=Documentation=<br />
:''See [[Project - Documentation]].''<br />
<br />
=Tests=<br />
*Improved set of tests: [http://octave.1599824.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=370633]<br />
**Tests for various functions. Would be nice to have a test file corresponding to every function (see below)<br />
**Tests for element by element operators: + - .* ./ .\ .^ | & < <= == >= > != !<br />
*** thorough tests for power operator including corner cases and strange combinations such as complex .^ range.<br />
**Tests for boolean operators: && ||<br />
**Tests for other operators: * / \ ' .'<br />
**Tests from bug reports.<br />
**Tests for indexed assignment. Need to consider the following:<br />
***fortran-style indexing<br />
***zero-one indexing<br />
***assignment of empty matrix as well as values resizing<br />
**Tests for all internal functions.<br />
<br />
* Implement a coverage tool for collecting coverage data and generating code coverage reports on m-file functions and scripts. This would be very useful for Octave development as well as for users who want a code coverage report for their own functions and scripts.<br />
<br />
We are far from even having one test for every function, so focus should be on getting the breadth of coverage first before trying to get the depth of 100% statement coverage. As of Dec 2015, 202 of 1020 m-files have no tests. Some of these will be plotting functions which have demos instead, but that leaves enough functions to be an interesting project. As of Dec 2015, there are 485 instances of C++ functions which need tests.<br />
<br />
After Octave is compiled, running the {{Codeline|make check}} build target will run the full test suite and generate a file called test/fntests.log in the build directory with a summary of the results. At the end of the file is a list of all functions for which no tests were found. An extract is posted in the [[files missing tests]] page. If you are not building Octave yourself, the test suite can be run on an installed binary copy by executing the {{Codeline|__run_test_suite__}} command at the Octave prompt. The fntests.log file will be written in the current directory in this case.<br />
<br />
There also need to be tests for functions written in the C++ files. See [[Add_BIST_tests_for_octave_functions_written_in_C%2B%2B]] for instructions and a list of instances.<br />
<br />
See also [[Continuous Build#Coverage Report]].<br />
<br />
=Programming=<br />
<br />
*Better error messages for missing operators?<br />
<br />
*Eliminate duplicate enums in pt-exp.cc, pt-const.cc, and ov.cc.<br />
<br />
*Handle octave_print_internal() stuff at the liboctave level. Then the octave_value classes could just call on the print() methods for the underlying classes.<br />
<br />
*As much as possible, eliminate explicit checks for the types of octave_value objects so that user-defined types will automatically do the right thing in more cases.<br />
<br />
*Only include config.h in files that actually need it, instead of including it in every .cc file. Unfortunately, this might not be so easy to figure out.<br />
<br />
*GNU coding standards:<br />
**Add a `Makefile' target to the Makefiles.<br />
**Comments on #else and #endif preprocessor commands.<br />
**Change error message format to match standards everywhere.<br />
<br />
*Eliminate more global variables.<br />
<br />
*Move procstream to liboctave.<br />
<br />
*Use references and classes in more places.<br />
<br />
*Share more code among the various _options functions.<br />
<br />
*Use non-empty identifiers in all warnings and errors issued by Octave, see [[Easy projects#Miscellaneous]].<br />
<br />
*Reduce the amount of datatypes in liboctave.<br />
<br />
*Re-implement operators using templates and modern C++. Current system evolved before templates and makes extensive use of macros to define interactions between scalar<->scalar, scalar<->matrix, scalar<->float, etc., etc.<br />
**In liboctave, the directory to work on is liboctave/operators<br />
**In libinterp, the directory to work on is libinterp/operators<br />
**In libinterp, there is also xpow.cc, xdiv.cc in libinterp/corefcn<br />
<br />
=Miscellaneous=<br />
<br />
*Implement some functions for interprocess communication: bind, accept, connect, gethostbyname, etc. (This functionality is already available in the octave sockets package, what is the purpose of moving it to core octave?)<br />
<br />
*The ability to transparently handle very large files: Juhana K Kouhia <kouhia@nic.funet.fi> wrote:<br />
*: If I have a one-dimensional signal data with the size 400 Mbytes, then what are my choices to operate with it:<br />
*:*I have to split the data<br />
*:*Octave has a virtual memory on its own and I don't have to worry about the splitting.<br />
*:If I split the data, then my easily programmed processing programs will become hard to program.<br />
*:If possible, I would like to have the virtual memory system in Octave i.e., the all big files, the user see as one big array or such. There could be several user selectable models to do the virtual memory depending on what kind of data the user have (1d, 2d) and in what order they are processed (stream or random access).<br />
<br />
*An interface to gdb. Michael Smolsky <fnsiguc@weizmann.weizmann.ac.il> wrote:<br />
*:I was thinking about a tool, which could be very useful for me in my numerical simulation work. It is an interconnection between gdb and octave. We are often managing very large arrays of data in our fortran or c codes, which might be studied with the help of octave at the algorithm development stages. Assume you're coding, say, wave equation. And want to debug the code. It would be great to pick some array from the memory of the code you're developing, fft it and see the image as a log-log plot of the spectral density. I'm facing similar problems now. To avoid high c-development cost, I develop in matlab/octave, and then rewrite into c. It might be so much easier, if I could off-load a c array right from the debugger into octave, study it, and, perhaps, change some [many] values with a convenient matlab/octave syntax, similar to <code>a(:,51:250)=zeros(100,200)</code>, and then store it back into the memory of my c code.<br />
<br />
*Implement gdb extensions for Octave types. Octave has the <code>etc/gdbinit</code> file, which has some basic support for displaying the contents of Octave types. Add more extensions to make it easier to debug octave_values and other Octave types.<br />
<br />
*Add a definition to lgrind so that it supports Octave. (See http://www.tex.ac.uk/tex-archive/support/lgrind/ for more information about lgrind.)<br />
<br />
*Spatial statistics, including covariogram estimation and kriging -- perhaps via an interface to [http://www.gstat.org/ gstat]?<br />
<br />
* the [http://octave.sourceforge.net/miscellaneous/function/units.html units] function from the miscellaneous package works by parsing the output of from a call to GNU units. This can be made much more robust by writing it in C++ and including its library "units.h"<br />
<br />
=Marketing and Community=<br />
<br />
* Make the Octave website/[[Project Infrastructure]] easier to maintain.<br />
<br />
* Make it easier for newcomers to contribute.<br />
<br />
* For marketing ideas, see the [https://openoffice.apache.org/orientation/intro-marketing.html Apache Open Office Introduction to Marketing]<br />
<br />
* Help design a user or a [https://www.openoffice.org/marketing/ooocon2006/presentations/wednesday_c10.pdf developer survey]<br />
<br />
* Help prepare and deliver presentations and [[Publications about Octave]] at colleges and universities.<br />
<br />
* Create a [[Forum for GNU Octave]].<br />
<br />
== Improve Windows binary packaging ==<br />
<br />
We are currently able to build and provide a [[Windows Installer|installer for Windows]]. The build process involves cross-compiling on a Linux system using a fork of the [http://mxe.cc/ MXE] project to build Octave and all of its dependencies. Any ideas for improving this process to make it easier or faster, or to improve the installer itself or the installation experience for Windows users would be appreciated.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
== Improve macOS binary packaging ==<br />
<br />
We would like to be able to easily generate binary packages for macOS. Right now, it's difficult and tedious to do so. Most OS X users install Octave using one of the source-based package managers such as Homebrew or MacPorts. Any way to help us build a binary package would be appreciated. Required knowledge is understanding how building binaries in macOS works. Our current approach to building binaries for Windows is to cross-compile from a GNU system using [http://mxe.cc/ MXE], something similar may be possible for OS X ([http://lilypond.org/gub/ GUB]?).<br />
<br />
There is a third-party project called [http://octave-app.org "Octave.app"] that creates and distributes macOS builds of Octave as a Mac app bundle. It is built on top of Homebrew and a set of custom Octave-related Homebrew formuale.<br />
<br />
'''Skills Required''': Knowledge of GNU build systems, Makefiles, configure files, chasing library dependencies, how to use a compiler. If you choose to work on GUB, Python will be required. No m-scripting or C++ necessary, beyond understanding [http://david.rothlis.net/c/compilation_model/ the C++ compilation model].<br />
<br />
=Performance=<br />
<br />
* A profiler for Octave would be a very useful tool. And now we have one! But it really needs a better interface.<br />
* Having {{Codeline|parfor}} functioning would speed code development and execution now that multicore architectures are widespread. See [http://octave.1599824.n4.nabble.com/Parfor-td4630575.html here] and [http://stackoverflow.com/questions/24970519/how-to-use-parallel-for-loop-in-octave-or-scilab here]. Existing code from the [[Parallel package | parallel]] and [http://octave.sourceforge.net/mpi/index.html mpi] packages could perhaps be adapted for this.<br />
* Develop a performance benchmark for Octave (interpreter, load/save, plotting, etc., but not simply tests of underlying libraries such as BLAS or LAPACK). This benchmark could be run periodically to make sure that changes during development do not introduce regressions in performance.<br />
<br />
=Packaging=<br />
<br />
* create a system that allows packages to deprecate functions as in core. Possibilities are:<br />
** get pkg to accept a deprecated directory inside the package and add it to the search path. Functions in those directories would have to be treated the same as the ones inside the core deprecated<br />
** PKG_ADD can be used to hack this. Package developers would still have to actually write the warnings on the function code but this would allow to have the functions in a separate directory so they don't foget to remove them on the next release<br />
** the package developer can also use something like Make to create a ''normal'' package from something that actually had a more complex structure, inclusive deprecated directories<br />
* get pkg to resolve dependencies automatically by downloading and installing them too<br />
* allow to download and install multiple versions of the same package<br />
* make the package just a bit more verbose by default (specifics?)<br />
* make pkg a little more like apt-get (what specific features of apt-get is this referring to?)<br />
* make pkg support more than one src directory<br />
** subdirectories with makefiles and top level make command of: cd <subdir> && ${MAKE}... ok as a substitute?<br />
* make pkg able to supply extra configure and make flags, useful for distributions, including -j for make (pkg now passes --jobs=N automatically, CFLAGS and CXXFLAGS environment variables are already respected, what's missing?)<br />
<br />
=Preferences=<br />
<br />
Octave has several functions for managing user preferences. Many function use persistent variables instead of relying upon the preference features.<br />
* The function {{Codeline|edit ()}} contains a persistent structure used as its personal set of preferences. These can all be moved to the user preference group for the editor.<br />
** "EDITOR"<br />
** "HOME"<br />
** "AUTHOR"<br />
** "EMAIL"<br />
** "LICENSE"<br />
** "MODE"<br />
** "EDITINPLACE"<br />
* The {{Codeline|savepath ()}} function modifies the startup script (rcfile), {{Codeline|~/.octaverc}} and inserts commands to allow the next session to begin with the same path. Instead user preference can be created for startup items and a preference for the user specified path can be added. Perhaps two path preferences should be used. One for the elements that should precede the core path and those that should follow. A start up directory preference might also be added to allow the user to specify where Octave should begin the next session.<br />
** "PREPATH"<br />
** "POSTPATH"<br />
** "STARTUPDIR"<br />
* A preference group for plotting can also be added. A preference for the default terminal would be useful for those who want to override the default. Preferences for the default {{Codeline|graphicstoolkit}} can also be added.<br />
** GNUPLOTTERM<br />
** GRAPHICSTOOLKIT<br />
* A preference group for printing can include preferences for the default printer, the ghostscript command, and possibly other parameters like orientation, and resolution.<br />
** PRINTER<br />
** GHOSTSCRIPTCOMMAND<br />
** ORIENTATION<br />
** RESOLUTION<br />
* Searching the m-files for use of {{Codeline|persistent}} should turn up other opportunities to use preferences.<br />
<br />
=Bugs=<br />
<br />
There are always bugs to fix. The [https://savannah.gnu.org/bugs/?group=octave bug tracker] is a good place to find tasks needing a hand. See also [[Short projects#Bugs]].<br />
<br />
= Matlab compatibility =<br />
<br />
== Missing functions ==<br />
<br />
There are certain functions present in MATLAB known to be missing in Octave.<br />
<br />
One list is provided on the source for function __unimplemented.m__, subfunction missing_functions; it can be edited in the Octave GUI or browsed at [http://hg.savannah.gnu.org/hgweb/octave/file/default/scripts/help/__unimplemented__.m#l547].<br />
<br />
Lists are also kept for [[:Category:Missing functions|several packages]].<br />
<br />
It is also possible to look at existing [[Wikipedia:Free and open-source software|FOSS]] implementations, from FreeMat and Scilab (for more closely compatible languages) to R or Scipy or Julia (for less compatible versions). Obviously, it is NOT OK to look at the Matlab implementation since this is not [[Wikipedia:Free software|free software]]!<br />
<br />
== Functions under different name ==<br />
<br />
Many Octave Forge functions perform the same as functions from matlab packages. However, they often exist under a different name or have incompatible API's. Often fixing this is a matter of changing their names, swap the order of their input arguments. At least, a list of this functions would be helpful.<br />
<br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Project Ideas]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Summer_of_Code_-_Getting_Started&diff=13330Summer of Code - Getting Started2020-09-16T01:21:15Z<p>Siko1056: /* Jupyter Notebook Integration */ Update project.</p>
<hr />
<div>The following is distilled from the [[Projects]] page for the benefit of potential [https://summerofcode.withgoogle.com Google] and [https://socis.esa.int/ ESA] Summer of Code (SoC) students. Although students are welcome to attempt any of the projects in that page or any of their own choosing, here we offer some suggestions on what good student projects might be.<br />
<br />
You can also take a look at last years [[Summer of Code]] projects for inspiration.<br />
<br />
= Steps Toward a Successful Application =<br />
<br />
== Help Us Get To Know You == <br />
* If you aren't communicating with us before the application is due, your application will not be accepted.<br />
*:* '''Join the [https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers mailing list]''' or read the archives and see what topics we discuss and how the developers interact with each other.<br />
*:* '''Hang out in our [https://webchat.freenode.net/?channels=#octave IRC channel]'''. Ask questions, answer questions from users, show us that you are motivated, and well-prepared. There will be more applicants than we can effectively mentor, so do ask for feedback on your public application to increase the strength of your proposal!<br />
* '''Do not wait for us to tell you what to do'''<br />
*: You should be doing something that interests you, and should not need us to tell you what to do. Similarly, you shouldn't ask us what to do either.<br />
*:* When you email the list and mentors, do not write it to say in what project you're interested. Be specific about your questions and clear on the email subject. For example, do not write an email with the subject "GSoC student interested in the ND images projects". Such email is likely be ignored. Instead, show you are already working on the topic, and email "Problem implementing morphological operators with bitpacked ND images".<br />
*:* It is good to ask advice on how to solve something you can't but you must show some work done. Remember, we are mentors and not your boss. Read [http://www.catb.org/esr/faqs/smart-questions.html How to ask questions the smart way]: <blockquote>''Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate that having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.''</blockquote><br />
*:* It can be difficult at the beginning to think on something to do. This is nature of free and open source software development. You will need to break the mental barrier that prevents you from thinking on what can be done. Once you do that, you will have no lack of ideas for what to do next.<br />
*:* Use Octave. Eventually you will come across something that does not work the way you like. Fix that. Or you will come across a missing function. Implement it. It may be a hard problem (they usually are). While solving that problem, you may find other missing capabilities or smaller bug fixes. Implement and contribute those to Octave.<br />
*:* Take a look at the [[Short projects]] for something that may be simple to start with.<br />
<br />
== Find Something That Interests You == <br />
*: It's '''critical''' that you '''find a project that excites you'''. You'll be spending most of the summer working on it (we expect you to treat the SoC as a full-time job).<br />
*: Don't just tell us how interested you are, show us that you're willing and able to '''contribute''' to Octave. You can do that by [https://savannah.gnu.org/bugs/?group=octave fixing a few bugs] or [https://savannah.gnu.org/patch/?group=octave submitting patches] well before the deadline, in addition to regularly interacting with Octave maintainers and users on the mailing list and IRC. Our experience shows us that successful SoC students demonstrate their interest early and often.<br />
== Prepare Your Proposal With Us ==<br />
*: By working with us to prepare your proposal, you'll be getting to know us and showing us how you approach problems. The best place for this is your Wiki user page and the [https://webchat.freenode.net/?channels=#octave IRC channel].<br />
== Complete Your Application ==<br />
*: Fill out our '''''public''''' application template.<br />
*:* This is best done by '''[[Special:CreateAccount|creating an account at this wiki]]''', and copying the '''[[Template:Student_application_template_public|template]]''' from its page.<br />
*:* You really only need to copy and answer the '''''public''''' part there, there is no need to showcase everything else to everybody reading your user page!<br />
*: Fill out our '''''private''''' application template.<br />
*:* This is best done by copying the '''[[Template:Student_application_template_private|template]]''' from its page and '''adding the required information to your application at Google (melange)''' or at '''ESA'''.<br><br />
*:* Only the organization admin and the possible mentors will see this data. You can still edit it after submitting until the deadline!<br />
<br />
== Things You'll be Expected to Know or Quickly Learn On Your Own ==<br />
<br />
Octave is mostly written in C++ and its own scripting language that is mostly compatible with Matlab. There are bits and pieces of Fortran, Perl, C, awk, and Unix shell scripts here and there. In addition to being familiar with C++ and Octave's scripting language, successful applicants will be familiar with or able to quickly learn about Octave's infrastructure. You can't spend the whole summer learning how to build Octave or prepare a changeset and still successfully complete your project.<br />
<br />
* '''The Build System'''<br />
*: [http://en.wikipedia.org/wiki/GNU_build_system The GNU build system] is used to build Octave.<br />
*: While you generally don't need to understand too much unless you actually want to change how Octave is built, you should be able to understand enough to get a general idea of how to build Octave.<br />
*: If you've ever done a {{Codeline|./configure && make && make install}} series of commands, you have already used the GNU build system.<br />
*: '''You must demonstrate that you are able to build the development version of Octave from sources before the application deadline.''' Linux is arguably the easiest system to work on. Instructions:<br />
*:* [[Building]]<br />
*:* [https://octave.org/doc/interpreter/Installation.html Octave Manual on Installing Octave]<br />
* '''The Version Control System'''<br />
*: We use [https://www.mercurial-scm.org/ Mercurial] (abbreviated hg).<br />
*: Mercurial is the [http://en.wikipedia.org/wiki/Distributed_Version_Control_System distributed version control system] (DVCS) we use for managing our source code. You should have some basic understanding of how a DVCS works, but hg is pretty easy to pick up, especially if you already know a VCS like git or svn.<br />
* '''The Procedure for Contributing Changesets'''<br />
*: You will be expected to follow the same procedures as other contributors and core developers.<br />
*: You will be helping current and future Octave developers by using our standard style for changes, commit messages, and so on. You should also read the same [[Contribution guidelines | contribution]] [https://hg.savannah.gnu.org/hgweb/octave/file/tip/etc/HACKING.md guidelines] we have for everyone.<br />
*: [[Hg_instructions_for_mentors#Mercurial_Tips_for_SoC_students | This page]] describes the procedures students are expected to use to publicly display their progress in a public mercurial repo during their work.<br />
* '''The Maintainers Mailing List'''<br />
*: We primarily use [https://lists.gnu.org/mailman/listinfo/octave-maintainers mailing lists] for communication among developers.<br />
*: The mailing list is used most often for discussions about non-trivial changes to Octave, or for setting the direction of development.<br />
*: You should follow basic mailing list etiquette. For us, this mostly means "do not [https://en.wikipedia.org/wiki/Posting_style#Top-posting top post]".<br />
* '''The IRC Channel'''<br />
*: We also have [http://webchat.freenode.net?channels=octave the #octave IRC channel in Freenode].<br />
*: You should be familiar with the IRC channel. It's very helpful for new contributors (you) to get immediate feedback on ideas and code.<br />
*: Unless your primary mentor has a strong preference for some other method of communication, the IRC channel will likely be your primary means of communicating with your mentor and Octave developers.<br />
* '''The Octave Forge Project'''<br />
*: [https://octave.sourceforge.io/ Octave Forge] is a collection of contributed packages that enhance the capabilities of core Octave. They are somewhat analogous to Matlab's toolboxes.<br />
* '''Related Skills'''<br />
*: In addition, you probably should know '''some''' mathematics, engineering, experimental science, or something of the sort.<br />
*: If so, you probably have already been exposed to the kinds of problems that Octave is used for.<br />
<br />
== Criteria by which applications are judged ==<br />
<br />
These might vary somewhat depending on the mentors and coordinators for a particular Summer of Code, but typically the main factors considered would be:<br />
<br />
* '''Applicant has demonstrated an ability to make substantial modifications to Octave'''<br />
*: The most important thing is that you've contributed some interesting code samples to judge you by. It's OK during the application period to ask for help on how to format these code samples, which normally are Mercurial patches.<br />
<br />
* '''Applicant shows understanding of topic'''<br />
*: Your application should make it clear that you're reasonably well versed in the subject area and won't need all summer just to read up on it.<br />
<br />
* '''Applicant shows understanding of and interest in Octave development'''<br />
*: The best evidence for this is previous contributions and interactions.<br />
<br />
* '''Well thought out, adequately detailed, realistic project plan'''<br />
*: "I'm good at this, so trust me" isn't enough. You should describe which algorithms you'll use and how you'll integrate with existing Octave code. You should also prepare a full timeline and goals for the midterm and final evaluations.<br />
<br />
= Suggested projects =<br />
<br />
The following projects are broadly grouped by category and probable skills required to tackle each. Remember to check [[Projects]] for more ideas if none of these suit you, and your own ideas are always welcome. You can also look at our [[Summer of Code|completed past projects]] for more inspiration.<br />
<br />
{{Note|These are suggested projects but you are welcome to propose your own projects provided you find an Octave mentor}}<br />
<br />
== Summary table ==<br />
<br />
{| class="wikitable sortable" style="text-align: center; width:99%"<br />
|-<br />
!Title<br />
!Mentor<br />
!co-Mentors<br />
!Class<br />
!New?<br />
!Difficulty<br />
!Last active<br />
|-<br />
! <br />!! !! !! !! !! !!<br />
|-<br />
| [[Summer of Code - Getting Started#ode15.7Bi.2Cs.7D_:_Matlab_Compatible_DAE_solvers | ode15{i,s} : Matlab Compatible DAE solvers]] || Carlo de Falco || Francesco Faccio, Marco Caliari, Jacopo Corno, Sebastian Schöps || Numerical || No || Medium || GSoC 2016<br />
|-<br />
| [[Summer of Code - Getting Started#Improve_logm.2C_sqrtm.2C_funm | Improve logm, sqrtm, funm]] || ? || Marco Caliari, Mudit Sharma || Numerical || [https://github.com/RickOne16/matrix No] || Hard || Independent devs 2016<br />
|-<br />
| [[Summer of Code - Getting Started#Improve_iterative_methods_for_sparse_linear_systems | Improve iterative methods for sparse linear systems]] || Marco Caliari || Carlo de Falco || Numerical || No || Hard || SOCIS 2016<br />
|-<br />
| [[Summer of Code - Getting Started#EPA_hydrology_software_suite | EPA hydrology software suite]] || [[User:KaKiLa| KaKiLa]] || ? || Octave Forge || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#FullSWOF overland flow simulator | FullSWOF overland flow simulator]] || [[User:KaKiLa| KaKiLa]] || ? || Octave Forge || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#TISEAN_package | TISEAN: Nonlinear Time Series Analysis]] || [[User:KaKiLa|KaKiLa]] || ? || Octave Forge || [[TISEAN_package | No]] || Medium || GSoC 2015<br />
|-<br />
| [[Summer of Code - Getting Started#Octave_Package_management | Octave Package management]] || Sebastian Schöps || [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco || Infrastructure || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#Symbolic_package | Symbolic package]] || Colin B. Macdonald || Mike Miller, Abhinav Tripathi || Octave Forge || [https://github.com/cbm755/octsympy Octsympy] || Medium || GSoC 2016<br />
|-<br />
| [[Summer of Code - Getting Started#OCS | OCS package]] || Sebastian Schöps || Sebastian Schöps || Octave Forge, Numerical || Yes || Easy || Never<br />
|-<br />
| [[Summer of Code - Getting Started#Using_Python_within_Octave | Pythonic package]] || Mike Miller || Colin B. Macdonald, Abhinav Tripathi || Infrastructure || No || Medium || some in GSoC 2016<br />
|-<br />
| [[Summer of Code - Getting Started#Jupyter_Notebook_Integration | Jupyter Notebook Integration]] || Mike Miller || Colin B. Macdonald, [[User:Siko1056|Kai T. Ohlhus]] || Infrastructure || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#Chebfun_in_Octave | Chebfun in Octave]] || Colin B. Macdonald || [[User:KaKiLa|KaKiLa]] || Infrastructure, Numerical || Yes || Hard || Never<br />
|-<br />
| [[Summer of Code - Getting Started#PolarAxes and Plotting Improvements | PolarAxes and Plotting Improvements ]] || ? || Rik || Graphics || Yes || Medium || Never<br />
|}<br />
<br />
== Numerical ==<br />
<br />
These projects involve implementing certain mathematical functions, primarily in core Octave.<br />
<br />
=== ode15{i,s} : Matlab Compatible DAE solvers ===<br />
<br />
An initial implementation of a Matlab compatible ode15{i,s} solver,<br />
based on [http://computation.llnl.gov/projects/sundials SUNDIALS], <br />
was done by Francesco Faccio during<br />
GSOC 2016.<br />
The blog describing the work is [http://gsoc2016ode15s.blogspot.it/ here].<br />
The resulting code has been pushed into the main Octave repository in the development branch and<br />
consists mainly of the following three files<br />
[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/libinterp/dldfcn/__ode15__.cc __ode15__.cc],<br />
[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15i.m ode15i.m] and<br />
[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15s.m ode15s.m].<br />
The list of outstanding tracker tickets concerning this implementation can be found <br />
[https://savannah.gnu.org/search/?Search=Search&words=ode15&type_of_search=bugs&only_group_id=1925&exact=1&max_rows=25#options here]<br />
<br />
Possible useful improvements that could be done in a new project include:<br />
<br />
* Implement a better function for selecting consistent initial conditions compatible with Matlab's decic.m. The algorithm to use is described [http://faculty.smu.edu/shampine/cic.pdf here]<br />
<br />
* make ode15{i,s} with datatypes other than double<br />
<br />
* improve interpolation at intermediate time steps.<br />
<br />
* general code profiling and optimization <br />
<br />
Other tasks, not strictly connected to ode15{i,s} but closely related that could be added <br />
to a possible project plan would be improving documentation and tests in odepkg and removing <br />
overlaps with the documentation in core Octave.<br />
<br />
* '''Required skills'''<br />
: C++; C; familiarity with numerical methods for DAEs; Basic knowledge of makefiles and/or autotools.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Potential mentors'''<br />
: Francesco Faccio, Carlo de Falco, Marco Caliari, Jacopo Corno, Sebastian Schöps<br />
<br />
=== Improve logm, sqrtm, funm ===<br />
<br />
The goal here is to implement some missing Matlab functions related to matrix functions like the [http://en.wikipedia.org/wiki/Matrix_exponential matrix exponential]. There is [http://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html a general discussion] of the problem. A good starting point for available algorithms and open-source implementations is Higham and Deadman's [http://eprints.ma.man.ac.uk/2102/01/covered/MIMS_ep2014_8.pdf "A Catalogue of Software for Matrix Functions"].<br />
<br />
* '''Required skills'''<br />
: Read and Write both C++ and Octave code, find and read research papers, research experience in numerical analysis, familiarity with analysis of algorithms.<br />
* '''Difficulty'''<br />
: Difficult.<br />
* '''Potential mentors'''<br />
: Marco Caliari, Mudit Sharma<br />
<br />
=== Improve iterative methods for sparse linear systems ===<br />
<br />
GNU Octave currently has the following Krylov subspace methods for sparse linear systems: pcg (spd matrices) and pcr (Hermitian matrices), bicg,<br />
bicgstab, cgs, gmres, and qmr (general matrices). The description of some of them (pcr, qmr) and their error messages are not aligned. Moreover, they have similar blocks of code (input check for instance) which can be written once and for all in common functions. The first step in this project could be a revision and a synchronization of the codes, starting from the project [https://socis16octave-improveiterativemethods.blogspot.com/ SOCIS2016] which is already merged into Octave (cset {{cset|6266e321ef22}}).<br />
<br />
In Matlab, some additional methods are available: minres and symmlq (symmetric matrices), bicgstabl (general matrices), lsqr (least<br />
squares). The second step in this project could be the implementation of some of these missing functions.<br />
<br />
The [https://www-users.cs.umn.edu/~saad/IterMethBook_2ndEd.pdf reference book by Yousef Saad] is available online.<br />
<br />
* '''Required skills'''<br />
: numerical linear algebra, m-file programming.<br />
* '''Difficulty'''<br />
: Maybe hard the mathematical part, medium the programming part.<br />
* '''Mentor'''<br />
: Marco Caliari, Carlo de Falco<br />
<br />
=== Chebfun in Octave ===<br />
<br />
[https://www.chebfun.org/ Chebfun] is a mathematics and software project for "numerical computing with functions". Basically it approximates functions to machine precision accuracy (10<sup>-15</sup>) using piecewise Chebyshev polynomial interpolants. Operations on those functions (arithmetic, derivatives, root-finding, etc) are then overloaded and return new interpolating polynomials, which are themselves proxies for the actual solution.<br />
<br />
Chebfun makes extensive use of classdef classes, and is one of the largest Free Software projects to do so. Unfortunately it currently only works in Matlab. This project seeks to (1) improve Octave's classdef support and (2) tweak Chebfun to work under Octave, for example, removing undocumented classdef features. The final goal is to have at least basic Chebfun features working on Octave. An additional goal would be making <code>pkg install chebfun.zip</code> work in Octave.<br />
<br />
The impact of this project is improving Octave and allowing Chebfun to be used without proprietary software.<br />
<br />
How to get started:<br />
<br />
* Learn about [https://www.chebfun.org/ Chebfun]<br />
* Browse [https://savannah.gnu.org/bugs/?group=octave Octave's bug list] for "classdef"-related bugs.<br />
<br />
* Clone this Chebfun [https://github.com/cbm755/chebfun/tree/octave_dev octave_dev branch].<br />
** On that, <code>f = chebfun(@(x) sin(x), [-2 6])</code> should work with Octave 4.3.0+ and maybe even with 4.2.1. Check that <code>f(pi)</code> and <code>g = f + 1</code> work.<br />
** A good first task would be to study [https://github.com/cbm755/chebfun/commit/e20b0ad2dc89cfe8e50ba461b864eff7d5bbef17 this commit], a workaround for <code>f.funs{1}</code> using <code>temp = f.funs; temp{1}</code>. <code>2*f</code> is failing, can you fix it, perhaps with this workaround? Or can you make <code>f.funs{1}</code> work by changing something in <code>@chebfun/subsref.m</code>?<br />
<br />
<br />
* '''Required skills'''<br />
: Octave m-file programming, classdef programming, probably C++, some familiarity with Approximation Theory (a branch of mathematics).<br />
* '''Difficulty'''<br />
: Medium (fixing Octave classdef bugs likely harder and requires a deep dive into how Octave supports OOP).<br />
* '''Potential mentors'''<br />
: Colin B. Macdonald, [[User:KaKiLa|KaKiLa]], Mike Miller (?), Carnë Draug (?), someone from Chebfun team (?).<br />
<br />
== Adding functionality to Forge packages ==<br />
<br />
<br />
=== EPA hydrology software suite ===<br />
Create native interfaces to the EPA software suites.<br />
<br />
Starting points<br />
* [https://forja.cica.es/projects/epanet-octave/ epanet-octave].<br />
* [https://github.com/OpenWaterAnalytics/ Open Water Analytics]<br />
<br />
* '''SWMM'''<br />
** [https://www.epa.gov/water-research/storm-water-management-model-swmm Official page]<br />
** Check work done in [https://github.com/water-systems/MatSWMM MatSWMM] [http://digital.csic.es/bitstream/10261/132982/1/MatSWMM.pdf article]<br />
<br />
* '''EPANET'''<br />
** [https://www.epa.gov/water-research/epanet Official page]<br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, API knowledge, file I/O, classdef (optional). <br />
<br />
* '''Difficulty'''<br />
: easy/medium<br />
<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]]<br />
<br />
=== FullSWOF overland flow simulator ===<br />
Create scripting tools for (optional: native interfaces).<br />
<br />
Starting points<br />
* [https://www.idpoisson.fr/fullswof/ The FullSWOF Project].<br />
* [https://arxiv.org/abs/1204.3210 FullSWOF: A software for overland flow simulation]<br />
* [https://bitbucket.org/binello7/fswof2d Initial work on Bitbucket]<br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, API knowledge, file I/O, classdef (optional). <br />
<br />
* '''Difficulty'''<br />
: easy/medium<br />
<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]]<br />
<br />
=== TISEAN package ===<br />
<br />
[http://www.mpipks-dresden.mpg.de/~tisean/Tisean_3.0.1/index.html TISEAN] is a suite of code for nonlinear time series analysis. It has been [[TISEAN package | partially re-implemented]] as libre software. The objective is to integrate TISEAN as an Octave Forge package, as was done for the Control package.<br />
[[TISEAN_package | A lot has been completed]] but [[TISEAN_package:Procedure | there is still work left to do]].<br />
<br />
There are missing functions to do computations on spike trains, to simulate autoregresive models, to create specialized plots, etc. Do check [[TISEAN_package:Procedure#Table_of_functions|the progress of the project]] to see if you are interested.<br />
<br />
* [http://octave.sourceforge.net/tisean/overview.html Package help at source forge.] <br />
* [https://sourceforge.net/p/octave/tisean/ci/default/tree/ Package repository at source forge.] <br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, and FORTRAN API knowledge. <br />
* '''Difficulty'''<br />
: easy/medium<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]]<br />
<br />
=== Symbolic package ===<br />
<br />
Octave's [https://github.com/cbm755/octsympy Symbolic package] handles symbolic computing and other CAS tools. The main component of Symbolic is a pure m-file class "@sym" which uses the Python package [https://www.sympy.org SymPy] to do (most of) the actual computations. The package aims to expose the full functionality of SymPy while also providing a high-level of compatibility with the Matlab Symbolic Math Toolbox. The Symbolic package requires communication between Octave and Python. Recently, a GSoC2016 project successfully re-implemented this communication using the new [[Pythonic|Pythonic package]].<br />
<br />
This project proposes to go further: instead of using Pythonic only for the communication layer, we'll use it throughout the Symbolic project. For example, we might make "@sym" a subclass of "@pyobject". We also could stop using the "python_cmd" interface and use Pythonic directly from methods. The main goal was already mentioned: to expose the *full functionality* of SymPy. For example, we would allow OO-style method calls such as "f.diff(x)" instead of "diff(f, x)".<br />
<br />
* '''Required skills'''<br />
: OO-programming with m-files, Python, and possibly C/C++ for improving Pythonic (if needed).<br />
* '''Difficulty'''<br />
: easy/medium<br />
* '''Mentors and/or other team members'''<br />
: Colin B. Macdonald, Mike Miller, Abhinav Tripathi<br />
<br />
=== OCS ===<br />
<br />
[[Ocs package | OCS]] is a circuit simulator for Octave. The objective of this project is to update the code to use modern features of Octave (e.g. classdef), [https://savannah.gnu.org/search/?Search=Search&words=%28ocs%29&type_of_search=bugs&only_group_id=1925&exact=1&max_rows=25#options fix open bugs], increase compatibility with SPICE and improve compatibility with other Octave packages (odepkg, control etc).<br />
<br />
* [http://octave.sourceforge.net/ocs/overview.html Package help at source forge.] <br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, and FORTRAN API knowledge. <br />
* '''Difficulty'''<br />
: easy/medium<br />
* '''Mentor'''<br />
: Sebastian Schöps, Carlo de Falco<br />
<br />
== Infrastructure ==<br />
<br />
=== Jupyter Notebook Integration ===<br />
<br />
[http://jupyter.org Jupyter Notebook] is a web-based worksheet interface for computing. There is a [https://github.com/Calysto/octave_kernel Octave kernel for Jupyter]. This project seeks in first place to improve that kernel to make Octave a first-class experience within the Jupyter Notebook.<br />
<br />
In general the [https://nbformat.readthedocs.io/en/latest/ Jupyter Notebook Format] is a plain JSON document, which is supported since Octave 7 (current development version). Another valuable project outcome was to run (and fill) those Jupyter Notebooks from within Octave. This would enable Jupyter Notebook users to evaluate long running Octave Notebooks on a computing server without permanent browser connection, which is [https://github.com/jupyter/notebook/issues/1647 still a pending issue].<br />
<br />
* '''Minimum requirements'''<br />
: Octave and Python programming knowledge.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Mentors'''<br />
: [[User:Siko1056|Kai T. Ohlhus]], Colin B. Macdonald, Mike Miller<br />
<br />
=== Using Python within Octave ===<br />
<br />
[[Pythonic]] allows one to call Python functions and interact with Python objects from within Octave .m file code and from the Octave command line interface. Pythonic may eventually not be a separate package, but rather a core feature of Octave. This project aims to improve Pythonic with the goal of making the package more stable, maintainable, and full-featured.<br />
<br />
Based on a previous summer project related to Pythonic, this work will consist of fast-paced collaborative software development based on tackling the [https://gitlab.com/mtmiller/octave-pythonic/issues Pythonic issue list]. You would also be expected to participate in software design decisions and discussion, as well as improve documentation, doctests, and unit tests. As an example of the sorts of decisions being made, note that Octave indexes from 1 whereas Python typically indexes from 0; in which cases is it appropriate to make this transparent to the user?<br />
<br />
* '''Mentors'''<br />
: Mike Miller, Colin B. Macdonald, Abhinav Tripathi, others?<br />
<br />
<br />
=== Octave Package management ===<br />
<br />
[[Packages]] are extensions for Octave, that are mainly maintained by the [[Octave Forge]] community.<br />
To get those extension to work with Octave, there is a single function, {{manual|pkg}}, which does pretty much everything.<br />
This function has a few limitations which are hard to implement with the current codebase, and will most likely require a full rewrite.<br />
A major step forward for a rewritten package manager is the [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project] by Andrew Janke.<br />
<br />
The planned improvements (see also {{bug|39479}}) are:<br />
<br />
* install and update from repositories (hg and git)<br />
* automatic handling of dependencies<br />
* easily load, update or check specific package versions<br />
* management of tests and demos in C++ sources of packages<br />
* more flexibility on dependencies, e.g., dependent on specific Octave build options or being dependent in one of multiple packages<br />
* support for multiple version packages<br />
* support for multiple Octave installs<br />
* support for system-wide and user installed packages<br />
* testing packages (<code>pkg test <package-name></code>)<br />
* improved metadata acquisition (<code>pkg list -forge</code>) from https://octave.sourceforge.io/<br />
<br />
The main objective of this project is to make {{manual|pkg}} more user friendly and to make it a tool to foster third party participation in Octave.<br />
However, the current {{manual|pkg}} also performs some maintenance functions which it probably should not.<br />
Instead a package for developers should be created with such tools.<br />
To do this enhancement effectively, a refactoring of the current {{codeline|pkg}} code will be needed (see [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project]).<br />
<br />
Many of these problems have been solved in other languages.<br />
Familiarity with how other languages handle this problem will be useful to come up with elegant solutions.<br />
In some cases, there are standards to follow.<br />
For example, there are specifications published by freedesktop.org about where files should go ([http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html base directory spec]) and Windows seems to have its own standards.<br />
See bugs {{bug|36477}} and {{bug|40444}} for more details.<br />
<br />
In addition, package names may start to collide very easily.<br />
One horrible way to workaround this by is choosing increasingly complex package names that give no hint on the package purpose.<br />
A much better is option is providing an Authority category like Perl 6 does.<br />
Nested packages is also an easy way to provide packages for specialized subjects (think {{codeline|image::morphology}}).<br />
A new {{manual|pkg}} would think all this things now, or allow their implementation at a later time.<br />
Read the [[OEP:pkg|unfinished plan]] for more details.<br />
<br />
* '''Minimum requirements'''<br />
: Ability to read and write Octave code, experience with Octave packages, and understanding of the basics of autotools. The most important skill is software design.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco, Sebastian Schöps<br />
<br />
== Image Analysis ==<br />
<br />
=== Improvements to N-dimensional image processing ===<br />
<br />
The image package has partial functionality for N-dimensional images. These images exist for example in medical imaging where slices from scans are assembled to form anatomical 3D images. If taken over time and at different laser wavelengths or light filters, they can also result in 5D images. Albeit less common, images with even more dimensions also exist. However, their existence is irrelevant since most of the image processing operations are mathematical operations which are independent of the number of dimensions.<br />
<br />
As part of GSoC 2013, the core functions for image IO, {{codeline|imwrite}} and {{codeline|imread}}, were extended to better support this type of images. Likewise, many functions in the image package, mostly morphology operators, were expanded to deal with this type of image. Since then, many other functions have been improved, sometimes completely rewritten, to abstract from the number of dimensions. In a certain way, supporting ND images is also related to choosing good algorithms since such large images tend to be quite large.<br />
<br />
This project will continue on the previous work, and be mentored by the previous GSoC student and current image package maintainer. Planning the project requires selection of functions lacking ND support and identifying their dependencies. For example, supporting {{codeline|imclose}} and {{codeline|imopen}} was better implemented by supporting {{codeline|imerode}} and {{codeline|imdilate}} which then propagated ND support to all of its dependencies. These dependencies need to be discovered first since often they are not being used yet, and may even be missing function. This project can also be about implementing functions that have [[Image package#Missing functions | not yet been implemented]]. Also note that while some functions in the image package will accept ND images as input, they are actually not correctly implemented and will give incorrect results.<br />
<br />
* '''Required skills'''<br />
: m-file scripting, and a fair amount of C++ since a lot of image analysis cannot be vectorized. Familiarity with common CS algorithms and willingness to read literature describing new algorithms will be useful. <br />
* '''Difficulty'''<br />
: Difficult.<br />
* '''Potential mentor'''<br />
: Carnë Draug<br />
<br />
=== Improve Octave's image IO ===<br />
<br />
There are a lot of image formats. To handle this, Octave uses [http://www.graphicsmagick.org/ GraphicsMagic] (GM), a library capable of handling [http://www.graphicsmagick.org/formats.html a lot of them] in a single C++ interface. However, GraphicsMagick still has its limitations. The most important are:<br />
<br />
* GM has build option {{codeline|quantum}} which defines the bitdepth to use when reading an image. Building GM with high quantum means that images of smaller bitdepth will take a lot more memory when reading, but building it too low will make it impossible to read images of higher bitdepth. It also means that the image needs to always be rescaled to the correct range.<br />
* GM supports unsigned integers only thus incorrectly reading files such as TIFF with floating point data<br />
* GM hides away details of the image such as whether the image file is indexed. This makes it hard to access the real data stored on file.<br />
<br />
This project would implement better image IO for scientific file formats while leaving GM handle the others. Since TIFF is the de facto standard for scientific images, this should be done first. Among the targets for the project are:<br />
<br />
* implement the Tiff class which is a wrap around libtiff, using classdef. To avoid creating too many private __oct functions, this project could also create a C++ interface to declare new Octave classdef functions.<br />
* improve imread, imwrite, and imfinfo for tiff files using the newly created Tiff class<br />
* port the bioformats into Octave and prepare a package for it<br />
* investigate other image IO libraries<br />
* clean up and finish the dicom package to include into Octave core<br />
* prepare a matlab compatible implementation of the FITS package for inclusion in Octave core<br />
<br />
* '''Required skills'''<br />
: Knowledge of C++ and C since most libraries are written in those languages.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Potential mentor'''<br />
: Carnë Draug<br />
<br />
== Graphics ==<br />
<br />
=== PolarAxes and Plotting Improvements ===<br />
<br />
Octave currently provides supports for polar axes by using a Cartesian 2-D axes and adding a significant number of properties and callback listerners to get things to work. What is needed is a first class implementation of a "polaraxes" object in C++. This will require creating a new fundamental graphics object type, and programming in C++/OpenGL to render the object. When "polaraxes" exist as an object type then m-files will be written to access them including polaraxes.m, polarplot.m, rticks.m, rticklabels.m, thetaticks, thetaticklabels.m, rlim.m, thetalim.m. relates to {{bug|35565}}, {{bug|49804}}, {{bug|52643}}.<br />
<br />
* '''Minimum requirements'''<br />
: Ability to read and write C++ code. Ability to read and write Octave code. Experience with OpenGL programming is optional.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Mentor'''<br />
: Rik <br />
<br />
<noinclude><br />
[[Category:Summer of Code]]<br />
[[Category:Project Ideas]]<br />
</noinclude></div>Siko1056https://wiki.octave.org/wiki/index.php?title=Summer_of_Code_-_Getting_Started&diff=13329Summer of Code - Getting Started2020-09-16T01:16:31Z<p>Siko1056: /* Infrastructure */ JSON project done.</p>
<hr />
<div>The following is distilled from the [[Projects]] page for the benefit of potential [https://summerofcode.withgoogle.com Google] and [https://socis.esa.int/ ESA] Summer of Code (SoC) students. Although students are welcome to attempt any of the projects in that page or any of their own choosing, here we offer some suggestions on what good student projects might be.<br />
<br />
You can also take a look at last years [[Summer of Code]] projects for inspiration.<br />
<br />
= Steps Toward a Successful Application =<br />
<br />
== Help Us Get To Know You == <br />
* If you aren't communicating with us before the application is due, your application will not be accepted.<br />
*:* '''Join the [https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers mailing list]''' or read the archives and see what topics we discuss and how the developers interact with each other.<br />
*:* '''Hang out in our [https://webchat.freenode.net/?channels=#octave IRC channel]'''. Ask questions, answer questions from users, show us that you are motivated, and well-prepared. There will be more applicants than we can effectively mentor, so do ask for feedback on your public application to increase the strength of your proposal!<br />
* '''Do not wait for us to tell you what to do'''<br />
*: You should be doing something that interests you, and should not need us to tell you what to do. Similarly, you shouldn't ask us what to do either.<br />
*:* When you email the list and mentors, do not write it to say in what project you're interested. Be specific about your questions and clear on the email subject. For example, do not write an email with the subject "GSoC student interested in the ND images projects". Such email is likely be ignored. Instead, show you are already working on the topic, and email "Problem implementing morphological operators with bitpacked ND images".<br />
*:* It is good to ask advice on how to solve something you can't but you must show some work done. Remember, we are mentors and not your boss. Read [http://www.catb.org/esr/faqs/smart-questions.html How to ask questions the smart way]: <blockquote>''Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate that having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.''</blockquote><br />
*:* It can be difficult at the beginning to think on something to do. This is nature of free and open source software development. You will need to break the mental barrier that prevents you from thinking on what can be done. Once you do that, you will have no lack of ideas for what to do next.<br />
*:* Use Octave. Eventually you will come across something that does not work the way you like. Fix that. Or you will come across a missing function. Implement it. It may be a hard problem (they usually are). While solving that problem, you may find other missing capabilities or smaller bug fixes. Implement and contribute those to Octave.<br />
*:* Take a look at the [[Short projects]] for something that may be simple to start with.<br />
<br />
== Find Something That Interests You == <br />
*: It's '''critical''' that you '''find a project that excites you'''. You'll be spending most of the summer working on it (we expect you to treat the SoC as a full-time job).<br />
*: Don't just tell us how interested you are, show us that you're willing and able to '''contribute''' to Octave. You can do that by [https://savannah.gnu.org/bugs/?group=octave fixing a few bugs] or [https://savannah.gnu.org/patch/?group=octave submitting patches] well before the deadline, in addition to regularly interacting with Octave maintainers and users on the mailing list and IRC. Our experience shows us that successful SoC students demonstrate their interest early and often.<br />
== Prepare Your Proposal With Us ==<br />
*: By working with us to prepare your proposal, you'll be getting to know us and showing us how you approach problems. The best place for this is your Wiki user page and the [https://webchat.freenode.net/?channels=#octave IRC channel].<br />
== Complete Your Application ==<br />
*: Fill out our '''''public''''' application template.<br />
*:* This is best done by '''[[Special:CreateAccount|creating an account at this wiki]]''', and copying the '''[[Template:Student_application_template_public|template]]''' from its page.<br />
*:* You really only need to copy and answer the '''''public''''' part there, there is no need to showcase everything else to everybody reading your user page!<br />
*: Fill out our '''''private''''' application template.<br />
*:* This is best done by copying the '''[[Template:Student_application_template_private|template]]''' from its page and '''adding the required information to your application at Google (melange)''' or at '''ESA'''.<br><br />
*:* Only the organization admin and the possible mentors will see this data. You can still edit it after submitting until the deadline!<br />
<br />
== Things You'll be Expected to Know or Quickly Learn On Your Own ==<br />
<br />
Octave is mostly written in C++ and its own scripting language that is mostly compatible with Matlab. There are bits and pieces of Fortran, Perl, C, awk, and Unix shell scripts here and there. In addition to being familiar with C++ and Octave's scripting language, successful applicants will be familiar with or able to quickly learn about Octave's infrastructure. You can't spend the whole summer learning how to build Octave or prepare a changeset and still successfully complete your project.<br />
<br />
* '''The Build System'''<br />
*: [http://en.wikipedia.org/wiki/GNU_build_system The GNU build system] is used to build Octave.<br />
*: While you generally don't need to understand too much unless you actually want to change how Octave is built, you should be able to understand enough to get a general idea of how to build Octave.<br />
*: If you've ever done a {{Codeline|./configure && make && make install}} series of commands, you have already used the GNU build system.<br />
*: '''You must demonstrate that you are able to build the development version of Octave from sources before the application deadline.''' Linux is arguably the easiest system to work on. Instructions:<br />
*:* [[Building]]<br />
*:* [https://octave.org/doc/interpreter/Installation.html Octave Manual on Installing Octave]<br />
* '''The Version Control System'''<br />
*: We use [https://www.mercurial-scm.org/ Mercurial] (abbreviated hg).<br />
*: Mercurial is the [http://en.wikipedia.org/wiki/Distributed_Version_Control_System distributed version control system] (DVCS) we use for managing our source code. You should have some basic understanding of how a DVCS works, but hg is pretty easy to pick up, especially if you already know a VCS like git or svn.<br />
* '''The Procedure for Contributing Changesets'''<br />
*: You will be expected to follow the same procedures as other contributors and core developers.<br />
*: You will be helping current and future Octave developers by using our standard style for changes, commit messages, and so on. You should also read the same [[Contribution guidelines | contribution]] [https://hg.savannah.gnu.org/hgweb/octave/file/tip/etc/HACKING.md guidelines] we have for everyone.<br />
*: [[Hg_instructions_for_mentors#Mercurial_Tips_for_SoC_students | This page]] describes the procedures students are expected to use to publicly display their progress in a public mercurial repo during their work.<br />
* '''The Maintainers Mailing List'''<br />
*: We primarily use [https://lists.gnu.org/mailman/listinfo/octave-maintainers mailing lists] for communication among developers.<br />
*: The mailing list is used most often for discussions about non-trivial changes to Octave, or for setting the direction of development.<br />
*: You should follow basic mailing list etiquette. For us, this mostly means "do not [https://en.wikipedia.org/wiki/Posting_style#Top-posting top post]".<br />
* '''The IRC Channel'''<br />
*: We also have [http://webchat.freenode.net?channels=octave the #octave IRC channel in Freenode].<br />
*: You should be familiar with the IRC channel. It's very helpful for new contributors (you) to get immediate feedback on ideas and code.<br />
*: Unless your primary mentor has a strong preference for some other method of communication, the IRC channel will likely be your primary means of communicating with your mentor and Octave developers.<br />
* '''The Octave Forge Project'''<br />
*: [https://octave.sourceforge.io/ Octave Forge] is a collection of contributed packages that enhance the capabilities of core Octave. They are somewhat analogous to Matlab's toolboxes.<br />
* '''Related Skills'''<br />
*: In addition, you probably should know '''some''' mathematics, engineering, experimental science, or something of the sort.<br />
*: If so, you probably have already been exposed to the kinds of problems that Octave is used for.<br />
<br />
== Criteria by which applications are judged ==<br />
<br />
These might vary somewhat depending on the mentors and coordinators for a particular Summer of Code, but typically the main factors considered would be:<br />
<br />
* '''Applicant has demonstrated an ability to make substantial modifications to Octave'''<br />
*: The most important thing is that you've contributed some interesting code samples to judge you by. It's OK during the application period to ask for help on how to format these code samples, which normally are Mercurial patches.<br />
<br />
* '''Applicant shows understanding of topic'''<br />
*: Your application should make it clear that you're reasonably well versed in the subject area and won't need all summer just to read up on it.<br />
<br />
* '''Applicant shows understanding of and interest in Octave development'''<br />
*: The best evidence for this is previous contributions and interactions.<br />
<br />
* '''Well thought out, adequately detailed, realistic project plan'''<br />
*: "I'm good at this, so trust me" isn't enough. You should describe which algorithms you'll use and how you'll integrate with existing Octave code. You should also prepare a full timeline and goals for the midterm and final evaluations.<br />
<br />
= Suggested projects =<br />
<br />
The following projects are broadly grouped by category and probable skills required to tackle each. Remember to check [[Projects]] for more ideas if none of these suit you, and your own ideas are always welcome. You can also look at our [[Summer of Code|completed past projects]] for more inspiration.<br />
<br />
{{Note|These are suggested projects but you are welcome to propose your own projects provided you find an Octave mentor}}<br />
<br />
== Summary table ==<br />
<br />
{| class="wikitable sortable" style="text-align: center; width:99%"<br />
|-<br />
!Title<br />
!Mentor<br />
!co-Mentors<br />
!Class<br />
!New?<br />
!Difficulty<br />
!Last active<br />
|-<br />
! <br />!! !! !! !! !! !!<br />
|-<br />
| [[Summer of Code - Getting Started#ode15.7Bi.2Cs.7D_:_Matlab_Compatible_DAE_solvers | ode15{i,s} : Matlab Compatible DAE solvers]] || Carlo de Falco || Francesco Faccio, Marco Caliari, Jacopo Corno, Sebastian Schöps || Numerical || No || Medium || GSoC 2016<br />
|-<br />
| [[Summer of Code - Getting Started#Improve_logm.2C_sqrtm.2C_funm | Improve logm, sqrtm, funm]] || ? || Marco Caliari, Mudit Sharma || Numerical || [https://github.com/RickOne16/matrix No] || Hard || Independent devs 2016<br />
|-<br />
| [[Summer of Code - Getting Started#Improve_iterative_methods_for_sparse_linear_systems | Improve iterative methods for sparse linear systems]] || Marco Caliari || Carlo de Falco || Numerical || No || Hard || SOCIS 2016<br />
|-<br />
| [[Summer of Code - Getting Started#EPA_hydrology_software_suite | EPA hydrology software suite]] || [[User:KaKiLa| KaKiLa]] || ? || Octave Forge || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#FullSWOF overland flow simulator | FullSWOF overland flow simulator]] || [[User:KaKiLa| KaKiLa]] || ? || Octave Forge || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#TISEAN_package | TISEAN: Nonlinear Time Series Analysis]] || [[User:KaKiLa|KaKiLa]] || ? || Octave Forge || [[TISEAN_package | No]] || Medium || GSoC 2015<br />
|-<br />
| [[Summer of Code - Getting Started#Octave_Package_management | Octave Package management]] || Sebastian Schöps || [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco || Infrastructure || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#Symbolic_package | Symbolic package]] || Colin B. Macdonald || Mike Miller, Abhinav Tripathi || Octave Forge || [https://github.com/cbm755/octsympy Octsympy] || Medium || GSoC 2016<br />
|-<br />
| [[Summer of Code - Getting Started#OCS | OCS package]] || Sebastian Schöps || Sebastian Schöps || Octave Forge, Numerical || Yes || Easy || Never<br />
|-<br />
| [[Summer of Code - Getting Started#Using_Python_within_Octave | Pythonic package]] || Mike Miller || Colin B. Macdonald, Abhinav Tripathi || Infrastructure || No || Medium || some in GSoC 2016<br />
|-<br />
| [[Summer of Code - Getting Started#Jupyter_Notebook_Integration | Jupyter Notebook Integration]] || Mike Miller || Colin B. Macdonald, [[User:Siko1056|Kai T. Ohlhus]] || Infrastructure || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#Chebfun_in_Octave | Chebfun in Octave]] || Colin B. Macdonald || [[User:KaKiLa|KaKiLa]] || Infrastructure, Numerical || Yes || Hard || Never<br />
|-<br />
| [[Summer of Code - Getting Started#PolarAxes and Plotting Improvements | PolarAxes and Plotting Improvements ]] || ? || Rik || Graphics || Yes || Medium || Never<br />
|}<br />
<br />
== Numerical ==<br />
<br />
These projects involve implementing certain mathematical functions, primarily in core Octave.<br />
<br />
=== ode15{i,s} : Matlab Compatible DAE solvers ===<br />
<br />
An initial implementation of a Matlab compatible ode15{i,s} solver,<br />
based on [http://computation.llnl.gov/projects/sundials SUNDIALS], <br />
was done by Francesco Faccio during<br />
GSOC 2016.<br />
The blog describing the work is [http://gsoc2016ode15s.blogspot.it/ here].<br />
The resulting code has been pushed into the main Octave repository in the development branch and<br />
consists mainly of the following three files<br />
[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/libinterp/dldfcn/__ode15__.cc __ode15__.cc],<br />
[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15i.m ode15i.m] and<br />
[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15s.m ode15s.m].<br />
The list of outstanding tracker tickets concerning this implementation can be found <br />
[https://savannah.gnu.org/search/?Search=Search&words=ode15&type_of_search=bugs&only_group_id=1925&exact=1&max_rows=25#options here]<br />
<br />
Possible useful improvements that could be done in a new project include:<br />
<br />
* Implement a better function for selecting consistent initial conditions compatible with Matlab's decic.m. The algorithm to use is described [http://faculty.smu.edu/shampine/cic.pdf here]<br />
<br />
* make ode15{i,s} with datatypes other than double<br />
<br />
* improve interpolation at intermediate time steps.<br />
<br />
* general code profiling and optimization <br />
<br />
Other tasks, not strictly connected to ode15{i,s} but closely related that could be added <br />
to a possible project plan would be improving documentation and tests in odepkg and removing <br />
overlaps with the documentation in core Octave.<br />
<br />
* '''Required skills'''<br />
: C++; C; familiarity with numerical methods for DAEs; Basic knowledge of makefiles and/or autotools.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Potential mentors'''<br />
: Francesco Faccio, Carlo de Falco, Marco Caliari, Jacopo Corno, Sebastian Schöps<br />
<br />
=== Improve logm, sqrtm, funm ===<br />
<br />
The goal here is to implement some missing Matlab functions related to matrix functions like the [http://en.wikipedia.org/wiki/Matrix_exponential matrix exponential]. There is [http://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html a general discussion] of the problem. A good starting point for available algorithms and open-source implementations is Higham and Deadman's [http://eprints.ma.man.ac.uk/2102/01/covered/MIMS_ep2014_8.pdf "A Catalogue of Software for Matrix Functions"].<br />
<br />
* '''Required skills'''<br />
: Read and Write both C++ and Octave code, find and read research papers, research experience in numerical analysis, familiarity with analysis of algorithms.<br />
* '''Difficulty'''<br />
: Difficult.<br />
* '''Potential mentors'''<br />
: Marco Caliari, Mudit Sharma<br />
<br />
=== Improve iterative methods for sparse linear systems ===<br />
<br />
GNU Octave currently has the following Krylov subspace methods for sparse linear systems: pcg (spd matrices) and pcr (Hermitian matrices), bicg,<br />
bicgstab, cgs, gmres, and qmr (general matrices). The description of some of them (pcr, qmr) and their error messages are not aligned. Moreover, they have similar blocks of code (input check for instance) which can be written once and for all in common functions. The first step in this project could be a revision and a synchronization of the codes, starting from the project [https://socis16octave-improveiterativemethods.blogspot.com/ SOCIS2016] which is already merged into Octave (cset {{cset|6266e321ef22}}).<br />
<br />
In Matlab, some additional methods are available: minres and symmlq (symmetric matrices), bicgstabl (general matrices), lsqr (least<br />
squares). The second step in this project could be the implementation of some of these missing functions.<br />
<br />
The [https://www-users.cs.umn.edu/~saad/IterMethBook_2ndEd.pdf reference book by Yousef Saad] is available online.<br />
<br />
* '''Required skills'''<br />
: numerical linear algebra, m-file programming.<br />
* '''Difficulty'''<br />
: Maybe hard the mathematical part, medium the programming part.<br />
* '''Mentor'''<br />
: Marco Caliari, Carlo de Falco<br />
<br />
=== Chebfun in Octave ===<br />
<br />
[https://www.chebfun.org/ Chebfun] is a mathematics and software project for "numerical computing with functions". Basically it approximates functions to machine precision accuracy (10<sup>-15</sup>) using piecewise Chebyshev polynomial interpolants. Operations on those functions (arithmetic, derivatives, root-finding, etc) are then overloaded and return new interpolating polynomials, which are themselves proxies for the actual solution.<br />
<br />
Chebfun makes extensive use of classdef classes, and is one of the largest Free Software projects to do so. Unfortunately it currently only works in Matlab. This project seeks to (1) improve Octave's classdef support and (2) tweak Chebfun to work under Octave, for example, removing undocumented classdef features. The final goal is to have at least basic Chebfun features working on Octave. An additional goal would be making <code>pkg install chebfun.zip</code> work in Octave.<br />
<br />
The impact of this project is improving Octave and allowing Chebfun to be used without proprietary software.<br />
<br />
How to get started:<br />
<br />
* Learn about [https://www.chebfun.org/ Chebfun]<br />
* Browse [https://savannah.gnu.org/bugs/?group=octave Octave's bug list] for "classdef"-related bugs.<br />
<br />
* Clone this Chebfun [https://github.com/cbm755/chebfun/tree/octave_dev octave_dev branch].<br />
** On that, <code>f = chebfun(@(x) sin(x), [-2 6])</code> should work with Octave 4.3.0+ and maybe even with 4.2.1. Check that <code>f(pi)</code> and <code>g = f + 1</code> work.<br />
** A good first task would be to study [https://github.com/cbm755/chebfun/commit/e20b0ad2dc89cfe8e50ba461b864eff7d5bbef17 this commit], a workaround for <code>f.funs{1}</code> using <code>temp = f.funs; temp{1}</code>. <code>2*f</code> is failing, can you fix it, perhaps with this workaround? Or can you make <code>f.funs{1}</code> work by changing something in <code>@chebfun/subsref.m</code>?<br />
<br />
<br />
* '''Required skills'''<br />
: Octave m-file programming, classdef programming, probably C++, some familiarity with Approximation Theory (a branch of mathematics).<br />
* '''Difficulty'''<br />
: Medium (fixing Octave classdef bugs likely harder and requires a deep dive into how Octave supports OOP).<br />
* '''Potential mentors'''<br />
: Colin B. Macdonald, [[User:KaKiLa|KaKiLa]], Mike Miller (?), Carnë Draug (?), someone from Chebfun team (?).<br />
<br />
== Adding functionality to Forge packages ==<br />
<br />
<br />
=== EPA hydrology software suite ===<br />
Create native interfaces to the EPA software suites.<br />
<br />
Starting points<br />
* [https://forja.cica.es/projects/epanet-octave/ epanet-octave].<br />
* [https://github.com/OpenWaterAnalytics/ Open Water Analytics]<br />
<br />
* '''SWMM'''<br />
** [https://www.epa.gov/water-research/storm-water-management-model-swmm Official page]<br />
** Check work done in [https://github.com/water-systems/MatSWMM MatSWMM] [http://digital.csic.es/bitstream/10261/132982/1/MatSWMM.pdf article]<br />
<br />
* '''EPANET'''<br />
** [https://www.epa.gov/water-research/epanet Official page]<br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, API knowledge, file I/O, classdef (optional). <br />
<br />
* '''Difficulty'''<br />
: easy/medium<br />
<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]]<br />
<br />
=== FullSWOF overland flow simulator ===<br />
Create scripting tools for (optional: native interfaces).<br />
<br />
Starting points<br />
* [https://www.idpoisson.fr/fullswof/ The FullSWOF Project].<br />
* [https://arxiv.org/abs/1204.3210 FullSWOF: A software for overland flow simulation]<br />
* [https://bitbucket.org/binello7/fswof2d Initial work on Bitbucket]<br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, API knowledge, file I/O, classdef (optional). <br />
<br />
* '''Difficulty'''<br />
: easy/medium<br />
<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]]<br />
<br />
=== TISEAN package ===<br />
<br />
[http://www.mpipks-dresden.mpg.de/~tisean/Tisean_3.0.1/index.html TISEAN] is a suite of code for nonlinear time series analysis. It has been [[TISEAN package | partially re-implemented]] as libre software. The objective is to integrate TISEAN as an Octave Forge package, as was done for the Control package.<br />
[[TISEAN_package | A lot has been completed]] but [[TISEAN_package:Procedure | there is still work left to do]].<br />
<br />
There are missing functions to do computations on spike trains, to simulate autoregresive models, to create specialized plots, etc. Do check [[TISEAN_package:Procedure#Table_of_functions|the progress of the project]] to see if you are interested.<br />
<br />
* [http://octave.sourceforge.net/tisean/overview.html Package help at source forge.] <br />
* [https://sourceforge.net/p/octave/tisean/ci/default/tree/ Package repository at source forge.] <br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, and FORTRAN API knowledge. <br />
* '''Difficulty'''<br />
: easy/medium<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]]<br />
<br />
=== Symbolic package ===<br />
<br />
Octave's [https://github.com/cbm755/octsympy Symbolic package] handles symbolic computing and other CAS tools. The main component of Symbolic is a pure m-file class "@sym" which uses the Python package [https://www.sympy.org SymPy] to do (most of) the actual computations. The package aims to expose the full functionality of SymPy while also providing a high-level of compatibility with the Matlab Symbolic Math Toolbox. The Symbolic package requires communication between Octave and Python. Recently, a GSoC2016 project successfully re-implemented this communication using the new [[Pythonic|Pythonic package]].<br />
<br />
This project proposes to go further: instead of using Pythonic only for the communication layer, we'll use it throughout the Symbolic project. For example, we might make "@sym" a subclass of "@pyobject". We also could stop using the "python_cmd" interface and use Pythonic directly from methods. The main goal was already mentioned: to expose the *full functionality* of SymPy. For example, we would allow OO-style method calls such as "f.diff(x)" instead of "diff(f, x)".<br />
<br />
* '''Required skills'''<br />
: OO-programming with m-files, Python, and possibly C/C++ for improving Pythonic (if needed).<br />
* '''Difficulty'''<br />
: easy/medium<br />
* '''Mentors and/or other team members'''<br />
: Colin B. Macdonald, Mike Miller, Abhinav Tripathi<br />
<br />
=== OCS ===<br />
<br />
[[Ocs package | OCS]] is a circuit simulator for Octave. The objective of this project is to update the code to use modern features of Octave (e.g. classdef), [https://savannah.gnu.org/search/?Search=Search&words=%28ocs%29&type_of_search=bugs&only_group_id=1925&exact=1&max_rows=25#options fix open bugs], increase compatibility with SPICE and improve compatibility with other Octave packages (odepkg, control etc).<br />
<br />
* [http://octave.sourceforge.net/ocs/overview.html Package help at source forge.] <br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, and FORTRAN API knowledge. <br />
* '''Difficulty'''<br />
: easy/medium<br />
* '''Mentor'''<br />
: Sebastian Schöps, Carlo de Falco<br />
<br />
== Infrastructure ==<br />
<br />
=== Jupyter Notebook Integration ===<br />
<br />
[http://jupyter.org Jupyter Notebook] is a web-based worksheet interface for computing. There is a [https://github.com/Calysto/octave_kernel Octave kernel for Jupyter]. This project seeks in first place to improve that kernel to make Octave a first-class experience within the Jupyter Notebook.<br />
<br />
In general the [https://nbformat.readthedocs.io/en/latest/ Jupyter Notebook Format] is a plain JSON document. In combination with another Octave GSoC project (see [[Summer of Code - Getting Started#JSON_encoding.2Fdecoding | JSON encoding/decoding]]), a second valuable outcome was that Octave can run (and fill) those Jupyter Notebooks on it's own. This would enable Jupyter Notebook users to evaluate long running Octave Notebooks on a computing server without permanent browser connection, which is [https://github.com/jupyter/notebook/issues/1647 still a pending issue].<br />
<br />
* '''Minimum requirements'''<br />
: Good Octave and Python programming knowledge.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Mentors'''<br />
: Colin B. Macdonald, Mike Miller, [[User:Siko1056|Kai T. Ohlhus]]<br />
<br />
=== Using Python within Octave ===<br />
<br />
[[Pythonic]] allows one to call Python functions and interact with Python objects from within Octave .m file code and from the Octave command line interface. Pythonic may eventually not be a separate package, but rather a core feature of Octave. This project aims to improve Pythonic with the goal of making the package more stable, maintainable, and full-featured.<br />
<br />
Based on a previous summer project related to Pythonic, this work will consist of fast-paced collaborative software development based on tackling the [https://gitlab.com/mtmiller/octave-pythonic/issues Pythonic issue list]. You would also be expected to participate in software design decisions and discussion, as well as improve documentation, doctests, and unit tests. As an example of the sorts of decisions being made, note that Octave indexes from 1 whereas Python typically indexes from 0; in which cases is it appropriate to make this transparent to the user?<br />
<br />
* '''Mentors'''<br />
: Mike Miller, Colin B. Macdonald, Abhinav Tripathi, others?<br />
<br />
<br />
=== Octave Package management ===<br />
<br />
[[Packages]] are extensions for Octave, that are mainly maintained by the [[Octave Forge]] community.<br />
To get those extension to work with Octave, there is a single function, {{manual|pkg}}, which does pretty much everything.<br />
This function has a few limitations which are hard to implement with the current codebase, and will most likely require a full rewrite.<br />
A major step forward for a rewritten package manager is the [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project] by Andrew Janke.<br />
<br />
The planned improvements (see also {{bug|39479}}) are:<br />
<br />
* install and update from repositories (hg and git)<br />
* automatic handling of dependencies<br />
* easily load, update or check specific package versions<br />
* management of tests and demos in C++ sources of packages<br />
* more flexibility on dependencies, e.g., dependent on specific Octave build options or being dependent in one of multiple packages<br />
* support for multiple version packages<br />
* support for multiple Octave installs<br />
* support for system-wide and user installed packages<br />
* testing packages (<code>pkg test <package-name></code>)<br />
* improved metadata acquisition (<code>pkg list -forge</code>) from https://octave.sourceforge.io/<br />
<br />
The main objective of this project is to make {{manual|pkg}} more user friendly and to make it a tool to foster third party participation in Octave.<br />
However, the current {{manual|pkg}} also performs some maintenance functions which it probably should not.<br />
Instead a package for developers should be created with such tools.<br />
To do this enhancement effectively, a refactoring of the current {{codeline|pkg}} code will be needed (see [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project]).<br />
<br />
Many of these problems have been solved in other languages.<br />
Familiarity with how other languages handle this problem will be useful to come up with elegant solutions.<br />
In some cases, there are standards to follow.<br />
For example, there are specifications published by freedesktop.org about where files should go ([http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html base directory spec]) and Windows seems to have its own standards.<br />
See bugs {{bug|36477}} and {{bug|40444}} for more details.<br />
<br />
In addition, package names may start to collide very easily.<br />
One horrible way to workaround this by is choosing increasingly complex package names that give no hint on the package purpose.<br />
A much better is option is providing an Authority category like Perl 6 does.<br />
Nested packages is also an easy way to provide packages for specialized subjects (think {{codeline|image::morphology}}).<br />
A new {{manual|pkg}} would think all this things now, or allow their implementation at a later time.<br />
Read the [[OEP:pkg|unfinished plan]] for more details.<br />
<br />
* '''Minimum requirements'''<br />
: Ability to read and write Octave code, experience with Octave packages, and understanding of the basics of autotools. The most important skill is software design.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco, Sebastian Schöps<br />
<br />
== Image Analysis ==<br />
<br />
=== Improvements to N-dimensional image processing ===<br />
<br />
The image package has partial functionality for N-dimensional images. These images exist for example in medical imaging where slices from scans are assembled to form anatomical 3D images. If taken over time and at different laser wavelengths or light filters, they can also result in 5D images. Albeit less common, images with even more dimensions also exist. However, their existence is irrelevant since most of the image processing operations are mathematical operations which are independent of the number of dimensions.<br />
<br />
As part of GSoC 2013, the core functions for image IO, {{codeline|imwrite}} and {{codeline|imread}}, were extended to better support this type of images. Likewise, many functions in the image package, mostly morphology operators, were expanded to deal with this type of image. Since then, many other functions have been improved, sometimes completely rewritten, to abstract from the number of dimensions. In a certain way, supporting ND images is also related to choosing good algorithms since such large images tend to be quite large.<br />
<br />
This project will continue on the previous work, and be mentored by the previous GSoC student and current image package maintainer. Planning the project requires selection of functions lacking ND support and identifying their dependencies. For example, supporting {{codeline|imclose}} and {{codeline|imopen}} was better implemented by supporting {{codeline|imerode}} and {{codeline|imdilate}} which then propagated ND support to all of its dependencies. These dependencies need to be discovered first since often they are not being used yet, and may even be missing function. This project can also be about implementing functions that have [[Image package#Missing functions | not yet been implemented]]. Also note that while some functions in the image package will accept ND images as input, they are actually not correctly implemented and will give incorrect results.<br />
<br />
* '''Required skills'''<br />
: m-file scripting, and a fair amount of C++ since a lot of image analysis cannot be vectorized. Familiarity with common CS algorithms and willingness to read literature describing new algorithms will be useful. <br />
* '''Difficulty'''<br />
: Difficult.<br />
* '''Potential mentor'''<br />
: Carnë Draug<br />
<br />
=== Improve Octave's image IO ===<br />
<br />
There are a lot of image formats. To handle this, Octave uses [http://www.graphicsmagick.org/ GraphicsMagic] (GM), a library capable of handling [http://www.graphicsmagick.org/formats.html a lot of them] in a single C++ interface. However, GraphicsMagick still has its limitations. The most important are:<br />
<br />
* GM has build option {{codeline|quantum}} which defines the bitdepth to use when reading an image. Building GM with high quantum means that images of smaller bitdepth will take a lot more memory when reading, but building it too low will make it impossible to read images of higher bitdepth. It also means that the image needs to always be rescaled to the correct range.<br />
* GM supports unsigned integers only thus incorrectly reading files such as TIFF with floating point data<br />
* GM hides away details of the image such as whether the image file is indexed. This makes it hard to access the real data stored on file.<br />
<br />
This project would implement better image IO for scientific file formats while leaving GM handle the others. Since TIFF is the de facto standard for scientific images, this should be done first. Among the targets for the project are:<br />
<br />
* implement the Tiff class which is a wrap around libtiff, using classdef. To avoid creating too many private __oct functions, this project could also create a C++ interface to declare new Octave classdef functions.<br />
* improve imread, imwrite, and imfinfo for tiff files using the newly created Tiff class<br />
* port the bioformats into Octave and prepare a package for it<br />
* investigate other image IO libraries<br />
* clean up and finish the dicom package to include into Octave core<br />
* prepare a matlab compatible implementation of the FITS package for inclusion in Octave core<br />
<br />
* '''Required skills'''<br />
: Knowledge of C++ and C since most libraries are written in those languages.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Potential mentor'''<br />
: Carnë Draug<br />
<br />
== Graphics ==<br />
<br />
=== PolarAxes and Plotting Improvements ===<br />
<br />
Octave currently provides supports for polar axes by using a Cartesian 2-D axes and adding a significant number of properties and callback listerners to get things to work. What is needed is a first class implementation of a "polaraxes" object in C++. This will require creating a new fundamental graphics object type, and programming in C++/OpenGL to render the object. When "polaraxes" exist as an object type then m-files will be written to access them including polaraxes.m, polarplot.m, rticks.m, rticklabels.m, thetaticks, thetaticklabels.m, rlim.m, thetalim.m. relates to {{bug|35565}}, {{bug|49804}}, {{bug|52643}}.<br />
<br />
* '''Minimum requirements'''<br />
: Ability to read and write C++ code. Ability to read and write Octave code. Experience with OpenGL programming is optional.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Mentor'''<br />
: Rik <br />
<br />
<noinclude><br />
[[Category:Summer of Code]]<br />
[[Category:Project Ideas]]<br />
</noinclude></div>Siko1056https://wiki.octave.org/wiki/index.php?title=Summer_of_Code_-_Getting_Started&diff=13328Summer of Code - Getting Started2020-09-16T01:15:45Z<p>Siko1056: /* Summary table */ JSON integration done.</p>
<hr />
<div>The following is distilled from the [[Projects]] page for the benefit of potential [https://summerofcode.withgoogle.com Google] and [https://socis.esa.int/ ESA] Summer of Code (SoC) students. Although students are welcome to attempt any of the projects in that page or any of their own choosing, here we offer some suggestions on what good student projects might be.<br />
<br />
You can also take a look at last years [[Summer of Code]] projects for inspiration.<br />
<br />
= Steps Toward a Successful Application =<br />
<br />
== Help Us Get To Know You == <br />
* If you aren't communicating with us before the application is due, your application will not be accepted.<br />
*:* '''Join the [https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers mailing list]''' or read the archives and see what topics we discuss and how the developers interact with each other.<br />
*:* '''Hang out in our [https://webchat.freenode.net/?channels=#octave IRC channel]'''. Ask questions, answer questions from users, show us that you are motivated, and well-prepared. There will be more applicants than we can effectively mentor, so do ask for feedback on your public application to increase the strength of your proposal!<br />
* '''Do not wait for us to tell you what to do'''<br />
*: You should be doing something that interests you, and should not need us to tell you what to do. Similarly, you shouldn't ask us what to do either.<br />
*:* When you email the list and mentors, do not write it to say in what project you're interested. Be specific about your questions and clear on the email subject. For example, do not write an email with the subject "GSoC student interested in the ND images projects". Such email is likely be ignored. Instead, show you are already working on the topic, and email "Problem implementing morphological operators with bitpacked ND images".<br />
*:* It is good to ask advice on how to solve something you can't but you must show some work done. Remember, we are mentors and not your boss. Read [http://www.catb.org/esr/faqs/smart-questions.html How to ask questions the smart way]: <blockquote>''Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate that having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.''</blockquote><br />
*:* It can be difficult at the beginning to think on something to do. This is nature of free and open source software development. You will need to break the mental barrier that prevents you from thinking on what can be done. Once you do that, you will have no lack of ideas for what to do next.<br />
*:* Use Octave. Eventually you will come across something that does not work the way you like. Fix that. Or you will come across a missing function. Implement it. It may be a hard problem (they usually are). While solving that problem, you may find other missing capabilities or smaller bug fixes. Implement and contribute those to Octave.<br />
*:* Take a look at the [[Short projects]] for something that may be simple to start with.<br />
<br />
== Find Something That Interests You == <br />
*: It's '''critical''' that you '''find a project that excites you'''. You'll be spending most of the summer working on it (we expect you to treat the SoC as a full-time job).<br />
*: Don't just tell us how interested you are, show us that you're willing and able to '''contribute''' to Octave. You can do that by [https://savannah.gnu.org/bugs/?group=octave fixing a few bugs] or [https://savannah.gnu.org/patch/?group=octave submitting patches] well before the deadline, in addition to regularly interacting with Octave maintainers and users on the mailing list and IRC. Our experience shows us that successful SoC students demonstrate their interest early and often.<br />
== Prepare Your Proposal With Us ==<br />
*: By working with us to prepare your proposal, you'll be getting to know us and showing us how you approach problems. The best place for this is your Wiki user page and the [https://webchat.freenode.net/?channels=#octave IRC channel].<br />
== Complete Your Application ==<br />
*: Fill out our '''''public''''' application template.<br />
*:* This is best done by '''[[Special:CreateAccount|creating an account at this wiki]]''', and copying the '''[[Template:Student_application_template_public|template]]''' from its page.<br />
*:* You really only need to copy and answer the '''''public''''' part there, there is no need to showcase everything else to everybody reading your user page!<br />
*: Fill out our '''''private''''' application template.<br />
*:* This is best done by copying the '''[[Template:Student_application_template_private|template]]''' from its page and '''adding the required information to your application at Google (melange)''' or at '''ESA'''.<br><br />
*:* Only the organization admin and the possible mentors will see this data. You can still edit it after submitting until the deadline!<br />
<br />
== Things You'll be Expected to Know or Quickly Learn On Your Own ==<br />
<br />
Octave is mostly written in C++ and its own scripting language that is mostly compatible with Matlab. There are bits and pieces of Fortran, Perl, C, awk, and Unix shell scripts here and there. In addition to being familiar with C++ and Octave's scripting language, successful applicants will be familiar with or able to quickly learn about Octave's infrastructure. You can't spend the whole summer learning how to build Octave or prepare a changeset and still successfully complete your project.<br />
<br />
* '''The Build System'''<br />
*: [http://en.wikipedia.org/wiki/GNU_build_system The GNU build system] is used to build Octave.<br />
*: While you generally don't need to understand too much unless you actually want to change how Octave is built, you should be able to understand enough to get a general idea of how to build Octave.<br />
*: If you've ever done a {{Codeline|./configure && make && make install}} series of commands, you have already used the GNU build system.<br />
*: '''You must demonstrate that you are able to build the development version of Octave from sources before the application deadline.''' Linux is arguably the easiest system to work on. Instructions:<br />
*:* [[Building]]<br />
*:* [https://octave.org/doc/interpreter/Installation.html Octave Manual on Installing Octave]<br />
* '''The Version Control System'''<br />
*: We use [https://www.mercurial-scm.org/ Mercurial] (abbreviated hg).<br />
*: Mercurial is the [http://en.wikipedia.org/wiki/Distributed_Version_Control_System distributed version control system] (DVCS) we use for managing our source code. You should have some basic understanding of how a DVCS works, but hg is pretty easy to pick up, especially if you already know a VCS like git or svn.<br />
* '''The Procedure for Contributing Changesets'''<br />
*: You will be expected to follow the same procedures as other contributors and core developers.<br />
*: You will be helping current and future Octave developers by using our standard style for changes, commit messages, and so on. You should also read the same [[Contribution guidelines | contribution]] [https://hg.savannah.gnu.org/hgweb/octave/file/tip/etc/HACKING.md guidelines] we have for everyone.<br />
*: [[Hg_instructions_for_mentors#Mercurial_Tips_for_SoC_students | This page]] describes the procedures students are expected to use to publicly display their progress in a public mercurial repo during their work.<br />
* '''The Maintainers Mailing List'''<br />
*: We primarily use [https://lists.gnu.org/mailman/listinfo/octave-maintainers mailing lists] for communication among developers.<br />
*: The mailing list is used most often for discussions about non-trivial changes to Octave, or for setting the direction of development.<br />
*: You should follow basic mailing list etiquette. For us, this mostly means "do not [https://en.wikipedia.org/wiki/Posting_style#Top-posting top post]".<br />
* '''The IRC Channel'''<br />
*: We also have [http://webchat.freenode.net?channels=octave the #octave IRC channel in Freenode].<br />
*: You should be familiar with the IRC channel. It's very helpful for new contributors (you) to get immediate feedback on ideas and code.<br />
*: Unless your primary mentor has a strong preference for some other method of communication, the IRC channel will likely be your primary means of communicating with your mentor and Octave developers.<br />
* '''The Octave Forge Project'''<br />
*: [https://octave.sourceforge.io/ Octave Forge] is a collection of contributed packages that enhance the capabilities of core Octave. They are somewhat analogous to Matlab's toolboxes.<br />
* '''Related Skills'''<br />
*: In addition, you probably should know '''some''' mathematics, engineering, experimental science, or something of the sort.<br />
*: If so, you probably have already been exposed to the kinds of problems that Octave is used for.<br />
<br />
== Criteria by which applications are judged ==<br />
<br />
These might vary somewhat depending on the mentors and coordinators for a particular Summer of Code, but typically the main factors considered would be:<br />
<br />
* '''Applicant has demonstrated an ability to make substantial modifications to Octave'''<br />
*: The most important thing is that you've contributed some interesting code samples to judge you by. It's OK during the application period to ask for help on how to format these code samples, which normally are Mercurial patches.<br />
<br />
* '''Applicant shows understanding of topic'''<br />
*: Your application should make it clear that you're reasonably well versed in the subject area and won't need all summer just to read up on it.<br />
<br />
* '''Applicant shows understanding of and interest in Octave development'''<br />
*: The best evidence for this is previous contributions and interactions.<br />
<br />
* '''Well thought out, adequately detailed, realistic project plan'''<br />
*: "I'm good at this, so trust me" isn't enough. You should describe which algorithms you'll use and how you'll integrate with existing Octave code. You should also prepare a full timeline and goals for the midterm and final evaluations.<br />
<br />
= Suggested projects =<br />
<br />
The following projects are broadly grouped by category and probable skills required to tackle each. Remember to check [[Projects]] for more ideas if none of these suit you, and your own ideas are always welcome. You can also look at our [[Summer of Code|completed past projects]] for more inspiration.<br />
<br />
{{Note|These are suggested projects but you are welcome to propose your own projects provided you find an Octave mentor}}<br />
<br />
== Summary table ==<br />
<br />
{| class="wikitable sortable" style="text-align: center; width:99%"<br />
|-<br />
!Title<br />
!Mentor<br />
!co-Mentors<br />
!Class<br />
!New?<br />
!Difficulty<br />
!Last active<br />
|-<br />
! <br />!! !! !! !! !! !!<br />
|-<br />
| [[Summer of Code - Getting Started#ode15.7Bi.2Cs.7D_:_Matlab_Compatible_DAE_solvers | ode15{i,s} : Matlab Compatible DAE solvers]] || Carlo de Falco || Francesco Faccio, Marco Caliari, Jacopo Corno, Sebastian Schöps || Numerical || No || Medium || GSoC 2016<br />
|-<br />
| [[Summer of Code - Getting Started#Improve_logm.2C_sqrtm.2C_funm | Improve logm, sqrtm, funm]] || ? || Marco Caliari, Mudit Sharma || Numerical || [https://github.com/RickOne16/matrix No] || Hard || Independent devs 2016<br />
|-<br />
| [[Summer of Code - Getting Started#Improve_iterative_methods_for_sparse_linear_systems | Improve iterative methods for sparse linear systems]] || Marco Caliari || Carlo de Falco || Numerical || No || Hard || SOCIS 2016<br />
|-<br />
| [[Summer of Code - Getting Started#EPA_hydrology_software_suite | EPA hydrology software suite]] || [[User:KaKiLa| KaKiLa]] || ? || Octave Forge || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#FullSWOF overland flow simulator | FullSWOF overland flow simulator]] || [[User:KaKiLa| KaKiLa]] || ? || Octave Forge || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#TISEAN_package | TISEAN: Nonlinear Time Series Analysis]] || [[User:KaKiLa|KaKiLa]] || ? || Octave Forge || [[TISEAN_package | No]] || Medium || GSoC 2015<br />
|-<br />
| [[Summer of Code - Getting Started#Octave_Package_management | Octave Package management]] || Sebastian Schöps || [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco || Infrastructure || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#Symbolic_package | Symbolic package]] || Colin B. Macdonald || Mike Miller, Abhinav Tripathi || Octave Forge || [https://github.com/cbm755/octsympy Octsympy] || Medium || GSoC 2016<br />
|-<br />
| [[Summer of Code - Getting Started#OCS | OCS package]] || Sebastian Schöps || Sebastian Schöps || Octave Forge, Numerical || Yes || Easy || Never<br />
|-<br />
| [[Summer of Code - Getting Started#Using_Python_within_Octave | Pythonic package]] || Mike Miller || Colin B. Macdonald, Abhinav Tripathi || Infrastructure || No || Medium || some in GSoC 2016<br />
|-<br />
| [[Summer of Code - Getting Started#Jupyter_Notebook_Integration | Jupyter Notebook Integration]] || Mike Miller || Colin B. Macdonald, [[User:Siko1056|Kai T. Ohlhus]] || Infrastructure || Yes || Medium || Never<br />
|-<br />
| [[Summer of Code - Getting Started#Chebfun_in_Octave | Chebfun in Octave]] || Colin B. Macdonald || [[User:KaKiLa|KaKiLa]] || Infrastructure, Numerical || Yes || Hard || Never<br />
|-<br />
| [[Summer of Code - Getting Started#PolarAxes and Plotting Improvements | PolarAxes and Plotting Improvements ]] || ? || Rik || Graphics || Yes || Medium || Never<br />
|}<br />
<br />
== Numerical ==<br />
<br />
These projects involve implementing certain mathematical functions, primarily in core Octave.<br />
<br />
=== ode15{i,s} : Matlab Compatible DAE solvers ===<br />
<br />
An initial implementation of a Matlab compatible ode15{i,s} solver,<br />
based on [http://computation.llnl.gov/projects/sundials SUNDIALS], <br />
was done by Francesco Faccio during<br />
GSOC 2016.<br />
The blog describing the work is [http://gsoc2016ode15s.blogspot.it/ here].<br />
The resulting code has been pushed into the main Octave repository in the development branch and<br />
consists mainly of the following three files<br />
[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/libinterp/dldfcn/__ode15__.cc __ode15__.cc],<br />
[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15i.m ode15i.m] and<br />
[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15s.m ode15s.m].<br />
The list of outstanding tracker tickets concerning this implementation can be found <br />
[https://savannah.gnu.org/search/?Search=Search&words=ode15&type_of_search=bugs&only_group_id=1925&exact=1&max_rows=25#options here]<br />
<br />
Possible useful improvements that could be done in a new project include:<br />
<br />
* Implement a better function for selecting consistent initial conditions compatible with Matlab's decic.m. The algorithm to use is described [http://faculty.smu.edu/shampine/cic.pdf here]<br />
<br />
* make ode15{i,s} with datatypes other than double<br />
<br />
* improve interpolation at intermediate time steps.<br />
<br />
* general code profiling and optimization <br />
<br />
Other tasks, not strictly connected to ode15{i,s} but closely related that could be added <br />
to a possible project plan would be improving documentation and tests in odepkg and removing <br />
overlaps with the documentation in core Octave.<br />
<br />
* '''Required skills'''<br />
: C++; C; familiarity with numerical methods for DAEs; Basic knowledge of makefiles and/or autotools.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Potential mentors'''<br />
: Francesco Faccio, Carlo de Falco, Marco Caliari, Jacopo Corno, Sebastian Schöps<br />
<br />
=== Improve logm, sqrtm, funm ===<br />
<br />
The goal here is to implement some missing Matlab functions related to matrix functions like the [http://en.wikipedia.org/wiki/Matrix_exponential matrix exponential]. There is [http://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html a general discussion] of the problem. A good starting point for available algorithms and open-source implementations is Higham and Deadman's [http://eprints.ma.man.ac.uk/2102/01/covered/MIMS_ep2014_8.pdf "A Catalogue of Software for Matrix Functions"].<br />
<br />
* '''Required skills'''<br />
: Read and Write both C++ and Octave code, find and read research papers, research experience in numerical analysis, familiarity with analysis of algorithms.<br />
* '''Difficulty'''<br />
: Difficult.<br />
* '''Potential mentors'''<br />
: Marco Caliari, Mudit Sharma<br />
<br />
=== Improve iterative methods for sparse linear systems ===<br />
<br />
GNU Octave currently has the following Krylov subspace methods for sparse linear systems: pcg (spd matrices) and pcr (Hermitian matrices), bicg,<br />
bicgstab, cgs, gmres, and qmr (general matrices). The description of some of them (pcr, qmr) and their error messages are not aligned. Moreover, they have similar blocks of code (input check for instance) which can be written once and for all in common functions. The first step in this project could be a revision and a synchronization of the codes, starting from the project [https://socis16octave-improveiterativemethods.blogspot.com/ SOCIS2016] which is already merged into Octave (cset {{cset|6266e321ef22}}).<br />
<br />
In Matlab, some additional methods are available: minres and symmlq (symmetric matrices), bicgstabl (general matrices), lsqr (least<br />
squares). The second step in this project could be the implementation of some of these missing functions.<br />
<br />
The [https://www-users.cs.umn.edu/~saad/IterMethBook_2ndEd.pdf reference book by Yousef Saad] is available online.<br />
<br />
* '''Required skills'''<br />
: numerical linear algebra, m-file programming.<br />
* '''Difficulty'''<br />
: Maybe hard the mathematical part, medium the programming part.<br />
* '''Mentor'''<br />
: Marco Caliari, Carlo de Falco<br />
<br />
=== Chebfun in Octave ===<br />
<br />
[https://www.chebfun.org/ Chebfun] is a mathematics and software project for "numerical computing with functions". Basically it approximates functions to machine precision accuracy (10<sup>-15</sup>) using piecewise Chebyshev polynomial interpolants. Operations on those functions (arithmetic, derivatives, root-finding, etc) are then overloaded and return new interpolating polynomials, which are themselves proxies for the actual solution.<br />
<br />
Chebfun makes extensive use of classdef classes, and is one of the largest Free Software projects to do so. Unfortunately it currently only works in Matlab. This project seeks to (1) improve Octave's classdef support and (2) tweak Chebfun to work under Octave, for example, removing undocumented classdef features. The final goal is to have at least basic Chebfun features working on Octave. An additional goal would be making <code>pkg install chebfun.zip</code> work in Octave.<br />
<br />
The impact of this project is improving Octave and allowing Chebfun to be used without proprietary software.<br />
<br />
How to get started:<br />
<br />
* Learn about [https://www.chebfun.org/ Chebfun]<br />
* Browse [https://savannah.gnu.org/bugs/?group=octave Octave's bug list] for "classdef"-related bugs.<br />
<br />
* Clone this Chebfun [https://github.com/cbm755/chebfun/tree/octave_dev octave_dev branch].<br />
** On that, <code>f = chebfun(@(x) sin(x), [-2 6])</code> should work with Octave 4.3.0+ and maybe even with 4.2.1. Check that <code>f(pi)</code> and <code>g = f + 1</code> work.<br />
** A good first task would be to study [https://github.com/cbm755/chebfun/commit/e20b0ad2dc89cfe8e50ba461b864eff7d5bbef17 this commit], a workaround for <code>f.funs{1}</code> using <code>temp = f.funs; temp{1}</code>. <code>2*f</code> is failing, can you fix it, perhaps with this workaround? Or can you make <code>f.funs{1}</code> work by changing something in <code>@chebfun/subsref.m</code>?<br />
<br />
<br />
* '''Required skills'''<br />
: Octave m-file programming, classdef programming, probably C++, some familiarity with Approximation Theory (a branch of mathematics).<br />
* '''Difficulty'''<br />
: Medium (fixing Octave classdef bugs likely harder and requires a deep dive into how Octave supports OOP).<br />
* '''Potential mentors'''<br />
: Colin B. Macdonald, [[User:KaKiLa|KaKiLa]], Mike Miller (?), Carnë Draug (?), someone from Chebfun team (?).<br />
<br />
== Adding functionality to Forge packages ==<br />
<br />
<br />
=== EPA hydrology software suite ===<br />
Create native interfaces to the EPA software suites.<br />
<br />
Starting points<br />
* [https://forja.cica.es/projects/epanet-octave/ epanet-octave].<br />
* [https://github.com/OpenWaterAnalytics/ Open Water Analytics]<br />
<br />
* '''SWMM'''<br />
** [https://www.epa.gov/water-research/storm-water-management-model-swmm Official page]<br />
** Check work done in [https://github.com/water-systems/MatSWMM MatSWMM] [http://digital.csic.es/bitstream/10261/132982/1/MatSWMM.pdf article]<br />
<br />
* '''EPANET'''<br />
** [https://www.epa.gov/water-research/epanet Official page]<br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, API knowledge, file I/O, classdef (optional). <br />
<br />
* '''Difficulty'''<br />
: easy/medium<br />
<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]]<br />
<br />
=== FullSWOF overland flow simulator ===<br />
Create scripting tools for (optional: native interfaces).<br />
<br />
Starting points<br />
* [https://www.idpoisson.fr/fullswof/ The FullSWOF Project].<br />
* [https://arxiv.org/abs/1204.3210 FullSWOF: A software for overland flow simulation]<br />
* [https://bitbucket.org/binello7/fswof2d Initial work on Bitbucket]<br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, API knowledge, file I/O, classdef (optional). <br />
<br />
* '''Difficulty'''<br />
: easy/medium<br />
<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]]<br />
<br />
=== TISEAN package ===<br />
<br />
[http://www.mpipks-dresden.mpg.de/~tisean/Tisean_3.0.1/index.html TISEAN] is a suite of code for nonlinear time series analysis. It has been [[TISEAN package | partially re-implemented]] as libre software. The objective is to integrate TISEAN as an Octave Forge package, as was done for the Control package.<br />
[[TISEAN_package | A lot has been completed]] but [[TISEAN_package:Procedure | there is still work left to do]].<br />
<br />
There are missing functions to do computations on spike trains, to simulate autoregresive models, to create specialized plots, etc. Do check [[TISEAN_package:Procedure#Table_of_functions|the progress of the project]] to see if you are interested.<br />
<br />
* [http://octave.sourceforge.net/tisean/overview.html Package help at source forge.] <br />
* [https://sourceforge.net/p/octave/tisean/ci/default/tree/ Package repository at source forge.] <br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, and FORTRAN API knowledge. <br />
* '''Difficulty'''<br />
: easy/medium<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]]<br />
<br />
=== Symbolic package ===<br />
<br />
Octave's [https://github.com/cbm755/octsympy Symbolic package] handles symbolic computing and other CAS tools. The main component of Symbolic is a pure m-file class "@sym" which uses the Python package [https://www.sympy.org SymPy] to do (most of) the actual computations. The package aims to expose the full functionality of SymPy while also providing a high-level of compatibility with the Matlab Symbolic Math Toolbox. The Symbolic package requires communication between Octave and Python. Recently, a GSoC2016 project successfully re-implemented this communication using the new [[Pythonic|Pythonic package]].<br />
<br />
This project proposes to go further: instead of using Pythonic only for the communication layer, we'll use it throughout the Symbolic project. For example, we might make "@sym" a subclass of "@pyobject". We also could stop using the "python_cmd" interface and use Pythonic directly from methods. The main goal was already mentioned: to expose the *full functionality* of SymPy. For example, we would allow OO-style method calls such as "f.diff(x)" instead of "diff(f, x)".<br />
<br />
* '''Required skills'''<br />
: OO-programming with m-files, Python, and possibly C/C++ for improving Pythonic (if needed).<br />
* '''Difficulty'''<br />
: easy/medium<br />
* '''Mentors and/or other team members'''<br />
: Colin B. Macdonald, Mike Miller, Abhinav Tripathi<br />
<br />
=== OCS ===<br />
<br />
[[Ocs package | OCS]] is a circuit simulator for Octave. The objective of this project is to update the code to use modern features of Octave (e.g. classdef), [https://savannah.gnu.org/search/?Search=Search&words=%28ocs%29&type_of_search=bugs&only_group_id=1925&exact=1&max_rows=25#options fix open bugs], increase compatibility with SPICE and improve compatibility with other Octave packages (odepkg, control etc).<br />
<br />
* [http://octave.sourceforge.net/ocs/overview.html Package help at source forge.] <br />
<br />
* '''Required skills'''<br />
: m-file scripting, C, C++, and FORTRAN API knowledge. <br />
* '''Difficulty'''<br />
: easy/medium<br />
* '''Mentor'''<br />
: Sebastian Schöps, Carlo de Falco<br />
<br />
== Infrastructure ==<br />
<br />
=== JSON encoding/decoding ===<br />
<br />
[https://en.wikipedia.org/wiki/JSON JavaScript Object Notation], in short JSON, is a very common human readable and structured data format. Unfortunately, GNU Octave still lacks of builtin support of that data format. Having JSON support, Octave can improve for example it's web service functions, which often exchange JSON data these days. Another interesting applicatoin is described in another Octave GSoC project, see [[Summer of Code - Getting Started#Jupyter_Integration | Jupyter integration]].<br />
<br />
In bug {{bug|53100}} a vivid discussion about proper JSON support took place. As JSON is a highly demanded feature for Octave, there are already several attempts to fill the gap:<br />
<br />
* [https://github.com/fangq/jsonlab jsonlab] (M-file implementation, probably slow for large JSON files)<br />
* [https://github.com/gllmflndn/JSONio JSONio] (C MEX wrapper around [https://github.com/zserge/jsmn jsmn])<br />
* [https://github.com/Andy1978/octave-rapidjson octave-rapidjson] (C++ Octave wrapper around [https://rapidjson.org/ RapidJSON])<br />
* [https://github.com/apjanke/octave-jsonstuff octave-jsonstuff] (C++ Octave wrapper around [https://rapidjson.org/ RapidJSON])<br />
<br />
For different reasons, none of them can be directly merged into Octave core yet. Thus there is still lots of work to do. The goal of this project is to evaluate (and to cherry pick from) the implementations above, to create Matlab compatible [https://www.mathworks.com/help/matlab/ref/jsonencode.html jsonencode] and [https://www.mathworks.com/help/matlab/ref/jsondecode.html jsondecode] functions. This involves proper documentation of the work and unit tests to ensure the correctness of the implementation.<br />
<br />
* '''Minimum requirements'''<br />
: Good Octave and C/C++ programming knowledge. Ability to make use of C/C++ libraries.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Mentor'''<br />
: [[User:Siko1056|Kai T. Ohlhus]]<br />
<br />
=== Jupyter Notebook Integration ===<br />
<br />
[http://jupyter.org Jupyter Notebook] is a web-based worksheet interface for computing. There is a [https://github.com/Calysto/octave_kernel Octave kernel for Jupyter]. This project seeks in first place to improve that kernel to make Octave a first-class experience within the Jupyter Notebook.<br />
<br />
In general the [https://nbformat.readthedocs.io/en/latest/ Jupyter Notebook Format] is a plain JSON document. In combination with another Octave GSoC project (see [[Summer of Code - Getting Started#JSON_encoding.2Fdecoding | JSON encoding/decoding]]), a second valuable outcome was that Octave can run (and fill) those Jupyter Notebooks on it's own. This would enable Jupyter Notebook users to evaluate long running Octave Notebooks on a computing server without permanent browser connection, which is [https://github.com/jupyter/notebook/issues/1647 still a pending issue].<br />
<br />
* '''Minimum requirements'''<br />
: Good Octave and Python programming knowledge.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Mentors'''<br />
: Colin B. Macdonald, Mike Miller, [[User:Siko1056|Kai T. Ohlhus]]<br />
<br />
=== Using Python within Octave ===<br />
<br />
[[Pythonic]] allows one to call Python functions and interact with Python objects from within Octave .m file code and from the Octave command line interface. Pythonic may eventually not be a separate package, but rather a core feature of Octave. This project aims to improve Pythonic with the goal of making the package more stable, maintainable, and full-featured.<br />
<br />
Based on a previous summer project related to Pythonic, this work will consist of fast-paced collaborative software development based on tackling the [https://gitlab.com/mtmiller/octave-pythonic/issues Pythonic issue list]. You would also be expected to participate in software design decisions and discussion, as well as improve documentation, doctests, and unit tests. As an example of the sorts of decisions being made, note that Octave indexes from 1 whereas Python typically indexes from 0; in which cases is it appropriate to make this transparent to the user?<br />
<br />
* '''Mentors'''<br />
: Mike Miller, Colin B. Macdonald, Abhinav Tripathi, others?<br />
<br />
<br />
=== Octave Package management ===<br />
<br />
[[Packages]] are extensions for Octave, that are mainly maintained by the [[Octave Forge]] community.<br />
To get those extension to work with Octave, there is a single function, {{manual|pkg}}, which does pretty much everything.<br />
This function has a few limitations which are hard to implement with the current codebase, and will most likely require a full rewrite.<br />
A major step forward for a rewritten package manager is the [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project] by Andrew Janke.<br />
<br />
The planned improvements (see also {{bug|39479}}) are:<br />
<br />
* install and update from repositories (hg and git)<br />
* automatic handling of dependencies<br />
* easily load, update or check specific package versions<br />
* management of tests and demos in C++ sources of packages<br />
* more flexibility on dependencies, e.g., dependent on specific Octave build options or being dependent in one of multiple packages<br />
* support for multiple version packages<br />
* support for multiple Octave installs<br />
* support for system-wide and user installed packages<br />
* testing packages (<code>pkg test <package-name></code>)<br />
* improved metadata acquisition (<code>pkg list -forge</code>) from https://octave.sourceforge.io/<br />
<br />
The main objective of this project is to make {{manual|pkg}} more user friendly and to make it a tool to foster third party participation in Octave.<br />
However, the current {{manual|pkg}} also performs some maintenance functions which it probably should not.<br />
Instead a package for developers should be created with such tools.<br />
To do this enhancement effectively, a refactoring of the current {{codeline|pkg}} code will be needed (see [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project]).<br />
<br />
Many of these problems have been solved in other languages.<br />
Familiarity with how other languages handle this problem will be useful to come up with elegant solutions.<br />
In some cases, there are standards to follow.<br />
For example, there are specifications published by freedesktop.org about where files should go ([http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html base directory spec]) and Windows seems to have its own standards.<br />
See bugs {{bug|36477}} and {{bug|40444}} for more details.<br />
<br />
In addition, package names may start to collide very easily.<br />
One horrible way to workaround this by is choosing increasingly complex package names that give no hint on the package purpose.<br />
A much better is option is providing an Authority category like Perl 6 does.<br />
Nested packages is also an easy way to provide packages for specialized subjects (think {{codeline|image::morphology}}).<br />
A new {{manual|pkg}} would think all this things now, or allow their implementation at a later time.<br />
Read the [[OEP:pkg|unfinished plan]] for more details.<br />
<br />
* '''Minimum requirements'''<br />
: Ability to read and write Octave code, experience with Octave packages, and understanding of the basics of autotools. The most important skill is software design.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Mentor'''<br />
: [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco, Sebastian Schöps<br />
<br />
== Image Analysis ==<br />
<br />
=== Improvements to N-dimensional image processing ===<br />
<br />
The image package has partial functionality for N-dimensional images. These images exist for example in medical imaging where slices from scans are assembled to form anatomical 3D images. If taken over time and at different laser wavelengths or light filters, they can also result in 5D images. Albeit less common, images with even more dimensions also exist. However, their existence is irrelevant since most of the image processing operations are mathematical operations which are independent of the number of dimensions.<br />
<br />
As part of GSoC 2013, the core functions for image IO, {{codeline|imwrite}} and {{codeline|imread}}, were extended to better support this type of images. Likewise, many functions in the image package, mostly morphology operators, were expanded to deal with this type of image. Since then, many other functions have been improved, sometimes completely rewritten, to abstract from the number of dimensions. In a certain way, supporting ND images is also related to choosing good algorithms since such large images tend to be quite large.<br />
<br />
This project will continue on the previous work, and be mentored by the previous GSoC student and current image package maintainer. Planning the project requires selection of functions lacking ND support and identifying their dependencies. For example, supporting {{codeline|imclose}} and {{codeline|imopen}} was better implemented by supporting {{codeline|imerode}} and {{codeline|imdilate}} which then propagated ND support to all of its dependencies. These dependencies need to be discovered first since often they are not being used yet, and may even be missing function. This project can also be about implementing functions that have [[Image package#Missing functions | not yet been implemented]]. Also note that while some functions in the image package will accept ND images as input, they are actually not correctly implemented and will give incorrect results.<br />
<br />
* '''Required skills'''<br />
: m-file scripting, and a fair amount of C++ since a lot of image analysis cannot be vectorized. Familiarity with common CS algorithms and willingness to read literature describing new algorithms will be useful. <br />
* '''Difficulty'''<br />
: Difficult.<br />
* '''Potential mentor'''<br />
: Carnë Draug<br />
<br />
=== Improve Octave's image IO ===<br />
<br />
There are a lot of image formats. To handle this, Octave uses [http://www.graphicsmagick.org/ GraphicsMagic] (GM), a library capable of handling [http://www.graphicsmagick.org/formats.html a lot of them] in a single C++ interface. However, GraphicsMagick still has its limitations. The most important are:<br />
<br />
* GM has build option {{codeline|quantum}} which defines the bitdepth to use when reading an image. Building GM with high quantum means that images of smaller bitdepth will take a lot more memory when reading, but building it too low will make it impossible to read images of higher bitdepth. It also means that the image needs to always be rescaled to the correct range.<br />
* GM supports unsigned integers only thus incorrectly reading files such as TIFF with floating point data<br />
* GM hides away details of the image such as whether the image file is indexed. This makes it hard to access the real data stored on file.<br />
<br />
This project would implement better image IO for scientific file formats while leaving GM handle the others. Since TIFF is the de facto standard for scientific images, this should be done first. Among the targets for the project are:<br />
<br />
* implement the Tiff class which is a wrap around libtiff, using classdef. To avoid creating too many private __oct functions, this project could also create a C++ interface to declare new Octave classdef functions.<br />
* improve imread, imwrite, and imfinfo for tiff files using the newly created Tiff class<br />
* port the bioformats into Octave and prepare a package for it<br />
* investigate other image IO libraries<br />
* clean up and finish the dicom package to include into Octave core<br />
* prepare a matlab compatible implementation of the FITS package for inclusion in Octave core<br />
<br />
* '''Required skills'''<br />
: Knowledge of C++ and C since most libraries are written in those languages.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Potential mentor'''<br />
: Carnë Draug<br />
<br />
== Graphics ==<br />
<br />
=== PolarAxes and Plotting Improvements ===<br />
<br />
Octave currently provides supports for polar axes by using a Cartesian 2-D axes and adding a significant number of properties and callback listerners to get things to work. What is needed is a first class implementation of a "polaraxes" object in C++. This will require creating a new fundamental graphics object type, and programming in C++/OpenGL to render the object. When "polaraxes" exist as an object type then m-files will be written to access them including polaraxes.m, polarplot.m, rticks.m, rticklabels.m, thetaticks, thetaticklabels.m, rlim.m, thetalim.m. relates to {{bug|35565}}, {{bug|49804}}, {{bug|52643}}.<br />
<br />
* '''Minimum requirements'''<br />
: Ability to read and write C++ code. Ability to read and write Octave code. Experience with OpenGL programming is optional.<br />
* '''Difficulty'''<br />
: Medium.<br />
* '''Mentor'''<br />
: Rik <br />
<br />
<noinclude><br />
[[Category:Summer of Code]]<br />
[[Category:Project Ideas]]<br />
</noinclude></div>Siko1056https://wiki.octave.org/wiki/index.php?title=GNU_Octave_Wiki&diff=13326GNU Octave Wiki2020-09-13T03:23:42Z<p>Siko1056: /* News */ Announce GSoC 2020 completion.</p>
<hr />
<div>[https://www.gnu.org/software/octave/ GNU Octave] is a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems, and for performing other numerical experiments. It also provides extensive graphics capabilities for data visualization and manipulation. The program is named after [https://en.wikipedia.org/wiki/Octave_Levenspiel Octave Levenspiel], a former professor of the principal author. GNU Octave is normally used through its interactive interface ([https://en.wikipedia.org/wiki/Command-line_interface CLI] and [https://en.wikipedia.org/wiki/Graphical_user_interface GUI]), but it can also be used to write non-interactive programs. The project was conceived around 1988 and at first it was intended to be a companion to a chemical reactor design course. The GNU Octave language is largely compatible to [https://en.wikipedia.org/wiki/MATLAB Matlab] so that most programs are easily portable. In addition, functions known from the C standard library and from UNIX system calls and functions are supported. C/C++ and Fortran code can be called from Octave by creating [https://octave.org/doc/interpreter/Getting-Started-with-Oct_002dFiles.html Oct-Files], or using Matlab compatible [https://octave.org/doc/interpreter/Mex_002dFiles.html Mex-Files].<br />
<br />
== [[:Category:Installation|Installing]] ==<br />
<br />
Installation instructions for:<br />
* [[Octave for macOS|macOS]]<br />
* [[Octave for GNU/Linux|GNU/Linux]], [[Octave for Android|Android]], and [[Octave for other Unix systems|other Unix systems]]<br />
* [[Octave for Microsoft_Windows|Microsoft Windows]]<br />
<br />
Get installers and sources from https://www.octave.org/download.<br />
<br />
{{Note|'''GNU Octave {{Release}}''' is the current stable release.}}<br />
<br />
Are you using an old version of Octave? Check the [[Release History]] page to see how old it is.<br />
<br />
== [https://www.gnu.org/software/octave/news.html News] ==<br />
<br />
* ''September 8, 2020'' &mdash; Congratulations! [[User:Abdallah_Elshamy|'''Abdallah Elshamy''']] successfully completed his [https://summerofcode.withgoogle.com/organizations/4930645207285760/ Google Summer of Code 2020] project with GNU Octave. [[Summer of Code#GSoC 2020 | More information]].<br />
* ''July 28, 2020'' &mdash; Read about the [[Online Developer Meeting (2020-07-28)]].<br />
* ''July 7, 2020'' &mdash; Try out our new user and developer forum [https://octave.discourse.group Octave Discourse].<br />
* ''{{Release Date}}'' &mdash; '''GNU Octave {{Release}}''' has been released (see above)!<br />
<br />
== Getting help ==<br />
<br />
* [https://octave.discourse.group Octave Discourse] - Forum for Octave users and developers.<br />
* [[FAQ|Frequently asked questions (FAQ)]]<br />
* [https://www.gnu.org/software/octave/doc/interpreter GNU Octave documentation]<br />
* [https://www.gnu.org/software/octave/support.html Other support options]<br />
<br />
== [[:Category:Resources|Getting started]] ==<br />
<br />
* [[Publications using Octave#Books|Books]]<br />
* [[Video tutorials|Videos]]<br />
* [https://bagustris.github.io/octave-tutorial Short course]<br />
<br />
[[File:Octave-flower.svg|right|frame|[[:Category:Octave Forge|Octave Forge]] is a collection of high quality packages for GNU Octave.]]<br />
<br />
== [[Packages]] / [[:Category:Octave Forge|Octave Forge]] ==<br />
<br />
* [https://octave.org/doc/interpreter/Installing-and-Removing-Packages.html Installing packages]<br />
* [[Creating packages]]<br />
* '''[[:Category:Octave Forge|Octave Forge]]''' &mdash; A collection of high quality packages for GNU Octave.<br />
<br />
== [[:Category:Development|Development]] ==<br />
<br />
We always need more help improving Octave and there are many ways [https://www.gnu.org/software/octave/get-involved.html you can contribute]. You can help by fixing bugs, developing new features, answering questions on the mailing list or IRC channel, helping to improve this wiki or other web pages.<br />
<br />
* Get an overview about the [[:Category:Development|GNU Octave development]].<br />
* Take a look at our [[Projects|project ideas]] and [[Summer of Code - Getting Started | Summer of Code project ideas]].<br />
<br />
== [[:Category:Academia|Academia]] ==<br />
<br />
* [[Publications using Octave]] &mdash; A compilation of scientific publications making reference to GNU Octave (add yours!).<br />
<br />
== External Links ==<br />
<br />
* [https://www.gnu.org/software/octave/ Octave Homepage]<br />
* [https://octave.sourceforge.io/ Octave Forge]<br />
* [https://savannah.gnu.org/bugs/?group=octave Bug Tracker]<br />
* [https://savannah.gnu.org/task/?group=octave Task Tracker]<br />
* [https://savannah.gnu.org/patch/?group=octave Patch Tracker]<br />
* [https://savannah.gnu.org/hg/?group=octave Development Repositories]<br />
* [https://planet.octave.org/ Planet Octave] - A collection of blog feeds featuring Octave developers and [[Summer of Code]] students.</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Forum_for_GNU_Octave&diff=13321Forum for GNU Octave2020-09-08T06:02:11Z<p>Siko1056: Mark as outdated.</p>
<hr />
<div>{{Warning|This page is '''outdated'''. In the [[Online Developer Meeting (2020-07-07)]] the Octave community decided to use [https://octave.discourse.group/ discourse].}}<br />
<br />
On the Octave help and maintainers mailing-list <br />
<ref>https://lists.gnu.org/archive/html/help-octave/2019-12/msg00133.html</ref><br />
<ref>https://lists.gnu.org/archive/html/help-octave/2020-01/msg00000.html</ref><br />
<ref>https://lists.gnu.org/archive/html/octave-maintainers/2020-01/msg00001.html</ref><br />
<ref>https://lists.gnu.org/archive/html/octave-maintainers/2019-12/msg00144.html</ref><br />
a discussion about a potential user forum has been started.<br />
<br />
== Forum candidates ==<br />
<br />
<br />
{| class="wikitable"<br />
! Software<br />
! Working demo<br />
! Requirements (see [[Special:Version]])<br />
|-<br />
| [https://www.phpbb.com/ phpBB]<br />
| [https://forum.freecadweb.org/viewtopic.php?f=10&t=28838 example]<br />
| <ref>https://www.phpbb.com/support/documents.php?mode=install&version=3#require</ref> MySQL 3.23+ <span style='color:green;'>&#9989;</span> PHP 5.4.7+ but less than PHP 7.3 <span style='color:green;'>&#9989;</span> <br />
|-<br />
| [https://discourse.org/ discourse]<br />
| [https://meta.discourse.org/t/merge-users-plugin/114917 example]<br />
| <ref>https://github.com/discourse/discourse/blob/master/docs/INSTALL.md</ref> Ruby 2.5.2+ [2.5.1p57] <span style='color:red;'>X</span><br />
|-<br />
| [https://github.com/CyberShadow/DFeed DFeed]<br />
| [https://forum.dlang.org/ example]<br />
| ?<br />
|}<br />
<br />
[[Category:Outdated pages]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=User:Siko1056&diff=13320User:Siko10562020-09-08T05:57:10Z<p>Siko1056: Some updates.</p>
<hr />
<div>This is '''Kai Torben Ohlhus''' (a.k.a. '''siko1056''' on Discourse and alike). I started contributing to GNU Octave during [[Summer of Code#GSoC 2013|GSoC 2013]] as student and worked on incomplete factorizations (read my [http://siko1056-gsoc.blogspot.com/ blog]). The project was completed in [[Summer of Code#GSoC 2014|GSoC 2014]] by [[User:Edu159 | Eduardo]].<br />
<br />
Since 2013, I continuously support the development of [https://savannah.gnu.org/project/memberlist.php?group=octave "core" Octave] and maintain parts of the Octave [[Project Infrastructure]]:<br />
<br />
* Several [https://hg.savannah.gnu.org/hgweb/octave/log?rev=ohlhus code contributions] to GNU Octave itself.<br />
** Active member of the [https://octave.1599824.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=370282 Octave mailing-lists].<br />
** Triage the [https://savannah.gnu.org/bugs/?group=octave bug tracker] (review, comment, and push patches).<br />
** Support the release process (create and upload [interpreter] and [[Doxygen]] documentation).<br />
* Co-maintainer and caring for updates of<br />
** [[Special:ListUsers/sysop | this Octave wiki]] ([[Special:Contributions/Siko1056 |all contributions]]).<br />
** the official GNU Octave website https://www.octave.org ([https://hg.octave.org/web-octave/ page source]).<br />
** the [https://octave.discourse.group Octave Discourse forum].<br />
* [[Summer of Code | GSoC]] mentor in 2014, 2018, and 2020, co-mentor in 2017.</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Windows_Installer&diff=13319Windows Installer2020-09-08T05:49:46Z<p>Siko1056: /* make */ Clarify difference between JOBS and -j</p>
<hr />
<div>:''This article is about how to make the Microsoft Windows installer; if you'd like just to use the installer, see [[Octave for Microsoft Windows]].''<br />
GNU Octave is primarily developed on GNU/Linux and other POSIX compliant systems. There have been many efforts in the past to build ports of GNU Octave for Microsoft Windows.<br />
This page contains instructions about creating a MS Windows installer using [[MXE|mxe-octave]] (a fork of [http://mxe.cc/ MXE]).<br />
This means, '''the MS Windows installer is [https://en.wikipedia.org/wiki/Cross_compiler cross-compiled] using a GNU/Linux system'''.<br />
<br />
==Creating the MS Windows Installer==<br />
<br />
===General steps===<br />
<br />
# Install the MXE build requirements.<ref>The requirements for each system are listed in the repository https://hg.octave.org/mxe-octave/file/tip/index.html. Start with the second step to read the {{Path|index.html}} file on your local machine.</ref><br />
# <code>hg clone https://hg.octave.org/mxe-octave</code><ref>Use <code>hg clone https://hg.octave.org/mxe-octave <name of mxe-octave build dir></code> to choose another directory.</ref><br />
# <code>cd mxe-octave</code><br />
# <code>./bootstrap</code> (Among other things, the <code>bootstrap</code> script creates the <code>configure</code> script for the next step.)<br />
# <code>./configure</code><br />
# <code>make all nsis-installer</code><br />
<br />
===Step details===<br />
<br />
====<code>./configure</code>====<br />
<br />
The current Microsoft Windows installers are build in three "flavors": for common 64- and 32-bit systems ('''"w64"''' and '''"w32"''') and for 64-bit systems exceeding 32 GB of main memory to store large data structures ('''"w64-64"''').<br />
<br />
{| class="wikitable"<br />
! "w64" (recommended)<br />
! "w64-64"<br />
! "w32"<br />
|-style="vertical-align:top;"<br />
| <pre style="min-width:330px;"><br />
./configure \<br />
--enable-devel-tools \<br />
--enable-binary-packages \<br />
--with-ccache \<br />
--enable-octave=<octave version><br />
</pre><br />
| <pre style="min-width:330px;"><br />
./configure \<br />
--enable-devel-tools \<br />
--enable-binary-packages \<br />
--with-ccache \<br />
--enable-octave=<octave version> \<br />
--enable-fortran-int64<br />
</pre><br />
| <pre style="min-width:330px;"><br />
./configure \<br />
--enable-devel-tools \<br />
--enable-binary-packages \<br />
--with-ccache \<br />
--enable-octave=<octave version> \<br />
--disable-windows-64<br />
</pre><br />
|}<br />
<br />
The individual options have the following meaning (see also <code>./configure --help</code>):<br />
<br />
* <code>--enable-devel-tools</code>: Include gdb and an MSYS shell in the binary.<br />
** If you seriously want to work with gdb, you need <code>--disable-strip-dist-files</code> as configure option to keep debug symbols in the installed binaries for debugging on MS Windows. Beware as the total Octave distribution will be > 2 GB, the max. size for an NSIS installer. Your only options are to make 7z-dist, zip-dist or tar-dist installers.<br />
* <code>--enable-binary-packages</code>: Cross-compile binary modules in [[Octave Forge]] packages. This saves time when installing them once the installation runs on Microsoft Windows. Furthermore, some packages require patches to cross-compile successfully (or with current Octave versions). Those additional patches would be missing when compiling the original packages from Octave Forge on Windows later on. Some Octave Forge packages require a working Octave during compilation. Therefore, the correct version(!) of Octave must be installed on the host system.<br />
* <code>--with-ccache</code>: The usage of [https://ccache.dev/ ccache] may speed up repetitive compilation drastically.<br />
* <code>--enable-octave=<octave version></code>: Build a specific version of GNU Octave, which can be one of: <br />
** <code>release</code> use {{Path|src/release-octave.mk}}, download and build the latest GNU Octave release.<br />
** <code>stable</code> or <code>default</code> uses {{Path|src/stable-octave.mk}} or {{Path|src/default-octave.mk}}, respectively. This builds from a self-created distribution tarball from the "stable" or "default" development branch of GNU Octave. See [[#Build installers for Octave development versions|below]] for details.<br />
* <code>--disable-windows-64</code>: Build for 32-bit MS Windows.<br />
* <code>--enable-fortran-int64</code>: Use 64-bit integers in Fortran code and especially in numerical library code. This option only affects the size of integers used in Fortran code like the BLAS and LAPACK libraries. On 64-bit systems, Octave always uses 64-bit integers for indexing and basic array operations. See [[Enable large arrays: Build octave such that it can use arrays larger than 2Gb.|Enable large arrays]] for details.<br />
* <code>--disable-system-opengl</code>: Include software OpenGL libraries. This might help when working with buggy graphics card drivers, but might be slower than hardware accelerated rendering.<br />
* <code>--with-pkg-dir=../mxe-octave-pkg</code>: If you are working with several build trees, you can share a common package directory.<br />
<br />
====<code>make</code>====<br />
<br />
* Use <code>make all 7z-dist</code>, <code>make all tar-dist</code> or <code>make all zip-dist</code> instead of <code>make all nsis-installer</code> if you want to build just an archive of the files to install on MS Windows instead of an installer wizard.<br />
* By default, packages will be built one at a time '''without parallelization'''. You may use <code>make JOBS=4</code> (choose a number other than 4 that is appropriate for your system) to build each individual package in parallel.<br />
** '''Avoid using the <code>-j</code> option for <code>make</code>:''' Using <code>-j</code> enables building packages in parallel, which can mess up the mxe build system. Use this option with care! Another pitfall is the example <code>make -j4 JOBS=4</code>, which can result in as many as 16 jobs running at once.<br />
* Include gdb in the installer by running <code>make gdb</code> before making the <code>nsis-installer</code> target.<br />
<br />
===Build installers for Octave development versions===<br />
<br />
# Build the "stable" or "default" Octave development branch on Linux (in separate source and build trees) including your favorite modifications and patches. Octave must be configured with Java support. How to do this depends on your Linux distribution, see [[Building]].<br />
# Verify that Octave runs fine in Linux (for example using <code>make check</code> and by trying to run your build <code>./run-octave --gui</code>).<br />
# Create a distribution archive called '''"octave-<version>.tar.lz"''' in the top build directory with <code>make dist-lzip DIST_IGNORE_HG_STATE=1</code>. <code>lzip</code> needs to be available for this step. (On Debian-like systems, it can be installed with <code>apt-get install lzip</code>).<br />
# Move or copy '''"octave-<version>.tar.lz"''' to the {{Path|<mxe-octave build>/pkg}} folder (or create a symbolic link to it).<br />
# Follow the [[#General steps|general steps]] and ensure the configuration with either of <code>--enable-octave=stable</code> or <code>--enable-octave=default</code>.<br />
# Move the final installer in {{Path|<mxe-octave build>/dist}} to some Microsoft Windows machine (USB thumb drive, LAN copy, whatever) and install it "as usual". If you created an archive, using <code>make all 7z-dist</code> for example, you'll have to manually create the desktop and start menu shortcuts (for GNU Octave and the MSYS-shell).<br />
<br />
For next builds, mxe-octave is already configured and all dependencies have been built so the only thing to do is to create a new '''"octave-<version>.tar.lz"''' and repeating the steps above. This should be much faster than the first run. If the new '''"octave-<version>.tar.lz"''' is not build and ignored, try the following:<br />
<br />
touch src/default-octave.mk<br />
<br />
If you've renamed '''"octave-<version>.tar.lz"''', be sure it matches with the package name in {{Path|src/default-octave.mk}}.<br />
<br />
===Remarks===<br />
<br />
* If you have several MXE-Octave build dirs (for e.g., stable and several development versions, or build trees for 32bit and 64bit Windows targets), it is possible to point to a common {{Path|pkg}} directory using the configure flag <code>--with-pkg-dir=path_to_common_pkg_directory</code>. That way downloading the packages for each build tree can be avoided. Thus, potentially saving a lot of downloading bandwidth.<br />
* As of late December 2015, [https://hg.octave.org/mxe-octave/rev/0962acdde3be MXE-Octave allows out-of-tree builds]. This makes it easier to build separate Octave versions with the same MXE-Octave tree.<br />
* To keep MXE-Octave up-to-date, from time to time run the following commands in the MXE-Octave repository:<br />
hg -v pull<br />
hg -v update<br />
* However, some package updates might need a clean build tree. If an incremental build fails after an update, consider running <code>make clean</code> or starting with a fresh clone, see [[#General steps|General steps]].<br />
* In the mean time, you might want to regularly clean up {{Path|<mxe-octave build dir>/log}} to save disk space. The logs are of informational value only and are not needed after the build completes. They can safely be deleted.<br />
* It can happen that you meet problems with Java. To build Octave with Java support built-in, MXE-Octave needs:<br />
** A Java JDK (Java Development Kit) on the '''build''' system. In other words, the javac (Java compiler) and jar (Java archiver) executables should be in the PATH-system-variable.<br />
** Java include files for MS Windows. They should reside in {{Path|<mxe-octave build dir>/usr/x86_64-w64-mingw32/include/java/win32}} or {{Path|<mxe-octave build dir>/usr/i686-w64-mingw32/include/java/win32}}, respectively. If they are not present, MXE-Octave downloads them automatically. However, this might fail occasionally (e.g. if the server cannot be reached). On a multi-boot system, a solution (note: dirty hack warning!) is symlinking to the MS Windows include files on the MS Windows partition from the MXE-Octave location. (Don't do this unless you are sure what you are doing.)<br />
<br />
===Troubleshooting===<br />
<br />
* The error message displayed by <code>make</code> is simply the last lines of the log file. This may truncate the actual error message. Find the full error messages in the {{Path|<mxe-octave build>/log}} directory.<br />
* Sometimes running <code>make</code> a second time without changing anything will fix the problem. In particular, <code>autotools</code> rebuilds some files in the first call <code>make</code>, which may cause the second call of <code>make</code> to succeed.<br />
* If it is building Octave that failed, the source will be left in {{Path|<mxe-octave build>/tmp-default-octave}} and it is possible to run "configure && make" in that directory.<br />
* The configuration will be for the target system, not your own. In particular, if you have not installed all of the packages that mxe-octave installs, then your configuration will be different. However, some configuration variables will differ even if you have the same packages, and some compiler features may be available on the host system that are not available in cross-compile mode.<br />
* A possible causes for build failure is having files in your local source or build directory that are not listed in the {{Path|module.mk}} files; these are not copied into the dist archive.<br />
* Sometimes mxe-octave builds fail at "libmng". This may be due to a race condition related to disk I/O when using a fast SSD harddisk. A way to get past this is by specifying "make nsis-installer JOBS=1", if required repeatedly (sometimes 5 or 6 times), interrupting the build in the next step/dependency once "libmng" has been built fine, and restarting with "make nsis-installer JOBS=<higher number>". As of December 2015 it is only libmng that has this issue.<br />
<br />
==Testing using virtual machines==<br />
<br />
Microsoft provides several virtual machine (e.g. VirtualBox) disk images of MS Windows for about one month of testing <br />
* https://developer.microsoft.com/en-us/windows/downloads/virtual-machines<br />
* https://developer.microsoft.com/en-us/microsoft-edge/tools/vms (primarily meant for testing the MS-Edge browser)<br />
The license (given on that page) for these images does not limit the use of these images. So it is perfectly possible to also test GNU Octave.<br />
<br />
The key idea is to create a shared folder inside the virtual machine to the mxe-octave build directory. It is advised to make it read-only. Either install (or unpack) Octave into MS Windows 10, or create a shortcut to {{Path|octave.vbs}} in the {{Path|<mxe-octave build dir>/dist/octave}} subdirectory on the Linux side.<br />
<br />
Some advantages:<br />
* No dedicated MS Windows machine or rebooting from Linux is needed;<br />
* The <strike>latest</strike> MS Windows 10 version is always available;<br />
* Building the installer archives (zip, 7z, ...) isn't needed. One can interrupt the build process after the local installation of Octave has been made in the dist/octave subdirectory of mxe-octave, i.e., when the message "generating installer" (or "zip...") is shown. This saves about 10-15 minutes. Of course one can also use the common distribution formats for the virtual MS Windows machine.<br />
<br />
Hints:<br />
* It is possible to adapt {{Path|mxe-octave/binary-dist-rules.mk}} to have a consistent name for the {{Path|<mxe-octave build dir>/dist/octave}} subdirectory (i.e., without time/date/bitwidth suffixes). This way, in MS Windows the shortcut doesn't need adaptation after each cross-build action. Maybe it would be better if {{Path|mxe-octave/binary-dist-rules.mk}} had a rule to create a symlink {{Path|<mxe-octave build dir>/dist/octave}} pointing to the latest cross-build.<br />
* The image expires after 30 days. But if you make a VirtualBox snapshot before starting the VM the first time, you can revert to that snapshot (essentially, the image will last longer). This way, you also won't need to uninstall Octave each time before installing a new build.<br />
<br />
==Footnotes==<br />
<br />
<references/><br />
<br />
[[Category:Building]]<br />
[[Category:Microsoft Windows]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Video_tutorials&diff=13312Video tutorials2020-08-30T03:27:03Z<p>Siko1056: Minor fixes.</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
| [https://www.youtube.com/playlist?list=PLCq1Hx5o5Rk0UH6Bnxx7OednyhVPOEgyj '''Octave Tutorial''' by Nicolas N]<br />
| 2020<br />
| 4 parts<br />
|-<br />
| [https://www.youtube.com/watch?v=sHGqwF2s-tM '''Learn GNU Octave under 10 Minutes''' by DevNami]<br />
| 2017<br />
| 1 part<br />
|-<br />
| [https://www.youtube.com/playlist?list=PL04PA2q0LfJI4kLcW0EKQcetWZd4q5bBP '''Octave and FreeMat Tutorial''' by Andrew Norman]<br />
| 2013<br />
| 7 parts<br />
|-<br />
| [https://www.youtube.com/channel/UCr-6gDvh0atAFM4VuYq7PHw/videos?sort=p&view=0&flow=list '''Octave Tutorial''' by Paul Nissenson]<br />
| 2011<br />
| 35 parts<br />
|}<br />
<br />
[[Category:Tutorials]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Video_tutorials&diff=13311Video tutorials2020-08-30T03:22:42Z<p>Siko1056: Add "Octave Tutorial" 2020.</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
| [https://www.youtube.com/playlist?list=PLCq1Hx5o5Rk0UH6Bnxx7OednyhVPOEgyj '''Octave Tutorial''' by <br />
Nicolas N]<br />
| 2020<br />
| 4 parts<br />
|-<br />
| [https://www.youtube.com/watch?v=sHGqwF2s-tM '''Learn GNU Octave under 10 Minutes''' by DevNami]<br />
| 2017<br />
| 1 part<br />
|-<br />
| [http://www.youtube.com/playlist?list=PL04PA2q0LfJI4kLcW0EKQcetWZd4q5bBP '''Octave and FreeMat Tutorial''' by Andrew Norman]<br />
| 2013<br />
| 7 parts<br />
|-<br />
| [https://www.youtube.com/channel/UCr-6gDvh0atAFM4VuYq7PHw/videos?sort=p&view=0&flow=list '''Octave Tutorial''' by Paul Nissenson]<br />
| 2011<br />
| 35 parts<br />
|}<br />
<br />
[[Category:Tutorials]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=FAQ&diff=13295FAQ2020-08-22T01:29:09Z<p>Siko1056: /* MS Windows */</p>
<hr />
<div>This is a list of frequently asked questions (FAQ) for GNU Octave users.<br />
<br />
We are always looking for new questions (with answers), better answers, or both. Feel free to edit this page with your changes.<br />
<br />
=Where do I get additional help?=<br />
<br />
If you can't find an answer to your question in this FAQ, wiki, or in the [http://www.octave.org/doc/interpreter manual] ([http://www.octave.org/octave.pdf PDF]) you can:<br />
<br />
* Search for an answer in our [https://lists.gnu.org/archive/html/help-octave/ mailing list archives]<br />
* Contact our user community using our [https://octave.discourse.group Octave Discourse].<br />
* Contact our user community using our [https://webchat.freenode.net/?channels=octave IRC chat room <code>#octave</code> in Freenode]<br />
<br />
<div class="tocinline">__TOC__</div><br />
<br />
=General=<br />
<br />
==What is Octave?==<br />
<br />
[https://www.gnu.org/software/octave/ GNU Octave] is a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems, and for performing other numerical experiments. It also provides extensive graphics capabilities for data visualization and manipulation. GNU Octave is normally used through its interactive interface ([https://en.wikipedia.org/wiki/Command-line_interface CLI] and [https://en.wikipedia.org/wiki/Graphical_user_interface GUI]), but it can also be used to write non-interactive programs. <br />
The GNU Octave language is quite similar to Matlab so that most programs are easily portable.<br />
<br />
The GNU Octave distribution includes a [http://www.octave.org/octave.pdf 1000+ page Texinfo manual]. Access to the complete text of the manual is available via the <code>doc</code> command at the GNU Octave prompt.<br />
<br />
==What is Octave Forge?==<br />
<br />
[https://octave.sourceforge.io/ Octave Forge] is a collection of [[packages]] for GNU Octave, something similar to the Matlab toolboxes. When talking about the two projects at the same time, GNU Octave is usually referred to as Octave core (or just "core"). Octave Forge also serves as a test bed for code that may eventually end up in the core, and distributes binaries for systems with a lack of developers tools (mainly Windows).<br />
<br />
==Who uses Octave?==<br />
<br />
A huge number of people ranging from students to researchers involved in various fields such as statistics,Machine Learning, data analytics, etc. Universities use it for research and teaching, companies of all sizes for development and individuals for certain private purposes. See [[Who Uses Octave?]] for more clarity.<br />
<br />
==Who develops Octave?==<br />
<br />
Discussions about writing the software that would eventually become Octave started in about 1988 with James B. Rawlings and [http://jweaton.org/ John W. Eaton] at the University of Texas. John W. Eaton is the original author of Octave, starting full-time development in February 1992. He is still the primary maintainer. The community of users and developers has in addition contributed some code and fuels the discussion on the mailing lists [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org] (user forum), [https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers@octave.org] (development issues). Since 2011, GNU Octave regularly participates in [[Summer of Code]] events as a mentor organisation. As part of those events, several students contributed to Octave by helping in removal of bugs and development of new features.<br />
<br />
==Why "Octave"?==<br />
<br />
Octave's name has nothing to do with music. It is named after [http://en.wikipedia.org/wiki/Octave_Levenspiel Octave Levenspiel], a former professor of John who was famous for his ability to do quick back-of-the-envelope calculations. You can hear John pronounce the name "Octave" a few times [http://videolectures.net/mloss08_eaton_oct/ in this video]. We hope that GNU Octave will help perform computations with the same ease as Dr. Levenspiel.<br />
<br />
==Why "GNU" Octave?==<br />
<br />
The [https://www.gnu.org/ GNU Project] was launched in 1984 to develop a complete Unix-like operating system which is free software: the GNU system. GNU is a recursive acronym for "GNU's Not Unix"; it is pronounced [https://www.gnu.org/gnu/pronunciation.en.html g'noo].<br />
<br />
The [https://www.fsf.org/ Free Software Foundation (FSF)] is the principal organization that has sponsored the GNU Project.<br />
<br />
Octave became GNU Octave in 1997 (beginning with [[Release History|version 2.0.6]]). This meant agreeing to consider Octave a part of the GNU Project and support the efforts of the FSF. A big part of this effort is to adhere to the [https://www.gnu.org/prep/standards/standards.html GNU coding standards] and to benefit from GNU's infrastructure (e.g. [https://hg.savannah.gnu.org/hgweb/octave/ code hosting] and [http://bugs.octave.org bug tracking]). Additionally, Octave receives [https://my.fsf.org/donate/working-together/octave sponsorship] from the FSF's Working Together fund. However, Octave is not and has never been developed by the FSF.<br />
<br />
==How can I cite Octave?==<br />
<br />
Octave is free software and does not legally bind you to cite it. However, we have invested a lot of time and effort in creating GNU Octave, and we would appreciate if you would cite if you used. To cite GNU Octave in publications use:<br />
<br />
John W. Eaton, David Bateman, Søren Hauberg, Rik Wehbring ({{Release Year}}).<br />
GNU Octave version {{Release}} manual: a high-level interactive language for numerical computations.<br />
URL https://www.gnu.org/software/octave/doc/v{{Release}}/<br />
<br />
A [https://en.wikipedia.org/wiki/BibTeX BibTeX] entry for [https://en.wikipedia.org/wiki/LaTeX LaTeX] users is:<br />
<br />
@manual{,<br />
title = {{GNU Octave} version {{Release}} manual: a high-level interactive language for numerical computations},<br />
author = {John W. Eaton and David Bateman and S{\o}ren Hauberg and Rik Wehbring},<br />
year = <span>{</span>{{Release Year}}},<br />
url = {https://www.gnu.org/software/octave/doc/v{{Release}}/},<br />
}<br />
<br />
Run {{manual|citation}} at the Octave prompt for details on how to best cite the Octave version you are running. Certain Octave packages also have recommended citations in which case use <code>citation package_name</code>.<br />
<br />
Note that there are two reasons for citing the software used. One is giving recognition to the work done by others which we have already addressed to. The other is giving details on the system used so that experiments can be replicated. For this, you should cite the version of Octave and all packages used (you can get this information using the <code>ver</code> command), as well as any details of your setup as part of your Methods. In addition, you should make your source available as well. See [http://software.ac.uk/so-exactly-what-software-did-you-use How to cite and describe software] for more details and an in depth discussion for the same.<br />
<br />
==What documentation exists for Octave?==<br />
<br />
Besides this wiki, the GNU Octave distribution includes a [http://www.octave.org/doc/interpreter 1000+ page Texinfo manual] ([http://www.octave.org/octave.pdf PDF]). Access to the complete text of the manual is available via the {{manual|doc}} command at the GNU Octave prompt. If you have problems using this manual, or find that some topic is not adequately explained, indexed, or cross-referenced, please report it on http://bugs.octave.org.<br />
<br />
==How can I report a bug in Octave?==<br />
<br />
Please read our website http://www.octave.org/bugs.html.<br />
<br />
<br />
= Common problems =<br />
<br />
== Octave does not start ==<br />
<br />
The following steps have been the solution to several bug reports and help requests. Please try them before asking for further support. If nothing below helps, please give us the following information:<br />
<br />
* Operating system: e.g. [https://support.microsoft.com/en-us/help/13443/windows-which-version-am-i-running '''MS Windows 10 (version 2004)'''] or '''Ubuntu 20.04'''<br />
* GNU Octave version: e.g. '''Version {{Release}}'''<br />
* Installation method: e.g. '''Downloaded and installed "octave-{{Release}}-w64-installer.exe" from https://www.octave.org/download.html'''<br />
<br />
=== MS Windows ===<br />
<br />
* After Octave upgrade the GUI does not open / shuts down immediately.<br />
** '''Solution:''' Delete the folder {{path|C:\Users\YOUR_USER_NAME\.config\octave}}<br />
* Missing/conflicting files.<br />
** '''Solution:''' Remove/Uninstall all existing Octave versions. Restart the system. Install GNU Octave again.<br />
<br />
* Permission errors<br />
** '''Solution 1:''' Octave on MS Windows uses VBS scripts to start the program. You can test whether your system is blocking VBS scripts by doing the following:<br />
**# Using Notepad or another text editor, create a text file containing only the text: <pre>msgbox("This is a test script, Click OK to close")</pre><br />
**# Save the file on your Desktop with the name {{Path|testscript.vbs}} (be sure that the editor didn't end it in .txt or .vbs.txt).<br />
**# Double click the file. If scripts can run, a popup window will appear with that message. <br />
**#* If the file opens in notepad or an editor, it means it still ended in .txt. MS Windows insecurely hides file extensions by default. To show file extensions follow [https://answers.microsoft.com/en-us/windows/forum/all/in-win10-how-to-show-the-file-extension-for/ed21ff20-cdb3-4263-9c7d-fc6ed125fc82 these instructions at Microsoft.com].<br />
**#* If both {{Path|testscript.vbs}} and {{Path|octave.vbs}} open a text- or other editor, it means your MS Windows file associations have .vbs files associated with another program. To fix this, right click the .vbs file, select "Open With", select "Choose Another App", check the box that says "Always use this app to open .vbs files". Finally, select "Microsoft Windows Based Script Host" from the list. If it is not in the list, select "More apps". If still not there, select "Look for Another App on this PC" and navigate to {{Path|C:\Windows\System32\wscript.exe}}, select it, and select "Open". If {{Path|wscript}} is still not present you will need to seek assistance installing missing MS Windows components.<br />
**# Try moving {{Path|testscript.vbs}} to another location, such as a {{Path|C:\temp folder}}. Additionally try to move {{Path|testscript.vbs}} in the Octave installation folder containing {{Path|octave.vbs}} and see if VBS scripts can be run there.<br />
**# If {{Path|testscript.vbs}} doesn't run in any of those locations, then scripting appears to be disabled or blocked on your system. If {{Path|testscript.vbs}} runs in some locations but not others, there there may be other security permissions errors to be solved. If {{Path|testscript.vbs}} runs in the same folder as {{Path|octave.vbs}}, but directly double-clicking on {{Path|octave.vbs}} does not start Octave, then there appears to be some problem other than script permissions. <br />
** '''Solution 2:''' Consult your malware detection (a.k.a. AntiVirus) software, if files are blocked.<br />
** '''Solution 3:''' Did you install Octave on a network-drive? Do you have the execution permissions?<br />
** '''Solution 4:''' Is your computer managed by your company? Does your administrator prohibit script execution?<br />
<br />
==I do not see any output of my script until it has finished?==<br />
<br />
By default Octave is set to pass its screen output through a [https://en.wikipedia.org/wiki/Terminal_pager pager] (usually the default pager is "less") which allows things such as navigating through the output with arrow keys or searching for text or regular expressions within the output. The pager only displays the output after it's finished receiving it, so when it is active you'll not be able to see anything until your script has terminated. To change this behavior temporarily or permanently you may want to use one of the options described [https://www.octave.org/doc/interpreter/Paging-Screen-Output.html in the manual].<br />
<br />
==When I try plotting from a script, why am I not seeing anything?==<br />
<br />
If you are running an Octave script that includes a plotting command, the script and Octave may terminate immediately. So the plot window does show up, but immediately closes when Octave finishes execution. Alternatively, if using fltk, the plot window needs a readline loop to show up (the time when Octave is sitting around doing nothing waiting for interactive input).<br />
<br />
A common solution is to put a {{manual|pause}} command at the end of your script.<br />
<br />
==How do I get sound input or output in MS Windows?==<br />
<br />
Sound input from a sound card and output to a sound card is fully supported since Octave 4.0.0 for all platforms. If you have problems with the [https://www.octave.org/doc/interpreter/Audio-Processing.html audio I/O functions] using Octave 4.0.0 or a newer version, please report them on the [http://bugs.octave.org bug tracker].<br />
<br />
==I have problem X using the latest Octave version==<br />
<br />
Please be more specific about what you mean by "latest version"?<br />
<br />
* The latest stable version is {{Release}}. Be aware that you may still have an older version due to whatever distribution method you are using. To get a newer stable version for your system see the following as in accordance to your Operating system: [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], or [[Octave for Microsoft Windows|Windows]].<br />
<br />
* If you refer to the latest Mercurial revision, please specify the [https://www.mercurial-scm.org/wiki/ChangeSetID changeset ID] not the revision number, e.g. the output of <code>hg summary</code> or <code>hg id</code>. Changeset IDs are globally unique across all repos.<br />
<br />
If your problem still persists with the "latest version", then please [http://bugs.octave.org/ report a bug] or ask for help at [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org]. Otherwise, don't be surprised if volunteers are less inclined to help you with a problem that only exists in an older version of Octave and is already fixed in a newer version.<br />
<br />
==Why is Octave's floating-point computation wrong?==<br />
<br />
Floating-point arithmetic is an approximation '''in binary''' to arithmetic on real or complex numbers. Just like you cannot represent 1/3 exactly in decimal arithmetic (0.333333... is only a rough approximation to 1/3), you cannot represent some fractions like <math>1/10</math> exactly in base 2. In binary, the representation to one tenth is <math>0.0\overline{0011}_b</math> where the bar indicates that it repeats infinitely (like how <math>1/6 = 0.1\overline{6}_d</math> in decimal). Because this infinite repetition cannot be represented exactly with a finite number of digits, rounding errors occur for values that appear to be exact in decimal but are in fact approximations in binary, such as for example how 0.3 - 0.2 - 0.1 is not equal to zero.<br />
<br />
In addition, some advanced operations are computed by approximation and there is no guarantee for them to be accurate, see [https://en.wikipedia.org/wiki/Rounding#Table-maker.27s_dilemma Table-maker's dilemma] for further references. Their results are system-dependent.<br />
<br />
This isn't a bug that is limited to GNU-Octave & it happens with any program that uses [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754 floating-point arithmetic]. To be fair, IEEE 754 also specifies decimal floating-point arithmetic, which has never seen wide adoption. The reason why Octave and other programs using IEEE 754 binary floating-point numbers is that they are ''fast'', because they are implemented in hardware or system libraries. Unless you are using very exotic hardware, Octave will use your computer's processor for basic floating-point arithmetic.<br />
<br />
Another approach to deal with rounding errors is interval arithmetic with the [[Interval package]] or symbolic computations with the [[Symbolic package]]. These approaches are likely to be slower, since not all operations can be performed on Hardware like pure floating-point arithmetic.<br />
<br />
To learn more about floating-point arithmetic, consult this [https://en.wikipedia.org/wiki/Floating-point_arithmetic Wikipedia article] or the classical reference by David Goldberg [http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html What Every Computer Scientist Should Know About Floating-Point Arithmetic].<br />
<br />
==Missing lines when printing under Windows with OpenGL toolkit and Intel integrated GPU==<br />
<br />
Some windows users with integrated Intel GPUs have reported missing lines when printing with an OpenGL toolkit like FLTK or Qt. {{bug|42534}}<br />
<br />
Users with this kind of problem should try to install/update their Intel OpenGL drivers for Windows or consider installing Mesa drivers from http://qt-project.org/wiki/Cross-compiling-Mesa-for-Windows.<br />
<br />
See also https://www.opengl.org/wiki/FAQ#Why_is_my_GL_version_only_1.4_or_lower.3F .<br />
<br />
==Plot hangs and makes the GUI unresponsive==<br />
<br />
If the Qt graphics toolkit is used and "plot" is used for the first time, the fontconfig scanner searches the font directory to build a font cache. This can take up to 3min on slow CPUs. See {{bug|45458}}<br />
<br />
==Error message about invalid call to script or invalid use of script in index expression==<br />
<br />
If Octave shows an error message about {{Codeline|invalid call to script .../close.m}} or {{Codeline|invalid use of of script .../close.m in index expression}}, it means that you have created a script called close.m that is overriding the built-in Octave function {{Codeline|close}}. Octave functions and scripts share the same global namespace. It is best to avoid creating your own scripts or functions that have the same name as an Octave function as to avoid this error regarding the invalid call to script or invalid use of script in index expression.<br />
<br />
=Licensing issues=<br />
<br />
==If I write code using Octave do I have to release it under the GPL?==<br />
<br />
The answer depends on precisely how the code is written and how it works:<br />
<br />
* Code written '''entirely in the scripting language of Octave''' (interpreted code in .m files) may be released under the terms of whatever license you choose.<br />
<br />
* Code written using [https://www.gnu.org/software/octave/doc/interpreter/Oct_002dFiles.html Octave's native code interface] (also known as a .oct file) necessarily links with Octave internals and is considered a derivative work of Octave. Therefore it must be released under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
<br />
* Code written using [https://www.gnu.org/software/octave/doc/interpreter/Mex_002dFiles.html Octave's implementation of the Matlab MEX interface] may be released under the terms of whatever license you choose, provided that the following conditions are met:<br />
<br />
:# The MEX file may not use any bindings that are specific to Octave, '''it has to use the MEX interface only'''. In other words, it should be possible in principle to use the MEX file with other programs that implement the MEX interface (e.g., Matlab). For example including an Octave header file or calling an Octave function within the MEX file, that is not related with Octave's implementation of the MEX interface make the MEX file a derivative work of Octave and has therefore to be released under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
:# The MEX file may not be distributed together with Octave in such a way that they effectively create a single work. For example, you should not distribute the MEX file and Octave together in a single package such that Octave automatically loads and runs the MEX file when it starts up. There are other possible ways to effectively create a single work.<br />
<br />
* Code that '''embeds the Octave interpreter''' (e.g., by calling the <code>octave_main</code> function), or that calls functions from Octave's libraries (e.g., liboctinterp, liboctave, or libcruft) is considered a derivative work of Octave and therefore must be released under terms that are compatible with the GPL.<br />
<br />
==Will you change the license of the Octave libraries for me?==<br />
<br />
'''No.''' Instead of asking us to change the licensing terms for Octave, we recommend that you release your program under terms that are compatible with the GPL, this way the free software community can be benefited from your work the same as you were/have benefited from the work of all the people who have contributed to Octave.<br />
<br />
==Should I favor the MEX interface to avoid the GPL?==<br />
<br />
'''No.''' The original reason for implementing the [https://www.gnu.org/software/octave/doc/interpreter/Mex_002dFiles.html MEX interface] for Octave was to allow Octave to run free software that uses MEX files (the particular goal was to run [https://computation.llnl.gov/projects/sundials/release-history#sundialsTB sundialsTB] in Octave). The intent was to liberate that software from Matlab and increase the amount of free softwares available to Octave users & not to enable people to write proprietary code for Octave. For the good of the community, we strongly encourage users of Octave to release the code they write for Octave under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
<br />
==Why can't I use code from File Exchange in Octave?==<br />
<br />
According to the Matlab Central [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use] (Last updated: 10-Aug-2016), all submitted code is licensed under the [https://en.wikipedia.org/wiki/BSD_licenses BSD license] by default (cf. § 5 [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use]), but it is clearly stated that:<br />
<br />
{{Quote|text=Content submitted to File Exchange may only be used with MathWorks products. | |§ 2(a)(iii) [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use]}}<br />
<br />
That does not apply to GNU Octave, therefore the usage is in general prohibited. It should suffice — although interpretations of this vary — to contact the author directly to send you the code personally (maybe released under a free license), or download the code from the author's own website, if available. [[Asking_for_package_to_be_released_under_GPL:_examples|Some examples of letters/email sent to authors for that purpose]].<br />
<br />
=Installation=<br />
<br />
==How can I install Octave on Windows?==<br />
<br />
:'' So as to install GNU-Octave for Windows O.S, refer to : [[Octave for Microsoft Windows]]''<br />
<br />
==How can I install Octave on MacOS?==<br />
<br />
:''So as to install GNU-Octave for MacOS, refer to : [[Octave for macOS]]''<br />
<br />
==How can I install Octave on GNU/Linux?==<br />
<br />
:'' So as to install GNU-Octave on GNU/Linux, refer to: [[Octave for GNU/Linux]]''<br />
<br />
==How to install Octave on Android OR What is the Octave app available in the Google Play store?==<br />
<br />
There is an '''unofficial''' Octave app available for Android in the Google Play store. Please see [[Octave for Android]] for further information.<br />
<br />
==How can I install Octave on platform X?==<br />
<br />
Octave currently runs on [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]]. It should be possible to make Octave work on other systems as well. If you are interested in porting Octave to other systems, please contact the maintainers development mailing list [https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers@octave.org].<br />
<br />
==What Octave version should I use?==<br />
<br />
For general use, it is recommended to use the latest stable version of Octave (currently {{Release}}), available from http://www.octave.org/download.html. For development and bleeding-edge features one can obtain the development source code from the Mercurial repository https://hg.savannah.gnu.org/hgweb/octave/graph/.<br />
<br />
The used version of Octave is available via the {{manual|ver}} command and a list of user-visible changes since the last release is available via the {{manual|news}} command at the GNU Octave prompt.<br />
<br />
==On what platforms does Octave run?==<br />
<br />
Octave runs on any platform you can compile it on. Binary distributions exist for [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]]. To work fully functional, Octave requires the used platform to support the underlying numerical libraries like [https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms BLAS], [https://en.wikipedia.org/wiki/LAPACK LAPACK], [http://www.suitesparse.com SuiteSparse], etc., and for plotting [https://www.opengl.org/ OpenGL] or [http://www.gnuplot.info/ gnuplot].<br />
<br />
==How can I obtain Octave's source code?==<br />
<br />
The latest version of the Octave source code (and older versions) is available from:<br />
<br />
* https://www.octave.org/download.html<br />
* https://ftp.gnu.org/gnu/octave/<br />
<br />
Since Octave is distributed under the terms of the GPL, you can get Octave from a friend who has a copy.<br />
<br />
==How can I build Octave from the source code?==<br />
<br />
To use Octave it is usually not required to build it from it's source code. Binary distributions exist for [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]].<br />
<br />
If you have reasons to build Octave from the source code, see [[Building]] for more information.<br />
<br />
==What do I need to build Octave from the source code?==<br />
<br />
For a list of build dependencies, refer to [[Building]].<br />
<br />
==Do I need GCC to build Octave from the source code?==<br />
<br />
No. The development is done primarily with [https://gcc.gnu.org/ GCC], so you may hit some incompatibilities. Octave is intended to be portable to any standard conforming compiler (for example [https://clang.llvm.org/ clang] is known to work as well). If you face any difficulties that you think are bugs, please report them to the [http://bugs.octave.org bug tracker], or ask for help on the [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org mailing list].<br />
<br />
=What's new in Octave?=<br />
<br />
Each new Octave release introduces many new features. A complete list of user visible changes can be seen by running <code>news</code> at the Octave prompt.<br />
<br />
* '''What's new in the next version of Octave?'''<br />
** See the [https://hg.savannah.gnu.org/hgweb/octave/file/tip/NEWS NEWS file] on the development branch.<br />
* '''What was new in Octave Version X.Y.Z?'''<br />
** See [[Release History]].<br />
<br />
=Packages and Octave Forge=<br />
<br />
==How do I install or load all Octave Forge packages?==<br />
<br />
Do not do it! Really, there is no reason to do this. Octave has many packages for different needs and is unlikely that you need all of them. You either have a small set of required packages, in which case<br />
you know them by name; or you want them all "just because", in which case you don't really need them.<br />
<br />
The common misconception is that the more packages one has installed and loaded, the more complete and powerful its Octave installation will be. However, in the same way one would never install all perl modules, ruby gems, python packages, and C++ libraries (because it simply makes no sense), one should not install all Octave packages.<br />
<br />
Packages should be installed and loaded selectively. Note that some packages are meant to shadow core functions changing the way Octave works, and that different packages can have different functions with the same name leading to unpredictable results.<br />
<br />
If you really really really want to do load all packages, you can with the following:<br />
<syntaxhighlight lang="octave"><br />
## WARNING: loading all packages is probably not the solution you are looking for.<br />
cellfun (@(x) pkg ("load", x.name), pkg ("list"));<br />
</syntaxhighlight><br />
<br />
==I have installed a package but still get a "foo undefined" error?==<br />
<br />
You have probably forgotten to load the package. Use {{Codeline|pkg load package-name}} to load it. Most packages are no longer loaded automatically to avoid surprises. See reasoning on related FAQ [[FAQ#How_do_I_install_all_Octave_packages.3F|how do I install all Octave packages]]. If you want a specific package to be loaded by default at startup, consider adding the {{Codeline|pkg load}} command on your {{path|[[.octaverc]]}} file.<br />
<br />
==I cannot install a package. Octave complains about a missing mkoctfile.==<br />
<br />
You should normally use your distribution's packages. For Debian and Fedora, Octave package <code>foo</code> will be a deb or rpm called <code>octave-foo</code>, and you should install that instead using <code>apt</code> or <code>yum</code>.<br />
<br />
If you really need to build Octave packages from source to install them, you'll need {{manual|mkoctfile}}. Most distributions split Octave into several packages. The script {{manual|mkoctfile}} is then part of a separate package:<br />
<br />
* Debian/Ubuntu: [https://packages.debian.org/stretch/liboctave-dev liboctave-dev]<br />
<br />
* Fedora: {{Codeline|octave-devel}}<br />
<br />
==How do I automatically load a package at Octave startup?==<br />
<br />
When Octave starts, it runs the file {{Path|~/.octaverc}} (in your user's home directory). If you want Octave to automatically load a package, simply add a <code>pkg load pkg-name</code> command to it. If the files does not exist, create it.<br />
<br />
If you do this, remember that other people may not have Octave configured to load packages at startup. Therefore, if you write code for others, remember that your programs still need to load the packages they require.<br />
<br />
=Octave usage=<br />
<br />
==How do I execute an Octave script?==<br />
<br />
First of all, make sure you understand [http://www.octave.org/doc/interpreter/Script-Files.html the difference between script files and function files]. If you want to execute a function defined in a file, just call the function like any other Octave function: <code>foo(arg1, arg2);</code><br />
<br />
To execute a script from within Octave, just type its name without the <code>.m</code> extension. Thus, if you have a script called <code>foo.m</code>, just type <code>foo</code> from within the Octave command prompt to execute it. You have to make sure that the script is in your current working directory or in Octave's load path. Type {{manual|pwd}} to get the current working directory or type {{manual|path}} to see which paths belong to Octave's load path. The current working directory is referred to as "." in the output of {{manual|path}}.<br />
<br />
If the script name has characters that are not valid for an Octave identifier, or if you do not want to use {{manual|addpath}} to add the script's location to the current path, you can use the {{manual|run}} function instead:<br />
<br />
<syntaxhighlight lang="octave"><br />
run ("Script Name With Spaces.m")<br />
run ("/opt/local/foo.m")<br />
</syntaxhighlight><br />
<br />
An alternative is to run the script from outside Octave by calling Octave from your operating system shell. Unlike calling the script from inside Octave, this also allows you to pass arguments from the shell into the script, which the script can access using the {{manual|argv}} command:<br />
<br />
$ octave the-script.m arg1 arg2<br />
<br />
In a Unix environment, if the script has a [http://en.wikipedia.org/wiki/Shebang_%28Unix%29 shebang] (e.g. <code>#!/usr/bin/octave</code>) and executable permissions, you can call it like any other Unix program with arguments:<br />
<br />
$ ./the-script arg1 arg2<br />
<br />
If you call the script from the shell and it's plotting, please note [[#When I try plotting from a script, why am I not seeing anything?|how to plot when running a script from the shell]].<br />
<br />
==How do I close a figure?== <br />
<br />
To close the current figure type {{manual|close}} in the Octave command prompt.<br />
<br />
==How do I set the number of displayed decimals?==<br />
<br />
You can control the number of displayed decimals using the {{manual|format}} command:<br />
<br />
<syntaxhighlight lang="octave"><br />
>> format long<br />
>> pi<br />
pi = 3.14159265358979<br />
>> format short<br />
>> pi<br />
pi = 3.1416<br />
</syntaxhighlight><br />
<br />
==How do I call an Octave function from C++?==<br />
<br />
Please read the manual https://www.gnu.org/software/octave/doc/interpreter/Calling-Octave-Functions-from-Oct_002dFiles.html.<br />
<br />
==How do I change color/line definition in gnuplot postscript?==<br />
<br />
Here is a awk script to get a rainbow color map<br />
<br />
#!/bin/awk -f<br />
<br />
BEGIN {<br />
split("0 4 6 7 5 3 1 2 8", rainbow, " ");<br />
split("7 3 1 0 2 4 6 5 8", invraim, " ");<br />
}<br />
<br />
$1 ~ /\/LT[0-8]/ {<br />
n = substr($1, 4, 1);<br />
if (n == 0)<br />
lt = "{ PL [] 0.9 0.1 0.1 DL } def";<br />
else if (n == 1)<br />
lt = "{ PL [4 dl 2 dl] 0.1 .75 0.1 DL } def";<br />
else if (n == 2)<br />
lt = "{ PL [2 dl 3 dl] 0.1 0.1 0.9 DL } def";<br />
else if (n == 3)<br />
lt = "{ PL [1 dl 1.5 dl] 0.9 0 0.8 DL } def";<br />
else if (n == 4)<br />
lt = "{ PL [5 dl 2 dl 1 dl 2 dl] 0.1 0.8 0.8 DL } def";<br />
else if (n == 5)<br />
lt = "{ PL [4 dl 3 dl 1 dl 3 dl] 0.9 0.8 0.2 DL } def";<br />
else if (n == 6)<br />
lt = "{ PL [2 dl 2 dl 2 dl 4 dl] 0.5 0.3 0.1 DL } def";<br />
else if (n == 7)<br />
lt = "{ PL [2 dl 2 dl 2 dl 2 dl 2 dl 4 dl] 1 0.4 0 DL } def";<br />
else if (n == 8)<br />
lt = "{ PL [2 dl 2 dl 2 dl 2 dl 2 dl 2 dl 2 dl 4 dl] 0.5 0.5 0.5 DL } def";<br />
$0 = sprintf("/LT%d %s", rainbow[n+1], lt);<br />
##$0 = sprintf("/LT%x %s", invraim[n+1], lt);<br />
##$0 = sprintf("/LT%x %s", n, lt);<br />
}<br />
<br />
{ print; }<br />
<br />
==How do I tell if a file exists?==<br />
<br />
One can use the function {{manual|exist}} to tell if a regular file, say <code>foo.txt</code> exist in Octave's load path, or the current directory:<br />
<br />
<syntaxhighlight lang="octave"><br />
>> exist ("foo.txt", "file") # 2, if file exists, 0 otherwise<br />
ans = 2<br />
</syntaxhighlight><br />
<br />
==How do I create a plot without a window popping up (plot to a file directly)?==<br />
<br />
<syntaxhighlight lang="octave"><br />
figure (1, "visible", "off");<br />
plot (sin (1:100));<br />
print -deps "/tmp/sin.eps"<br />
</syntaxhighlight><br />
<br />
One can set that behavior as default:<br />
<br />
<syntaxhighlight lang="octave"><br />
set (0, "defaultfigurevisible", "off");<br />
</syntaxhighlight><br />
<br />
==How do I increase Octave's precision?==<br />
<br />
Octave's default numerical type is [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754] binary64, a.k.a. "double" or "hardware floats". This type has a precision of 53 bits or about 16 decimal digits. It is supported by each modern computer hardware, so it is really '''fast'''. This type is assumed throughout for Octave's calculations. If more precision was required, one can obtain a "few bits more" by using integer types, e.g. {{manual|uint64}}, but in general one cannot expect more precision from any '''fast''' numerical software. Just to visualize "how big" those numerical limits are, consider the following table:<br />
<br />
{| class="wikitable"<br />
|+ Limits of some of Octave's data types obtained by {{manual|intmax}} and {{manual|flintmax}}.<br />
|-<br />
| <code>intmax ("uint64")</code><br />
| style="text-align: right;" | <code>18,446,744,073,709,551,615</code><br />
| <code>2^64-1</code><br />
|-<br />
| <code>intmax ("int64")</code><br />
| style="text-align: right;" | <code>9,223,372,036,854,775,807</code><br />
| <code>2^63-1</code><br />
|-<br />
| <code>flintmax ("double")</code><br />
| style="text-align: right;" | <code>9,007,199,254,740,992</code><br />
| <code>2^53</code><br />
|-<br />
| <code>flintmax ("single")</code><br />
| style="text-align: right;" | <code>16,777,216</code><br />
| <code>2^24</code><br />
|}<br />
<br />
When working with other types than "double" in Octave, one has to make sure, that the first operand is converted to the desired type:<br />
<br />
<syntaxhighlight lang="Octave"><br />
>> uint64 (2^53 + 1)<br />
ans = 9007199254740992<br />
>> uint64 (2^53) + 1<br />
ans = 9007199254740993<br />
</syntaxhighlight><br />
<br />
Notice the difference, in the first line the addition within the brackets is performed using double precision, therefore the result gets "truncated" to the maximum possible value without a warning. The third line uses throughout uint64 precision.<br />
<br />
Consider carefully if your problem really needs more precision. Often if you're running out of precision the problem lies fundamentally in your methods being [https://en.wikipedia.org/wiki/Numerical_stability numerically unstable], thus more precision will not help you here.<br />
<br />
If you absolutely must have more precision, you're at present better off using a [https://en.wikipedia.org/wiki/Computer_algebra_system CAS] instead of Octave. However, CAS or symbolic computations must be implemented '''in software''' which makes it much slower than hardware floats. An example of such a CAS is [http://www.sagemath.org/ Sage] or have a look at Octave's [[Symbolic package]].<br />
<br />
==How do I run a Matlab P-file in Octave?==<br />
<br />
You can't. Matlab P-files (files with a <code>.p</code> file extension), also known as P-code, are [https://en.wikipedia.org/wiki/Obfuscation_%28software%29 obfuscated] files that cannot be run outside of Matlab itself. The original source Matlab m-files that were used to generate these P-files should be used in Octave instead.<br />
<br />
There are no plans to support running P-files produced by Matlab in Octave.<br />
<br />
==How does Octave solve linear systems?==<br />
<br />
In addition to consulting Octave's source for the precise details, you can read the Octave manual for a complete high-level description of the algorithm that Octave uses to decide how to solve a particular linear system, e.g. how the backslash operator <code>A \ x</code> will be interpreted. Sections [http://www.octave.org/doc/interpreter/Techniques-Used-for-Linear-Algebra.html Techniques Used for Linear Algebra] and [http://www.octave.org/doc/interpreter/Sparse-Linear-Algebra.html Linear Algebra on Sparse Matrices] from the manual describe this procedure.<br />
<br />
==How do I do X?==<br />
<br />
You are probably looking for the function {{manual|lookfor}}. This function searches the help text of all functions for a specific string and returns a list of functions. Note that by default it will only search the first line of the help text (check <code>help lookfor</code> at the octave prompt for more). The following example helps to find the function to calculate correlation coefficient in a matrix:<br />
<br />
>> lookfor correlation<br />
corr Compute matrix of correlation coefficients.<br />
corrcoef Compute a matrix of correlation coefficients.<br />
spearman Compute Spearman's rank correlation coefficient RHO.<br />
<br />
Also, there's a high chance that the function name has a suggestive name, and so you can try auto-completion to get some hints. For the previous example, typing <code>corr</code> at the octave prompt followed by pressing the {{key press|Tab}}-Key twice would suggest the following:<br />
<br />
>> corr<br />
corr corrcoef<br />
<br />
=Differences between Octave and Matlab=<br />
:''See [[Differences between Octave and Matlab]]''.<br />
<br />
=[https://en.wikipedia.org/wiki/Graphical_user_interface GUI]=<br />
<br />
==Does Octave have a GUI?==<br />
<br />
'''Yes!''' It was officially released with Octave 4.0.0. It was also available since version 3.8.0 as an experimental feature (use the {{Codeline|--force-gui}} option to start Octave).<br />
<br />
==Why did you create yet another GUI instead of making one that already exists better?==<br />
<br />
The previously existing GUIs were not part of Octave itself. The integration within Octave was rather bad, as all of them treated Octave as a foreign black box and used pipes for communication. This approach is bound to fail with each new version of Octave, as any fix would only be temporary. For historical reasons and to honor the approaches, a short list of previous GUIs for Octave:<br />
<br />
* '''QtOctave''' was a great, beautiful, and very useful tool which is now abandoned and incompatible with newer versions of Octave. We are thankful to its developers to make it free software so we could reuse large chunks of it for what is now the Octave GUI.<br />
<br />
* '''Quint''' was a project for an Octave GUI that actually tried to do it right. Eventually [https://lists.gnu.org/archive/html/octave-maintainers/2011-07/msg00096.html it was merged into the Octave repository] and is no longer a separate project. Also, many bits from QtOctave were reused in the GUI.<br />
<br />
* '''[http://www.xoctave.com/ Xoctave]''', which is proprietary and commercial.<br />
<br />
* '''GUI Octave''', which was proprietary and is no longer available.<br />
<br />
=Graphics: backends and toolkits=<br />
<br />
==What are the supported graphics backends?==<br />
<br />
* [https://www.opengl.org/ OpenGL] via the graphics toolkits '''[https://www.qt.io/ qt]''' (current default) and '''[http://www.fltk.org/ fltk]'''<br />
* [http://www.gnuplot.info/ gnuplot] via the '''gnuplot''' graphics toolkit<br />
<br />
==How do I change my graphics toolkit?==<br />
<br />
There are three commands to deal with graphics toolkits:<br />
<br />
{| class="wikitable"<br />
| <code>available_graphics_toolkits</code><br />
| lists all available graphics toolkits<br />
|-<br />
| <code>graphics_toolkit</code><br />
| displays the currently used graphics toolkit<br />
|-<br />
| <code>graphics_toolkit ("qt/fltk/gnuplot")</code><br />
| sets the graphics toolkit to either of [https://www.qt.io/ qt], [http://www.fltk.org/ fltk], or [http://www.gnuplot.info/ gnuplot], if available<br />
|}<br />
<br />
==Why did you replace gnuplot with an OpenGL backend?==<br />
<br />
The development of Octave is committed to being both compatible with Matlab and adding additional features. Toward those ends, the developers decided to introduce a native OpenGL backend that supports Matlab handle graphics and its uicontrols. Starting with the 3.8 release, Octave uses OpenGL graphics by default (with [http://www.fltk.org/ FLTK widgets] in Octave 3.8 and [https://www.qt.io/ Qt widgets] in Octave 4.0 and later).<br />
<br />
==Are there any plans to remove the gnuplot backend?==<br />
<br />
'''No.''' There are no plans to remove the gnuplot backend. It will be available as long as our users find it useful.<br />
<br />
==How can I implement a new graphics backend/toolkit?==<br />
<br />
This is one of those times where the best documentation is to read the existing code. We have three different toolkits in Octave now, so there are some examples to draw from.<br />
<br />
= Development =<br />
<br />
== When will feature X be released or implemented? ==<br />
<br />
When it's ready, sooner [https://www.octave.org/get-involved.html if you help]. You can [https://savannah.gnu.org/patch/?group=octave send us patches] if you can implement feature X yourself. If you can't, some [https://www.octave.org/commercial-support.html developers may be convinced to work on your specific problem for some money].<br />
<br />
== How can I get involved in Octave development? ==<br />
<br />
:''See [[Developer FAQ]]''.<br />
<br />
[[Category:FAQ]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=FAQ&diff=13294FAQ2020-08-22T01:28:01Z<p>Siko1056: /* MS Windows */ Revisit the great article Nrjank :-)</p>
<hr />
<div>This is a list of frequently asked questions (FAQ) for GNU Octave users.<br />
<br />
We are always looking for new questions (with answers), better answers, or both. Feel free to edit this page with your changes.<br />
<br />
=Where do I get additional help?=<br />
<br />
If you can't find an answer to your question in this FAQ, wiki, or in the [http://www.octave.org/doc/interpreter manual] ([http://www.octave.org/octave.pdf PDF]) you can:<br />
<br />
* Search for an answer in our [https://lists.gnu.org/archive/html/help-octave/ mailing list archives]<br />
* Contact our user community using our [https://octave.discourse.group Octave Discourse].<br />
* Contact our user community using our [https://webchat.freenode.net/?channels=octave IRC chat room <code>#octave</code> in Freenode]<br />
<br />
<div class="tocinline">__TOC__</div><br />
<br />
=General=<br />
<br />
==What is Octave?==<br />
<br />
[https://www.gnu.org/software/octave/ GNU Octave] is a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems, and for performing other numerical experiments. It also provides extensive graphics capabilities for data visualization and manipulation. GNU Octave is normally used through its interactive interface ([https://en.wikipedia.org/wiki/Command-line_interface CLI] and [https://en.wikipedia.org/wiki/Graphical_user_interface GUI]), but it can also be used to write non-interactive programs. <br />
The GNU Octave language is quite similar to Matlab so that most programs are easily portable.<br />
<br />
The GNU Octave distribution includes a [http://www.octave.org/octave.pdf 1000+ page Texinfo manual]. Access to the complete text of the manual is available via the <code>doc</code> command at the GNU Octave prompt.<br />
<br />
==What is Octave Forge?==<br />
<br />
[https://octave.sourceforge.io/ Octave Forge] is a collection of [[packages]] for GNU Octave, something similar to the Matlab toolboxes. When talking about the two projects at the same time, GNU Octave is usually referred to as Octave core (or just "core"). Octave Forge also serves as a test bed for code that may eventually end up in the core, and distributes binaries for systems with a lack of developers tools (mainly Windows).<br />
<br />
==Who uses Octave?==<br />
<br />
A huge number of people ranging from students to researchers involved in various fields such as statistics,Machine Learning, data analytics, etc. Universities use it for research and teaching, companies of all sizes for development and individuals for certain private purposes. See [[Who Uses Octave?]] for more clarity.<br />
<br />
==Who develops Octave?==<br />
<br />
Discussions about writing the software that would eventually become Octave started in about 1988 with James B. Rawlings and [http://jweaton.org/ John W. Eaton] at the University of Texas. John W. Eaton is the original author of Octave, starting full-time development in February 1992. He is still the primary maintainer. The community of users and developers has in addition contributed some code and fuels the discussion on the mailing lists [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org] (user forum), [https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers@octave.org] (development issues). Since 2011, GNU Octave regularly participates in [[Summer of Code]] events as a mentor organisation. As part of those events, several students contributed to Octave by helping in removal of bugs and development of new features.<br />
<br />
==Why "Octave"?==<br />
<br />
Octave's name has nothing to do with music. It is named after [http://en.wikipedia.org/wiki/Octave_Levenspiel Octave Levenspiel], a former professor of John who was famous for his ability to do quick back-of-the-envelope calculations. You can hear John pronounce the name "Octave" a few times [http://videolectures.net/mloss08_eaton_oct/ in this video]. We hope that GNU Octave will help perform computations with the same ease as Dr. Levenspiel.<br />
<br />
==Why "GNU" Octave?==<br />
<br />
The [https://www.gnu.org/ GNU Project] was launched in 1984 to develop a complete Unix-like operating system which is free software: the GNU system. GNU is a recursive acronym for "GNU's Not Unix"; it is pronounced [https://www.gnu.org/gnu/pronunciation.en.html g'noo].<br />
<br />
The [https://www.fsf.org/ Free Software Foundation (FSF)] is the principal organization that has sponsored the GNU Project.<br />
<br />
Octave became GNU Octave in 1997 (beginning with [[Release History|version 2.0.6]]). This meant agreeing to consider Octave a part of the GNU Project and support the efforts of the FSF. A big part of this effort is to adhere to the [https://www.gnu.org/prep/standards/standards.html GNU coding standards] and to benefit from GNU's infrastructure (e.g. [https://hg.savannah.gnu.org/hgweb/octave/ code hosting] and [http://bugs.octave.org bug tracking]). Additionally, Octave receives [https://my.fsf.org/donate/working-together/octave sponsorship] from the FSF's Working Together fund. However, Octave is not and has never been developed by the FSF.<br />
<br />
==How can I cite Octave?==<br />
<br />
Octave is free software and does not legally bind you to cite it. However, we have invested a lot of time and effort in creating GNU Octave, and we would appreciate if you would cite if you used. To cite GNU Octave in publications use:<br />
<br />
John W. Eaton, David Bateman, Søren Hauberg, Rik Wehbring ({{Release Year}}).<br />
GNU Octave version {{Release}} manual: a high-level interactive language for numerical computations.<br />
URL https://www.gnu.org/software/octave/doc/v{{Release}}/<br />
<br />
A [https://en.wikipedia.org/wiki/BibTeX BibTeX] entry for [https://en.wikipedia.org/wiki/LaTeX LaTeX] users is:<br />
<br />
@manual{,<br />
title = {{GNU Octave} version {{Release}} manual: a high-level interactive language for numerical computations},<br />
author = {John W. Eaton and David Bateman and S{\o}ren Hauberg and Rik Wehbring},<br />
year = <span>{</span>{{Release Year}}},<br />
url = {https://www.gnu.org/software/octave/doc/v{{Release}}/},<br />
}<br />
<br />
Run {{manual|citation}} at the Octave prompt for details on how to best cite the Octave version you are running. Certain Octave packages also have recommended citations in which case use <code>citation package_name</code>.<br />
<br />
Note that there are two reasons for citing the software used. One is giving recognition to the work done by others which we have already addressed to. The other is giving details on the system used so that experiments can be replicated. For this, you should cite the version of Octave and all packages used (you can get this information using the <code>ver</code> command), as well as any details of your setup as part of your Methods. In addition, you should make your source available as well. See [http://software.ac.uk/so-exactly-what-software-did-you-use How to cite and describe software] for more details and an in depth discussion for the same.<br />
<br />
==What documentation exists for Octave?==<br />
<br />
Besides this wiki, the GNU Octave distribution includes a [http://www.octave.org/doc/interpreter 1000+ page Texinfo manual] ([http://www.octave.org/octave.pdf PDF]). Access to the complete text of the manual is available via the {{manual|doc}} command at the GNU Octave prompt. If you have problems using this manual, or find that some topic is not adequately explained, indexed, or cross-referenced, please report it on http://bugs.octave.org.<br />
<br />
==How can I report a bug in Octave?==<br />
<br />
Please read our website http://www.octave.org/bugs.html.<br />
<br />
<br />
= Common problems =<br />
<br />
== Octave does not start ==<br />
<br />
The following steps have been the solution to several bug reports and help requests. Please try them before asking for further support. If nothing below helps, please give us the following information:<br />
<br />
* Operating system: e.g. [https://support.microsoft.com/en-us/help/13443/windows-which-version-am-i-running '''MS Windows 10 (version 2004)'''] or '''Ubuntu 20.04'''<br />
* GNU Octave version: e.g. '''Version {{Release}}'''<br />
* Installation method: e.g. '''Downloaded and installed "octave-{{Release}}-w64-installer.exe" from https://www.octave.org/download.html'''<br />
<br />
=== MS Windows ===<br />
<br />
* After Octave upgrade the GUI does not open / shuts down immediately.<br />
** '''Solution:''' Delete the folder {{path|C:\Users\YOUR_USER_NAME\.config\octave}}<br />
* Missing/conflicting files.<br />
** '''Solution:''' Remove/Uninstall all existing Octave versions. Restart the system. Install GNU Octave again.<br />
<br />
* Permission errors<br />
** '''Solution 1:''' Octave on MS Windows uses VBS scripts to start the program. You can test whether your system is blocking VBS scripts by doing the following:<br />
**# Using Notepad or another text editor, create a text file containing only the text: <pre>msgbox("This is a test script, Click OK to close")</pre><br />
**# Save the file on your Desktop with the name {{Path|testscript.vbs}} (be sure that the editor didn't end it in .txt or .vbs.txt)<br />
**# Double click the file. If scripts can run, a popup window will appear with that message. <br />
**#* If the file opens in notepad or an editor, it means it still ended in .txt. MS Windows insecurely hides file extensions by default. To show file extensions follow [https://answers.microsoft.com/en-us/windows/forum/all/in-win10-how-to-show-the-file-extension-for/ed21ff20-cdb3-4263-9c7d-fc6ed125fc82 these instructions at Microsoft.com].<br />
**#* If both {{Path|testscript.vbs}} and {{Path|octave.vbs}} open a text- or other editor, it means your MS Windows file associations have .vbs files associated with another program. To fix this, right click the .vbs file, select "Open With", select "Choose Another App", check the box that says "Always use this app to open .vbs files". Finally, select "Microsoft Windows Based Script Host" from the list. If it is not in the list, select "More apps". If still not there, select "Look for Another App on this PC" and navigate to {{Path|C:\Windows\System32\wscript.exe}}, select it, and select "Open". If {{Path|wscript}} is still not present you will need to seek assistance installing missing MS Windows components.<br />
**# Try moving {{Path|testscript.vbs}} to another location, such as a {{Path|C:\temp folder}}. Additionally try to move {{Path|testscript.vbs}} in the Octave installation folder containing {{Path|octave.vbs}} and see if VBS scripts can be run there.<br />
**# If {{Path|testscript.vbs}} doesn't run in any of those locations, then scripting appears to be disabled or blocked on your system. If {{Path|testscript.vbs}} runs in some locations but not others, there there may be other security permissions errors to be solved. If {{Path|testscript.vbs}} runs in the same folder as {{Path|octave.vbs}}, but directly double-clicking on {{Path|octave.vbs}} does not start Octave, then there appears to be some problem other than script permissions. <br />
** '''Solution 2:''' Consult your malware detection (a.k.a. AntiVirus) software, if files are blocked.<br />
** '''Solution 3:''' Did you install Octave on a network-drive? Do you have the execution permissions?<br />
** '''Solution 4:''' Is your computer managed by your company? Does your administrator prohibit script execution?<br />
<br />
==I do not see any output of my script until it has finished?==<br />
<br />
By default Octave is set to pass its screen output through a [https://en.wikipedia.org/wiki/Terminal_pager pager] (usually the default pager is "less") which allows things such as navigating through the output with arrow keys or searching for text or regular expressions within the output. The pager only displays the output after it's finished receiving it, so when it is active you'll not be able to see anything until your script has terminated. To change this behavior temporarily or permanently you may want to use one of the options described [https://www.octave.org/doc/interpreter/Paging-Screen-Output.html in the manual].<br />
<br />
==When I try plotting from a script, why am I not seeing anything?==<br />
<br />
If you are running an Octave script that includes a plotting command, the script and Octave may terminate immediately. So the plot window does show up, but immediately closes when Octave finishes execution. Alternatively, if using fltk, the plot window needs a readline loop to show up (the time when Octave is sitting around doing nothing waiting for interactive input).<br />
<br />
A common solution is to put a {{manual|pause}} command at the end of your script.<br />
<br />
==How do I get sound input or output in MS Windows?==<br />
<br />
Sound input from a sound card and output to a sound card is fully supported since Octave 4.0.0 for all platforms. If you have problems with the [https://www.octave.org/doc/interpreter/Audio-Processing.html audio I/O functions] using Octave 4.0.0 or a newer version, please report them on the [http://bugs.octave.org bug tracker].<br />
<br />
==I have problem X using the latest Octave version==<br />
<br />
Please be more specific about what you mean by "latest version"?<br />
<br />
* The latest stable version is {{Release}}. Be aware that you may still have an older version due to whatever distribution method you are using. To get a newer stable version for your system see the following as in accordance to your Operating system: [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], or [[Octave for Microsoft Windows|Windows]].<br />
<br />
* If you refer to the latest Mercurial revision, please specify the [https://www.mercurial-scm.org/wiki/ChangeSetID changeset ID] not the revision number, e.g. the output of <code>hg summary</code> or <code>hg id</code>. Changeset IDs are globally unique across all repos.<br />
<br />
If your problem still persists with the "latest version", then please [http://bugs.octave.org/ report a bug] or ask for help at [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org]. Otherwise, don't be surprised if volunteers are less inclined to help you with a problem that only exists in an older version of Octave and is already fixed in a newer version.<br />
<br />
==Why is Octave's floating-point computation wrong?==<br />
<br />
Floating-point arithmetic is an approximation '''in binary''' to arithmetic on real or complex numbers. Just like you cannot represent 1/3 exactly in decimal arithmetic (0.333333... is only a rough approximation to 1/3), you cannot represent some fractions like <math>1/10</math> exactly in base 2. In binary, the representation to one tenth is <math>0.0\overline{0011}_b</math> where the bar indicates that it repeats infinitely (like how <math>1/6 = 0.1\overline{6}_d</math> in decimal). Because this infinite repetition cannot be represented exactly with a finite number of digits, rounding errors occur for values that appear to be exact in decimal but are in fact approximations in binary, such as for example how 0.3 - 0.2 - 0.1 is not equal to zero.<br />
<br />
In addition, some advanced operations are computed by approximation and there is no guarantee for them to be accurate, see [https://en.wikipedia.org/wiki/Rounding#Table-maker.27s_dilemma Table-maker's dilemma] for further references. Their results are system-dependent.<br />
<br />
This isn't a bug that is limited to GNU-Octave & it happens with any program that uses [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754 floating-point arithmetic]. To be fair, IEEE 754 also specifies decimal floating-point arithmetic, which has never seen wide adoption. The reason why Octave and other programs using IEEE 754 binary floating-point numbers is that they are ''fast'', because they are implemented in hardware or system libraries. Unless you are using very exotic hardware, Octave will use your computer's processor for basic floating-point arithmetic.<br />
<br />
Another approach to deal with rounding errors is interval arithmetic with the [[Interval package]] or symbolic computations with the [[Symbolic package]]. These approaches are likely to be slower, since not all operations can be performed on Hardware like pure floating-point arithmetic.<br />
<br />
To learn more about floating-point arithmetic, consult this [https://en.wikipedia.org/wiki/Floating-point_arithmetic Wikipedia article] or the classical reference by David Goldberg [http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html What Every Computer Scientist Should Know About Floating-Point Arithmetic].<br />
<br />
==Missing lines when printing under Windows with OpenGL toolkit and Intel integrated GPU==<br />
<br />
Some windows users with integrated Intel GPUs have reported missing lines when printing with an OpenGL toolkit like FLTK or Qt. {{bug|42534}}<br />
<br />
Users with this kind of problem should try to install/update their Intel OpenGL drivers for Windows or consider installing Mesa drivers from http://qt-project.org/wiki/Cross-compiling-Mesa-for-Windows.<br />
<br />
See also https://www.opengl.org/wiki/FAQ#Why_is_my_GL_version_only_1.4_or_lower.3F .<br />
<br />
==Plot hangs and makes the GUI unresponsive==<br />
<br />
If the Qt graphics toolkit is used and "plot" is used for the first time, the fontconfig scanner searches the font directory to build a font cache. This can take up to 3min on slow CPUs. See {{bug|45458}}<br />
<br />
==Error message about invalid call to script or invalid use of script in index expression==<br />
<br />
If Octave shows an error message about {{Codeline|invalid call to script .../close.m}} or {{Codeline|invalid use of of script .../close.m in index expression}}, it means that you have created a script called close.m that is overriding the built-in Octave function {{Codeline|close}}. Octave functions and scripts share the same global namespace. It is best to avoid creating your own scripts or functions that have the same name as an Octave function as to avoid this error regarding the invalid call to script or invalid use of script in index expression.<br />
<br />
=Licensing issues=<br />
<br />
==If I write code using Octave do I have to release it under the GPL?==<br />
<br />
The answer depends on precisely how the code is written and how it works:<br />
<br />
* Code written '''entirely in the scripting language of Octave''' (interpreted code in .m files) may be released under the terms of whatever license you choose.<br />
<br />
* Code written using [https://www.gnu.org/software/octave/doc/interpreter/Oct_002dFiles.html Octave's native code interface] (also known as a .oct file) necessarily links with Octave internals and is considered a derivative work of Octave. Therefore it must be released under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
<br />
* Code written using [https://www.gnu.org/software/octave/doc/interpreter/Mex_002dFiles.html Octave's implementation of the Matlab MEX interface] may be released under the terms of whatever license you choose, provided that the following conditions are met:<br />
<br />
:# The MEX file may not use any bindings that are specific to Octave, '''it has to use the MEX interface only'''. In other words, it should be possible in principle to use the MEX file with other programs that implement the MEX interface (e.g., Matlab). For example including an Octave header file or calling an Octave function within the MEX file, that is not related with Octave's implementation of the MEX interface make the MEX file a derivative work of Octave and has therefore to be released under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
:# The MEX file may not be distributed together with Octave in such a way that they effectively create a single work. For example, you should not distribute the MEX file and Octave together in a single package such that Octave automatically loads and runs the MEX file when it starts up. There are other possible ways to effectively create a single work.<br />
<br />
* Code that '''embeds the Octave interpreter''' (e.g., by calling the <code>octave_main</code> function), or that calls functions from Octave's libraries (e.g., liboctinterp, liboctave, or libcruft) is considered a derivative work of Octave and therefore must be released under terms that are compatible with the GPL.<br />
<br />
==Will you change the license of the Octave libraries for me?==<br />
<br />
'''No.''' Instead of asking us to change the licensing terms for Octave, we recommend that you release your program under terms that are compatible with the GPL, this way the free software community can be benefited from your work the same as you were/have benefited from the work of all the people who have contributed to Octave.<br />
<br />
==Should I favor the MEX interface to avoid the GPL?==<br />
<br />
'''No.''' The original reason for implementing the [https://www.gnu.org/software/octave/doc/interpreter/Mex_002dFiles.html MEX interface] for Octave was to allow Octave to run free software that uses MEX files (the particular goal was to run [https://computation.llnl.gov/projects/sundials/release-history#sundialsTB sundialsTB] in Octave). The intent was to liberate that software from Matlab and increase the amount of free softwares available to Octave users & not to enable people to write proprietary code for Octave. For the good of the community, we strongly encourage users of Octave to release the code they write for Octave under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
<br />
==Why can't I use code from File Exchange in Octave?==<br />
<br />
According to the Matlab Central [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use] (Last updated: 10-Aug-2016), all submitted code is licensed under the [https://en.wikipedia.org/wiki/BSD_licenses BSD license] by default (cf. § 5 [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use]), but it is clearly stated that:<br />
<br />
{{Quote|text=Content submitted to File Exchange may only be used with MathWorks products. | |§ 2(a)(iii) [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use]}}<br />
<br />
That does not apply to GNU Octave, therefore the usage is in general prohibited. It should suffice — although interpretations of this vary — to contact the author directly to send you the code personally (maybe released under a free license), or download the code from the author's own website, if available. [[Asking_for_package_to_be_released_under_GPL:_examples|Some examples of letters/email sent to authors for that purpose]].<br />
<br />
=Installation=<br />
<br />
==How can I install Octave on Windows?==<br />
<br />
:'' So as to install GNU-Octave for Windows O.S, refer to : [[Octave for Microsoft Windows]]''<br />
<br />
==How can I install Octave on MacOS?==<br />
<br />
:''So as to install GNU-Octave for MacOS, refer to : [[Octave for macOS]]''<br />
<br />
==How can I install Octave on GNU/Linux?==<br />
<br />
:'' So as to install GNU-Octave on GNU/Linux, refer to: [[Octave for GNU/Linux]]''<br />
<br />
==How to install Octave on Android OR What is the Octave app available in the Google Play store?==<br />
<br />
There is an '''unofficial''' Octave app available for Android in the Google Play store. Please see [[Octave for Android]] for further information.<br />
<br />
==How can I install Octave on platform X?==<br />
<br />
Octave currently runs on [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]]. It should be possible to make Octave work on other systems as well. If you are interested in porting Octave to other systems, please contact the maintainers development mailing list [https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers@octave.org].<br />
<br />
==What Octave version should I use?==<br />
<br />
For general use, it is recommended to use the latest stable version of Octave (currently {{Release}}), available from http://www.octave.org/download.html. For development and bleeding-edge features one can obtain the development source code from the Mercurial repository https://hg.savannah.gnu.org/hgweb/octave/graph/.<br />
<br />
The used version of Octave is available via the {{manual|ver}} command and a list of user-visible changes since the last release is available via the {{manual|news}} command at the GNU Octave prompt.<br />
<br />
==On what platforms does Octave run?==<br />
<br />
Octave runs on any platform you can compile it on. Binary distributions exist for [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]]. To work fully functional, Octave requires the used platform to support the underlying numerical libraries like [https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms BLAS], [https://en.wikipedia.org/wiki/LAPACK LAPACK], [http://www.suitesparse.com SuiteSparse], etc., and for plotting [https://www.opengl.org/ OpenGL] or [http://www.gnuplot.info/ gnuplot].<br />
<br />
==How can I obtain Octave's source code?==<br />
<br />
The latest version of the Octave source code (and older versions) is available from:<br />
<br />
* https://www.octave.org/download.html<br />
* https://ftp.gnu.org/gnu/octave/<br />
<br />
Since Octave is distributed under the terms of the GPL, you can get Octave from a friend who has a copy.<br />
<br />
==How can I build Octave from the source code?==<br />
<br />
To use Octave it is usually not required to build it from it's source code. Binary distributions exist for [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]].<br />
<br />
If you have reasons to build Octave from the source code, see [[Building]] for more information.<br />
<br />
==What do I need to build Octave from the source code?==<br />
<br />
For a list of build dependencies, refer to [[Building]].<br />
<br />
==Do I need GCC to build Octave from the source code?==<br />
<br />
No. The development is done primarily with [https://gcc.gnu.org/ GCC], so you may hit some incompatibilities. Octave is intended to be portable to any standard conforming compiler (for example [https://clang.llvm.org/ clang] is known to work as well). If you face any difficulties that you think are bugs, please report them to the [http://bugs.octave.org bug tracker], or ask for help on the [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org mailing list].<br />
<br />
=What's new in Octave?=<br />
<br />
Each new Octave release introduces many new features. A complete list of user visible changes can be seen by running <code>news</code> at the Octave prompt.<br />
<br />
* '''What's new in the next version of Octave?'''<br />
** See the [https://hg.savannah.gnu.org/hgweb/octave/file/tip/NEWS NEWS file] on the development branch.<br />
* '''What was new in Octave Version X.Y.Z?'''<br />
** See [[Release History]].<br />
<br />
=Packages and Octave Forge=<br />
<br />
==How do I install or load all Octave Forge packages?==<br />
<br />
Do not do it! Really, there is no reason to do this. Octave has many packages for different needs and is unlikely that you need all of them. You either have a small set of required packages, in which case<br />
you know them by name; or you want them all "just because", in which case you don't really need them.<br />
<br />
The common misconception is that the more packages one has installed and loaded, the more complete and powerful its Octave installation will be. However, in the same way one would never install all perl modules, ruby gems, python packages, and C++ libraries (because it simply makes no sense), one should not install all Octave packages.<br />
<br />
Packages should be installed and loaded selectively. Note that some packages are meant to shadow core functions changing the way Octave works, and that different packages can have different functions with the same name leading to unpredictable results.<br />
<br />
If you really really really want to do load all packages, you can with the following:<br />
<syntaxhighlight lang="octave"><br />
## WARNING: loading all packages is probably not the solution you are looking for.<br />
cellfun (@(x) pkg ("load", x.name), pkg ("list"));<br />
</syntaxhighlight><br />
<br />
==I have installed a package but still get a "foo undefined" error?==<br />
<br />
You have probably forgotten to load the package. Use {{Codeline|pkg load package-name}} to load it. Most packages are no longer loaded automatically to avoid surprises. See reasoning on related FAQ [[FAQ#How_do_I_install_all_Octave_packages.3F|how do I install all Octave packages]]. If you want a specific package to be loaded by default at startup, consider adding the {{Codeline|pkg load}} command on your {{path|[[.octaverc]]}} file.<br />
<br />
==I cannot install a package. Octave complains about a missing mkoctfile.==<br />
<br />
You should normally use your distribution's packages. For Debian and Fedora, Octave package <code>foo</code> will be a deb or rpm called <code>octave-foo</code>, and you should install that instead using <code>apt</code> or <code>yum</code>.<br />
<br />
If you really need to build Octave packages from source to install them, you'll need {{manual|mkoctfile}}. Most distributions split Octave into several packages. The script {{manual|mkoctfile}} is then part of a separate package:<br />
<br />
* Debian/Ubuntu: [https://packages.debian.org/stretch/liboctave-dev liboctave-dev]<br />
<br />
* Fedora: {{Codeline|octave-devel}}<br />
<br />
==How do I automatically load a package at Octave startup?==<br />
<br />
When Octave starts, it runs the file {{Path|~/.octaverc}} (in your user's home directory). If you want Octave to automatically load a package, simply add a <code>pkg load pkg-name</code> command to it. If the files does not exist, create it.<br />
<br />
If you do this, remember that other people may not have Octave configured to load packages at startup. Therefore, if you write code for others, remember that your programs still need to load the packages they require.<br />
<br />
=Octave usage=<br />
<br />
==How do I execute an Octave script?==<br />
<br />
First of all, make sure you understand [http://www.octave.org/doc/interpreter/Script-Files.html the difference between script files and function files]. If you want to execute a function defined in a file, just call the function like any other Octave function: <code>foo(arg1, arg2);</code><br />
<br />
To execute a script from within Octave, just type its name without the <code>.m</code> extension. Thus, if you have a script called <code>foo.m</code>, just type <code>foo</code> from within the Octave command prompt to execute it. You have to make sure that the script is in your current working directory or in Octave's load path. Type {{manual|pwd}} to get the current working directory or type {{manual|path}} to see which paths belong to Octave's load path. The current working directory is referred to as "." in the output of {{manual|path}}.<br />
<br />
If the script name has characters that are not valid for an Octave identifier, or if you do not want to use {{manual|addpath}} to add the script's location to the current path, you can use the {{manual|run}} function instead:<br />
<br />
<syntaxhighlight lang="octave"><br />
run ("Script Name With Spaces.m")<br />
run ("/opt/local/foo.m")<br />
</syntaxhighlight><br />
<br />
An alternative is to run the script from outside Octave by calling Octave from your operating system shell. Unlike calling the script from inside Octave, this also allows you to pass arguments from the shell into the script, which the script can access using the {{manual|argv}} command:<br />
<br />
$ octave the-script.m arg1 arg2<br />
<br />
In a Unix environment, if the script has a [http://en.wikipedia.org/wiki/Shebang_%28Unix%29 shebang] (e.g. <code>#!/usr/bin/octave</code>) and executable permissions, you can call it like any other Unix program with arguments:<br />
<br />
$ ./the-script arg1 arg2<br />
<br />
If you call the script from the shell and it's plotting, please note [[#When I try plotting from a script, why am I not seeing anything?|how to plot when running a script from the shell]].<br />
<br />
==How do I close a figure?== <br />
<br />
To close the current figure type {{manual|close}} in the Octave command prompt.<br />
<br />
==How do I set the number of displayed decimals?==<br />
<br />
You can control the number of displayed decimals using the {{manual|format}} command:<br />
<br />
<syntaxhighlight lang="octave"><br />
>> format long<br />
>> pi<br />
pi = 3.14159265358979<br />
>> format short<br />
>> pi<br />
pi = 3.1416<br />
</syntaxhighlight><br />
<br />
==How do I call an Octave function from C++?==<br />
<br />
Please read the manual https://www.gnu.org/software/octave/doc/interpreter/Calling-Octave-Functions-from-Oct_002dFiles.html.<br />
<br />
==How do I change color/line definition in gnuplot postscript?==<br />
<br />
Here is a awk script to get a rainbow color map<br />
<br />
#!/bin/awk -f<br />
<br />
BEGIN {<br />
split("0 4 6 7 5 3 1 2 8", rainbow, " ");<br />
split("7 3 1 0 2 4 6 5 8", invraim, " ");<br />
}<br />
<br />
$1 ~ /\/LT[0-8]/ {<br />
n = substr($1, 4, 1);<br />
if (n == 0)<br />
lt = "{ PL [] 0.9 0.1 0.1 DL } def";<br />
else if (n == 1)<br />
lt = "{ PL [4 dl 2 dl] 0.1 .75 0.1 DL } def";<br />
else if (n == 2)<br />
lt = "{ PL [2 dl 3 dl] 0.1 0.1 0.9 DL } def";<br />
else if (n == 3)<br />
lt = "{ PL [1 dl 1.5 dl] 0.9 0 0.8 DL } def";<br />
else if (n == 4)<br />
lt = "{ PL [5 dl 2 dl 1 dl 2 dl] 0.1 0.8 0.8 DL } def";<br />
else if (n == 5)<br />
lt = "{ PL [4 dl 3 dl 1 dl 3 dl] 0.9 0.8 0.2 DL } def";<br />
else if (n == 6)<br />
lt = "{ PL [2 dl 2 dl 2 dl 4 dl] 0.5 0.3 0.1 DL } def";<br />
else if (n == 7)<br />
lt = "{ PL [2 dl 2 dl 2 dl 2 dl 2 dl 4 dl] 1 0.4 0 DL } def";<br />
else if (n == 8)<br />
lt = "{ PL [2 dl 2 dl 2 dl 2 dl 2 dl 2 dl 2 dl 4 dl] 0.5 0.5 0.5 DL } def";<br />
$0 = sprintf("/LT%d %s", rainbow[n+1], lt);<br />
##$0 = sprintf("/LT%x %s", invraim[n+1], lt);<br />
##$0 = sprintf("/LT%x %s", n, lt);<br />
}<br />
<br />
{ print; }<br />
<br />
==How do I tell if a file exists?==<br />
<br />
One can use the function {{manual|exist}} to tell if a regular file, say <code>foo.txt</code> exist in Octave's load path, or the current directory:<br />
<br />
<syntaxhighlight lang="octave"><br />
>> exist ("foo.txt", "file") # 2, if file exists, 0 otherwise<br />
ans = 2<br />
</syntaxhighlight><br />
<br />
==How do I create a plot without a window popping up (plot to a file directly)?==<br />
<br />
<syntaxhighlight lang="octave"><br />
figure (1, "visible", "off");<br />
plot (sin (1:100));<br />
print -deps "/tmp/sin.eps"<br />
</syntaxhighlight><br />
<br />
One can set that behavior as default:<br />
<br />
<syntaxhighlight lang="octave"><br />
set (0, "defaultfigurevisible", "off");<br />
</syntaxhighlight><br />
<br />
==How do I increase Octave's precision?==<br />
<br />
Octave's default numerical type is [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754] binary64, a.k.a. "double" or "hardware floats". This type has a precision of 53 bits or about 16 decimal digits. It is supported by each modern computer hardware, so it is really '''fast'''. This type is assumed throughout for Octave's calculations. If more precision was required, one can obtain a "few bits more" by using integer types, e.g. {{manual|uint64}}, but in general one cannot expect more precision from any '''fast''' numerical software. Just to visualize "how big" those numerical limits are, consider the following table:<br />
<br />
{| class="wikitable"<br />
|+ Limits of some of Octave's data types obtained by {{manual|intmax}} and {{manual|flintmax}}.<br />
|-<br />
| <code>intmax ("uint64")</code><br />
| style="text-align: right;" | <code>18,446,744,073,709,551,615</code><br />
| <code>2^64-1</code><br />
|-<br />
| <code>intmax ("int64")</code><br />
| style="text-align: right;" | <code>9,223,372,036,854,775,807</code><br />
| <code>2^63-1</code><br />
|-<br />
| <code>flintmax ("double")</code><br />
| style="text-align: right;" | <code>9,007,199,254,740,992</code><br />
| <code>2^53</code><br />
|-<br />
| <code>flintmax ("single")</code><br />
| style="text-align: right;" | <code>16,777,216</code><br />
| <code>2^24</code><br />
|}<br />
<br />
When working with other types than "double" in Octave, one has to make sure, that the first operand is converted to the desired type:<br />
<br />
<syntaxhighlight lang="Octave"><br />
>> uint64 (2^53 + 1)<br />
ans = 9007199254740992<br />
>> uint64 (2^53) + 1<br />
ans = 9007199254740993<br />
</syntaxhighlight><br />
<br />
Notice the difference, in the first line the addition within the brackets is performed using double precision, therefore the result gets "truncated" to the maximum possible value without a warning. The third line uses throughout uint64 precision.<br />
<br />
Consider carefully if your problem really needs more precision. Often if you're running out of precision the problem lies fundamentally in your methods being [https://en.wikipedia.org/wiki/Numerical_stability numerically unstable], thus more precision will not help you here.<br />
<br />
If you absolutely must have more precision, you're at present better off using a [https://en.wikipedia.org/wiki/Computer_algebra_system CAS] instead of Octave. However, CAS or symbolic computations must be implemented '''in software''' which makes it much slower than hardware floats. An example of such a CAS is [http://www.sagemath.org/ Sage] or have a look at Octave's [[Symbolic package]].<br />
<br />
==How do I run a Matlab P-file in Octave?==<br />
<br />
You can't. Matlab P-files (files with a <code>.p</code> file extension), also known as P-code, are [https://en.wikipedia.org/wiki/Obfuscation_%28software%29 obfuscated] files that cannot be run outside of Matlab itself. The original source Matlab m-files that were used to generate these P-files should be used in Octave instead.<br />
<br />
There are no plans to support running P-files produced by Matlab in Octave.<br />
<br />
==How does Octave solve linear systems?==<br />
<br />
In addition to consulting Octave's source for the precise details, you can read the Octave manual for a complete high-level description of the algorithm that Octave uses to decide how to solve a particular linear system, e.g. how the backslash operator <code>A \ x</code> will be interpreted. Sections [http://www.octave.org/doc/interpreter/Techniques-Used-for-Linear-Algebra.html Techniques Used for Linear Algebra] and [http://www.octave.org/doc/interpreter/Sparse-Linear-Algebra.html Linear Algebra on Sparse Matrices] from the manual describe this procedure.<br />
<br />
==How do I do X?==<br />
<br />
You are probably looking for the function {{manual|lookfor}}. This function searches the help text of all functions for a specific string and returns a list of functions. Note that by default it will only search the first line of the help text (check <code>help lookfor</code> at the octave prompt for more). The following example helps to find the function to calculate correlation coefficient in a matrix:<br />
<br />
>> lookfor correlation<br />
corr Compute matrix of correlation coefficients.<br />
corrcoef Compute a matrix of correlation coefficients.<br />
spearman Compute Spearman's rank correlation coefficient RHO.<br />
<br />
Also, there's a high chance that the function name has a suggestive name, and so you can try auto-completion to get some hints. For the previous example, typing <code>corr</code> at the octave prompt followed by pressing the {{key press|Tab}}-Key twice would suggest the following:<br />
<br />
>> corr<br />
corr corrcoef<br />
<br />
=Differences between Octave and Matlab=<br />
:''See [[Differences between Octave and Matlab]]''.<br />
<br />
=[https://en.wikipedia.org/wiki/Graphical_user_interface GUI]=<br />
<br />
==Does Octave have a GUI?==<br />
<br />
'''Yes!''' It was officially released with Octave 4.0.0. It was also available since version 3.8.0 as an experimental feature (use the {{Codeline|--force-gui}} option to start Octave).<br />
<br />
==Why did you create yet another GUI instead of making one that already exists better?==<br />
<br />
The previously existing GUIs were not part of Octave itself. The integration within Octave was rather bad, as all of them treated Octave as a foreign black box and used pipes for communication. This approach is bound to fail with each new version of Octave, as any fix would only be temporary. For historical reasons and to honor the approaches, a short list of previous GUIs for Octave:<br />
<br />
* '''QtOctave''' was a great, beautiful, and very useful tool which is now abandoned and incompatible with newer versions of Octave. We are thankful to its developers to make it free software so we could reuse large chunks of it for what is now the Octave GUI.<br />
<br />
* '''Quint''' was a project for an Octave GUI that actually tried to do it right. Eventually [https://lists.gnu.org/archive/html/octave-maintainers/2011-07/msg00096.html it was merged into the Octave repository] and is no longer a separate project. Also, many bits from QtOctave were reused in the GUI.<br />
<br />
* '''[http://www.xoctave.com/ Xoctave]''', which is proprietary and commercial.<br />
<br />
* '''GUI Octave''', which was proprietary and is no longer available.<br />
<br />
=Graphics: backends and toolkits=<br />
<br />
==What are the supported graphics backends?==<br />
<br />
* [https://www.opengl.org/ OpenGL] via the graphics toolkits '''[https://www.qt.io/ qt]''' (current default) and '''[http://www.fltk.org/ fltk]'''<br />
* [http://www.gnuplot.info/ gnuplot] via the '''gnuplot''' graphics toolkit<br />
<br />
==How do I change my graphics toolkit?==<br />
<br />
There are three commands to deal with graphics toolkits:<br />
<br />
{| class="wikitable"<br />
| <code>available_graphics_toolkits</code><br />
| lists all available graphics toolkits<br />
|-<br />
| <code>graphics_toolkit</code><br />
| displays the currently used graphics toolkit<br />
|-<br />
| <code>graphics_toolkit ("qt/fltk/gnuplot")</code><br />
| sets the graphics toolkit to either of [https://www.qt.io/ qt], [http://www.fltk.org/ fltk], or [http://www.gnuplot.info/ gnuplot], if available<br />
|}<br />
<br />
==Why did you replace gnuplot with an OpenGL backend?==<br />
<br />
The development of Octave is committed to being both compatible with Matlab and adding additional features. Toward those ends, the developers decided to introduce a native OpenGL backend that supports Matlab handle graphics and its uicontrols. Starting with the 3.8 release, Octave uses OpenGL graphics by default (with [http://www.fltk.org/ FLTK widgets] in Octave 3.8 and [https://www.qt.io/ Qt widgets] in Octave 4.0 and later).<br />
<br />
==Are there any plans to remove the gnuplot backend?==<br />
<br />
'''No.''' There are no plans to remove the gnuplot backend. It will be available as long as our users find it useful.<br />
<br />
==How can I implement a new graphics backend/toolkit?==<br />
<br />
This is one of those times where the best documentation is to read the existing code. We have three different toolkits in Octave now, so there are some examples to draw from.<br />
<br />
= Development =<br />
<br />
== When will feature X be released or implemented? ==<br />
<br />
When it's ready, sooner [https://www.octave.org/get-involved.html if you help]. You can [https://savannah.gnu.org/patch/?group=octave send us patches] if you can implement feature X yourself. If you can't, some [https://www.octave.org/commercial-support.html developers may be convinced to work on your specific problem for some money].<br />
<br />
== How can I get involved in Octave development? ==<br />
<br />
:''See [[Developer FAQ]]''.<br />
<br />
[[Category:FAQ]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Help_text_style_guide&diff=13291Help text style guide2020-08-18T05:24:47Z<p>Siko1056: /* Ellipsis (...) */ Update deftypefn to current standards.</p>
<hr />
<div>== Guidelines ==<br />
<br />
The first line of the documentation string should consist of a summary of<br />
the function.<br />
<br />
Subsequent lines may expand the general nature of the function.<br />
<br />
After the introduction there should be paragraphs describing the meaning<br />
and usage of each input, followed by the meaning and usage of each output.<br />
<br />
Finally, there may be more general information such as notes about the<br />
algorithm used, references to scientific papers, notes about any<br />
incompatibilities with Matlab, etc.<br />
<br />
=== First sentence ===<br />
<br />
The first sentence of help text should start with a statement that is like a command. For example, the first sentence of {{Codeline|hist}}:<br />
<pre><br />
Produce histogram counts or plots. # good<br />
Produces histogram counts or plots. # bad<br />
hist produces histogram counts or plots. # bad<br />
</pre><br />
<br />
Usually it looks good to do likewise for the rest of the first paragraph.<br />
Subsequent paragraphs usually look better if they have proper subjects.<br />
<br />
=== Voice ===<br />
<br />
Write documentation strings in the active voice, not the passive, and in<br />
the present tense, not the future. For instance, use "Return a list<br />
containing A and B." instead of "A list containing A and B will be<br />
returned."<br />
<br />
Avoid using the word "cause" (or its equivalents) unnecessarily.<br />
Instead of, "Cause Octave to display text in boldface," just write<br />
"Display text in boldface."<br />
<br />
=== Wording ===<br />
<br />
The documentation string for a variable that is a yes-or-no flag should<br />
start with words such as "Nonzero means...", to make it clear that<br />
all nonzero values are equivalent and indicate explicitly what zero and<br />
nonzero mean.<br />
<br />
=== Whitespace ===<br />
<br />
Use two spaces between the period marking the end of a sentence and the<br />
word which opens the next sentence. This convention has no effect for<br />
typeset formats like Tex, but improves the readability of the documentation<br />
in fixed-width environments such as the Info reader.<br />
<br />
<pre><br />
there is no correct for sentence spacing. But we need a convention # good<br />
there is no correct for sentence spacing. But we need a convention # bad<br />
</pre><br />
<br />
Do not start or end a documentation string with whitespace.<br />
<br />
Do not indent subsequent lines of a documentation string so<br />
that the text is lined up in the source code with the text of the first<br />
line. This looks nice in the source code, but looks bizarre when users<br />
view the documentation. Remember that the indentation before the<br />
starting double-quote is not part of the string!<br />
<br />
=== Line length ===<br />
<br />
Format the documentation string so that it fits within an 80-column screen.<br />
It is a good idea for most lines to be no wider than 60 characters.<br />
<br />
However, rather than simply filling the entire documentation string, you<br />
can make it much more readable by choosing line breaks with care.<br />
Use blank lines between topics if the documentation string is long.<br />
<br />
=== Variable naming ===<br />
<br />
When choosing variable names try to adhere to the following guidelines.<br />
<br />
{| class="wikitable"<br />
! Variable type<br />
! Standard names<br />
|-<br />
|vectors<br />
|x,y,z,t,w<br />
|-<br />
|matrices<br />
|A,B,M<br />
|-<br />
|strings<br />
|str, s<br />
|-<br />
|filename<br />
|fname<br />
|-<br />
|cells<br />
|c<br />
|-<br />
|cellstrs<br />
|cstr<br />
|}<br />
<br />
=== Manual reference ===<br />
<br />
When submitting a function to Octave, a tag for the docstring should be added to some appropriate place in one of the manual's .txi source files (they are all in {{Path|doc/interpreter/}}). Find the most appropriate section in the manual and add the following with the related functions:<br />
{{Code|adding tag for function help text in Octave's manual|<pre><br />
+@DOCSTRING(function_name)<br />
</pre>}}<br />
<br />
If appropriate, also write some text about the function on the manual for better inclusion into the manual.<br />
<br />
<br />
== TexInfo ==<br />
This is the preferred format for help text. There is also a comprehensive [https://www.gnu.org/software/texinfo/manual/texinfo/ TexInfo manual].<br />
<br />
=== Examples ===<br />
<br />
If you give a code example in the documentation written in Texinfo with<br />
the {{codeline|@example}} environment, you should be aware that the text<br />
within such an environment will not be wrapped. It is recommended that<br />
you keep the lines short enough to fit on pages in the generated pdf or<br />
ps documents. That means, keep the lines of examples under 60 characters.<br />
<br />
=== Octave specific macros ===<br />
==== seealso ====<br />
Do not use this macro empty as it will create problems with the {{forge|generate_html}} package.<br />
==== deftypefn ====<br />
This environment will enclose the function help text. It takes as argument the type of function. Typical values are<br />
* Function File -- for functions in .m files<br />
* Loadable Function -- for functions in .oct files<br />
* Accessor method<br />
* Class property<br />
<br />
Besides this environment there is also the alternative {{Codeline|deftypenx}} for alternative forms. Typically these are mentioned at the top of the help text, right after the {{Codeline|deftypen}} although this is not really necessary. Cases where it's acceptable to have them on other sections would be methods on the help text of a class constructor, since they will not always be on a separate file.<br />
<br />
=== Formatting ===<br />
<br />
==== Formulas ====<br />
Do not use the example environment to insert formulas, consider using {{Codeline|@verbatim}} instead. <br />
<br />
{{Code||<pre><br />
@verbatim<br />
E[Z(i,k) ]<br />
IRL(k) = ------------<br />
V(i)<br />
@end verbatim<br />
</pre>}}<br />
<br />
However, this will never print as a nice looking mathematical formula that TeX is known for. It is possible to have Tex formulas but then they won't be displayed on HTML or Info (Octave help) so the following can be done:<br />
<br />
{{Code||<pre><br />
@tex<br />
\def\frac#1#2{{\begingroup#1\endgroup\over#2}}<br />
$$ IRL(k) = \frac{E[Z(i,k)]}{V(i)} $$<br />
@end tex<br />
@ifnottex<br />
@verbatim<br />
E[Z(i,k) ]<br />
IRL(k) = ------------<br />
V(i)<br />
@end verbatim<br />
@end ifnottex<br />
</pre>}}<br />
<br />
==== Plain-tex missing macros ====<br />
When compared to LaTeX, plain TeX is missing some very useful macros for including mathematical notation. The following is a list of their definitions which can be added on a as needed basis:<br />
<br />
* frac<br />
<pre>\def\frac#1#2{{\begingroup#1\endgroup\over#2}}</pre><br />
<br />
=== Special inserts ===<br />
==== Escape characters ====<br />
To escape characters in TexInfo, use the character {{Codeline|@}}. Only the characters '''@''', '''{''' and '''}''' need to be escaped.<br />
<br />
* {{Codeline|<nowiki>@@</nowiki>}} stands for a single '''@''' (do not put braces after an {{Codeline|<nowiki>@@</nowiki>}} command)<br />
* {{Codeline|<nowiki>@{</nowiki>}} stands for a single '''{'''<br />
* {{Codeline|<nowiki>@}</nowiki>}} stands for a single '''}'''<br />
<br />
In certain contexts (such as {{Codeline|@acronym}} or {{Codeline|@xref}}), commas may need to be escaped. In such situations, use {{Codeline|<nowiki>@comma{}</nowiki>}}.<br />
<br />
==== Ellipsis (...) ====<br />
Ellipsis are frequently used in octave help text, especially when defining a function API. Use the {{Codeline|<nowiki>@dots{}</nowiki>}} rather than three dots.<br />
<br />
{{Code||<pre><br />
@deftypefn {} {} imhist (@var{I})<br />
@deftypefnx {} {[@var{counts}, @var{x}] =} imhist (@dots{})<br />
</pre>}}<br />
<br />
==== Matlab ====<br />
Sometimes it is needed to mention Matlab in the help text. An example might be to mention that a weird behavior needs to be kept for Matlab compatibility. In such case, small caps should be used. For example, the following is used in the {{Codeline|length}} help text:<br />
<br />
{{Code||<pre><br />
For matrix objects, the length is the number of rows or columns, whichever is<br />
greater (this odd definition is used for compatibility with @sc{matlab}).<br />
</pre>}}<br />
<br />
[[Category:Development]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Continuous_Build&diff=13290Continuous Build2020-08-12T05:38:55Z<p>Siko1056: /* ccache */ Strip unimportant output from the symlink example</p>
<hr />
<div>GNU Octave uses [https://buildbot.net/ Buildbot] to build and test the current development version on multiple systems in a number of different configurations.<br />
<br />
{{Note|The current status of the builds may be found at http://buildbot.octave.org:8010/#/waterfall.}}<br />
<br />
= Systems and Configurations =<br />
<br />
The following systems and configurations are currently covered for Octave builds:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Builder ID !! Hg Version !! System !! Compiler !! Build Options !! Frequency<br />
|-<br />
| clang-4.0-debian || default || Debian Testing || Clang 4.0 || || Any Change<br />
|-<br />
| stable-clang-4.0-debian || stable || Debian Testing || Clang 4.0 || || Any Change<br />
|-<br />
| clang-5.0-debian || default || Debian Testing || Clang 5.0 || || Any Change<br />
|-<br />
| stable-clang-5.0-debian || stable || Debian Testing || Clang 5.0 || || Any Change<br />
|-<br />
| clang-fedora || default || Fedora 25 || Clang (system default) || || Any Change<br />
|-<br />
| stable-clang-fedora || stable || Fedora 25 || Clang (system default) || || Any Change<br />
|-<br />
| clang-osx (currently inactive) || default || OS X || Clang || || Any Change<br />
|-<br />
| gcc-7-debian || default || Debian Testing || GCC 7 || || Any Change<br />
|-<br />
| gcc-7-lto-debian || default || Debian Testing || GCC 7 || Enable link time optimization || Any Change<br />
|-<br />
| gcc-fedora || default || Fedora 25 || GCC (system default) || || Any Change<br />
|-<br />
| gcc-lto-fedora || default || Fedora 25 || GCC (system default) || Enable link time optimization || Any Change<br />
|-<br />
| no-extras-debian || default || Debian Testing || GCC (system default) || Disable all optional dependencies || Any Change<br />
|-<br />
| stable-no-extras-debian || stable || Debian Testing || GCC (system default) || Disable all optional dependencies || Any Change<br />
|-<br />
|}<br />
<br />
And for mxe-octave:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Builder ID !! Hg Version !! Build System !! Host System !! Compiler !! Build Options !! Frequency<br />
|-<br />
| mxe-native-all-on-debian || default || Debian Testing || Debian || GCC (mxe-octave default) || GNU Linux, build all dependencies || Daily<br />
|-<br />
| mxe-native-on-debian || default || Debian Testing || Debian || GCC (system default) || GNU Linux, use system compiler, fontconfig, and X11 libraries || Daily<br />
|-<br />
| w32-on-debian || default || Debian Testing || Windows || GCC (mxe-octave default) || Windows 32 || Daily<br />
|-<br />
| w32-stable-on-debian || stable || Debian Testing || Windows || GCC (mxe-octave default) || Windows 32 || Daily<br />
|-<br />
| w32-release-on-debian || release (tarball) || Debian Testing || Windows || GCC (mxe-octave default) || Windows 32 || Daily<br />
|-<br />
| w64-32-on-debian || default || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64 || Daily<br />
|-<br />
| w64-32-stable-on-debian || stable || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64 || Daily<br />
|-<br />
| w64-32-release-on-debian || release (tarball) || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64 || Daily<br />
|-<br />
| w64-64-on-debian || default || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64, 64-bit indexing || Daily<br />
|-<br />
| w64-64-stable-on-debian || stable || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64, 64-bit indexing || Daily<br />
|-<br />
| w64-64-release-on-debian || release (tarball) || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64, 64-bit indexing || Daily<br />
|-<br />
|}<br />
<br />
= Setup and run a Buildbot Worker =<br />
<br />
Your system may be behind a firewall. It does not have to have a distinct public IP address.<br />
<br />
To support Octave development and run a Buildbot Worker, you must do the following:<br />
<br />
* Contact the [https://octave.discourse.group/c/maintainers/7 Octave Maintainers on Discourse] to let us know that you wish to provide a system to use as a Buildbot Worker. We will give you a <code>WORKERNAME</code> and a '''secret''' <code>PASSWORD</code> to configure your Buildbot Worker.<br />
* Install buildbot. Packages exist for most distributions. See the buildbot docs for other options. You should create a separate user account with no special privileges that will run buildbot.<br />
* Decide for a <code>BASEDIR</code>. For example, if the home directory for the buildbot user is {{Path|/var/lib/buildbot}} and your <code>WORKERNAME</code> is set to <code>'debian-x86_64'</code> , then <code>BASEDIR</code> might be {{Path|/var/lib/buildbot/worker/debian-x86_64}}.<br />
* <code>MASTERHOST</code> is <code>buildbot.octave.org</code> and <code>PORT</code> is <code>9989</code>.<br />
* Create the configuration<pre>buildbot-worker create-worker BASEDIR MASTERHOST:PORT WORKERNAME PASSWORD</pre><br />
* Run buildbot on the worker system, preferably by starting it automatically when your system boots. It should be running with the buildbot user ID. <pre>buildbot-worker start BASEDIR</pre><br />
<br />
== ccache ==<br />
<br />
You may also want to set up '''ccache''' to work with buildbot (strongly recommended to speed up builds). If you create a directory {{Path|~/buildbot/bin}}, it will be added to the execution PATH when the Buildbot Master runs commands on the Buildbot Worker. This directory can have symbolic links like the following:<br />
<br />
cc -> /usr/bin/ccache<br />
c++ -> /usr/bin/ccache<br />
gcc -> /usr/bin/ccache<br />
gfortran -> /usr/bin/ccache<br />
<br />
They should point to the actual location of ccache if it is not in {{Path|/usr/bin}}.<br />
<br />
== Space Requirements ==<br />
<br />
Building Octave takes a significant amount of disk space. With debugging symbols, you may need several GB for each build, plus room for ccache (possibly 50GB) if you use it. If you use a cache size that is larger than the default, you'll need to specify that in the {{Path|.ccache/ccache.conf}} file using a line like<br />
<br />
max_size = 50G<br />
<br />
If the directory containing the build and ccache directories doesn't have sufficient space, then these directory names may point to a separate partition that does have enough space available.<br />
<br />
= External links =<br />
<br />
* [https://hg.octave.org/octave-buildbot/ Buildbot configuration repository] for http://buildbot.octave.org:8010<br />
<br />
[[Category:Building]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Continuous_Build&diff=13289Continuous Build2020-08-12T05:36:16Z<p>Siko1056: /* External links */ Link Buildbot configuration repository</p>
<hr />
<div>GNU Octave uses [https://buildbot.net/ Buildbot] to build and test the current development version on multiple systems in a number of different configurations.<br />
<br />
{{Note|The current status of the builds may be found at http://buildbot.octave.org:8010/#/waterfall.}}<br />
<br />
= Systems and Configurations =<br />
<br />
The following systems and configurations are currently covered for Octave builds:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Builder ID !! Hg Version !! System !! Compiler !! Build Options !! Frequency<br />
|-<br />
| clang-4.0-debian || default || Debian Testing || Clang 4.0 || || Any Change<br />
|-<br />
| stable-clang-4.0-debian || stable || Debian Testing || Clang 4.0 || || Any Change<br />
|-<br />
| clang-5.0-debian || default || Debian Testing || Clang 5.0 || || Any Change<br />
|-<br />
| stable-clang-5.0-debian || stable || Debian Testing || Clang 5.0 || || Any Change<br />
|-<br />
| clang-fedora || default || Fedora 25 || Clang (system default) || || Any Change<br />
|-<br />
| stable-clang-fedora || stable || Fedora 25 || Clang (system default) || || Any Change<br />
|-<br />
| clang-osx (currently inactive) || default || OS X || Clang || || Any Change<br />
|-<br />
| gcc-7-debian || default || Debian Testing || GCC 7 || || Any Change<br />
|-<br />
| gcc-7-lto-debian || default || Debian Testing || GCC 7 || Enable link time optimization || Any Change<br />
|-<br />
| gcc-fedora || default || Fedora 25 || GCC (system default) || || Any Change<br />
|-<br />
| gcc-lto-fedora || default || Fedora 25 || GCC (system default) || Enable link time optimization || Any Change<br />
|-<br />
| no-extras-debian || default || Debian Testing || GCC (system default) || Disable all optional dependencies || Any Change<br />
|-<br />
| stable-no-extras-debian || stable || Debian Testing || GCC (system default) || Disable all optional dependencies || Any Change<br />
|-<br />
|}<br />
<br />
And for mxe-octave:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Builder ID !! Hg Version !! Build System !! Host System !! Compiler !! Build Options !! Frequency<br />
|-<br />
| mxe-native-all-on-debian || default || Debian Testing || Debian || GCC (mxe-octave default) || GNU Linux, build all dependencies || Daily<br />
|-<br />
| mxe-native-on-debian || default || Debian Testing || Debian || GCC (system default) || GNU Linux, use system compiler, fontconfig, and X11 libraries || Daily<br />
|-<br />
| w32-on-debian || default || Debian Testing || Windows || GCC (mxe-octave default) || Windows 32 || Daily<br />
|-<br />
| w32-stable-on-debian || stable || Debian Testing || Windows || GCC (mxe-octave default) || Windows 32 || Daily<br />
|-<br />
| w32-release-on-debian || release (tarball) || Debian Testing || Windows || GCC (mxe-octave default) || Windows 32 || Daily<br />
|-<br />
| w64-32-on-debian || default || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64 || Daily<br />
|-<br />
| w64-32-stable-on-debian || stable || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64 || Daily<br />
|-<br />
| w64-32-release-on-debian || release (tarball) || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64 || Daily<br />
|-<br />
| w64-64-on-debian || default || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64, 64-bit indexing || Daily<br />
|-<br />
| w64-64-stable-on-debian || stable || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64, 64-bit indexing || Daily<br />
|-<br />
| w64-64-release-on-debian || release (tarball) || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64, 64-bit indexing || Daily<br />
|-<br />
|}<br />
<br />
= Setup and run a Buildbot Worker =<br />
<br />
Your system may be behind a firewall. It does not have to have a distinct public IP address.<br />
<br />
To support Octave development and run a Buildbot Worker, you must do the following:<br />
<br />
* Contact the [https://octave.discourse.group/c/maintainers/7 Octave Maintainers on Discourse] to let us know that you wish to provide a system to use as a Buildbot Worker. We will give you a <code>WORKERNAME</code> and a '''secret''' <code>PASSWORD</code> to configure your Buildbot Worker.<br />
* Install buildbot. Packages exist for most distributions. See the buildbot docs for other options. You should create a separate user account with no special privileges that will run buildbot.<br />
* Decide for a <code>BASEDIR</code>. For example, if the home directory for the buildbot user is {{Path|/var/lib/buildbot}} and your <code>WORKERNAME</code> is set to <code>'debian-x86_64'</code> , then <code>BASEDIR</code> might be {{Path|/var/lib/buildbot/worker/debian-x86_64}}.<br />
* <code>MASTERHOST</code> is <code>buildbot.octave.org</code> and <code>PORT</code> is <code>9989</code>.<br />
* Create the configuration<pre>buildbot-worker create-worker BASEDIR MASTERHOST:PORT WORKERNAME PASSWORD</pre><br />
* Run buildbot on the worker system, preferably by starting it automatically when your system boots. It should be running with the buildbot user ID. <pre>buildbot-worker start BASEDIR</pre><br />
<br />
== ccache ==<br />
<br />
You may also want to set up '''ccache''' to work with buildbot (strongly recommended to speed up builds). If you create a directory {{Path|~/buildbot/bin}}, it will be added to the execution PATH when the Buildbot Master runs commands on the Buildbot Worker. This directory can have symbolic links like the following:<br />
<br />
lrwxrwxrwx 1 buildbot buildbot 15 Aug 26 11:39 gcc -> /usr/bin/ccache<br />
lrwxrwxrwx 1 buildbot buildbot 15 Aug 26 11:40 cc -> /usr/bin/ccache<br />
lrwxrwxrwx 1 buildbot buildbot 15 Aug 26 11:40 c++ -> /usr/bin/ccache<br />
lrwxrwxrwx 1 buildbot buildbot 15 Aug 31 23:46 gfortran -> /usr/bin/ccache<br />
<br />
They should point to the actual location of ccache if it is not in {{Path|/usr/bin}}.<br />
<br />
== Space Requirements ==<br />
<br />
Building Octave takes a significant amount of disk space. With debugging symbols, you may need several GB for each build, plus room for ccache (possibly 50GB) if you use it. If you use a cache size that is larger than the default, you'll need to specify that in the {{Path|.ccache/ccache.conf}} file using a line like<br />
<br />
max_size = 50G<br />
<br />
If the directory containing the build and ccache directories doesn't have sufficient space, then these directory names may point to a separate partition that does have enough space available.<br />
<br />
= External links =<br />
<br />
* [https://hg.octave.org/octave-buildbot/ Buildbot configuration repository] for http://buildbot.octave.org:8010<br />
<br />
[[Category:Building]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Debugging_Octave&diff=13286Debugging Octave2020-07-30T01:12:46Z<p>Siko1056: Minor fixes.</p>
<hr />
<div>= Preliminaries =<br />
<br />
Since compilation of all the source from scratch can take long it is good to have a source folder where most of the source has been compiled. To do this, you can create a parallel build:<br />
<br />
<syntaxhighlight lang="bash"><br />
mkdir dbg-octave<br />
cd dbg-octave<br />
/path/to/octave/source/configure FFLAGS=-g CFLAGS=-g CXXFLAGS=-g --enable-address-sanitizer-flags --prefix=/opt/dbg-octave<br />
make # or make -jN where N is the number of CPU cores<br />
</syntaxhighlight><br />
<br />
This will create a new build of Octave in a different directory without optimizations (no -O2 gcc parameter) and with debug symbols compiled in. This build is useful for debugging Octave itself.<br />
<br />
= Tools for debugging =<br />
<br />
There are different tools for debugging. This article concentrates on describing how to use <code>gdb</code>.<br />
<br />
If you run Octave from a build tree, execute <code>./run-octave -g</code> to start a gdb session that is prepared to run Octave (with the necessary environment correctly set up). Note that when Octave runs in GUI mode, it forks at startup on Linux and MacOS systems, so this method will only work if <code>gdb</code> correctly follows the process across the <code>fork</code> and <code>exec</code> system calls.<br />
<br />
Alternatively, you can attach a debugger to a running Octave session. Current development versions of Octave include the command <code>__debug_octave__</code> to manage the details. Executing this command at the Octave prompt should open a separate window for a debugger session attached to the current Octave process. On Linux systems, the default terminal window is <code>gnome-terminal</code>. On MacOS systems, the default debugger is <code>lldb</code>.<br />
<br />
For some kinds of errors on some OS, the last approach might not be useful. The OS might kill the shell that runs gdb as soon as the spawning process (i.e. Octave) crashes. In that case, you can attach to Octave from an "independent" shell. Execute <code>getpid ()</code> in Octave and take note of the displayed *PID*. Open a shell and execute <code>gdb -p *PID*</code> (replace <code>*PID*</code> with the actual PID). On Windows, use the msys2 shell that can be started with the file <code>cmdshell.bat</code> in Octave's installation folder.<br />
<br />
Independent of how <code>gdb</code> was started and Octave was attached to it, it is now possible to issue gdb commands on the <code>(gdb)</code> prompt. See e.g. the [https://sourceware.org/gdb/download/onlinedocs/gdb/index.html gdb documentation]. To return to Octave while gdb is still attached to it, execute <code>continue</code> (or <code>c</code>) at the <code>(gdb)</code> prompt.<br />
<br />
*NOTE: Ubuntu introduced a patch to disallow ptracing of non-child processes by non-root users - i.e. only a process which is a parent of another process can ptrace it for normal users - whilst root can still ptrace every process.<br />
That's why gdb won't be able to link to the octave process if you start gdb from within an Octave session using the <code>__debug_octave__</code> command.<br />
<br />
You can temporarily disable this restriction by doing:<br />
<syntaxhighlight lang="bash"><br />
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope<br />
</syntaxhighlight><br />
and then reopen <code>gdb</code> using the command mentioned above from within an Octave session or if you have admin rights you can simply do:<br />
<syntaxhighlight lang="bash"><br />
__debug_octave__ ("gnome-terminal --command 'sudo gdb -p %d'")<br />
</syntaxhighlight><br />
<br />
= Debugging oct-files =<br />
<br />
To debug oct-files, avoid making any optimization during compilation. Use <code>export CXXFLAGS="-ggdb -Wall -O0"</code> for C++ code or <code>export CFLAGS="-ggdb -Wall -O0"</code> for C code to suppress optimization. Compile the oct-file with the debug flag <code>-g</code> which enables debug symbols<br />
<br />
<syntaxhighlight lang="bash"><br />
mkoctfile -g file.cpp<br />
</syntaxhighlight><br />
<br />
In next step you will use GNU debugger or gdb. The symbols from your oct-file will only be available to gdb once the oct-file is loaded in Octave. To do that without executing any functions from the oct-file, you can ask Octave to display the help for the oct-file:<br />
<br />
<syntaxhighlight lang="bash"><br />
octave> help file<br />
</syntaxhighlight><br />
<br />
start now the GNU debugger with octave by following the instructions above.<br />
<br />
Now you can set a breakpoint in the line of interest of your oct-file in gdb prompt:<br />
<br />
<syntaxhighlight lang="bash"><br />
(gdb) b file.cpp:40<br />
</syntaxhighlight><br />
<br />
by typing c the execution of octave will continue and you can run your oct-file directly or via an m-script.<br />
<br />
<syntaxhighlight lang="octave"><br />
octave> x = file(y)<br />
</syntaxhighlight> <br />
<br />
the debugger will stop on the above defined line and you can start debugging according to the manual of GNU debugger.<br />
<br />
== Producing a stack trace ==<br />
<br />
Sometimes Octave might crash, meaning, it terminates abruptly and returns control to the operating system shell. In these cases, it is very helpful to produce a stack trace to diagnose the problem. For this, it can be useful to (re)compile Octave with debugging symbols. Otherwise, the stack trace can be harder to read and optimizations might make debugging more difficult. (But it is also possible to produce a stack trace with a "standard" build.)<br />
<br />
Attach <code>gdb</code> to Octave as described before and return execution to Octave. Then, execute whatever commands are necessary to cause Octave to crash. At that point, you will be back in the gdb session. Type <code>where</code> or <code>bt</code> at the gdb prompt to obtain a stack trace.<br />
<br />
When running in GUI mode or debugging threading issues, it is usually useful to get information about all the execution threads at the point of the crash. To do that, use the gdb command <code>thread apply all bt</code>.<br />
<br />
You could also get some help from your system tools. In most GNU/Linux systems whenever a crash happens in a software, a <i>core dump</i> will be generated. These core dumps are handled by a registered component of the system and finally might be stored somewhere in the directory tree. You should find them, view them and inspect them.<br />
<br />
=== Where are core dumps stored? ===<br />
<br />
It differs on each system. First you should see how core dumps are handled on your system. To do so, type this in a shell terminal:<br />
<syntaxhighlight lang="bash"><br />
$ cat /proc/sys/kernel/core_pattern<br />
</syntaxhighlight><br />
This may print a file name pattern along with a path where all core dumps will be saved <b>ONLY</b> if it does not start by a pipe or '|'. If it does, <i>the kernel will treat the rest of the pattern as a command to run. The core dump will be written to the standard input of that program instead of to a file</i>, and you need to consult that program's help or manual.<br />
<br />
=== How to view a core dump? ===<br />
<br />
To do this you should use gdb. Core dumps are saved under root user, so you may need to change owner of the core dump you are interested in if you are not logged in as root. After that type in the terminal:<br />
<syntaxhighlight lang="bash"><br />
gdb octave -c <Path to core dump><br />
</syntaxhighlight><br />
<br />
Always expect some warnings from gdb in a few first times of doing this. Most likely gdb will tell you that:<br />
<br />
1. The core dump file is not in the correct format. It is the case if the core dump handler of your system compresses core dumps before storing them, and you need to decompress the core dump first.<br />
<br />
2. Core dump was generated by a-path-to/octave-gui. Then quit gdb and start it again by:<br />
<syntaxhighlight lang="bash"><br />
gdb octave-gui -c <Path to core dump><br />
</syntaxhighlight><br />
<br />
3. Some debug info are missing. In this case gdb itself will tell you how to install them. Install them and start gdb again.<br />
<br />
If everything worked fine, you can use <code>where</code> command in gdb prompt to see a full stack trace of the crash.<br />
<br />
=== Helpful gdb commands ===<br />
<br />
[http://www.gnu.org/software/gdb/documentation gdb documentation]<br />
<br />
The following command shows the back trace of all threads belonging to the Octave process:<br />
<syntaxhighlight lang="bash"><br />
(gdb) thread apply all bt<br />
</syntaxhighlight><br />
<br />
For debugging octave_value variables (e.g. <code>my_octave_value</code>) to find out what the variable actually is (instead of just it's base class):<br />
<syntaxhighlight lang="bash"><br />
(gdb) print *(my_octave_value.rep)<br />
</syntaxhighlight><br />
<br />
The file <code>etc/gdbinit</code> in the Octave repository contains some macros that can be helpful:<br />
* <code>display-dims DIM_VECTOR</code>: Display the contents of an Octave dimension vector.<br />
* <code>display-dense-array ARRAY</code>: Display the contents of an ordinary, i.e., dense Octave array.<br />
* <code>display-sparse-array SPARSE_ARRAY</code>: Display the contents of a sparse Octave array.<br />
* <code>show-octave-dbstack</code>: Display the contents of the current Octave debugging stack.<br />
<br />
== ddd ==<br />
<br />
[http://www.gnu.org/software/ddd GUI for gdb]<br />
<br />
[[Category:Development]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Online_Developer_Meeting_(2020-07-28)&diff=13283Online Developer Meeting (2020-07-28)2020-07-29T05:59:31Z<p>Siko1056: /* Todays topics */ Code sprints</p>
<hr />
<div>* Date: [https://octave.discourse.group/t/online-developer-meeting/106 Tuesday, July 28, 2020 @ 18:00 UTC]<br />
* Location: https://meet.jit.si/octave-dev-2020-07-28<br />
<br />
== Todays topics ==<br />
<br />
* Meet and greet 5 minutes before meeting (audio testing).<br />
<br />
=== Octave 6 release status ===<br />
<br />
* We should create a first release candidate (RC) Octave '''6.0.90''' soon. Base for discussing and working on further bug findings.<br />
** Update gnulib before RC<br />
** Tag some cset on stable.<br />
** Build MS Windows binaries.<br />
** Upload to https://alpha.gnu.org/gnu/octave/ .<br />
<br />
* Still hard to fix blocking bugs<br />
** Bug with graphic handles while closing Octave (bug {{bug|58814}}) was reported. This happens when exit is called from a script or when directly calling exit after running the script in the CLI. How to properly handle graphics callbacks during exit?<br />
** 32-bit MS Windows builds<br />
*** ode15 with Sundials make problems (bug {{bug|58795}}). Maybe already solved.<br />
*** Precision problems failing the test suite (bug {{bug|58807}}). Solvable by requiring SSE2 instructions. Go ahead with it.<br />
*** Unreported GUI problems. Done with (bug {{bug|58844}}).<br />
<br />
* Are there breaking changes in Octave 6 to inform package maintainers? No, only deprecated functions are now removed.<br />
<br />
* Add script to start GDB session from Octave for debugging, see [[Debugging Octave]].<br />
<br />
=== Octave community ===<br />
<br />
* Changes about the mailing-list advertisements<br />
** Are there sports left where the help mailing-list is advertised, e.g. GUI? Maybe not.<br />
<br />
* Get rid of nabble? (Discussion was short here)<br />
<br />
=== Octave 7 ideas ===<br />
<br />
* Range datatype<br />
** Should Octave support numeric operations on them?<br />
** There was a thread on the maintainers mailing-list by jwe. Open discourse thread about it.<br />
<br />
* Loading and saving<br />
** Octave load/save supports a bunch of data types (mat v4, text, ascii, ...)<br />
*** Deprecate some of them? Open Discourse discussion about it.<br />
*** Large array support for Octave's own storage types?<br />
*** Storage of nested functions in mat v4 in Matlab possible?<br />
** Focus on the HDF5 format in the future. Matlab prioritizes it too, external tools for viewing the files available.<br />
** Support classdef load/save.<br />
<br />
=== Code sprints ===<br />
<br />
* There was a suggestion to have online code sprints, dedicated to one particular topic, as addition to the online developer meetings.<br />
<br />
== Ideas for next meeting ==<br />
<br />
=== Topic suggestions ===<br />
<br />
== See also ==<br />
<br />
* Next meeting: TBA<br />
* Last meeting: [[Online Developer Meeting (2020-07-07)]]<br />
<br />
[[Category:2020]]<br />
[[Category:Meetings]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Online_Developer_Meeting_(2020-07-28)&diff=13282Online Developer Meeting (2020-07-28)2020-07-29T03:06:10Z<p>Siko1056: /* Octave 6 release status */</p>
<hr />
<div>* Date: [https://octave.discourse.group/t/online-developer-meeting/106 Tuesday, July 28, 2020 @ 18:00 UTC]<br />
* Location: https://meet.jit.si/octave-dev-2020-07-28<br />
<br />
== Todays topics ==<br />
<br />
* Meet and greet 5 minutes before meeting (audio testing).<br />
<br />
=== Octave 6 release status ===<br />
<br />
* We should create a first release candidate (RC) Octave '''6.0.90''' soon. Base for discussing and working on further bug findings.<br />
** Update gnulib before RC<br />
** Tag some cset on stable.<br />
** Build MS Windows binaries.<br />
** Upload to https://alpha.gnu.org/gnu/octave/ .<br />
<br />
* Still hard to fix blocking bugs<br />
** Bug with graphic handles while closing Octave (bug {{bug|58814}}) was reported. This happens when exit is called from a script or when directly calling exit after running the script in the CLI. How to properly handle graphics callbacks during exit?<br />
** 32-bit MS Windows builds<br />
*** ode15 with Sundials make problems (bug {{bug|58795}}). Maybe already solved.<br />
*** Precision problems failing the test suite (bug {{bug|58807}}). Solvable by requiring SSE2 instructions. Go ahead with it.<br />
*** Unreported GUI problems. Done with (bug {{bug|58844}}).<br />
<br />
* Are there breaking changes in Octave 6 to inform package maintainers? No, only deprecated functions are now removed.<br />
<br />
* Add script to start GDB session from Octave for debugging, see [[Debugging Octave]].<br />
<br />
=== Octave community ===<br />
<br />
* Changes about the mailing-list advertisements<br />
** Are there sports left where the help mailing-list is advertised, e.g. GUI? Maybe not.<br />
<br />
* Get rid of nabble? (Discussion was short here)<br />
<br />
=== Octave 7 ideas ===<br />
<br />
* Range datatype<br />
** Should Octave support numeric operations on them?<br />
** There was a thread on the maintainers mailing-list by jwe. Open discourse thread about it.<br />
<br />
* Loading and saving<br />
** Octave load/save supports a bunch of data types (mat v4, text, ascii, ...)<br />
*** Deprecate some of them? Open Discourse discussion about it.<br />
*** Large array support for Octave's own storage types?<br />
*** Storage of nested functions in mat v4 in Matlab possible?<br />
** Focus on the HDF5 format in the future. Matlab prioritizes it too, external tools for viewing the files available.<br />
** Support classdef load/save.<br />
<br />
== Ideas for next meeting ==<br />
<br />
=== Topic suggestions ===<br />
<br />
== See also ==<br />
<br />
* Next meeting: TBA<br />
* Last meeting: [[Online Developer Meeting (2020-07-07)]]<br />
<br />
[[Category:2020]]<br />
[[Category:Meetings]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Continuous_Build&diff=13281Continuous Build2020-07-29T02:22:32Z<p>Siko1056: Overhaul page, describe the Buildbot Worker setup more easy.</p>
<hr />
<div>GNU Octave uses [https://buildbot.net/ Buildbot] to build and test the current development version on multiple systems in a number of different configurations.<br />
<br />
{{Note|The current status of the builds may be found at http://buildbot.octave.org:8010/#/waterfall.}}<br />
<br />
= Systems and Configurations =<br />
<br />
The following systems and configurations are currently covered for Octave builds:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Builder ID !! Hg Version !! System !! Compiler !! Build Options !! Frequency<br />
|-<br />
| clang-3.8-debian || default || Debian Testing || Clang 3.8 || Disable GraphicsMagick || Any Change<br />
|-<br />
| clang-4.0-debian || default || Debian Testing || Clang 4.0 || || Any Change<br />
|-<br />
| clang-5.0-debian || default || Debian Testing || Clang 5.0 || || Any Change<br />
|-<br />
| clang-fedora || default || Fedora 25 || Clang (system default) || || Any Change<br />
|-<br />
| clang-osx || default || OS X || Clang || || Any Change<br />
|-<br />
| gcc-6-debian || default || Debian Testing || GCC 6 || || Any Change<br />
|-<br />
| gcc-7-debian || default || Debian Testing || GCC 7 || || Any Change<br />
|-<br />
| gcc-7-lto-debian || default || Debian Testing || GCC (system default) || || Any Change<br />
|-<br />
| gcc-fedora || default || Fedora 25 || GCC (system default) || || Any Change<br />
|-<br />
| gcc-lto-fedora || default || Fedora 25 || GCC (system default) || Enable link time optimization || Any Change<br />
|-<br />
| no-extras-debian || default || Debian Testing || GCC (system default) || Disable all optional dependencies || Any Change<br />
|-<br />
|}<br />
<br />
And for mxe-octave:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Builder ID !! Hg Version !! Build System !! Host System !! Compiler !! Build Options !! Frequency<br />
|-<br />
| mxe-native-all-on-debian || default || Debian Testing || Debian || GCC (system default) || GNU Linux, build all dependencies || Daily<br />
|-<br />
| mxe-native-on-debian || default || Debian Testing || Debian || GCC (system default) || GNU Linux, use system compiler, fontconfig, and X11 libraries || Daily<br />
|-<br />
| w32-on-debian || default || Debian Testing || Windows || GCC (mxe-octave default) || Windows 32 || Daily<br />
|-<br />
| w32-stable-on-debian || stable || Debian Testing || Windows || GCC (mxe-octave default) || Windows 32 || Daily<br />
|-<br />
| w64-32-on-debian || default || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64 || Daily<br />
|-<br />
| w64-32-stable-on-debian || stable || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64 || Daily<br />
|-<br />
| w64-64-on-debian || default || Debian Testing || Windows || GCC (mxe-octave default) || Windows 64, 64-bit indexing || Daily<br />
|-<br />
|}<br />
<br />
= Setup and run a Buildbot Worker =<br />
<br />
Your system may be behind a firewall. It does not have to have a distinct public IP address.<br />
<br />
To support Octave development and run a Buildbot Worker, you must do the following:<br />
<br />
* Contact the [https://octave.discourse.group/c/maintainers/7 Octave Maintainers on Discourse] to let us know that you wish to provide a system to use as a Buildbot Worker. We will give you a <code>WORKERNAME</code> and a '''secret''' <code>PASSWORD</code> to configure your Buildbot Worker.<br />
* Install buildbot. Packages exist for most distributions. See the buildbot docs for other options. You should create a separate user account with no special privileges that will run buildbot.<br />
* Decide for a <code>BASEDIR</code>. For example, if the home directory for the buildbot user is {{Path|/var/lib/buildbot}} and your <code>WORKERNAME</code> is set to <code>'debian-x86_64'</code> , then <code>BASEDIR</code> might be {{Path|/var/lib/buildbot/worker/debian-x86_64}}.<br />
* <code>MASTERHOST</code> is <code>buildbot.octave.org</code> and <code>PORT</code> is <code>9989</code>.<br />
* Create the configuration<pre>buildbot-worker create-worker BASEDIR MASTERHOST:PORT WORKERNAME PASSWORD</pre><br />
* Run buildbot on the worker system, preferably by starting it automatically when your system boots. It should be running with the buildbot user ID. <pre>buildbot-worker start BASEDIR</pre><br />
<br />
== ccache ==<br />
<br />
You may also want to set up '''ccache''' to work with buildbot (strongly recommended to speed up builds). If you create a directory {{Path|~/buildbot/bin}}, it will be added to the execution PATH when the Buildbot Master runs commands on the Buildbot Worker. This directory can have symbolic links like the following:<br />
<br />
lrwxrwxrwx 1 buildbot buildbot 15 Aug 26 11:39 gcc -> /usr/bin/ccache<br />
lrwxrwxrwx 1 buildbot buildbot 15 Aug 26 11:40 cc -> /usr/bin/ccache<br />
lrwxrwxrwx 1 buildbot buildbot 15 Aug 26 11:40 c++ -> /usr/bin/ccache<br />
lrwxrwxrwx 1 buildbot buildbot 15 Aug 31 23:46 gfortran -> /usr/bin/ccache<br />
<br />
They should point to the actual location of ccache if it is not in {{Path|/usr/bin}}.<br />
<br />
== Space Requirements ==<br />
<br />
Building Octave takes a significant amount of disk space. With debugging symbols, you may need several GB for each build, plus room for ccache (possibly 50GB) if you use it. If you use a cache size that is larger than the default, you'll need to specify that in the {{Path|.ccache/ccache.conf}} file using a line like<br />
<br />
max_size = 50G<br />
<br />
If the directory containing the build and ccache directories doesn't have sufficient space, then these directory names may point to a separate partition that does have enough space available.<br />
<br />
[[Category:Building]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=GNU_Octave_Wiki&diff=13280GNU Octave Wiki2020-07-28T19:17:45Z<p>Siko1056: /* News */</p>
<hr />
<div>[https://www.gnu.org/software/octave/ GNU Octave] is a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems, and for performing other numerical experiments. It also provides extensive graphics capabilities for data visualization and manipulation. The program is named after [https://en.wikipedia.org/wiki/Octave_Levenspiel Octave Levenspiel], a former professor of the principal author. GNU Octave is normally used through its interactive interface ([https://en.wikipedia.org/wiki/Command-line_interface CLI] and [https://en.wikipedia.org/wiki/Graphical_user_interface GUI]), but it can also be used to write non-interactive programs. The project was conceived around 1988 and at first it was intended to be a companion to a chemical reactor design course. The GNU Octave language is largely compatible to [https://en.wikipedia.org/wiki/MATLAB Matlab] so that most programs are easily portable. In addition, functions known from the C standard library and from UNIX system calls and functions are supported. C/C++ and Fortran code can be called from Octave by creating [https://octave.org/doc/interpreter/Getting-Started-with-Oct_002dFiles.html Oct-Files], or using Matlab compatible [https://octave.org/doc/interpreter/Mex_002dFiles.html Mex-Files].<br />
<br />
== [[:Category:Installation|Installing]] ==<br />
<br />
Installation instructions for:<br />
* [[Octave for macOS|macOS]]<br />
* [[Octave for GNU/Linux|GNU/Linux]], [[Octave for Android|Android]], and [[Octave for other Unix systems|other Unix systems]]<br />
* [[Octave for Microsoft_Windows|Microsoft Windows]]<br />
<br />
Get installers and sources from https://www.octave.org/download.<br />
<br />
{{Note|'''GNU Octave {{Release}}''' is the current stable release.}}<br />
<br />
Are you using an old version of Octave? Check the [[Release History]] page to see how old it is.<br />
<br />
== [https://www.gnu.org/software/octave/news.html News] ==<br />
<br />
* ''July 28, 2020'' &mdash; Read about the [[Online Developer Meeting (2020-07-28)]].<br />
* ''July 7, 2020'' &mdash; Try out our new user and developer forum [https://octave.discourse.group Octave Discourse].<br />
* ''May 5, 2020'' &mdash; Congratulations! [[User:Abdallah_Elshamy|'''Abdallah Elshamy''']] works with GNU Octave during [https://summerofcode.withgoogle.com/organizations/4930645207285760/ Google Summer of Code 2020]. [[Summer of Code#GSoC 2020 | More information]].<br />
* ''{{Release Date}}'' &mdash; '''GNU Octave {{Release}}''' has been released (see above)!<br />
<br />
== Getting help ==<br />
<br />
* [https://octave.discourse.group Octave Discourse] - Forum for Octave users and developers.<br />
* [[FAQ|Frequently asked questions (FAQ)]]<br />
* [https://www.gnu.org/software/octave/doc/interpreter GNU Octave documentation]<br />
* [https://www.gnu.org/software/octave/support.html Other support options]<br />
<br />
== [[:Category:Resources|Getting started]] ==<br />
<br />
* [[Publications using Octave#Books|Books]]<br />
* [[Video tutorials|Videos]]<br />
* [https://bagustris.github.io/octave-tutorial Short course]<br />
<br />
[[File:Octave-flower.svg|right|frame|[[:Category:Octave Forge|Octave Forge]] is a collection of high quality packages for GNU Octave.]]<br />
<br />
== [[Packages]] / [[:Category:Octave Forge|Octave Forge]] ==<br />
<br />
* [https://octave.org/doc/interpreter/Installing-and-Removing-Packages.html Installing packages]<br />
* [[Creating packages]]<br />
* '''[[:Category:Octave Forge|Octave Forge]]''' &mdash; A collection of high quality packages for GNU Octave.<br />
<br />
== [[:Category:Development|Development]] ==<br />
<br />
We always need more help improving Octave and there are many ways [https://www.gnu.org/software/octave/get-involved.html you can contribute]. You can help by fixing bugs, developing new features, answering questions on the mailing list or IRC channel, helping to improve this wiki or other web pages.<br />
<br />
* Get an overview about the [[:Category:Development|GNU Octave development]].<br />
* Take a look at our [[Projects|project ideas]] and [[Summer of Code - Getting Started | Summer of Code project ideas]].<br />
<br />
== [[:Category:Academia|Academia]] ==<br />
<br />
* [[Publications using Octave]] &mdash; A compilation of scientific publications making reference to GNU Octave (add yours!).<br />
<br />
== External Links ==<br />
<br />
* [https://www.gnu.org/software/octave/ Octave Homepage]<br />
* [https://octave.sourceforge.io/ Octave Forge]<br />
* [https://savannah.gnu.org/bugs/?group=octave Bug Tracker]<br />
* [https://savannah.gnu.org/task/?group=octave Task Tracker]<br />
* [https://savannah.gnu.org/patch/?group=octave Patch Tracker]<br />
* [https://savannah.gnu.org/hg/?group=octave Development Repositories]<br />
* [https://planet.octave.org/ Planet Octave] - A collection of blog feeds featuring Octave developers and [[Summer of Code]] students.</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Online_Developer_Meeting_(2020-07-28)&diff=13279Online Developer Meeting (2020-07-28)2020-07-28T19:16:56Z<p>Siko1056: /* Todays topics */</p>
<hr />
<div>* Date: [https://octave.discourse.group/t/online-developer-meeting/106 Tuesday, July 28, 2020 @ 18:00 UTC]<br />
* Location: https://meet.jit.si/octave-dev-2020-07-28<br />
<br />
== Todays topics ==<br />
<br />
* Meet and greet 5 minutes before meeting (audio testing).<br />
<br />
=== Octave 6 release status ===<br />
<br />
* We should create a first release candidate (RC) Octave '''6.0.90''' soon. Base for discussing and working on further bug findings.<br />
** Update gnulib before RC<br />
** Tag some cset on stable.<br />
** Build MS Windows binaries.<br />
** Upload to https://alpha.gnu.org/gnu/octave/ .<br />
<br />
* Still hard to fix blocking bugs<br />
** Bug with graphic handles while closing Octave (bug {{bug|58814}}) was reported. This happens when exit is called from a script or when directly calling exit after running the script in the CLI. How to properly handle graphics callbacks during exit?<br />
** 32-bit MS Windows builds<br />
*** ode15 with Sundials make problems (bug {{bug|58795}}). Maybe already solved.<br />
*** Precision problems failing the test suite (bug {{bug|58807}}). Solvable by requiring SSE2 instructions. Go ahead with it.<br />
*** Unreported GUI problems. Please report them.<br />
<br />
* Are there breaking changes in Octave 6 to inform package maintainers? No, only deprecated functions are now removed.<br />
<br />
* Add script to start GDB session from Octave for debugging, see [[Debugging Octave]].<br />
<br />
=== Octave community ===<br />
<br />
* Changes about the mailing-list advertisements<br />
** Are there sports left where the help mailing-list is advertised, e.g. GUI? Maybe not.<br />
<br />
* Get rid of nabble? (Discussion was short here)<br />
<br />
=== Octave 7 ideas ===<br />
<br />
* Range datatype<br />
** Should Octave support numeric operations on them?<br />
** There was a thread on the maintainers mailing-list by jwe. Open discourse thread about it.<br />
<br />
* Loading and saving<br />
** Octave load/save supports a bunch of data types (mat v4, text, ascii, ...)<br />
*** Deprecate some of them? Open Discourse discussion about it.<br />
*** Large array support for Octave's own storage types?<br />
*** Storage of nested functions in mat v4 in Matlab possible?<br />
** Focus on the HDF5 format in the future. Matlab prioritizes it too, external tools for viewing the files available.<br />
** Support classdef load/save.<br />
<br />
== Ideas for next meeting ==<br />
<br />
=== Topic suggestions ===<br />
<br />
== See also ==<br />
<br />
* Next meeting: TBA<br />
* Last meeting: [[Online Developer Meeting (2020-07-07)]]<br />
<br />
[[Category:2020]]<br />
[[Category:Meetings]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Online_Developer_Meeting_(2020-07-28)&diff=13278Online Developer Meeting (2020-07-28)2020-07-28T19:10:40Z<p>Siko1056: /* Octave 6 release status */</p>
<hr />
<div>* Date: [https://octave.discourse.group/t/online-developer-meeting/106 Tuesday, July 28, 2020 @ 18:00 UTC]<br />
* Location: https://meet.jit.si/octave-dev-2020-07-28<br />
<br />
== Todays topics ==<br />
<br />
* Meet and greet 5 minutes before meeting (audio testing).<br />
<br />
=== Octave 6 release status ===<br />
<br />
* We should create a first release candidate (RC) Octave '''6.0.90''' soon. Base for discussing and working on further bug findings.<br />
** Update gnulib before RC<br />
** Tag some cset on stable.<br />
** Build MS Windows binaries.<br />
** Upload to https://alpha.gnu.org/gnu/octave/ .<br />
<br />
* Still hard to fix blocking bugs<br />
** Bug with graphic handles while closing Octave (bug {{bug|58814}}) was reported. This happens when exit is called from a script or when directly calling exit after running the script in the CLI. How to properly handle graphics callbacks during exit?<br />
** 32-bit MS Windows builds<br />
*** ode15 with Sundials make problems (bug {{bug|58795}}). Maybe already solved.<br />
*** Precision problems failing the test suite (bug {{bug|58807}}). Solvable by requiring SSE2 instructions. Go ahead with it.<br />
*** Unreported GUI problems. Please report them.<br />
<br />
* Are there breaking changes in Octave 6 to inform package maintainers? No, only deprecated functions are now removed.<br />
<br />
* Add script to start GDB session from Octave for debugging, see [[Debugging Octave]].<br />
<br />
== Ideas for next meeting ==<br />
<br />
=== Topic suggestions ===<br />
<br />
== See also ==<br />
<br />
* Next meeting: TBA<br />
* Last meeting: [[Online Developer Meeting (2020-07-07)]]<br />
<br />
[[Category:2020]]<br />
[[Category:Meetings]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Online_Developer_Meeting_(2020-07-28)&diff=13277Online Developer Meeting (2020-07-28)2020-07-28T19:07:20Z<p>Siko1056: /* Todays topics */</p>
<hr />
<div>* Date: [https://octave.discourse.group/t/online-developer-meeting/106 Tuesday, July 28, 2020 @ 18:00 UTC]<br />
* Location: https://meet.jit.si/octave-dev-2020-07-28<br />
<br />
== Todays topics ==<br />
<br />
* Meet and greet 5 minutes before meeting (audio testing).<br />
<br />
=== Octave 6 release status ===<br />
<br />
* We should create a first release candidate (RC) Octave '''6.0.90''' soon. Base for discussing and working on further bug findings.<br />
** Update gnulib before RC<br />
** Tag some cset on stable.<br />
** Build MS Windows binaries.<br />
** Upload to https://alpha.gnu.org/gnu/octave/ .<br />
<br />
* Still hard to fix blocking bugs<br />
** Bug with graphic handles while closing Octave (bug {{bug|58814}}) was reported. This happens when exit is called from a script or when directly calling exit after running the script in the CLI. How to properly handle graphics callbacks during exit?<br />
** ode15 with Sundials make problems on 32-bit MS Windows builds (bug {{bug|58795}}). Maybe already solved.<br />
** 32-bit MS Windows builds have precision problems failing the test suite (bug {{bug|58807}}). Solvable by requiring SSE2 instructions. Go ahead with it.<br />
<br />
== Ideas for next meeting ==<br />
<br />
=== Topic suggestions ===<br />
<br />
== See also ==<br />
<br />
* Next meeting: TBA<br />
* Last meeting: [[Online Developer Meeting (2020-07-07)]]<br />
<br />
[[Category:2020]]<br />
[[Category:Meetings]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Online_Developer_Meeting_(2020-07-28)&diff=13276Online Developer Meeting (2020-07-28)2020-07-28T17:54:44Z<p>Siko1056: Add link.</p>
<hr />
<div>* Date: [https://octave.discourse.group/t/online-developer-meeting/106 Tuesday, July 28, 2020 @ 18:00 UTC]<br />
* Location: https://meet.jit.si/octave-dev-2020-07-28<br />
<br />
== Todays topics ==<br />
<br />
* Meet and greet 5 minutes before meeting (audio testing).<br />
<br />
=== Octave 6 release status ===<br />
<br />
* We should create a first release candidate (RC) Octave '''6.0.90''' soon. Base for discussing and working on further bug findings.<br />
** Update gnulib before RC<br />
** Tag some cset on stable.<br />
** Build MS Windows binaries.<br />
** Upload to https://alpha.gnu.org/gnu/octave/ .<br />
<br />
* Still hard to fix blocking bugs<br />
** Build (RC) anyway!<br />
** crashes during doc graphics creation seem to be fixed (bug {{bug|56952}})<br />
** still elusive crashes while running the test suite on the build bots (bug {{bug|57591}}) -> Maybe the broader user base of an RC can shed some light on "real-life frequency" of these crashes.<br />
** possible background: interaction between graphics system and interpreter is different from interaction of rest of GUI with the interpreter. Possibly resolvable by a copy-on-write approach for graphics objects (postponed to Octave 7)<br />
<br />
* Try to tackle bugs with debuggers<br />
** valgrind slow<br />
** <code>-fsanitize=thread</code> in memory and faster<br />
<br />
* Before Octave 6.1.0 release, discharge MS Windows 10 Malware Detection Systems (e.g. upload to https://www.virustotal.com/)<br />
<br />
== Ideas for next meeting ==<br />
<br />
=== Topic suggestions ===<br />
<br />
== See also ==<br />
<br />
* Next meeting: TBA<br />
* Last meeting: [[Online Developer Meeting (2020-07-07)]]<br />
<br />
[[Category:2020]]<br />
[[Category:Meetings]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Online_Developer_Meeting_(2020-07-28)&diff=13275Online Developer Meeting (2020-07-28)2020-07-28T07:28:29Z<p>Siko1056: /* Octave 6 release status */ Remove fixed bugs.</p>
<hr />
<div>* Date: [https://octave.discourse.group/t/online-developer-meeting/106 Tuesday, July 28, 2020 @ 18:00 UTC]<br />
* Location: Jitsi (link TBA)<br />
<br />
== Todays topics ==<br />
<br />
* Meet and greet 5 minutes before meeting (audio testing).<br />
<br />
=== Octave 6 release status ===<br />
<br />
* We should create a first release candidate (RC) Octave '''6.0.90''' soon. Base for discussing and working on further bug findings.<br />
** Update gnulib before RC<br />
** Tag some cset on stable.<br />
** Build MS Windows binaries.<br />
** Upload to https://alpha.gnu.org/gnu/octave/ .<br />
<br />
* Still hard to fix blocking bugs<br />
** Build (RC) anyway!<br />
** crashes during doc graphics creation seem to be fixed (bug {{bug|56952}})<br />
** still elusive crashes while running the test suite on the build bots (bug {{bug|57591}}) -> Maybe the broader user base of an RC can shed some light on "real-life frequency" of these crashes.<br />
** possible background: interaction between graphics system and interpreter is different from interaction of rest of GUI with the interpreter. Possibly resolvable by a copy-on-write approach for graphics objects (postponed to Octave 7)<br />
<br />
* Try to tackle bugs with debuggers<br />
** valgrind slow<br />
** <code>-fsanitize=thread</code> in memory and faster<br />
<br />
* Before Octave 6.1.0 release, discharge MS Windows 10 Malware Detection Systems (e.g. upload to https://www.virustotal.com/)<br />
<br />
== Ideas for next meeting ==<br />
<br />
=== Topic suggestions ===<br />
<br />
== See also ==<br />
<br />
* Next meeting: TBA<br />
* Last meeting: [[Online Developer Meeting (2020-07-07)]]<br />
<br />
[[Category:2020]]<br />
[[Category:Meetings]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=GNU_Octave_Wiki&diff=13274GNU Octave Wiki2020-07-28T07:27:16Z<p>Siko1056: /* News */ Announce Online Developer Meeting (2020-07-28).</p>
<hr />
<div>[https://www.gnu.org/software/octave/ GNU Octave] is a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems, and for performing other numerical experiments. It also provides extensive graphics capabilities for data visualization and manipulation. The program is named after [https://en.wikipedia.org/wiki/Octave_Levenspiel Octave Levenspiel], a former professor of the principal author. GNU Octave is normally used through its interactive interface ([https://en.wikipedia.org/wiki/Command-line_interface CLI] and [https://en.wikipedia.org/wiki/Graphical_user_interface GUI]), but it can also be used to write non-interactive programs. The project was conceived around 1988 and at first it was intended to be a companion to a chemical reactor design course. The GNU Octave language is largely compatible to [https://en.wikipedia.org/wiki/MATLAB Matlab] so that most programs are easily portable. In addition, functions known from the C standard library and from UNIX system calls and functions are supported. C/C++ and Fortran code can be called from Octave by creating [https://octave.org/doc/interpreter/Getting-Started-with-Oct_002dFiles.html Oct-Files], or using Matlab compatible [https://octave.org/doc/interpreter/Mex_002dFiles.html Mex-Files].<br />
<br />
== [[:Category:Installation|Installing]] ==<br />
<br />
Installation instructions for:<br />
* [[Octave for macOS|macOS]]<br />
* [[Octave for GNU/Linux|GNU/Linux]], [[Octave for Android|Android]], and [[Octave for other Unix systems|other Unix systems]]<br />
* [[Octave for Microsoft_Windows|Microsoft Windows]]<br />
<br />
Get installers and sources from https://www.octave.org/download.<br />
<br />
{{Note|'''GNU Octave {{Release}}''' is the current stable release.}}<br />
<br />
Are you using an old version of Octave? Check the [[Release History]] page to see how old it is.<br />
<br />
== [https://www.gnu.org/software/octave/news.html News] ==<br />
<br />
* ''July 28, 2020'' &mdash; Join us on our [[Online Developer Meeting (2020-07-28)]].<br />
* ''July 7, 2020'' &mdash; Try out our new user and developer forum [https://octave.discourse.group Octave Discourse].<br />
* ''May 5, 2020'' &mdash; Congratulations! [[User:Abdallah_Elshamy|'''Abdallah Elshamy''']] works with GNU Octave during [https://summerofcode.withgoogle.com/organizations/4930645207285760/ Google Summer of Code 2020]. [[Summer of Code#GSoC 2020 | More information]].<br />
* ''{{Release Date}}'' &mdash; '''GNU Octave {{Release}}''' has been released (see above)!<br />
<br />
== Getting help ==<br />
<br />
* [https://octave.discourse.group Octave Discourse] - Forum for Octave users and developers.<br />
* [[FAQ|Frequently asked questions (FAQ)]]<br />
* [https://www.gnu.org/software/octave/doc/interpreter GNU Octave documentation]<br />
* [https://www.gnu.org/software/octave/support.html Other support options]<br />
<br />
== [[:Category:Resources|Getting started]] ==<br />
<br />
* [[Publications using Octave#Books|Books]]<br />
* [[Video tutorials|Videos]]<br />
* [https://bagustris.github.io/octave-tutorial Short course]<br />
<br />
[[File:Octave-flower.svg|right|frame|[[:Category:Octave Forge|Octave Forge]] is a collection of high quality packages for GNU Octave.]]<br />
<br />
== [[Packages]] / [[:Category:Octave Forge|Octave Forge]] ==<br />
<br />
* [https://octave.org/doc/interpreter/Installing-and-Removing-Packages.html Installing packages]<br />
* [[Creating packages]]<br />
* '''[[:Category:Octave Forge|Octave Forge]]''' &mdash; A collection of high quality packages for GNU Octave.<br />
<br />
== [[:Category:Development|Development]] ==<br />
<br />
We always need more help improving Octave and there are many ways [https://www.gnu.org/software/octave/get-involved.html you can contribute]. You can help by fixing bugs, developing new features, answering questions on the mailing list or IRC channel, helping to improve this wiki or other web pages.<br />
<br />
* Get an overview about the [[:Category:Development|GNU Octave development]].<br />
* Take a look at our [[Projects|project ideas]] and [[Summer of Code - Getting Started | Summer of Code project ideas]].<br />
<br />
== [[:Category:Academia|Academia]] ==<br />
<br />
* [[Publications using Octave]] &mdash; A compilation of scientific publications making reference to GNU Octave (add yours!).<br />
<br />
== External Links ==<br />
<br />
* [https://www.gnu.org/software/octave/ Octave Homepage]<br />
* [https://octave.sourceforge.io/ Octave Forge]<br />
* [https://savannah.gnu.org/bugs/?group=octave Bug Tracker]<br />
* [https://savannah.gnu.org/task/?group=octave Task Tracker]<br />
* [https://savannah.gnu.org/patch/?group=octave Patch Tracker]<br />
* [https://savannah.gnu.org/hg/?group=octave Development Repositories]<br />
* [https://planet.octave.org/ Planet Octave] - A collection of blog feeds featuring Octave developers and [[Summer of Code]] students.</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Online_Developer_Meeting_(2020-07-07)&diff=13273Online Developer Meeting (2020-07-07)2020-07-28T07:23:51Z<p>Siko1056: /* See also */ Announce next meeting.</p>
<hr />
<div>* Date: [https://lists.gnu.org/archive/html/octave-maintainers/2020-06/msg00134.html Tuesday, July 7, 2020 @ 14:00 UTC]<br />
* Location: https://meet.jit.si/octave-dev-2020-07-07<br />
<br />
== Todays topics ==<br />
<br />
* Meet and greet 5 minutes before meeting (audio testing).<br />
<br />
=== Octave 6 release status ===<br />
<br />
* We should create a first release candidate (RC) Octave '''6.0.90''' soon. Base for discussing and working on further bug findings.<br />
** Update gnulib before RC<br />
** Tag some cset on stable.<br />
** Build MS Windows binaries.<br />
** Upload to https://alpha.gnu.org/gnu/octave/ .<br />
<br />
* Still hard to fix blocking bugs<br />
** Build (RC) anyway!<br />
** crashes during doc graphics creation seem to be fixed (bug {{bug|56952}})<br />
** still elusive crashes while running the test suite on the build bots (bug {{bug|57591}}) -> Maybe the broader user base of an RC can shed some light on "real-life frequency" of these crashes.<br />
** possible background: interaction between graphics system and interpreter is different from interaction of rest of GUI with the interpreter. Possibly resolvable by a copy-on-write approach for graphics objects (postponed to Octave 7)<br />
<br />
* Other important bugs<br />
** calling script from nested functions (bug {{bug|58691}} fixed)<br />
** empty list creation if one element is not assigned (bug {{bug|58686}} not a blocker)<br />
<br />
* Try to tackle bugs with debuggers<br />
** valgrind slow<br />
** <code>-fsanitize=thread</code> in memory and faster<br />
<br />
* Before Octave 6.1.0 release, discharge MS Windows 10 Malware Detection Systems (e.g. upload to https://www.virustotal.com/)<br />
<br />
=== Community Infrastructure ([[User:siko1056|Kai]]) ===<br />
<br />
* [https://octave.discourse.group/ Discourse for GNU Octave] '''YES, we give it a try!''' 😁<br />
** Replacement for mailing-lists (help@octave.org and maintainers@octave.org) and https://planet.octave.org<br />
*** Leave old mailing-lists as they are now, but no longer actively advertise them.<br />
*** '''TODO:''' Advertise Octave Discourse <strike>on Octave homepage</strike> and announce on mailing-lists<br />
** Badge system, will stay active for the start<br />
** Discussions are welcome<br />
*** Max. image upload size: (Yes) There is not a restriction in the file size, but in the megapixels <code>max image megapixels = 40</code> and dimension <code>max image width = 690</code>, <code>max image height = 500</code>.<br />
*** Max. edit time: Yes, there is <code>editing grace period = 300</code> seconds, but admins can edit any post.<br />
*** Possible exit strategy in case we don't like Discourse?<br />
**** Return to still active mailing-lists always possible.<br />
**** Disable Posting in that Forum, try to leave it as archive. If Discourse does not allow archives, we can export the SQL database and try to host the knowledge on some other facility.<br />
** See also https://octave.discourse.group/t/do-we-want-to-adopt-discourse/39<br />
* (No time left, maybe next time) <strike>Hosting Octave main website on "https://www.octave.org" (jwe's dreamhost.com account) rather than "https://www.gnu.org/software/octave/", see [[Project Infrastructure]].<br />
** Updating Octave's main website is pain ([https://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], see [https://hg.octave.org/web-octave/file/tip/Makefile Makefile])</strike><br />
<br />
== Ideas for next meeting ==<br />
<br />
=== Topic suggestions ===<br />
<br />
== See also ==<br />
<br />
* Next meeting: [[Online Developer Meeting (2020-07-28)]]<br />
* Last meeting: [[Online Developer Meeting (2020-06-09)]]<br />
<br />
[[Category:2020]]<br />
[[Category:Meetings]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Online_Developer_Meeting_(2020-07-28)&diff=13272Online Developer Meeting (2020-07-28)2020-07-28T07:23:07Z<p>Siko1056: Create page.</p>
<hr />
<div>* Date: [https://octave.discourse.group/t/online-developer-meeting/106 Tuesday, July 28, 2020 @ 18:00 UTC]<br />
* Location: Jitsi (link TBA)<br />
<br />
== Todays topics ==<br />
<br />
* Meet and greet 5 minutes before meeting (audio testing).<br />
<br />
=== Octave 6 release status ===<br />
<br />
* We should create a first release candidate (RC) Octave '''6.0.90''' soon. Base for discussing and working on further bug findings.<br />
** Update gnulib before RC<br />
** Tag some cset on stable.<br />
** Build MS Windows binaries.<br />
** Upload to https://alpha.gnu.org/gnu/octave/ .<br />
<br />
* Still hard to fix blocking bugs<br />
** Build (RC) anyway!<br />
** crashes during doc graphics creation seem to be fixed (bug {{bug|56952}})<br />
** still elusive crashes while running the test suite on the build bots (bug {{bug|57591}}) -> Maybe the broader user base of an RC can shed some light on "real-life frequency" of these crashes.<br />
** possible background: interaction between graphics system and interpreter is different from interaction of rest of GUI with the interpreter. Possibly resolvable by a copy-on-write approach for graphics objects (postponed to Octave 7)<br />
<br />
* Other important bugs<br />
** calling script from nested functions (bug {{bug|58691}} fixed)<br />
** empty list creation if one element is not assigned (bug {{bug|58686}} not a blocker)<br />
<br />
* Try to tackle bugs with debuggers<br />
** valgrind slow<br />
** <code>-fsanitize=thread</code> in memory and faster<br />
<br />
* Before Octave 6.1.0 release, discharge MS Windows 10 Malware Detection Systems (e.g. upload to https://www.virustotal.com/)<br />
<br />
== Ideas for next meeting ==<br />
<br />
=== Topic suggestions ===<br />
<br />
== See also ==<br />
<br />
* Next meeting: TBA<br />
* Last meeting: [[Online Developer Meeting (2020-07-07)]]<br />
<br />
[[Category:2020]]<br />
[[Category:Meetings]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=FAQ&diff=13271FAQ2020-07-27T01:08:56Z<p>Siko1056: /* MS Windows */ Add solution about script execution prohibition.</p>
<hr />
<div>This is a list of frequently asked questions (FAQ) for GNU Octave users.<br />
<br />
We are always looking for new questions (with answers), better answers, or both. Feel free to edit this page with your changes.<br />
<br />
=Where do I get additional help?=<br />
<br />
If you can't find an answer to your question in this FAQ, wiki, or in the [http://www.octave.org/doc/interpreter manual] ([http://www.octave.org/octave.pdf PDF]) you can:<br />
<br />
* Search for an answer in our [https://lists.gnu.org/archive/html/help-octave/ mailing list archives]<br />
* Contact our user community using our [https://octave.discourse.group Octave Discourse].<br />
* Contact our user community using our [https://webchat.freenode.net/?channels=octave IRC chat room <code>#octave</code> in Freenode]<br />
<br />
<div class="tocinline">__TOC__</div><br />
<br />
=General=<br />
<br />
==What is Octave?==<br />
<br />
[https://www.gnu.org/software/octave/ GNU Octave] is a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems, and for performing other numerical experiments. It also provides extensive graphics capabilities for data visualization and manipulation. GNU Octave is normally used through its interactive interface ([https://en.wikipedia.org/wiki/Command-line_interface CLI] and [https://en.wikipedia.org/wiki/Graphical_user_interface GUI]), but it can also be used to write non-interactive programs. <br />
The GNU Octave language is quite similar to Matlab so that most programs are easily portable.<br />
<br />
The GNU Octave distribution includes a [http://www.octave.org/octave.pdf 1000+ page Texinfo manual]. Access to the complete text of the manual is available via the <code>doc</code> command at the GNU Octave prompt.<br />
<br />
==What is Octave Forge?==<br />
<br />
[https://octave.sourceforge.io/ Octave Forge] is a collection of [[packages]] for GNU Octave, something similar to the Matlab toolboxes. When talking about the two projects at the same time, GNU Octave is usually referred to as Octave core (or just "core"). Octave Forge also serves as a test bed for code that may eventually end up in the core, and distributes binaries for systems with a lack of developers tools (mainly Windows).<br />
<br />
==Who uses Octave?==<br />
<br />
A huge number of people ranging from students to researchers involved in various fields such as statistics,Machine Learning, data analytics, etc. Universities use it for research and teaching, companies of all sizes for development and individuals for certain private purposes. See [[Who Uses Octave?]] for more clarity.<br />
<br />
==Who develops Octave?==<br />
<br />
Discussions about writing the software that would eventually become Octave started in about 1988 with James B. Rawlings and [http://jweaton.org/ John W. Eaton] at the University of Texas. John W. Eaton is the original author of Octave, starting full-time development in February 1992. He is still the primary maintainer. The community of users and developers has in addition contributed some code and fuels the discussion on the mailing lists [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org] (user forum), [https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers@octave.org] (development issues). Since 2011, GNU Octave regularly participates in [[Summer of Code]] events as a mentor organisation. As part of those events, several students contributed to Octave by helping in removal of bugs and development of new features.<br />
<br />
==Why "Octave"?==<br />
<br />
Octave's name has nothing to do with music. It is named after [http://en.wikipedia.org/wiki/Octave_Levenspiel Octave Levenspiel], a former professor of John who was famous for his ability to do quick back-of-the-envelope calculations. You can hear John pronounce the name "Octave" a few times [http://videolectures.net/mloss08_eaton_oct/ in this video]. We hope that GNU Octave will help perform computations with the same ease as Dr. Levenspiel.<br />
<br />
==Why "GNU" Octave?==<br />
<br />
The [https://www.gnu.org/ GNU Project] was launched in 1984 to develop a complete Unix-like operating system which is free software: the GNU system. GNU is a recursive acronym for "GNU's Not Unix"; it is pronounced [https://www.gnu.org/gnu/pronunciation.en.html g'noo].<br />
<br />
The [https://www.fsf.org/ Free Software Foundation (FSF)] is the principal organization that has sponsored the GNU Project.<br />
<br />
Octave became GNU Octave in 1997 (beginning with [[Release History|version 2.0.6]]). This meant agreeing to consider Octave a part of the GNU Project and support the efforts of the FSF. A big part of this effort is to adhere to the [https://www.gnu.org/prep/standards/standards.html GNU coding standards] and to benefit from GNU's infrastructure (e.g. [https://hg.savannah.gnu.org/hgweb/octave/ code hosting] and [http://bugs.octave.org bug tracking]). Additionally, Octave receives [https://my.fsf.org/donate/working-together/octave sponsorship] from the FSF's Working Together fund. However, Octave is not and has never been developed by the FSF.<br />
<br />
==How can I cite Octave?==<br />
<br />
Octave is free software and does not legally bind you to cite it. However, we have invested a lot of time and effort in creating GNU Octave, and we would appreciate if you would cite if you used. To cite GNU Octave in publications use:<br />
<br />
John W. Eaton, David Bateman, Søren Hauberg, Rik Wehbring ({{Release Year}}).<br />
GNU Octave version {{Release}} manual: a high-level interactive language for numerical computations.<br />
URL https://www.gnu.org/software/octave/doc/v{{Release}}/<br />
<br />
A [https://en.wikipedia.org/wiki/BibTeX BibTeX] entry for [https://en.wikipedia.org/wiki/LaTeX LaTeX] users is:<br />
<br />
@manual{,<br />
title = {{GNU Octave} version {{Release}} manual: a high-level interactive language for numerical computations},<br />
author = {John W. Eaton and David Bateman and S{\o}ren Hauberg and Rik Wehbring},<br />
year = <span>{</span>{{Release Year}}},<br />
url = {https://www.gnu.org/software/octave/doc/v{{Release}}/},<br />
}<br />
<br />
Run {{manual|citation}} at the Octave prompt for details on how to best cite the Octave version you are running. Certain Octave packages also have recommended citations in which case use <code>citation package_name</code>.<br />
<br />
Note that there are two reasons for citing the software used. One is giving recognition to the work done by others which we have already addressed to. The other is giving details on the system used so that experiments can be replicated. For this, you should cite the version of Octave and all packages used (you can get this information using the <code>ver</code> command), as well as any details of your setup as part of your Methods. In addition, you should make your source available as well. See [http://software.ac.uk/so-exactly-what-software-did-you-use How to cite and describe software] for more details and an in depth discussion for the same.<br />
<br />
==What documentation exists for Octave?==<br />
<br />
Besides this wiki, the GNU Octave distribution includes a [http://www.octave.org/doc/interpreter 1000+ page Texinfo manual] ([http://www.octave.org/octave.pdf PDF]). Access to the complete text of the manual is available via the {{manual|doc}} command at the GNU Octave prompt. If you have problems using this manual, or find that some topic is not adequately explained, indexed, or cross-referenced, please report it on http://bugs.octave.org.<br />
<br />
==How can I report a bug in Octave?==<br />
<br />
Please read our website http://www.octave.org/bugs.html.<br />
<br />
<br />
= Common problems =<br />
<br />
== Octave does not start ==<br />
<br />
The following steps have been the solution to several bug reports and help requests. Please try them before asking for further support. If nothing below helps, please give us the following information:<br />
<br />
* Operating system: e.g. [https://support.microsoft.com/en-us/help/13443/windows-which-version-am-i-running '''MS Windows 10 (version 2004)'''] or '''Ubuntu 20.04'''<br />
* GNU Octave version: e.g. '''Version {{Release}}'''<br />
* Installation method: e.g. '''Downloaded and installed "octave-{{Release}}-w64-installer.exe" from https://www.octave.org/download.html'''<br />
<br />
=== MS Windows ===<br />
<br />
* After Octave upgrade the GUI does not open / shuts down immediately.<br />
** '''Solution:''' Delete the folder {{path|C:\Users\YOUR_USER_NAME\.config\octave}}<br />
* Missing/conflicting files.<br />
** '''Solution:''' Remove/Uninstall all existing Octave versions. Restart the system. Install GNU Octave again.<br />
* Permission errors.<br />
** '''Solution 1:''' Consult your malware detection (a.k.a. AntiVirus) software, if files are blocked.<br />
** '''Solution 2:''' Did you install Octave on a network-drive? Do you have the execution permissions?<br />
** '''Solution 3:''' Is your computer managed by your company? Does your administrator prohibit script execution?<br />
<br />
==I do not see any output of my script until it has finished?==<br />
<br />
By default Octave is set to pass its screen output through a [https://en.wikipedia.org/wiki/Terminal_pager pager] (usually the default pager is "less") which allows things such as navigating through the output with arrow keys or searching for text or regular expressions within the output. The pager only displays the output after it's finished receiving it, so when it is active you'll not be able to see anything until your script has terminated. To change this behavior temporarily or permanently you may want to use one of the options described [https://www.octave.org/doc/interpreter/Paging-Screen-Output.html in the manual].<br />
<br />
==When I try plotting from a script, why am I not seeing anything?==<br />
<br />
If you are running an Octave script that includes a plotting command, the script and Octave may terminate immediately. So the plot window does show up, but immediately closes when Octave finishes execution. Alternatively, if using fltk, the plot window needs a readline loop to show up (the time when Octave is sitting around doing nothing waiting for interactive input).<br />
<br />
A common solution is to put a {{manual|pause}} command at the end of your script.<br />
<br />
==How do I get sound input or output in MS Windows?==<br />
<br />
Sound input from a sound card and output to a sound card is fully supported since Octave 4.0.0 for all platforms. If you have problems with the [https://www.octave.org/doc/interpreter/Audio-Processing.html audio I/O functions] using Octave 4.0.0 or a newer version, please report them on the [http://bugs.octave.org bug tracker].<br />
<br />
==I have problem X using the latest Octave version==<br />
<br />
Please be more specific about what you mean by "latest version"?<br />
<br />
* The latest stable version is {{Release}}. Be aware that you may still have an older version due to whatever distribution method you are using. To get a newer stable version for your system see the following as in accordance to your Operating system: [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], or [[Octave for Microsoft Windows|Windows]].<br />
<br />
* If you refer to the latest Mercurial revision, please specify the [https://www.mercurial-scm.org/wiki/ChangeSetID changeset ID] not the revision number, e.g. the output of <code>hg summary</code> or <code>hg id</code>. Changeset IDs are globally unique across all repos.<br />
<br />
If your problem still persists with the "latest version", then please [http://bugs.octave.org/ report a bug] or ask for help at [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org]. Otherwise, don't be surprised if volunteers are less inclined to help you with a problem that only exists in an older version of Octave and is already fixed in a newer version.<br />
<br />
==Why is Octave's floating-point computation wrong?==<br />
<br />
Floating-point arithmetic is an approximation '''in binary''' to arithmetic on real or complex numbers. Just like you cannot represent 1/3 exactly in decimal arithmetic (0.333333... is only a rough approximation to 1/3), you cannot represent some fractions like <math>1/10</math> exactly in base 2. In binary, the representation to one tenth is <math>0.0\overline{0011}_b</math> where the bar indicates that it repeats infinitely (like how <math>1/6 = 0.1\overline{6}_d</math> in decimal). Because this infinite repetition cannot be represented exactly with a finite number of digits, rounding errors occur for values that appear to be exact in decimal but are in fact approximations in binary, such as for example how 0.3 - 0.2 - 0.1 is not equal to zero.<br />
<br />
In addition, some advanced operations are computed by approximation and there is no guarantee for them to be accurate, see [https://en.wikipedia.org/wiki/Rounding#Table-maker.27s_dilemma Table-maker's dilemma] for further references. Their results are system-dependent.<br />
<br />
This isn't a bug that is limited to GNU-Octave & it happens with any program that uses [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754 floating-point arithmetic]. To be fair, IEEE 754 also specifies decimal floating-point arithmetic, which has never seen wide adoption. The reason why Octave and other programs using IEEE 754 binary floating-point numbers is that they are ''fast'', because they are implemented in hardware or system libraries. Unless you are using very exotic hardware, Octave will use your computer's processor for basic floating-point arithmetic.<br />
<br />
Another approach to deal with rounding errors is interval arithmetic with the [[Interval package]] or symbolic computations with the [[Symbolic package]]. These approaches are likely to be slower, since not all operations can be performed on Hardware like pure floating-point arithmetic.<br />
<br />
To learn more about floating-point arithmetic, consult this [https://en.wikipedia.org/wiki/Floating-point_arithmetic Wikipedia article] or the classical reference by David Goldberg [http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html What Every Computer Scientist Should Know About Floating-Point Arithmetic].<br />
<br />
==Missing lines when printing under Windows with OpenGL toolkit and Intel integrated GPU==<br />
<br />
Some windows users with integrated Intel GPUs have reported missing lines when printing with an OpenGL toolkit like FLTK or Qt. {{bug|42534}}<br />
<br />
Users with this kind of problem should try to install/update their Intel OpenGL drivers for Windows or consider installing Mesa drivers from http://qt-project.org/wiki/Cross-compiling-Mesa-for-Windows.<br />
<br />
See also https://www.opengl.org/wiki/FAQ#Why_is_my_GL_version_only_1.4_or_lower.3F .<br />
<br />
==Plot hangs and makes the GUI unresponsive==<br />
<br />
If the Qt graphics toolkit is used and "plot" is used for the first time, the fontconfig scanner searches the font directory to build a font cache. This can take up to 3min on slow CPUs. See {{bug|45458}}<br />
<br />
==Error message about invalid call to script or invalid use of script in index expression==<br />
<br />
If Octave shows an error message about {{Codeline|invalid call to script .../close.m}} or {{Codeline|invalid use of of script .../close.m in index expression}}, it means that you have created a script called close.m that is overriding the built-in Octave function {{Codeline|close}}. Octave functions and scripts share the same global namespace. It is best to avoid creating your own scripts or functions that have the same name as an Octave function as to avoid this error regarding the invalid call to script or invalid use of script in index expression.<br />
<br />
=Licensing issues=<br />
<br />
==If I write code using Octave do I have to release it under the GPL?==<br />
<br />
The answer depends on precisely how the code is written and how it works:<br />
<br />
* Code written '''entirely in the scripting language of Octave''' (interpreted code in .m files) may be released under the terms of whatever license you choose.<br />
<br />
* Code written using [https://www.gnu.org/software/octave/doc/interpreter/Oct_002dFiles.html Octave's native code interface] (also known as a .oct file) necessarily links with Octave internals and is considered a derivative work of Octave. Therefore it must be released under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
<br />
* Code written using [https://www.gnu.org/software/octave/doc/interpreter/Mex_002dFiles.html Octave's implementation of the Matlab MEX interface] may be released under the terms of whatever license you choose, provided that the following conditions are met:<br />
<br />
:# The MEX file may not use any bindings that are specific to Octave, '''it has to use the MEX interface only'''. In other words, it should be possible in principle to use the MEX file with other programs that implement the MEX interface (e.g., Matlab). For example including an Octave header file or calling an Octave function within the MEX file, that is not related with Octave's implementation of the MEX interface make the MEX file a derivative work of Octave and has therefore to be released under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
:# The MEX file may not be distributed together with Octave in such a way that they effectively create a single work. For example, you should not distribute the MEX file and Octave together in a single package such that Octave automatically loads and runs the MEX file when it starts up. There are other possible ways to effectively create a single work.<br />
<br />
* Code that '''embeds the Octave interpreter''' (e.g., by calling the <code>octave_main</code> function), or that calls functions from Octave's libraries (e.g., liboctinterp, liboctave, or libcruft) is considered a derivative work of Octave and therefore must be released under terms that are compatible with the GPL.<br />
<br />
==Will you change the license of the Octave libraries for me?==<br />
<br />
'''No.''' Instead of asking us to change the licensing terms for Octave, we recommend that you release your program under terms that are compatible with the GPL, this way the free software community can be benefited from your work the same as you were/have benefited from the work of all the people who have contributed to Octave.<br />
<br />
==Should I favor the MEX interface to avoid the GPL?==<br />
<br />
'''No.''' The original reason for implementing the [https://www.gnu.org/software/octave/doc/interpreter/Mex_002dFiles.html MEX interface] for Octave was to allow Octave to run free software that uses MEX files (the particular goal was to run [https://computation.llnl.gov/projects/sundials/release-history#sundialsTB sundialsTB] in Octave). The intent was to liberate that software from Matlab and increase the amount of free softwares available to Octave users & not to enable people to write proprietary code for Octave. For the good of the community, we strongly encourage users of Octave to release the code they write for Octave under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
<br />
==Why can't I use code from File Exchange in Octave?==<br />
<br />
According to the Matlab Central [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use] (Last updated: 10-Aug-2016), all submitted code is licensed under the [https://en.wikipedia.org/wiki/BSD_licenses BSD license] by default (cf. § 5 [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use]), but it is clearly stated that:<br />
<br />
{{Quote|text=Content submitted to File Exchange may only be used with MathWorks products. | |§ 2(a)(iii) [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use]}}<br />
<br />
That does not apply to GNU Octave, therefore the usage is in general prohibited. It should suffice — although interpretations of this vary — to contact the author directly to send you the code personally (maybe released under a free license), or download the code from the author's own website, if available. [[Asking_for_package_to_be_released_under_GPL:_examples|Some examples of letters/email sent to authors for that purpose]].<br />
<br />
=Installation=<br />
<br />
==How can I install Octave on Windows?==<br />
<br />
:'' So as to install GNU-Octave for Windows O.S, refer to : [[Octave for Microsoft Windows]]''<br />
<br />
==How can I install Octave on MacOS?==<br />
<br />
:''So as to install GNU-Octave for MacOS, refer to : [[Octave for macOS]]''<br />
<br />
==How can I install Octave on GNU/Linux?==<br />
<br />
:'' So as to install GNU-Octave on GNU/Linux, refer to: [[Octave for GNU/Linux]]''<br />
<br />
==How to install Octave on Android OR What is the Octave app available in the Google Play store?==<br />
<br />
There is an '''unofficial''' Octave app available for Android in the Google Play store. Please see [[Octave for Android]] for further information.<br />
<br />
==How can I install Octave on platform X?==<br />
<br />
Octave currently runs on [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]]. It should be possible to make Octave work on other systems as well. If you are interested in porting Octave to other systems, please contact the maintainers development mailing list [https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers@octave.org].<br />
<br />
==What Octave version should I use?==<br />
<br />
For general use, it is recommended to use the latest stable version of Octave (currently {{Release}}), available from http://www.octave.org/download.html. For development and bleeding-edge features one can obtain the development source code from the Mercurial repository https://hg.savannah.gnu.org/hgweb/octave/graph/.<br />
<br />
The used version of Octave is available via the {{manual|ver}} command and a list of user-visible changes since the last release is available via the {{manual|news}} command at the GNU Octave prompt.<br />
<br />
==On what platforms does Octave run?==<br />
<br />
Octave runs on any platform you can compile it on. Binary distributions exist for [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]]. To work fully functional, Octave requires the used platform to support the underlying numerical libraries like [https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms BLAS], [https://en.wikipedia.org/wiki/LAPACK LAPACK], [http://www.suitesparse.com SuiteSparse], etc., and for plotting [https://www.opengl.org/ OpenGL] or [http://www.gnuplot.info/ gnuplot].<br />
<br />
==How can I obtain Octave's source code?==<br />
<br />
The latest version of the Octave source code (and older versions) is available from:<br />
<br />
* https://www.octave.org/download.html<br />
* https://ftp.gnu.org/gnu/octave/<br />
<br />
Since Octave is distributed under the terms of the GPL, you can get Octave from a friend who has a copy.<br />
<br />
==How can I build Octave from the source code?==<br />
<br />
To use Octave it is usually not required to build it from it's source code. Binary distributions exist for [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]].<br />
<br />
If you have reasons to build Octave from the source code, see [[Building]] for more information.<br />
<br />
==What do I need to build Octave from the source code?==<br />
<br />
For a list of build dependencies, refer to [[Building]].<br />
<br />
==Do I need GCC to build Octave from the source code?==<br />
<br />
No. The development is done primarily with [https://gcc.gnu.org/ GCC], so you may hit some incompatibilities. Octave is intended to be portable to any standard conforming compiler (for example [https://clang.llvm.org/ clang] is known to work as well). If you face any difficulties that you think are bugs, please report them to the [http://bugs.octave.org bug tracker], or ask for help on the [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org mailing list].<br />
<br />
=What's new in Octave?=<br />
<br />
Each new Octave release introduces many new features. A complete list of user visible changes can be seen by running <code>news</code> at the Octave prompt.<br />
<br />
* '''What's new in the next version of Octave?'''<br />
** See the [https://hg.savannah.gnu.org/hgweb/octave/file/tip/NEWS NEWS file] on the development branch.<br />
* '''What was new in Octave Version X.Y.Z?'''<br />
** See [[Release History]].<br />
<br />
=Packages and Octave Forge=<br />
<br />
==How do I install or load all Octave Forge packages?==<br />
<br />
Do not do it! Really, there is no reason to do this. Octave has many packages for different needs and is unlikely that you need all of them. You either have a small set of required packages, in which case<br />
you know them by name; or you want them all "just because", in which case you don't really need them.<br />
<br />
The common misconception is that the more packages one has installed and loaded, the more complete and powerful its Octave installation will be. However, in the same way one would never install all perl modules, ruby gems, python packages, and C++ libraries (because it simply makes no sense), one should not install all Octave packages.<br />
<br />
Packages should be installed and loaded selectively. Note that some packages are meant to shadow core functions changing the way Octave works, and that different packages can have different functions with the same name leading to unpredictable results.<br />
<br />
If you really really really want to do load all packages, you can with the following:<br />
<syntaxhighlight lang="octave"><br />
## WARNING: loading all packages is probably not the solution you are looking for.<br />
cellfun (@(x) pkg ("load", x.name), pkg ("list"));<br />
</syntaxhighlight><br />
<br />
==I have installed a package but still get a "foo undefined" error?==<br />
<br />
You have probably forgotten to load the package. Use {{Codeline|pkg load package-name}} to load it. Most packages are no longer loaded automatically to avoid surprises. See reasoning on related FAQ [[FAQ#How_do_I_install_all_Octave_packages.3F|how do I install all Octave packages]]. If you want a specific package to be loaded by default at startup, consider adding the {{Codeline|pkg load}} command on your {{path|[[.octaverc]]}} file.<br />
<br />
==I cannot install a package. Octave complains about a missing mkoctfile.==<br />
<br />
You should normally use your distribution's packages. For Debian and Fedora, Octave package <code>foo</code> will be a deb or rpm called <code>octave-foo</code>, and you should install that instead using <code>apt</code> or <code>yum</code>.<br />
<br />
If you really need to build Octave packages from source to install them, you'll need {{manual|mkoctfile}}. Most distributions split Octave into several packages. The script {{manual|mkoctfile}} is then part of a separate package:<br />
<br />
* Debian/Ubuntu: [https://packages.debian.org/stretch/liboctave-dev liboctave-dev]<br />
<br />
* Fedora: {{Codeline|octave-devel}}<br />
<br />
==How do I automatically load a package at Octave startup?==<br />
<br />
When Octave starts, it runs the file {{Path|~/.octaverc}} (in your user's home directory). If you want Octave to automatically load a package, simply add a <code>pkg load pkg-name</code> command to it. If the files does not exist, create it.<br />
<br />
If you do this, remember that other people may not have Octave configured to load packages at startup. Therefore, if you write code for others, remember that your programs still need to load the packages they require.<br />
<br />
=Octave usage=<br />
<br />
==How do I execute an Octave script?==<br />
<br />
First of all, make sure you understand [http://www.octave.org/doc/interpreter/Script-Files.html the difference between script files and function files]. If you want to execute a function defined in a file, just call the function like any other Octave function: <code>foo(arg1, arg2);</code><br />
<br />
To execute a script from within Octave, just type its name without the <code>.m</code> extension. Thus, if you have a script called <code>foo.m</code>, just type <code>foo</code> from within the Octave command prompt to execute it. You have to make sure that the script is in your current working directory or in Octave's load path. Type {{manual|pwd}} to get the current working directory or type {{manual|path}} to see which paths belong to Octave's load path. The current working directory is referred to as "." in the output of {{manual|path}}.<br />
<br />
If the script name has characters that are not valid for an Octave identifier, or if you do not want to use {{manual|addpath}} to add the script's location to the current path, you can use the {{manual|run}} function instead:<br />
<br />
<syntaxhighlight lang="octave"><br />
run ("Script Name With Spaces.m")<br />
run ("/opt/local/foo.m")<br />
</syntaxhighlight><br />
<br />
An alternative is to run the script from outside Octave by calling Octave from your operating system shell. Unlike calling the script from inside Octave, this also allows you to pass arguments from the shell into the script, which the script can access using the {{manual|argv}} command:<br />
<br />
$ octave the-script.m arg1 arg2<br />
<br />
In a Unix environment, if the script has a [http://en.wikipedia.org/wiki/Shebang_%28Unix%29 shebang] (e.g. <code>#!/usr/bin/octave</code>) and executable permissions, you can call it like any other Unix program with arguments:<br />
<br />
$ ./the-script arg1 arg2<br />
<br />
If you call the script from the shell and it's plotting, please note [[#When I try plotting from a script, why am I not seeing anything?|how to plot when running a script from the shell]].<br />
<br />
==How do I close a figure?== <br />
<br />
To close the current figure type {{manual|close}} in the Octave command prompt.<br />
<br />
==How do I set the number of displayed decimals?==<br />
<br />
You can control the number of displayed decimals using the {{manual|format}} command:<br />
<br />
<syntaxhighlight lang="octave"><br />
>> format long<br />
>> pi<br />
pi = 3.14159265358979<br />
>> format short<br />
>> pi<br />
pi = 3.1416<br />
</syntaxhighlight><br />
<br />
==How do I call an Octave function from C++?==<br />
<br />
Please read the manual https://www.gnu.org/software/octave/doc/interpreter/Calling-Octave-Functions-from-Oct_002dFiles.html.<br />
<br />
==How do I change color/line definition in gnuplot postscript?==<br />
<br />
Here is a awk script to get a rainbow color map<br />
<br />
#!/bin/awk -f<br />
<br />
BEGIN {<br />
split("0 4 6 7 5 3 1 2 8", rainbow, " ");<br />
split("7 3 1 0 2 4 6 5 8", invraim, " ");<br />
}<br />
<br />
$1 ~ /\/LT[0-8]/ {<br />
n = substr($1, 4, 1);<br />
if (n == 0)<br />
lt = "{ PL [] 0.9 0.1 0.1 DL } def";<br />
else if (n == 1)<br />
lt = "{ PL [4 dl 2 dl] 0.1 .75 0.1 DL } def";<br />
else if (n == 2)<br />
lt = "{ PL [2 dl 3 dl] 0.1 0.1 0.9 DL } def";<br />
else if (n == 3)<br />
lt = "{ PL [1 dl 1.5 dl] 0.9 0 0.8 DL } def";<br />
else if (n == 4)<br />
lt = "{ PL [5 dl 2 dl 1 dl 2 dl] 0.1 0.8 0.8 DL } def";<br />
else if (n == 5)<br />
lt = "{ PL [4 dl 3 dl 1 dl 3 dl] 0.9 0.8 0.2 DL } def";<br />
else if (n == 6)<br />
lt = "{ PL [2 dl 2 dl 2 dl 4 dl] 0.5 0.3 0.1 DL } def";<br />
else if (n == 7)<br />
lt = "{ PL [2 dl 2 dl 2 dl 2 dl 2 dl 4 dl] 1 0.4 0 DL } def";<br />
else if (n == 8)<br />
lt = "{ PL [2 dl 2 dl 2 dl 2 dl 2 dl 2 dl 2 dl 4 dl] 0.5 0.5 0.5 DL } def";<br />
$0 = sprintf("/LT%d %s", rainbow[n+1], lt);<br />
##$0 = sprintf("/LT%x %s", invraim[n+1], lt);<br />
##$0 = sprintf("/LT%x %s", n, lt);<br />
}<br />
<br />
{ print; }<br />
<br />
==How do I tell if a file exists?==<br />
<br />
One can use the function {{manual|exist}} to tell if a regular file, say <code>foo.txt</code> exist in Octave's load path, or the current directory:<br />
<br />
<syntaxhighlight lang="octave"><br />
>> exist ("foo.txt", "file") # 2, if file exists, 0 otherwise<br />
ans = 2<br />
</syntaxhighlight><br />
<br />
==How do I create a plot without a window popping up (plot to a file directly)?==<br />
<br />
<syntaxhighlight lang="octave"><br />
figure (1, "visible", "off");<br />
plot (sin (1:100));<br />
print -deps "/tmp/sin.eps"<br />
</syntaxhighlight><br />
<br />
One can set that behavior as default:<br />
<br />
<syntaxhighlight lang="octave"><br />
set (0, "defaultfigurevisible", "off");<br />
</syntaxhighlight><br />
<br />
==How do I increase Octave's precision?==<br />
<br />
Octave's default numerical type is [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754] binary64, a.k.a. "double" or "hardware floats". This type has a precision of 53 bits or about 16 decimal digits. It is supported by each modern computer hardware, so it is really '''fast'''. This type is assumed throughout for Octave's calculations. If more precision was required, one can obtain a "few bits more" by using integer types, e.g. {{manual|uint64}}, but in general one cannot expect more precision from any '''fast''' numerical software. Just to visualize "how big" those numerical limits are, consider the following table:<br />
<br />
{| class="wikitable"<br />
|+ Limits of some of Octave's data types obtained by {{manual|intmax}} and {{manual|flintmax}}.<br />
|-<br />
| <code>intmax ("uint64")</code><br />
| style="text-align: right;" | <code>18,446,744,073,709,551,615</code><br />
| <code>2^64-1</code><br />
|-<br />
| <code>intmax ("int64")</code><br />
| style="text-align: right;" | <code>9,223,372,036,854,775,807</code><br />
| <code>2^63-1</code><br />
|-<br />
| <code>flintmax ("double")</code><br />
| style="text-align: right;" | <code>9,007,199,254,740,992</code><br />
| <code>2^53</code><br />
|-<br />
| <code>flintmax ("single")</code><br />
| style="text-align: right;" | <code>16,777,216</code><br />
| <code>2^24</code><br />
|}<br />
<br />
When working with other types than "double" in Octave, one has to make sure, that the first operand is converted to the desired type:<br />
<br />
<syntaxhighlight lang="Octave"><br />
>> uint64 (2^53 + 1)<br />
ans = 9007199254740992<br />
>> uint64 (2^53) + 1<br />
ans = 9007199254740993<br />
</syntaxhighlight><br />
<br />
Notice the difference, in the first line the addition within the brackets is performed using double precision, therefore the result gets "truncated" to the maximum possible value without a warning. The third line uses throughout uint64 precision.<br />
<br />
Consider carefully if your problem really needs more precision. Often if you're running out of precision the problem lies fundamentally in your methods being [https://en.wikipedia.org/wiki/Numerical_stability numerically unstable], thus more precision will not help you here.<br />
<br />
If you absolutely must have more precision, you're at present better off using a [https://en.wikipedia.org/wiki/Computer_algebra_system CAS] instead of Octave. However, CAS or symbolic computations must be implemented '''in software''' which makes it much slower than hardware floats. An example of such a CAS is [http://www.sagemath.org/ Sage] or have a look at Octave's [[Symbolic package]].<br />
<br />
==How do I run a Matlab P-file in Octave?==<br />
<br />
You can't. Matlab P-files (files with a <code>.p</code> file extension), also known as P-code, are [https://en.wikipedia.org/wiki/Obfuscation_%28software%29 obfuscated] files that cannot be run outside of Matlab itself. The original source Matlab m-files that were used to generate these P-files should be used in Octave instead.<br />
<br />
There are no plans to support running P-files produced by Matlab in Octave.<br />
<br />
==How does Octave solve linear systems?==<br />
<br />
In addition to consulting Octave's source for the precise details, you can read the Octave manual for a complete high-level description of the algorithm that Octave uses to decide how to solve a particular linear system, e.g. how the backslash operator <code>A \ x</code> will be interpreted. Sections [http://www.octave.org/doc/interpreter/Techniques-Used-for-Linear-Algebra.html Techniques Used for Linear Algebra] and [http://www.octave.org/doc/interpreter/Sparse-Linear-Algebra.html Linear Algebra on Sparse Matrices] from the manual describe this procedure.<br />
<br />
==How do I do X?==<br />
<br />
You are probably looking for the function {{manual|lookfor}}. This function searches the help text of all functions for a specific string and returns a list of functions. Note that by default it will only search the first line of the help text (check <code>help lookfor</code> at the octave prompt for more). The following example helps to find the function to calculate correlation coefficient in a matrix:<br />
<br />
>> lookfor correlation<br />
corr Compute matrix of correlation coefficients.<br />
corrcoef Compute a matrix of correlation coefficients.<br />
spearman Compute Spearman's rank correlation coefficient RHO.<br />
<br />
Also, there's a high chance that the function name has a suggestive name, and so you can try auto-completion to get some hints. For the previous example, typing <code>corr</code> at the octave prompt followed by pressing the {{key press|Tab}}-Key twice would suggest the following:<br />
<br />
>> corr<br />
corr corrcoef<br />
<br />
=Differences between Octave and Matlab=<br />
:''See [[Differences between Octave and Matlab]]''.<br />
<br />
=[https://en.wikipedia.org/wiki/Graphical_user_interface GUI]=<br />
<br />
==Does Octave have a GUI?==<br />
<br />
'''Yes!''' It was officially released with Octave 4.0.0. It was also available since version 3.8.0 as an experimental feature (use the {{Codeline|--force-gui}} option to start Octave).<br />
<br />
==Why did you create yet another GUI instead of making one that already exists better?==<br />
<br />
The previously existing GUIs were not part of Octave itself. The integration within Octave was rather bad, as all of them treated Octave as a foreign black box and used pipes for communication. This approach is bound to fail with each new version of Octave, as any fix would only be temporary. For historical reasons and to honor the approaches, a short list of previous GUIs for Octave:<br />
<br />
* '''QtOctave''' was a great, beautiful, and very useful tool which is now abandoned and incompatible with newer versions of Octave. We are thankful to its developers to make it free software so we could reuse large chunks of it for what is now the Octave GUI.<br />
<br />
* '''Quint''' was a project for an Octave GUI that actually tried to do it right. Eventually [https://lists.gnu.org/archive/html/octave-maintainers/2011-07/msg00096.html it was merged into the Octave repository] and is no longer a separate project. Also, many bits from QtOctave were reused in the GUI.<br />
<br />
* '''[http://www.xoctave.com/ Xoctave]''', which is proprietary and commercial.<br />
<br />
* '''GUI Octave''', which was proprietary and is no longer available.<br />
<br />
=Graphics: backends and toolkits=<br />
<br />
==What are the supported graphics backends?==<br />
<br />
* [https://www.opengl.org/ OpenGL] via the graphics toolkits '''[https://www.qt.io/ qt]''' (current default) and '''[http://www.fltk.org/ fltk]'''<br />
* [http://www.gnuplot.info/ gnuplot] via the '''gnuplot''' graphics toolkit<br />
<br />
==How do I change my graphics toolkit?==<br />
<br />
There are three commands to deal with graphics toolkits:<br />
<br />
{| class="wikitable"<br />
| <code>available_graphics_toolkits</code><br />
| lists all available graphics toolkits<br />
|-<br />
| <code>graphics_toolkit</code><br />
| displays the currently used graphics toolkit<br />
|-<br />
| <code>graphics_toolkit ("qt/fltk/gnuplot")</code><br />
| sets the graphics toolkit to either of [https://www.qt.io/ qt], [http://www.fltk.org/ fltk], or [http://www.gnuplot.info/ gnuplot], if available<br />
|}<br />
<br />
==Why did you replace gnuplot with an OpenGL backend?==<br />
<br />
The development of Octave is committed to being both compatible with Matlab and adding additional features. Toward those ends, the developers decided to introduce a native OpenGL backend that supports Matlab handle graphics and its uicontrols. Starting with the 3.8 release, Octave uses OpenGL graphics by default (with [http://www.fltk.org/ FLTK widgets] in Octave 3.8 and [https://www.qt.io/ Qt widgets] in Octave 4.0 and later).<br />
<br />
==Are there any plans to remove the gnuplot backend?==<br />
<br />
'''No.''' There are no plans to remove the gnuplot backend. It will be available as long as our users find it useful.<br />
<br />
==How can I implement a new graphics backend/toolkit?==<br />
<br />
This is one of those times where the best documentation is to read the existing code. We have three different toolkits in Octave now, so there are some examples to draw from.<br />
<br />
= Development =<br />
<br />
== When will feature X be released or implemented? ==<br />
<br />
When it's ready, sooner [https://www.octave.org/get-involved.html if you help]. You can [https://savannah.gnu.org/patch/?group=octave send us patches] if you can implement feature X yourself. If you can't, some [https://www.octave.org/commercial-support.html developers may be convinced to work on your specific problem for some money].<br />
<br />
== How can I get involved in Octave development? ==<br />
<br />
:''See [[Developer FAQ]]''.<br />
<br />
[[Category:FAQ]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=FAQ&diff=13270FAQ2020-07-27T01:01:45Z<p>Siko1056: /* Octave does not start */ Update MS Windows 10 version</p>
<hr />
<div>This is a list of frequently asked questions (FAQ) for GNU Octave users.<br />
<br />
We are always looking for new questions (with answers), better answers, or both. Feel free to edit this page with your changes.<br />
<br />
=Where do I get additional help?=<br />
<br />
If you can't find an answer to your question in this FAQ, wiki, or in the [http://www.octave.org/doc/interpreter manual] ([http://www.octave.org/octave.pdf PDF]) you can:<br />
<br />
* Search for an answer in our [https://lists.gnu.org/archive/html/help-octave/ mailing list archives]<br />
* Contact our user community using our [https://octave.discourse.group Octave Discourse].<br />
* Contact our user community using our [https://webchat.freenode.net/?channels=octave IRC chat room <code>#octave</code> in Freenode]<br />
<br />
<div class="tocinline">__TOC__</div><br />
<br />
=General=<br />
<br />
==What is Octave?==<br />
<br />
[https://www.gnu.org/software/octave/ GNU Octave] is a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems, and for performing other numerical experiments. It also provides extensive graphics capabilities for data visualization and manipulation. GNU Octave is normally used through its interactive interface ([https://en.wikipedia.org/wiki/Command-line_interface CLI] and [https://en.wikipedia.org/wiki/Graphical_user_interface GUI]), but it can also be used to write non-interactive programs. <br />
The GNU Octave language is quite similar to Matlab so that most programs are easily portable.<br />
<br />
The GNU Octave distribution includes a [http://www.octave.org/octave.pdf 1000+ page Texinfo manual]. Access to the complete text of the manual is available via the <code>doc</code> command at the GNU Octave prompt.<br />
<br />
==What is Octave Forge?==<br />
<br />
[https://octave.sourceforge.io/ Octave Forge] is a collection of [[packages]] for GNU Octave, something similar to the Matlab toolboxes. When talking about the two projects at the same time, GNU Octave is usually referred to as Octave core (or just "core"). Octave Forge also serves as a test bed for code that may eventually end up in the core, and distributes binaries for systems with a lack of developers tools (mainly Windows).<br />
<br />
==Who uses Octave?==<br />
<br />
A huge number of people ranging from students to researchers involved in various fields such as statistics,Machine Learning, data analytics, etc. Universities use it for research and teaching, companies of all sizes for development and individuals for certain private purposes. See [[Who Uses Octave?]] for more clarity.<br />
<br />
==Who develops Octave?==<br />
<br />
Discussions about writing the software that would eventually become Octave started in about 1988 with James B. Rawlings and [http://jweaton.org/ John W. Eaton] at the University of Texas. John W. Eaton is the original author of Octave, starting full-time development in February 1992. He is still the primary maintainer. The community of users and developers has in addition contributed some code and fuels the discussion on the mailing lists [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org] (user forum), [https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers@octave.org] (development issues). Since 2011, GNU Octave regularly participates in [[Summer of Code]] events as a mentor organisation. As part of those events, several students contributed to Octave by helping in removal of bugs and development of new features.<br />
<br />
==Why "Octave"?==<br />
<br />
Octave's name has nothing to do with music. It is named after [http://en.wikipedia.org/wiki/Octave_Levenspiel Octave Levenspiel], a former professor of John who was famous for his ability to do quick back-of-the-envelope calculations. You can hear John pronounce the name "Octave" a few times [http://videolectures.net/mloss08_eaton_oct/ in this video]. We hope that GNU Octave will help perform computations with the same ease as Dr. Levenspiel.<br />
<br />
==Why "GNU" Octave?==<br />
<br />
The [https://www.gnu.org/ GNU Project] was launched in 1984 to develop a complete Unix-like operating system which is free software: the GNU system. GNU is a recursive acronym for "GNU's Not Unix"; it is pronounced [https://www.gnu.org/gnu/pronunciation.en.html g'noo].<br />
<br />
The [https://www.fsf.org/ Free Software Foundation (FSF)] is the principal organization that has sponsored the GNU Project.<br />
<br />
Octave became GNU Octave in 1997 (beginning with [[Release History|version 2.0.6]]). This meant agreeing to consider Octave a part of the GNU Project and support the efforts of the FSF. A big part of this effort is to adhere to the [https://www.gnu.org/prep/standards/standards.html GNU coding standards] and to benefit from GNU's infrastructure (e.g. [https://hg.savannah.gnu.org/hgweb/octave/ code hosting] and [http://bugs.octave.org bug tracking]). Additionally, Octave receives [https://my.fsf.org/donate/working-together/octave sponsorship] from the FSF's Working Together fund. However, Octave is not and has never been developed by the FSF.<br />
<br />
==How can I cite Octave?==<br />
<br />
Octave is free software and does not legally bind you to cite it. However, we have invested a lot of time and effort in creating GNU Octave, and we would appreciate if you would cite if you used. To cite GNU Octave in publications use:<br />
<br />
John W. Eaton, David Bateman, Søren Hauberg, Rik Wehbring ({{Release Year}}).<br />
GNU Octave version {{Release}} manual: a high-level interactive language for numerical computations.<br />
URL https://www.gnu.org/software/octave/doc/v{{Release}}/<br />
<br />
A [https://en.wikipedia.org/wiki/BibTeX BibTeX] entry for [https://en.wikipedia.org/wiki/LaTeX LaTeX] users is:<br />
<br />
@manual{,<br />
title = {{GNU Octave} version {{Release}} manual: a high-level interactive language for numerical computations},<br />
author = {John W. Eaton and David Bateman and S{\o}ren Hauberg and Rik Wehbring},<br />
year = <span>{</span>{{Release Year}}},<br />
url = {https://www.gnu.org/software/octave/doc/v{{Release}}/},<br />
}<br />
<br />
Run {{manual|citation}} at the Octave prompt for details on how to best cite the Octave version you are running. Certain Octave packages also have recommended citations in which case use <code>citation package_name</code>.<br />
<br />
Note that there are two reasons for citing the software used. One is giving recognition to the work done by others which we have already addressed to. The other is giving details on the system used so that experiments can be replicated. For this, you should cite the version of Octave and all packages used (you can get this information using the <code>ver</code> command), as well as any details of your setup as part of your Methods. In addition, you should make your source available as well. See [http://software.ac.uk/so-exactly-what-software-did-you-use How to cite and describe software] for more details and an in depth discussion for the same.<br />
<br />
==What documentation exists for Octave?==<br />
<br />
Besides this wiki, the GNU Octave distribution includes a [http://www.octave.org/doc/interpreter 1000+ page Texinfo manual] ([http://www.octave.org/octave.pdf PDF]). Access to the complete text of the manual is available via the {{manual|doc}} command at the GNU Octave prompt. If you have problems using this manual, or find that some topic is not adequately explained, indexed, or cross-referenced, please report it on http://bugs.octave.org.<br />
<br />
==How can I report a bug in Octave?==<br />
<br />
Please read our website http://www.octave.org/bugs.html.<br />
<br />
<br />
= Common problems =<br />
<br />
== Octave does not start ==<br />
<br />
The following steps have been the solution to several bug reports and help requests. Please try them before asking for further support. If nothing below helps, please give us the following information:<br />
<br />
* Operating system: e.g. [https://support.microsoft.com/en-us/help/13443/windows-which-version-am-i-running '''MS Windows 10 (version 2004)'''] or '''Ubuntu 20.04'''<br />
* GNU Octave version: e.g. '''Version {{Release}}'''<br />
* Installation method: e.g. '''Downloaded and installed "octave-{{Release}}-w64-installer.exe" from https://www.octave.org/download.html'''<br />
<br />
=== MS Windows ===<br />
<br />
* After Octave upgrade the GUI does not open / shuts down immediately.<br />
** '''Solution:''' Delete the folder {{path|C:\Users\YOUR_USER_NAME\.config\octave}}<br />
* Missing/conflicting files.<br />
** '''Solution:''' Remove/Uninstall all existing Octave versions. Restart the system. Install GNU Octave again.<br />
* Permission errors.<br />
** '''Solution 1:''' Consult your malware detection (a.k.a. AntiVirus) software, if files are blocked.<br />
** '''Solution 2:''' Did you install Octave on a network-drive? Do you have the execution permissions?<br />
<br />
==I do not see any output of my script until it has finished?==<br />
<br />
By default Octave is set to pass its screen output through a [https://en.wikipedia.org/wiki/Terminal_pager pager] (usually the default pager is "less") which allows things such as navigating through the output with arrow keys or searching for text or regular expressions within the output. The pager only displays the output after it's finished receiving it, so when it is active you'll not be able to see anything until your script has terminated. To change this behavior temporarily or permanently you may want to use one of the options described [https://www.octave.org/doc/interpreter/Paging-Screen-Output.html in the manual].<br />
<br />
==When I try plotting from a script, why am I not seeing anything?==<br />
<br />
If you are running an Octave script that includes a plotting command, the script and Octave may terminate immediately. So the plot window does show up, but immediately closes when Octave finishes execution. Alternatively, if using fltk, the plot window needs a readline loop to show up (the time when Octave is sitting around doing nothing waiting for interactive input).<br />
<br />
A common solution is to put a {{manual|pause}} command at the end of your script.<br />
<br />
==How do I get sound input or output in MS Windows?==<br />
<br />
Sound input from a sound card and output to a sound card is fully supported since Octave 4.0.0 for all platforms. If you have problems with the [https://www.octave.org/doc/interpreter/Audio-Processing.html audio I/O functions] using Octave 4.0.0 or a newer version, please report them on the [http://bugs.octave.org bug tracker].<br />
<br />
==I have problem X using the latest Octave version==<br />
<br />
Please be more specific about what you mean by "latest version"?<br />
<br />
* The latest stable version is {{Release}}. Be aware that you may still have an older version due to whatever distribution method you are using. To get a newer stable version for your system see the following as in accordance to your Operating system: [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], or [[Octave for Microsoft Windows|Windows]].<br />
<br />
* If you refer to the latest Mercurial revision, please specify the [https://www.mercurial-scm.org/wiki/ChangeSetID changeset ID] not the revision number, e.g. the output of <code>hg summary</code> or <code>hg id</code>. Changeset IDs are globally unique across all repos.<br />
<br />
If your problem still persists with the "latest version", then please [http://bugs.octave.org/ report a bug] or ask for help at [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org]. Otherwise, don't be surprised if volunteers are less inclined to help you with a problem that only exists in an older version of Octave and is already fixed in a newer version.<br />
<br />
==Why is Octave's floating-point computation wrong?==<br />
<br />
Floating-point arithmetic is an approximation '''in binary''' to arithmetic on real or complex numbers. Just like you cannot represent 1/3 exactly in decimal arithmetic (0.333333... is only a rough approximation to 1/3), you cannot represent some fractions like <math>1/10</math> exactly in base 2. In binary, the representation to one tenth is <math>0.0\overline{0011}_b</math> where the bar indicates that it repeats infinitely (like how <math>1/6 = 0.1\overline{6}_d</math> in decimal). Because this infinite repetition cannot be represented exactly with a finite number of digits, rounding errors occur for values that appear to be exact in decimal but are in fact approximations in binary, such as for example how 0.3 - 0.2 - 0.1 is not equal to zero.<br />
<br />
In addition, some advanced operations are computed by approximation and there is no guarantee for them to be accurate, see [https://en.wikipedia.org/wiki/Rounding#Table-maker.27s_dilemma Table-maker's dilemma] for further references. Their results are system-dependent.<br />
<br />
This isn't a bug that is limited to GNU-Octave & it happens with any program that uses [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754 floating-point arithmetic]. To be fair, IEEE 754 also specifies decimal floating-point arithmetic, which has never seen wide adoption. The reason why Octave and other programs using IEEE 754 binary floating-point numbers is that they are ''fast'', because they are implemented in hardware or system libraries. Unless you are using very exotic hardware, Octave will use your computer's processor for basic floating-point arithmetic.<br />
<br />
Another approach to deal with rounding errors is interval arithmetic with the [[Interval package]] or symbolic computations with the [[Symbolic package]]. These approaches are likely to be slower, since not all operations can be performed on Hardware like pure floating-point arithmetic.<br />
<br />
To learn more about floating-point arithmetic, consult this [https://en.wikipedia.org/wiki/Floating-point_arithmetic Wikipedia article] or the classical reference by David Goldberg [http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html What Every Computer Scientist Should Know About Floating-Point Arithmetic].<br />
<br />
==Missing lines when printing under Windows with OpenGL toolkit and Intel integrated GPU==<br />
<br />
Some windows users with integrated Intel GPUs have reported missing lines when printing with an OpenGL toolkit like FLTK or Qt. {{bug|42534}}<br />
<br />
Users with this kind of problem should try to install/update their Intel OpenGL drivers for Windows or consider installing Mesa drivers from http://qt-project.org/wiki/Cross-compiling-Mesa-for-Windows.<br />
<br />
See also https://www.opengl.org/wiki/FAQ#Why_is_my_GL_version_only_1.4_or_lower.3F .<br />
<br />
==Plot hangs and makes the GUI unresponsive==<br />
<br />
If the Qt graphics toolkit is used and "plot" is used for the first time, the fontconfig scanner searches the font directory to build a font cache. This can take up to 3min on slow CPUs. See {{bug|45458}}<br />
<br />
==Error message about invalid call to script or invalid use of script in index expression==<br />
<br />
If Octave shows an error message about {{Codeline|invalid call to script .../close.m}} or {{Codeline|invalid use of of script .../close.m in index expression}}, it means that you have created a script called close.m that is overriding the built-in Octave function {{Codeline|close}}. Octave functions and scripts share the same global namespace. It is best to avoid creating your own scripts or functions that have the same name as an Octave function as to avoid this error regarding the invalid call to script or invalid use of script in index expression.<br />
<br />
=Licensing issues=<br />
<br />
==If I write code using Octave do I have to release it under the GPL?==<br />
<br />
The answer depends on precisely how the code is written and how it works:<br />
<br />
* Code written '''entirely in the scripting language of Octave''' (interpreted code in .m files) may be released under the terms of whatever license you choose.<br />
<br />
* Code written using [https://www.gnu.org/software/octave/doc/interpreter/Oct_002dFiles.html Octave's native code interface] (also known as a .oct file) necessarily links with Octave internals and is considered a derivative work of Octave. Therefore it must be released under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
<br />
* Code written using [https://www.gnu.org/software/octave/doc/interpreter/Mex_002dFiles.html Octave's implementation of the Matlab MEX interface] may be released under the terms of whatever license you choose, provided that the following conditions are met:<br />
<br />
:# The MEX file may not use any bindings that are specific to Octave, '''it has to use the MEX interface only'''. In other words, it should be possible in principle to use the MEX file with other programs that implement the MEX interface (e.g., Matlab). For example including an Octave header file or calling an Octave function within the MEX file, that is not related with Octave's implementation of the MEX interface make the MEX file a derivative work of Octave and has therefore to be released under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
:# The MEX file may not be distributed together with Octave in such a way that they effectively create a single work. For example, you should not distribute the MEX file and Octave together in a single package such that Octave automatically loads and runs the MEX file when it starts up. There are other possible ways to effectively create a single work.<br />
<br />
* Code that '''embeds the Octave interpreter''' (e.g., by calling the <code>octave_main</code> function), or that calls functions from Octave's libraries (e.g., liboctinterp, liboctave, or libcruft) is considered a derivative work of Octave and therefore must be released under terms that are compatible with the GPL.<br />
<br />
==Will you change the license of the Octave libraries for me?==<br />
<br />
'''No.''' Instead of asking us to change the licensing terms for Octave, we recommend that you release your program under terms that are compatible with the GPL, this way the free software community can be benefited from your work the same as you were/have benefited from the work of all the people who have contributed to Octave.<br />
<br />
==Should I favor the MEX interface to avoid the GPL?==<br />
<br />
'''No.''' The original reason for implementing the [https://www.gnu.org/software/octave/doc/interpreter/Mex_002dFiles.html MEX interface] for Octave was to allow Octave to run free software that uses MEX files (the particular goal was to run [https://computation.llnl.gov/projects/sundials/release-history#sundialsTB sundialsTB] in Octave). The intent was to liberate that software from Matlab and increase the amount of free softwares available to Octave users & not to enable people to write proprietary code for Octave. For the good of the community, we strongly encourage users of Octave to release the code they write for Octave under terms that are compatible with the [https://www.gnu.org/licenses/gpl.html GPL].<br />
<br />
==Why can't I use code from File Exchange in Octave?==<br />
<br />
According to the Matlab Central [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use] (Last updated: 10-Aug-2016), all submitted code is licensed under the [https://en.wikipedia.org/wiki/BSD_licenses BSD license] by default (cf. § 5 [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use]), but it is clearly stated that:<br />
<br />
{{Quote|text=Content submitted to File Exchange may only be used with MathWorks products. | |§ 2(a)(iii) [https://www.mathworks.com/matlabcentral/termsofuse.html Terms of Use]}}<br />
<br />
That does not apply to GNU Octave, therefore the usage is in general prohibited. It should suffice — although interpretations of this vary — to contact the author directly to send you the code personally (maybe released under a free license), or download the code from the author's own website, if available. [[Asking_for_package_to_be_released_under_GPL:_examples|Some examples of letters/email sent to authors for that purpose]].<br />
<br />
=Installation=<br />
<br />
==How can I install Octave on Windows?==<br />
<br />
:'' So as to install GNU-Octave for Windows O.S, refer to : [[Octave for Microsoft Windows]]''<br />
<br />
==How can I install Octave on MacOS?==<br />
<br />
:''So as to install GNU-Octave for MacOS, refer to : [[Octave for macOS]]''<br />
<br />
==How can I install Octave on GNU/Linux?==<br />
<br />
:'' So as to install GNU-Octave on GNU/Linux, refer to: [[Octave for GNU/Linux]]''<br />
<br />
==How to install Octave on Android OR What is the Octave app available in the Google Play store?==<br />
<br />
There is an '''unofficial''' Octave app available for Android in the Google Play store. Please see [[Octave for Android]] for further information.<br />
<br />
==How can I install Octave on platform X?==<br />
<br />
Octave currently runs on [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]]. It should be possible to make Octave work on other systems as well. If you are interested in porting Octave to other systems, please contact the maintainers development mailing list [https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers@octave.org].<br />
<br />
==What Octave version should I use?==<br />
<br />
For general use, it is recommended to use the latest stable version of Octave (currently {{Release}}), available from http://www.octave.org/download.html. For development and bleeding-edge features one can obtain the development source code from the Mercurial repository https://hg.savannah.gnu.org/hgweb/octave/graph/.<br />
<br />
The used version of Octave is available via the {{manual|ver}} command and a list of user-visible changes since the last release is available via the {{manual|news}} command at the GNU Octave prompt.<br />
<br />
==On what platforms does Octave run?==<br />
<br />
Octave runs on any platform you can compile it on. Binary distributions exist for [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]]. To work fully functional, Octave requires the used platform to support the underlying numerical libraries like [https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms BLAS], [https://en.wikipedia.org/wiki/LAPACK LAPACK], [http://www.suitesparse.com SuiteSparse], etc., and for plotting [https://www.opengl.org/ OpenGL] or [http://www.gnuplot.info/ gnuplot].<br />
<br />
==How can I obtain Octave's source code?==<br />
<br />
The latest version of the Octave source code (and older versions) is available from:<br />
<br />
* https://www.octave.org/download.html<br />
* https://ftp.gnu.org/gnu/octave/<br />
<br />
Since Octave is distributed under the terms of the GPL, you can get Octave from a friend who has a copy.<br />
<br />
==How can I build Octave from the source code?==<br />
<br />
To use Octave it is usually not required to build it from it's source code. Binary distributions exist for [[Octave for GNU/Linux|GNU/Linux]], [[Octave for macOS|macOS]], and [[Octave for Microsoft Windows|Windows]].<br />
<br />
If you have reasons to build Octave from the source code, see [[Building]] for more information.<br />
<br />
==What do I need to build Octave from the source code?==<br />
<br />
For a list of build dependencies, refer to [[Building]].<br />
<br />
==Do I need GCC to build Octave from the source code?==<br />
<br />
No. The development is done primarily with [https://gcc.gnu.org/ GCC], so you may hit some incompatibilities. Octave is intended to be portable to any standard conforming compiler (for example [https://clang.llvm.org/ clang] is known to work as well). If you face any difficulties that you think are bugs, please report them to the [http://bugs.octave.org bug tracker], or ask for help on the [https://lists.gnu.org/mailman/listinfo/help-octave help@octave.org mailing list].<br />
<br />
=What's new in Octave?=<br />
<br />
Each new Octave release introduces many new features. A complete list of user visible changes can be seen by running <code>news</code> at the Octave prompt.<br />
<br />
* '''What's new in the next version of Octave?'''<br />
** See the [https://hg.savannah.gnu.org/hgweb/octave/file/tip/NEWS NEWS file] on the development branch.<br />
* '''What was new in Octave Version X.Y.Z?'''<br />
** See [[Release History]].<br />
<br />
=Packages and Octave Forge=<br />
<br />
==How do I install or load all Octave Forge packages?==<br />
<br />
Do not do it! Really, there is no reason to do this. Octave has many packages for different needs and is unlikely that you need all of them. You either have a small set of required packages, in which case<br />
you know them by name; or you want them all "just because", in which case you don't really need them.<br />
<br />
The common misconception is that the more packages one has installed and loaded, the more complete and powerful its Octave installation will be. However, in the same way one would never install all perl modules, ruby gems, python packages, and C++ libraries (because it simply makes no sense), one should not install all Octave packages.<br />
<br />
Packages should be installed and loaded selectively. Note that some packages are meant to shadow core functions changing the way Octave works, and that different packages can have different functions with the same name leading to unpredictable results.<br />
<br />
If you really really really want to do load all packages, you can with the following:<br />
<syntaxhighlight lang="octave"><br />
## WARNING: loading all packages is probably not the solution you are looking for.<br />
cellfun (@(x) pkg ("load", x.name), pkg ("list"));<br />
</syntaxhighlight><br />
<br />
==I have installed a package but still get a "foo undefined" error?==<br />
<br />
You have probably forgotten to load the package. Use {{Codeline|pkg load package-name}} to load it. Most packages are no longer loaded automatically to avoid surprises. See reasoning on related FAQ [[FAQ#How_do_I_install_all_Octave_packages.3F|how do I install all Octave packages]]. If you want a specific package to be loaded by default at startup, consider adding the {{Codeline|pkg load}} command on your {{path|[[.octaverc]]}} file.<br />
<br />
==I cannot install a package. Octave complains about a missing mkoctfile.==<br />
<br />
You should normally use your distribution's packages. For Debian and Fedora, Octave package <code>foo</code> will be a deb or rpm called <code>octave-foo</code>, and you should install that instead using <code>apt</code> or <code>yum</code>.<br />
<br />
If you really need to build Octave packages from source to install them, you'll need {{manual|mkoctfile}}. Most distributions split Octave into several packages. The script {{manual|mkoctfile}} is then part of a separate package:<br />
<br />
* Debian/Ubuntu: [https://packages.debian.org/stretch/liboctave-dev liboctave-dev]<br />
<br />
* Fedora: {{Codeline|octave-devel}}<br />
<br />
==How do I automatically load a package at Octave startup?==<br />
<br />
When Octave starts, it runs the file {{Path|~/.octaverc}} (in your user's home directory). If you want Octave to automatically load a package, simply add a <code>pkg load pkg-name</code> command to it. If the files does not exist, create it.<br />
<br />
If you do this, remember that other people may not have Octave configured to load packages at startup. Therefore, if you write code for others, remember that your programs still need to load the packages they require.<br />
<br />
=Octave usage=<br />
<br />
==How do I execute an Octave script?==<br />
<br />
First of all, make sure you understand [http://www.octave.org/doc/interpreter/Script-Files.html the difference between script files and function files]. If you want to execute a function defined in a file, just call the function like any other Octave function: <code>foo(arg1, arg2);</code><br />
<br />
To execute a script from within Octave, just type its name without the <code>.m</code> extension. Thus, if you have a script called <code>foo.m</code>, just type <code>foo</code> from within the Octave command prompt to execute it. You have to make sure that the script is in your current working directory or in Octave's load path. Type {{manual|pwd}} to get the current working directory or type {{manual|path}} to see which paths belong to Octave's load path. The current working directory is referred to as "." in the output of {{manual|path}}.<br />
<br />
If the script name has characters that are not valid for an Octave identifier, or if you do not want to use {{manual|addpath}} to add the script's location to the current path, you can use the {{manual|run}} function instead:<br />
<br />
<syntaxhighlight lang="octave"><br />
run ("Script Name With Spaces.m")<br />
run ("/opt/local/foo.m")<br />
</syntaxhighlight><br />
<br />
An alternative is to run the script from outside Octave by calling Octave from your operating system shell. Unlike calling the script from inside Octave, this also allows you to pass arguments from the shell into the script, which the script can access using the {{manual|argv}} command:<br />
<br />
$ octave the-script.m arg1 arg2<br />
<br />
In a Unix environment, if the script has a [http://en.wikipedia.org/wiki/Shebang_%28Unix%29 shebang] (e.g. <code>#!/usr/bin/octave</code>) and executable permissions, you can call it like any other Unix program with arguments:<br />
<br />
$ ./the-script arg1 arg2<br />
<br />
If you call the script from the shell and it's plotting, please note [[#When I try plotting from a script, why am I not seeing anything?|how to plot when running a script from the shell]].<br />
<br />
==How do I close a figure?== <br />
<br />
To close the current figure type {{manual|close}} in the Octave command prompt.<br />
<br />
==How do I set the number of displayed decimals?==<br />
<br />
You can control the number of displayed decimals using the {{manual|format}} command:<br />
<br />
<syntaxhighlight lang="octave"><br />
>> format long<br />
>> pi<br />
pi = 3.14159265358979<br />
>> format short<br />
>> pi<br />
pi = 3.1416<br />
</syntaxhighlight><br />
<br />
==How do I call an Octave function from C++?==<br />
<br />
Please read the manual https://www.gnu.org/software/octave/doc/interpreter/Calling-Octave-Functions-from-Oct_002dFiles.html.<br />
<br />
==How do I change color/line definition in gnuplot postscript?==<br />
<br />
Here is a awk script to get a rainbow color map<br />
<br />
#!/bin/awk -f<br />
<br />
BEGIN {<br />
split("0 4 6 7 5 3 1 2 8", rainbow, " ");<br />
split("7 3 1 0 2 4 6 5 8", invraim, " ");<br />
}<br />
<br />
$1 ~ /\/LT[0-8]/ {<br />
n = substr($1, 4, 1);<br />
if (n == 0)<br />
lt = "{ PL [] 0.9 0.1 0.1 DL } def";<br />
else if (n == 1)<br />
lt = "{ PL [4 dl 2 dl] 0.1 .75 0.1 DL } def";<br />
else if (n == 2)<br />
lt = "{ PL [2 dl 3 dl] 0.1 0.1 0.9 DL } def";<br />
else if (n == 3)<br />
lt = "{ PL [1 dl 1.5 dl] 0.9 0 0.8 DL } def";<br />
else if (n == 4)<br />
lt = "{ PL [5 dl 2 dl 1 dl 2 dl] 0.1 0.8 0.8 DL } def";<br />
else if (n == 5)<br />
lt = "{ PL [4 dl 3 dl 1 dl 3 dl] 0.9 0.8 0.2 DL } def";<br />
else if (n == 6)<br />
lt = "{ PL [2 dl 2 dl 2 dl 4 dl] 0.5 0.3 0.1 DL } def";<br />
else if (n == 7)<br />
lt = "{ PL [2 dl 2 dl 2 dl 2 dl 2 dl 4 dl] 1 0.4 0 DL } def";<br />
else if (n == 8)<br />
lt = "{ PL [2 dl 2 dl 2 dl 2 dl 2 dl 2 dl 2 dl 4 dl] 0.5 0.5 0.5 DL } def";<br />
$0 = sprintf("/LT%d %s", rainbow[n+1], lt);<br />
##$0 = sprintf("/LT%x %s", invraim[n+1], lt);<br />
##$0 = sprintf("/LT%x %s", n, lt);<br />
}<br />
<br />
{ print; }<br />
<br />
==How do I tell if a file exists?==<br />
<br />
One can use the function {{manual|exist}} to tell if a regular file, say <code>foo.txt</code> exist in Octave's load path, or the current directory:<br />
<br />
<syntaxhighlight lang="octave"><br />
>> exist ("foo.txt", "file") # 2, if file exists, 0 otherwise<br />
ans = 2<br />
</syntaxhighlight><br />
<br />
==How do I create a plot without a window popping up (plot to a file directly)?==<br />
<br />
<syntaxhighlight lang="octave"><br />
figure (1, "visible", "off");<br />
plot (sin (1:100));<br />
print -deps "/tmp/sin.eps"<br />
</syntaxhighlight><br />
<br />
One can set that behavior as default:<br />
<br />
<syntaxhighlight lang="octave"><br />
set (0, "defaultfigurevisible", "off");<br />
</syntaxhighlight><br />
<br />
==How do I increase Octave's precision?==<br />
<br />
Octave's default numerical type is [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754] binary64, a.k.a. "double" or "hardware floats". This type has a precision of 53 bits or about 16 decimal digits. It is supported by each modern computer hardware, so it is really '''fast'''. This type is assumed throughout for Octave's calculations. If more precision was required, one can obtain a "few bits more" by using integer types, e.g. {{manual|uint64}}, but in general one cannot expect more precision from any '''fast''' numerical software. Just to visualize "how big" those numerical limits are, consider the following table:<br />
<br />
{| class="wikitable"<br />
|+ Limits of some of Octave's data types obtained by {{manual|intmax}} and {{manual|flintmax}}.<br />
|-<br />
| <code>intmax ("uint64")</code><br />
| style="text-align: right;" | <code>18,446,744,073,709,551,615</code><br />
| <code>2^64-1</code><br />
|-<br />
| <code>intmax ("int64")</code><br />
| style="text-align: right;" | <code>9,223,372,036,854,775,807</code><br />
| <code>2^63-1</code><br />
|-<br />
| <code>flintmax ("double")</code><br />
| style="text-align: right;" | <code>9,007,199,254,740,992</code><br />
| <code>2^53</code><br />
|-<br />
| <code>flintmax ("single")</code><br />
| style="text-align: right;" | <code>16,777,216</code><br />
| <code>2^24</code><br />
|}<br />
<br />
When working with other types than "double" in Octave, one has to make sure, that the first operand is converted to the desired type:<br />
<br />
<syntaxhighlight lang="Octave"><br />
>> uint64 (2^53 + 1)<br />
ans = 9007199254740992<br />
>> uint64 (2^53) + 1<br />
ans = 9007199254740993<br />
</syntaxhighlight><br />
<br />
Notice the difference, in the first line the addition within the brackets is performed using double precision, therefore the result gets "truncated" to the maximum possible value without a warning. The third line uses throughout uint64 precision.<br />
<br />
Consider carefully if your problem really needs more precision. Often if you're running out of precision the problem lies fundamentally in your methods being [https://en.wikipedia.org/wiki/Numerical_stability numerically unstable], thus more precision will not help you here.<br />
<br />
If you absolutely must have more precision, you're at present better off using a [https://en.wikipedia.org/wiki/Computer_algebra_system CAS] instead of Octave. However, CAS or symbolic computations must be implemented '''in software''' which makes it much slower than hardware floats. An example of such a CAS is [http://www.sagemath.org/ Sage] or have a look at Octave's [[Symbolic package]].<br />
<br />
==How do I run a Matlab P-file in Octave?==<br />
<br />
You can't. Matlab P-files (files with a <code>.p</code> file extension), also known as P-code, are [https://en.wikipedia.org/wiki/Obfuscation_%28software%29 obfuscated] files that cannot be run outside of Matlab itself. The original source Matlab m-files that were used to generate these P-files should be used in Octave instead.<br />
<br />
There are no plans to support running P-files produced by Matlab in Octave.<br />
<br />
==How does Octave solve linear systems?==<br />
<br />
In addition to consulting Octave's source for the precise details, you can read the Octave manual for a complete high-level description of the algorithm that Octave uses to decide how to solve a particular linear system, e.g. how the backslash operator <code>A \ x</code> will be interpreted. Sections [http://www.octave.org/doc/interpreter/Techniques-Used-for-Linear-Algebra.html Techniques Used for Linear Algebra] and [http://www.octave.org/doc/interpreter/Sparse-Linear-Algebra.html Linear Algebra on Sparse Matrices] from the manual describe this procedure.<br />
<br />
==How do I do X?==<br />
<br />
You are probably looking for the function {{manual|lookfor}}. This function searches the help text of all functions for a specific string and returns a list of functions. Note that by default it will only search the first line of the help text (check <code>help lookfor</code> at the octave prompt for more). The following example helps to find the function to calculate correlation coefficient in a matrix:<br />
<br />
>> lookfor correlation<br />
corr Compute matrix of correlation coefficients.<br />
corrcoef Compute a matrix of correlation coefficients.<br />
spearman Compute Spearman's rank correlation coefficient RHO.<br />
<br />
Also, there's a high chance that the function name has a suggestive name, and so you can try auto-completion to get some hints. For the previous example, typing <code>corr</code> at the octave prompt followed by pressing the {{key press|Tab}}-Key twice would suggest the following:<br />
<br />
>> corr<br />
corr corrcoef<br />
<br />
=Differences between Octave and Matlab=<br />
:''See [[Differences between Octave and Matlab]]''.<br />
<br />
=[https://en.wikipedia.org/wiki/Graphical_user_interface GUI]=<br />
<br />
==Does Octave have a GUI?==<br />
<br />
'''Yes!''' It was officially released with Octave 4.0.0. It was also available since version 3.8.0 as an experimental feature (use the {{Codeline|--force-gui}} option to start Octave).<br />
<br />
==Why did you create yet another GUI instead of making one that already exists better?==<br />
<br />
The previously existing GUIs were not part of Octave itself. The integration within Octave was rather bad, as all of them treated Octave as a foreign black box and used pipes for communication. This approach is bound to fail with each new version of Octave, as any fix would only be temporary. For historical reasons and to honor the approaches, a short list of previous GUIs for Octave:<br />
<br />
* '''QtOctave''' was a great, beautiful, and very useful tool which is now abandoned and incompatible with newer versions of Octave. We are thankful to its developers to make it free software so we could reuse large chunks of it for what is now the Octave GUI.<br />
<br />
* '''Quint''' was a project for an Octave GUI that actually tried to do it right. Eventually [https://lists.gnu.org/archive/html/octave-maintainers/2011-07/msg00096.html it was merged into the Octave repository] and is no longer a separate project. Also, many bits from QtOctave were reused in the GUI.<br />
<br />
* '''[http://www.xoctave.com/ Xoctave]''', which is proprietary and commercial.<br />
<br />
* '''GUI Octave''', which was proprietary and is no longer available.<br />
<br />
=Graphics: backends and toolkits=<br />
<br />
==What are the supported graphics backends?==<br />
<br />
* [https://www.opengl.org/ OpenGL] via the graphics toolkits '''[https://www.qt.io/ qt]''' (current default) and '''[http://www.fltk.org/ fltk]'''<br />
* [http://www.gnuplot.info/ gnuplot] via the '''gnuplot''' graphics toolkit<br />
<br />
==How do I change my graphics toolkit?==<br />
<br />
There are three commands to deal with graphics toolkits:<br />
<br />
{| class="wikitable"<br />
| <code>available_graphics_toolkits</code><br />
| lists all available graphics toolkits<br />
|-<br />
| <code>graphics_toolkit</code><br />
| displays the currently used graphics toolkit<br />
|-<br />
| <code>graphics_toolkit ("qt/fltk/gnuplot")</code><br />
| sets the graphics toolkit to either of [https://www.qt.io/ qt], [http://www.fltk.org/ fltk], or [http://www.gnuplot.info/ gnuplot], if available<br />
|}<br />
<br />
==Why did you replace gnuplot with an OpenGL backend?==<br />
<br />
The development of Octave is committed to being both compatible with Matlab and adding additional features. Toward those ends, the developers decided to introduce a native OpenGL backend that supports Matlab handle graphics and its uicontrols. Starting with the 3.8 release, Octave uses OpenGL graphics by default (with [http://www.fltk.org/ FLTK widgets] in Octave 3.8 and [https://www.qt.io/ Qt widgets] in Octave 4.0 and later).<br />
<br />
==Are there any plans to remove the gnuplot backend?==<br />
<br />
'''No.''' There are no plans to remove the gnuplot backend. It will be available as long as our users find it useful.<br />
<br />
==How can I implement a new graphics backend/toolkit?==<br />
<br />
This is one of those times where the best documentation is to read the existing code. We have three different toolkits in Octave now, so there are some examples to draw from.<br />
<br />
= Development =<br />
<br />
== When will feature X be released or implemented? ==<br />
<br />
When it's ready, sooner [https://www.octave.org/get-involved.html if you help]. You can [https://savannah.gnu.org/patch/?group=octave send us patches] if you can implement feature X yourself. If you can't, some [https://www.octave.org/commercial-support.html developers may be convinced to work on your specific problem for some money].<br />
<br />
== How can I get involved in Octave development? ==<br />
<br />
:''See [[Developer FAQ]]''.<br />
<br />
[[Category:FAQ]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Uicontrols&diff=13254Uicontrols2020-07-13T06:11:41Z<p>Siko1056: /* uicontrols: Build a GUI in GNU Octave */ Use syntax highlighter.</p>
<hr />
<div>= uicontrols: Build a GUI in GNU Octave =<br />
<br />
You have to use the "qt" graphics toolkit (default since 4.0). For the best results GNU Octave version >= 4.2.x should be used.<br />
<br />
== Resources ==<br />
<br />
* https://www.gnu.org/software/octave/doc/interpreter/GUI-Development.html<br />
<br />
== Examples ==<br />
<br />
=== imageViewer ===<br />
<br />
GUI which opens a file selection dialog when a button is pressed and views the selected image.<br />
<br />
[[File:imageViewer1.png]] [[File:imageViewer2.png]]<br />
<br />
{{Code|imageViewer example|<syntaxhighlight lang="octave"><br />
%% In file 'imageViewer.m'<br />
function imageViewer ()<br />
MainFrm = figure ( ...<br />
'position', [100, 100, 250, 350]); <br />
<br />
TitleFrm = axes ( ... <br />
'position', [0, 0.8, 1, 0.2], ... <br />
'color', [0.9, 0.95, 1], ...<br />
'xtick', [], ... <br />
'ytick', [], ... <br />
'xlim', [0, 1], ... <br />
'ylim', [0, 1] );<br />
<br />
Title = text (0.05, 0.5, 'Preview Image', 'fontsize', 30);<br />
<br />
ImgFrm = axes ( ...<br />
'position', [0, 0.2, 1, 0.6], ... <br />
'xtick', [], ... <br />
'ytick', [], ...<br />
'xlim', [0, 1], ... <br />
'ylim', [0, 1]);<br />
<br />
ButtonFrm = uicontrol (MainFrm, ...<br />
'style', 'pushbutton', ... <br />
'string', 'OPEN THE IMAGE', ...<br />
'units', 'normalized', ...<br />
'position', [0, 0, 1, 0.2], ...<br />
'callback', { @previewImage, ImgFrm });<br />
end<br />
<br />
%% callback subfunction (in same file)<br />
function previewImage (hObject, eventdata, ImageFrame)<br />
[fname, fpath] = uigetfile();<br />
Img = imread (fullfile(fpath, fname));<br />
axes(ImageFrame);<br />
imshow(Img, []);<br />
axis image off<br />
end<br />
</syntaxhighlight>}}<br />
<br />
Then run <code>imageViewer()</code> from your terminal:<br />
<br />
=== demo_uicontrol ===<br />
<br />
This example tries to show all available uicontrols (needs Octave >= 4.0 and qt):<br />
<br />
[[File:demo_uicontrol1.png]]<br />
<br />
{{Code|demo_uicontrol.m|<syntaxhighlight lang="octave"><br />
## 20.03.2017 Andreas Weber <andy@josoansi.de><br />
## Demo which has the aim to show all available GUI elements.<br />
## Useful since Octave 4.0<br />
<br />
close all<br />
clear h<br />
<br />
graphics_toolkit qt<br />
<br />
h.ax = axes ("position", [0.05 0.42 0.5 0.5]);<br />
h.fcn = @(x) polyval([-0.1 0.5 3 0], x);<br />
<br />
function update_plot (obj, init = false)<br />
<br />
## gcbo holds the handle of the control<br />
h = guidata (obj);<br />
replot = false;<br />
recalc = false;<br />
switch (gcbo)<br />
case {h.print_pushbutton}<br />
fn = uiputfile ("*.png");<br />
print (fn);<br />
case {h.grid_checkbox}<br />
v = get (gcbo, "value");<br />
grid (merge (v, "on", "off"));<br />
case {h.minor_grid_toggle}<br />
v = get (gcbo, "value");<br />
grid ("minor", merge (v, "on", "off"));<br />
case {h.plot_title_edit}<br />
v = get (gcbo, "string");<br />
set (get (h.ax, "title"), "string", v);<br />
case {h.linecolor_radio_blue}<br />
set (h.linecolor_radio_red, "value", 0);<br />
replot = true;<br />
case {h.linecolor_radio_red}<br />
set (h.linecolor_radio_blue, "value", 0);<br />
replot = true;<br />
case {h.linestyle_popup, h.markerstyle_list}<br />
replot = true;<br />
case {h.noise_slider}<br />
recalc = true;<br />
endswitch<br />
<br />
if (recalc || init)<br />
x = linspace (-4, 9);<br />
noise = get (h.noise_slider, "value");<br />
set (h.noise_label, "string", sprintf ("Noise: %.1f%%", noise * 100));<br />
y = h.fcn (x) + 5 * noise * randn (size (x));<br />
if (init)<br />
h.plot = plot (x, y, "b");<br />
guidata (obj, h);<br />
else<br />
set (h.plot, "ydata", y);<br />
endif<br />
endif<br />
<br />
if (replot)<br />
cb_red = get (h.linecolor_radio_red, "value");<br />
lstyle = get (h.linestyle_popup, "string"){get (h.linestyle_popup, "value")};<br />
lstyle = strtrim (lstyle(1:2));<br />
<br />
mstyle = get (h.markerstyle_list, "string"){get (h.markerstyle_list, "value")};<br />
if (strfind (mstyle, "none"))<br />
mstyle = "none";<br />
else<br />
mstyle = mstyle(2);<br />
endif<br />
<br />
set (h.plot, "color", merge (cb_red, [1 0 0 ], [0 0 1]),<br />
"linestyle", lstyle,<br />
"marker", mstyle);<br />
endif<br />
<br />
endfunction<br />
<br />
<br />
## plot title<br />
h.plot_title_label = uicontrol ("style", "text",<br />
"units", "normalized",<br />
"string", "plot title: (text)",<br />
"horizontalalignment", "left",<br />
"position", [0.6 0.85 0.35 0.08]);<br />
<br />
h.plot_title_edit = uicontrol ("style", "edit",<br />
"units", "normalized",<br />
"string", "Please fill me! (edit)",<br />
"callback", @update_plot,<br />
"position", [0.6 0.80 0.35 0.06]);<br />
<br />
## grid<br />
h.grid_checkbox = uicontrol ("style", "checkbox",<br />
"units", "normalized",<br />
"string", "show grid\n(checkbox)",<br />
"value", 0,<br />
"callback", @update_plot,<br />
"position", [0.6 0.65 0.35 0.09]);<br />
<br />
h.minor_grid_toggle = uicontrol ("style", "togglebutton",<br />
"units", "normalized",<br />
"string", "minor\n(togglebutton)",<br />
"callback", @update_plot,<br />
"value", 0,<br />
"position", [0.77 0.65 0.18 0.09]);<br />
<br />
## print figure<br />
h.print_pushbutton = uicontrol ("style", "pushbutton",<br />
"units", "normalized",<br />
"string", "print plot\n(pushbutton)",<br />
"callback", @update_plot,<br />
"position", [0.6 0.45 0.35 0.09]);<br />
## noise<br />
h.noise_label = uicontrol ("style", "text",<br />
"units", "normalized",<br />
"string", "Noise:",<br />
"horizontalalignment", "left",<br />
"position", [0.05 0.3 0.35 0.08]);<br />
<br />
h.noise_slider = uicontrol ("style", "slider",<br />
"units", "normalized",<br />
"string", "slider",<br />
"callback", @update_plot,<br />
"value", 0.4,<br />
"position", [0.05 0.25 0.35 0.06]);<br />
<br />
## linecolor<br />
h.linecolor_label = uicontrol ("style", "text",<br />
"units", "normalized",<br />
"string", "Linecolor:",<br />
"horizontalalignment", "left",<br />
"position", [0.05 0.12 0.35 0.08]);<br />
<br />
h.linecolor_radio_blue = uicontrol ("style", "radiobutton",<br />
"units", "normalized",<br />
"string", "blue",<br />
"callback", @update_plot,<br />
"position", [0.05 0.08 0.15 0.04]);<br />
<br />
h.linecolor_radio_red = uicontrol ("style", "radiobutton",<br />
"units", "normalized",<br />
"string", "red",<br />
"callback", @update_plot,<br />
"value", 0,<br />
"position", [0.05 0.02 0.15 0.04]);<br />
<br />
## linestyle<br />
h.linestyle_label = uicontrol ("style", "text",<br />
"units", "normalized",<br />
"string", "Linestyle:",<br />
"horizontalalignment", "left",<br />
"position", [0.25 0.12 0.35 0.08]);<br />
<br />
h.linestyle_popup = uicontrol ("style", "popupmenu",<br />
"units", "normalized",<br />
"string", {"- solid lines",<br />
"-- dashed lines",<br />
": dotted lines",<br />
"-. dash-dotted lines"},<br />
"callback", @update_plot,<br />
"position", [0.25 0.05 0.3 0.06]);<br />
<br />
## markerstyle<br />
h.markerstyle_label = uicontrol ("style", "text",<br />
"units", "normalized",<br />
"string", "Marker style:",<br />
"horizontalalignment", "left",<br />
"position", [0.58 0.3 0.35 0.08]);<br />
<br />
h.markerstyle_list = uicontrol ("style", "listbox",<br />
"units", "normalized",<br />
"string", {"none",<br />
"'+' crosshair",<br />
"'o' circle",<br />
"'*' star",<br />
"'.' point",<br />
"'x' cross",<br />
"'s' square",<br />
"'d' diamond",<br />
"'^' upward-facing triangle",<br />
"'v' downward-facing triangle",<br />
"'>' right-facing triangle",<br />
"'<' left-facing triangle",<br />
"'p' pentagram",<br />
"'h' hexagram"},<br />
"callback", @update_plot,<br />
"position", [0.58 0.04 0.38 0.26]);<br />
<br />
set (gcf, "color", get(0, "defaultuicontrolbackgroundcolor"))<br />
guidata (gcf, h)<br />
update_plot (gcf, true);<br />
</syntaxhighlight>}}<br />
<br />
[[Category:Examples]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Interactive_plots&diff=13253Interactive plots2020-07-13T06:09:46Z<p>Siko1056: /* Demo 1 */ Use syntax highlighter.</p>
<hr />
<div>This page shows some possibilities to create interactive OpenGL plots (qt or fltk toolkit) not using uicontrols.<br />
<br />
See also [[uicontrols]] where you can create buttons and slider to create plots<br />
<br />
== Demo 1 ==<br />
<br />
[[File:interactive_select2.gif]]<br />
<br />
{{Code|imageViewer example|<syntaxhighlight lang="octave"><br />
clear all<br />
graphics_toolkit qt<br />
set (0, "defaultlinelinewidth", 2);<br />
<br />
h.points = rand (2, 3); # 3 random points<br />
h.line = [];<br />
h.marker = [];<br />
set (gcf, "userdata", h)<br />
<br />
function down_fig (hsrc, evt)<br />
<br />
h = get (hsrc, "userdata");<br />
if (isempty (h.marker))<br />
hold on<br />
h.marker = plot (NA, NA, "o", "markersize", 15, "color", "green");<br />
hold off<br />
endif<br />
<br />
set (hsrc, "userdata", h);<br />
drag_fig (hsrc, evt);<br />
endfunction<br />
<br />
function drag_fig (hsrc, evt)<br />
<br />
# evt 1:left button, 2:middle button, 3:right button<br />
h = get (hsrc, "userdata");<br />
<br />
if (! isempty (h.marker))<br />
c = get (gca, "currentpoint")([1;3]);<br />
set (h.marker, "xdata", c(1));<br />
set (h.marker, "ydata", c(2));<br />
<br />
# find nearest point<br />
d = h.points - c;<br />
[~, idx] = min (hypot (d(1, :), d(2, :)));<br />
h.points(:, idx) = c;<br />
<br />
endif<br />
<br />
# draw / update the line<br />
tmp = [h.points h.points(:,1)]; # duplicate first point to close triangle<br />
if (isempty (h.line))<br />
h.line = plot (tmp(1, :), tmp(2, :), "-o");<br />
h.text = text (NA, NA, "", "horizontalalignment", "center");<br />
## testing<br />
axis ([0 1 0 1])<br />
else<br />
set (h.line, "xdata", tmp(1, :));<br />
set (h.line, "ydata", tmp(2, :));<br />
endif<br />
<br />
# calculate the area<br />
A = polyarea (h.points(1, :),<br />
h.points(2, :));<br />
P = mean (h.points, 2);<br />
set (h.text, "position", mean (h.points, 2).');<br />
set (h.text, "string", sprintf ("A = %.3f", A));<br />
<br />
set (hsrc, "userdata", h);<br />
<br />
endfunction<br />
<br />
function up_fig (hsrc, evt)<br />
<br />
h = get (gcbf, "userdata");<br />
delete (h.marker);<br />
h.marker = [];<br />
set (gcbf, "userdata", h);<br />
<br />
endfunction<br />
<br />
set (gcf, "windowbuttondownfcn", @down_fig);<br />
set (gcf, "windowbuttonmotionfcn", @drag_fig)<br />
set (gcf, "windowbuttonupfcn", @up_fig)<br />
<br />
# first update<br />
drag_fig (gcf, [])<br />
</syntaxhighlight>}}<br />
<br />
[[Category:Examples]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Octave_load&diff=13252Octave load2020-07-13T06:07:47Z<p>Siko1056: Mark as outdated.</p>
<hr />
<div>{{Warning|This article is '''outdated'''. For current C++ code examples see the Octave Manual https://octave.org/doc/latest/Standalone-Programs.html.}}<br />
<br />
The code below shows an example of how to load a matrix from a file in Octave's binary file format.<br />
An example of how to load data from a file in Octave's ascii format can be found in this [[fortran|page]].<br />
<br />
{{Code|octave_binary_io_example.cc: C++ function to load a matrix from a BINARY file in Octave native format|<syntaxhighlight lang="C" style="font-size:13px"><br />
<br />
#include <fstream><br />
#include <octave/oct.h><br />
#include <octave/ov.h><br />
#include <octave/zfstream.h><br />
#include <octave/octave.h><br />
#include <octave/parse.h><br />
#include <octave/toplev.h><br />
#include <octave/load-save.h><br />
#include <octave/ls-oct-binary.h><br />
#include <octave/oct-map.h><br />
#include <cstring><br />
<br />
std::fstream file;<br />
std::ios::openmode m = std::ios::in;<br />
load_save_format format = LS_BINARY;<br />
oct_mach_info::float_format flt_fmt = oct_mach_info::flt_fmt_unknown;<br />
bool swap = false;<br />
<br />
int main (void)<br />
{<br />
string_vector argv (1);<br />
<br />
install_types (); <br />
argv(0) = std::string ("test_var");<br />
<br />
file.open ("test.bin", m);<br />
if (read_binary_file_header (file, swap, flt_fmt, true) != 0)<br />
return -1;<br />
<br />
octave_scalar_map m = do_load (file, "test.bin", format, <br />
flt_fmt, false, swap, true, argv, <br />
0, 1, 1).scalar_map_value ();<br />
<br />
<br />
std::cout << m.contents ("test_var").matrix_value ();<br />
<br />
file.close ();<br />
return 0;<br />
<br />
}<br />
<br />
<br />
</syntaxhighlight>}}<br />
<br />
<br />
To test, type the following in Octave:<br />
<br />
{{Code||<syntaxhighlight lang="Octave" style="font-size:13px"><br />
<br />
>> test_var = randn(5);<br />
>> save -binary test.bin test_var<br />
<br />
<br />
</syntaxhighlight>}}<br />
<br />
<br />
Compile and run the example with the following commads<br />
<br />
{{Code||<syntaxhighlight lang="bash" style="font-size:13px"><br />
<br />
$ mkoctfile --link-stand-alone octave_binary_io_example.cc<br />
$ ./a.out<br />
<br />
</syntaxhighlight>}}<br />
<br />
[[Category:Outdated pages]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Fortran&diff=13251Fortran2020-07-13T05:17:36Z<p>Siko1056: Add description about the data file.</p>
<hr />
<div>This page describes an example of how to call liboctave functions from a Fortran program.<br />
In the example we will load a single matrix, stored in ASCII format, from a data file.<br />
It consists of two steps:<br />
<br />
# write a C++ function with a C compatible interface and C linkage that reads a variable from an Octave ASCII file<br />
# write Fortran code using the "iso_c_binding" intrinsic module to call the C++ function<br />
<br />
=== Data file ===<br />
<br />
{{File|data.txt|<syntaxhighlight lang="text"><br />
1.59797350e-01 5.41307474e-01 1.12127655e-01 2.09249248e-01<br />
3.22564589e-01 7.94307947e-01 8.25924316e-01 5.38352076e-01<br />
3.63990736e-01 1.90371212e-02 2.89370865e-01 1.30131246e-01<br />
6.28360462e-01 1.98831330e-01 6.89539723e-01 6.91062597e-01<br />
</syntaxhighlight>}}<br />
<br />
The file was generated with<br />
<br />
<syntaxhighlight lang="octave"><br />
A = rand (4);<br />
save -ascii data.txt A<br />
</syntaxhighlight><br />
<br />
=== C++ function ===<br />
<br />
C++ function to load a single matrix, stored in ASCII format, from a data file.<br />
<br />
{{File|octave_file_io.cc|<syntaxhighlight lang="C++"><br />
// Octave header<br />
#include <octave/oct.h><br />
#include <octave/ls-mat-ascii.h><br />
<br />
// Custom header containing the C compatible interface<br />
#include <octave_file_io.h><br />
<br />
//! Load a single matrix, stored in ASCII format, from a data file.<br />
//!<br />
//! @param file_name name of the data file.<br />
//! @param data pointer to the read-in matrix stored as fortran vector<br />
//! (column-major order).<br />
//! @param numel number of elements in @p data.<br />
<br />
int octave_load (const char* file_name, double** data, int* numel)<br />
{<br />
// Define variable to hold the read data.<br />
octave_value read_data;<br />
<br />
// Read a plain ASCII matrix from data file.<br />
std::ifstream in_file_stream (file_name, std::ios::binary);<br />
read_mat_ascii_data (in_file_stream, file_name, read_data);<br />
in_file_stream.close ();<br />
<br />
// Convert read data to numerical array (matrix).<br />
NDArray A = read_data.array_value ();<br />
<br />
// Extract number of elements in matrix A.<br />
*numel = A.numel ();<br />
<br />
// Allocate memory to pointer to returned values.<br />
*data = (double*) malloc (A.numel () * sizeof (double));<br />
<br />
// Copy the content of matrix A to data structure Fortran can handle.<br />
memcpy (*data, A.fortran_vec (), A.numel () * sizeof (double));<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight>}}<br />
<br />
=== Header file ===<br />
<br />
Header file with C interface to {{Path|octave_file_io.cc}}.<br />
<br />
{{File|octave_file_io.h|<syntaxhighlight lang="C"><br />
#ifndef OCTAVE_FILE_IO_H<br />
#define OCTAVE_FILE_IO_H<br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int octave_load (const char* filename, double** data, int* numel);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
<br />
#endif<br />
</syntaxhighlight>}}<br />
<br />
=== Fortran Code ===<br />
<br />
Fortran main program to read the plain ASCII matrix with the help of the Octave-C++ function. The read in matrix is printed to the screen.<br />
<br />
{{File|octave_file_io_example.f90|<syntaxhighlight lang="fortran"><br />
program octave_file_io_example<br />
<br />
use iso_c_binding<br />
<br />
implicit none<br />
<br />
interface<br />
function octave_load (filename, data, numel) bind(c, name="octave_load")<br />
<br />
use iso_c_binding<br />
implicit none<br />
<br />
integer(c_int) :: octave_load<br />
<br />
character(kind=c_char), intent(in) :: filename(*)<br />
<br />
type(c_ptr), intent(out) :: data<br />
integer(c_int), intent(out) :: numel<br />
<br />
end function octave_load<br />
end interface<br />
<br />
integer(c_int) :: res<br />
type(c_ptr) :: data<br />
real(c_double), pointer :: fdata(:)<br />
integer(c_int) :: numel<br />
<br />
res = octave_load (c_char_'data.txt' // c_null_char, data, numel)<br />
<br />
call c_f_pointer (data, fdata, (/numel/))<br />
<br />
write (*,*) fdata<br />
<br />
end program octave_file_io_example<br />
</syntaxhighlight>}}<br />
<br />
=== Compiling the code ===<br />
<br />
Generate {{Path|octave_file_io.o}} from {{Path|octave_file_io.cc}}.<br />
<br />
mkoctfile -I. -c octave_file_io.cc<br />
<br />
Generate {{Path|octave_file_io_example.exe}} from {{Path|octave_file_io_example.f90}} including {{Path|octave_file_io.o}}.<br />
<br />
mkoctfile -I. --link-stand-alone octave_file_io_example.f90 octave_file_io.o -o octave_file_io_example.exe -lgfortran<br />
<br />
If you receive errors about missing libraries, make sure your <code>LD_LIBRARY_PATH</code> is set correctly to find all Octave libraries, e.g.<br />
<br />
$ ldd ./octave_file_io_example.exe<br />
...<br />
libgfortran.so.4 => /usr/lib64/libgfortran.so.4 (0x00007fe9eb62b000)<br />
liboctinterp.so.8 => not found<br />
liboctave.so.8 => not found<br />
...<br />
<br />
Then find {{Path|liboctinterp.so.8}} and {{Path|liboctave.so.8}} on your system and type<br />
<br />
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/lib/octave/{{Release}}/ <br />
<br />
<br />
[[Category:Examples]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Fortran&diff=13250Fortran2020-07-13T05:14:24Z<p>Siko1056: /* Compiling the code */</p>
<hr />
<div>This page describes an example of how to call liboctave functions from a Fortran program.<br />
In the example we will load an Octave array from a file in Octave's native ASCII format,<br />
it consists of two steps:<br />
<br />
* write a C++ function with a C compatible interface and C linkage that reads a variable from an Octave ASCII file<br />
* write Fortran code using the "iso_c_binding" intrinsic module to call the C++ function<br />
<br />
=== C++ function ===<br />
<br />
C++ function to load a single matrix, stored in ASCII format, from a data file.<br />
<br />
{{File|octave_file_io.cc|<syntaxhighlight lang="C++"><br />
// Octave header<br />
#include <octave/oct.h><br />
#include <octave/ls-mat-ascii.h><br />
<br />
// Custom header containing the C compatible interface<br />
#include <octave_file_io.h><br />
<br />
//! Load a single matrix, stored in ASCII format, from a data file.<br />
//!<br />
//! @param file_name name of the data file.<br />
//! @param data pointer to the read-in matrix stored as fortran vector<br />
//! (column-major order).<br />
//! @param numel number of elements in @p data.<br />
<br />
int octave_load (const char* file_name, double** data, int* numel)<br />
{<br />
// Define variable to hold the read data.<br />
octave_value read_data;<br />
<br />
// Read a plain ASCII matrix from data file.<br />
std::ifstream in_file_stream (file_name, std::ios::binary);<br />
read_mat_ascii_data (in_file_stream, file_name, read_data);<br />
in_file_stream.close ();<br />
<br />
// Convert read data to numerical array (matrix).<br />
NDArray A = read_data.array_value ();<br />
<br />
// Extract number of elements in matrix A.<br />
*numel = A.numel ();<br />
<br />
// Allocate memory to pointer to returned values.<br />
*data = (double*) malloc (A.numel () * sizeof (double));<br />
<br />
// Copy the content of matrix A to data structure Fortran can handle.<br />
memcpy (*data, A.fortran_vec (), A.numel () * sizeof (double));<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight>}}<br />
<br />
=== Header file ===<br />
<br />
Header file with C interface to {{Path|octave_file_io.cc}}.<br />
<br />
{{File|octave_file_io.h|<syntaxhighlight lang="C"><br />
#ifndef OCTAVE_FILE_IO_H<br />
#define OCTAVE_FILE_IO_H<br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int octave_load (const char* filename, double** data, int* numel);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
<br />
#endif<br />
</syntaxhighlight>}}<br />
<br />
=== Fortran Code ===<br />
<br />
Fortran main program to read the plain ASCII matrix with the help of the Octave-C++ function. The read in matrix is printed to the screen.<br />
<br />
{{File|octave_file_io_example.f90|<syntaxhighlight lang="fortran"><br />
program octave_file_io_example<br />
<br />
use iso_c_binding<br />
<br />
implicit none<br />
<br />
interface<br />
function octave_load (filename, data, numel) bind(c, name="octave_load")<br />
<br />
use iso_c_binding<br />
implicit none<br />
<br />
integer(c_int) :: octave_load<br />
<br />
character(kind=c_char), intent(in) :: filename(*)<br />
<br />
type(c_ptr), intent(out) :: data<br />
integer(c_int), intent(out) :: numel<br />
<br />
end function octave_load<br />
end interface<br />
<br />
integer(c_int) :: res<br />
type(c_ptr) :: data<br />
real(c_double), pointer :: fdata(:)<br />
integer(c_int) :: numel<br />
<br />
res = octave_load (c_char_'data.txt' // c_null_char, data, numel)<br />
<br />
call c_f_pointer (data, fdata, (/numel/))<br />
<br />
write (*,*) fdata<br />
<br />
end program octave_file_io_example<br />
</syntaxhighlight>}}<br />
<br />
=== Compiling the code ===<br />
<br />
Generate {{Path|octave_file_io.o}} from {{Path|octave_file_io.cc}}.<br />
<br />
mkoctfile -I. -c octave_file_io.cc<br />
<br />
Generate {{Path|octave_file_io_example.exe}} from {{Path|octave_file_io_example.f90}} including {{Path|octave_file_io.o}}.<br />
<br />
mkoctfile -I. --link-stand-alone octave_file_io_example.f90 octave_file_io.o -o octave_file_io_example.exe -lgfortran<br />
<br />
If you receive errors about missing libraries, make sure your <code>LD_LIBRARY_PATH</code> is set correctly to find all Octave libraries, e.g.<br />
<br />
$ ldd ./octave_file_io_example.exe<br />
...<br />
libgfortran.so.4 => /usr/lib64/libgfortran.so.4 (0x00007fe9eb62b000)<br />
liboctinterp.so.8 => not found<br />
liboctave.so.8 => not found<br />
...<br />
<br />
Then find {{Path|liboctinterp.so.8}} and {{Path|liboctave.so.8}} on your system and type<br />
<br />
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/lib/octave/{{Release}}/ <br />
<br />
<br />
[[Category:Examples]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Fortran&diff=13249Fortran2020-07-13T05:03:20Z<p>Siko1056: /* Header file */</p>
<hr />
<div>This page describes an example of how to call liboctave functions from a Fortran program.<br />
In the example we will load an Octave array from a file in Octave's native ASCII format,<br />
it consists of two steps:<br />
<br />
* write a C++ function with a C compatible interface and C linkage that reads a variable from an Octave ASCII file<br />
* write Fortran code using the "iso_c_binding" intrinsic module to call the C++ function<br />
<br />
=== C++ function ===<br />
<br />
C++ function to load a single matrix, stored in ASCII format, from a data file.<br />
<br />
{{File|octave_file_io.cc|<syntaxhighlight lang="C++"><br />
// Octave header<br />
#include <octave/oct.h><br />
#include <octave/ls-mat-ascii.h><br />
<br />
// Custom header containing the C compatible interface<br />
#include <octave_file_io.h><br />
<br />
//! Load a single matrix, stored in ASCII format, from a data file.<br />
//!<br />
//! @param file_name name of the data file.<br />
//! @param data pointer to the read-in matrix stored as fortran vector<br />
//! (column-major order).<br />
//! @param numel number of elements in @p data.<br />
<br />
int octave_load (const char* file_name, double** data, int* numel)<br />
{<br />
// Define variable to hold the read data.<br />
octave_value read_data;<br />
<br />
// Read a plain ASCII matrix from data file.<br />
std::ifstream in_file_stream (file_name, std::ios::binary);<br />
read_mat_ascii_data (in_file_stream, file_name, read_data);<br />
in_file_stream.close ();<br />
<br />
// Convert read data to numerical array (matrix).<br />
NDArray A = read_data.array_value ();<br />
<br />
// Extract number of elements in matrix A.<br />
*numel = A.numel ();<br />
<br />
// Allocate memory to pointer to returned values.<br />
*data = (double*) malloc (A.numel () * sizeof (double));<br />
<br />
// Copy the content of matrix A to data structure Fortran can handle.<br />
memcpy (*data, A.fortran_vec (), A.numel () * sizeof (double));<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight>}}<br />
<br />
=== Header file ===<br />
<br />
Header file with C interface to {{Path|octave_file_io.cc}}.<br />
<br />
{{File|octave_file_io.h|<syntaxhighlight lang="C"><br />
#ifndef OCTAVE_FILE_IO_H<br />
#define OCTAVE_FILE_IO_H<br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int octave_load (const char* filename, double** data, int* numel);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
<br />
#endif<br />
</syntaxhighlight>}}<br />
<br />
=== Fortran Code ===<br />
<br />
Fortran main program to read the plain ASCII matrix with the help of the Octave-C++ function. The read in matrix is printed to the screen.<br />
<br />
{{File|octave_file_io_example.f90|<syntaxhighlight lang="fortran"><br />
program octave_file_io_example<br />
<br />
use iso_c_binding<br />
<br />
implicit none<br />
<br />
interface<br />
function octave_load (filename, data, numel) bind(c, name="octave_load")<br />
<br />
use iso_c_binding<br />
implicit none<br />
<br />
integer(c_int) :: octave_load<br />
<br />
character(kind=c_char), intent(in) :: filename(*)<br />
<br />
type(c_ptr), intent(out) :: data<br />
integer(c_int), intent(out) :: numel<br />
<br />
end function octave_load<br />
end interface<br />
<br />
integer(c_int) :: res<br />
type(c_ptr) :: data<br />
real(c_double), pointer :: fdata(:)<br />
integer(c_int) :: numel<br />
<br />
res = octave_load (c_char_'data.txt' // c_null_char, data, numel)<br />
<br />
call c_f_pointer (data, fdata, (/numel/))<br />
<br />
write (*,*) fdata<br />
<br />
end program octave_file_io_example<br />
</syntaxhighlight>}}<br />
<br />
=== Compiling the code ===<br />
<br />
mkoctfile -I. octave_file_io.cc <br />
mkoctfile -I. --mkoctfile --link-stand-alone octave_file_io_example.f90 octave_file_io.o -o octave_file_io_example<br />
<br />
[[Category:Examples]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Fortran&diff=13248Fortran2020-07-13T05:03:05Z<p>Siko1056: /* Header file */</p>
<hr />
<div>This page describes an example of how to call liboctave functions from a Fortran program.<br />
In the example we will load an Octave array from a file in Octave's native ASCII format,<br />
it consists of two steps:<br />
<br />
* write a C++ function with a C compatible interface and C linkage that reads a variable from an Octave ASCII file<br />
* write Fortran code using the "iso_c_binding" intrinsic module to call the C++ function<br />
<br />
=== C++ function ===<br />
<br />
C++ function to load a single matrix, stored in ASCII format, from a data file.<br />
<br />
{{File|octave_file_io.cc|<syntaxhighlight lang="C++"><br />
// Octave header<br />
#include <octave/oct.h><br />
#include <octave/ls-mat-ascii.h><br />
<br />
// Custom header containing the C compatible interface<br />
#include <octave_file_io.h><br />
<br />
//! Load a single matrix, stored in ASCII format, from a data file.<br />
//!<br />
//! @param file_name name of the data file.<br />
//! @param data pointer to the read-in matrix stored as fortran vector<br />
//! (column-major order).<br />
//! @param numel number of elements in @p data.<br />
<br />
int octave_load (const char* file_name, double** data, int* numel)<br />
{<br />
// Define variable to hold the read data.<br />
octave_value read_data;<br />
<br />
// Read a plain ASCII matrix from data file.<br />
std::ifstream in_file_stream (file_name, std::ios::binary);<br />
read_mat_ascii_data (in_file_stream, file_name, read_data);<br />
in_file_stream.close ();<br />
<br />
// Convert read data to numerical array (matrix).<br />
NDArray A = read_data.array_value ();<br />
<br />
// Extract number of elements in matrix A.<br />
*numel = A.numel ();<br />
<br />
// Allocate memory to pointer to returned values.<br />
*data = (double*) malloc (A.numel () * sizeof (double));<br />
<br />
// Copy the content of matrix A to data structure Fortran can handle.<br />
memcpy (*data, A.fortran_vec (), A.numel () * sizeof (double));<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight>}}<br />
<br />
=== Header file ===<br />
<br />
Header file with C interface to {{Path|octave_file_io.cc}}.<br />
<br />
{{File|octave_file_io.h|<syntaxhighlight lang="C"><br />
#ifndef OCTAVE_FILE_IO_H<br />
#define OCTAVE_FILE_IO_H<br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int octave_load (const char* filename, const char* varname, double** data, int* numel);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
<br />
#endif<br />
</syntaxhighlight>}}<br />
<br />
=== Fortran Code ===<br />
<br />
Fortran main program to read the plain ASCII matrix with the help of the Octave-C++ function. The read in matrix is printed to the screen.<br />
<br />
{{File|octave_file_io_example.f90|<syntaxhighlight lang="fortran"><br />
program octave_file_io_example<br />
<br />
use iso_c_binding<br />
<br />
implicit none<br />
<br />
interface<br />
function octave_load (filename, data, numel) bind(c, name="octave_load")<br />
<br />
use iso_c_binding<br />
implicit none<br />
<br />
integer(c_int) :: octave_load<br />
<br />
character(kind=c_char), intent(in) :: filename(*)<br />
<br />
type(c_ptr), intent(out) :: data<br />
integer(c_int), intent(out) :: numel<br />
<br />
end function octave_load<br />
end interface<br />
<br />
integer(c_int) :: res<br />
type(c_ptr) :: data<br />
real(c_double), pointer :: fdata(:)<br />
integer(c_int) :: numel<br />
<br />
res = octave_load (c_char_'data.txt' // c_null_char, data, numel)<br />
<br />
call c_f_pointer (data, fdata, (/numel/))<br />
<br />
write (*,*) fdata<br />
<br />
end program octave_file_io_example<br />
</syntaxhighlight>}}<br />
<br />
=== Compiling the code ===<br />
<br />
mkoctfile -I. octave_file_io.cc <br />
mkoctfile -I. --mkoctfile --link-stand-alone octave_file_io_example.f90 octave_file_io.o -o octave_file_io_example<br />
<br />
[[Category:Examples]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Fortran&diff=13247Fortran2020-07-13T05:02:53Z<p>Siko1056: /* Fortran Code */ Update Fortran code.</p>
<hr />
<div>This page describes an example of how to call liboctave functions from a Fortran program.<br />
In the example we will load an Octave array from a file in Octave's native ASCII format,<br />
it consists of two steps:<br />
<br />
* write a C++ function with a C compatible interface and C linkage that reads a variable from an Octave ASCII file<br />
* write Fortran code using the "iso_c_binding" intrinsic module to call the C++ function<br />
<br />
=== C++ function ===<br />
<br />
C++ function to load a single matrix, stored in ASCII format, from a data file.<br />
<br />
{{File|octave_file_io.cc|<syntaxhighlight lang="C++"><br />
// Octave header<br />
#include <octave/oct.h><br />
#include <octave/ls-mat-ascii.h><br />
<br />
// Custom header containing the C compatible interface<br />
#include <octave_file_io.h><br />
<br />
//! Load a single matrix, stored in ASCII format, from a data file.<br />
//!<br />
//! @param file_name name of the data file.<br />
//! @param data pointer to the read-in matrix stored as fortran vector<br />
//! (column-major order).<br />
//! @param numel number of elements in @p data.<br />
<br />
int octave_load (const char* file_name, double** data, int* numel)<br />
{<br />
// Define variable to hold the read data.<br />
octave_value read_data;<br />
<br />
// Read a plain ASCII matrix from data file.<br />
std::ifstream in_file_stream (file_name, std::ios::binary);<br />
read_mat_ascii_data (in_file_stream, file_name, read_data);<br />
in_file_stream.close ();<br />
<br />
// Convert read data to numerical array (matrix).<br />
NDArray A = read_data.array_value ();<br />
<br />
// Extract number of elements in matrix A.<br />
*numel = A.numel ();<br />
<br />
// Allocate memory to pointer to returned values.<br />
*data = (double*) malloc (A.numel () * sizeof (double));<br />
<br />
// Copy the content of matrix A to data structure Fortran can handle.<br />
memcpy (*data, A.fortran_vec (), A.numel () * sizeof (double));<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight>}}<br />
<br />
=== Header file ===<br />
<br />
Header file with C interface to {{Path|octave_file_io.cc}}.<br />
<br />
{{File|octave_file_io.h|<syntaxhighlight lang="C" style="font-size:13px"><br />
#ifndef OCTAVE_FILE_IO_H<br />
#define OCTAVE_FILE_IO_H<br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int octave_load (const char* filename, const char* varname, double** data, int* numel);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
<br />
#endif<br />
</syntaxhighlight>}}<br />
<br />
=== Fortran Code ===<br />
<br />
Fortran main program to read the plain ASCII matrix with the help of the Octave-C++ function. The read in matrix is printed to the screen.<br />
<br />
{{File|octave_file_io_example.f90|<syntaxhighlight lang="fortran"><br />
program octave_file_io_example<br />
<br />
use iso_c_binding<br />
<br />
implicit none<br />
<br />
interface<br />
function octave_load (filename, data, numel) bind(c, name="octave_load")<br />
<br />
use iso_c_binding<br />
implicit none<br />
<br />
integer(c_int) :: octave_load<br />
<br />
character(kind=c_char), intent(in) :: filename(*)<br />
<br />
type(c_ptr), intent(out) :: data<br />
integer(c_int), intent(out) :: numel<br />
<br />
end function octave_load<br />
end interface<br />
<br />
integer(c_int) :: res<br />
type(c_ptr) :: data<br />
real(c_double), pointer :: fdata(:)<br />
integer(c_int) :: numel<br />
<br />
res = octave_load (c_char_'data.txt' // c_null_char, data, numel)<br />
<br />
call c_f_pointer (data, fdata, (/numel/))<br />
<br />
write (*,*) fdata<br />
<br />
end program octave_file_io_example<br />
</syntaxhighlight>}}<br />
<br />
=== Compiling the code ===<br />
<br />
mkoctfile -I. octave_file_io.cc <br />
mkoctfile -I. --mkoctfile --link-stand-alone octave_file_io_example.f90 octave_file_io.o -o octave_file_io_example<br />
<br />
[[Category:Examples]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Fortran&diff=13246Fortran2020-07-13T05:00:32Z<p>Siko1056: /* Header file */ Update.</p>
<hr />
<div>This page describes an example of how to call liboctave functions from a Fortran program.<br />
In the example we will load an Octave array from a file in Octave's native ASCII format,<br />
it consists of two steps:<br />
<br />
* write a C++ function with a C compatible interface and C linkage that reads a variable from an Octave ASCII file<br />
* write Fortran code using the "iso_c_binding" intrinsic module to call the C++ function<br />
<br />
=== C++ function ===<br />
<br />
C++ function to load a single matrix, stored in ASCII format, from a data file.<br />
<br />
{{File|octave_file_io.cc|<syntaxhighlight lang="C++"><br />
// Octave header<br />
#include <octave/oct.h><br />
#include <octave/ls-mat-ascii.h><br />
<br />
// Custom header containing the C compatible interface<br />
#include <octave_file_io.h><br />
<br />
//! Load a single matrix, stored in ASCII format, from a data file.<br />
//!<br />
//! @param file_name name of the data file.<br />
//! @param data pointer to the read-in matrix stored as fortran vector<br />
//! (column-major order).<br />
//! @param numel number of elements in @p data.<br />
<br />
int octave_load (const char* file_name, double** data, int* numel)<br />
{<br />
// Define variable to hold the read data.<br />
octave_value read_data;<br />
<br />
// Read a plain ASCII matrix from data file.<br />
std::ifstream in_file_stream (file_name, std::ios::binary);<br />
read_mat_ascii_data (in_file_stream, file_name, read_data);<br />
in_file_stream.close ();<br />
<br />
// Convert read data to numerical array (matrix).<br />
NDArray A = read_data.array_value ();<br />
<br />
// Extract number of elements in matrix A.<br />
*numel = A.numel ();<br />
<br />
// Allocate memory to pointer to returned values.<br />
*data = (double*) malloc (A.numel () * sizeof (double));<br />
<br />
// Copy the content of matrix A to data structure Fortran can handle.<br />
memcpy (*data, A.fortran_vec (), A.numel () * sizeof (double));<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight>}}<br />
<br />
=== Header file ===<br />
<br />
Header file with C interface to {{Path|octave_file_io.cc}}.<br />
<br />
{{File|octave_file_io.h|<syntaxhighlight lang="C" style="font-size:13px"><br />
#ifndef OCTAVE_FILE_IO_H<br />
#define OCTAVE_FILE_IO_H<br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int octave_load (const char* filename, const char* varname, double** data, int* numel);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
<br />
#endif<br />
</syntaxhighlight>}}<br />
<br />
=== Fortran Code ===<br />
<br />
{{Code|octave_file_io_example.f90|<syntaxhighlight lang="fortran" style="font-size:13px"><br />
program octave_file_io_example<br />
<br />
use iso_c_binding<br />
<br />
implicit none<br />
<br />
interface <br />
function octave_load (filename, varname, data, numel) bind(c, name="octave_load")<br />
<br />
use iso_c_binding<br />
implicit none<br />
<br />
integer(c_int) :: octave_load<br />
<br />
character(kind=c_char), intent(in) :: filename(*)<br />
character(kind=c_char), intent(in) :: varname(*)<br />
<br />
type(c_ptr), intent(out) :: data<br />
integer(c_int), intent(out) :: numel<br />
<br />
end function octave_load<br />
end interface<br />
<br />
integer(c_int) :: res <br />
type(c_ptr) :: data<br />
real(c_double), pointer :: fdata(:)<br />
integer(c_int) :: numel<br />
<br />
res = octave_load (c_char_'pippo.octxt' // c_null_char, c_char_'A' // c_null_char, data, numel)<br />
<br />
call c_f_pointer (data, fdata, (/numel/))<br />
<br />
write (*,*) fdata<br />
<br />
end program octave_file_io_example<br />
</syntaxhighlight>}}<br />
<br />
<br />
<br />
<br />
=== Compiling the code ===<br />
<br />
mkoctfile -I. octave_file_io.cc <br />
mkoctfile -I. --mkoctfile --link-stand-alone octave_file_io_example.f90 octave_file_io.o -o octave_file_io_example<br />
<br />
[[Category:Examples]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Fortran&diff=13245Fortran2020-07-13T04:59:13Z<p>Siko1056: /* C++ function */</p>
<hr />
<div>This page describes an example of how to call liboctave functions from a Fortran program.<br />
In the example we will load an Octave array from a file in Octave's native ASCII format,<br />
it consists of two steps:<br />
<br />
* write a C++ function with a C compatible interface and C linkage that reads a variable from an Octave ASCII file<br />
* write Fortran code using the "iso_c_binding" intrinsic module to call the C++ function<br />
<br />
=== C++ function ===<br />
<br />
C++ function to load a single matrix, stored in ASCII format, from a data file.<br />
<br />
{{File|octave_file_io.cc|<syntaxhighlight lang="C++"><br />
// Octave header<br />
#include <octave/oct.h><br />
#include <octave/ls-mat-ascii.h><br />
<br />
// Custom header containing the C compatible interface<br />
#include <octave_file_io.h><br />
<br />
//! Load a single matrix, stored in ASCII format, from a data file.<br />
//!<br />
//! @param file_name name of the data file.<br />
//! @param data pointer to the read-in matrix stored as fortran vector<br />
//! (column-major order).<br />
//! @param numel number of elements in @p data.<br />
<br />
int octave_load (const char* file_name, double** data, int* numel)<br />
{<br />
// Define variable to hold the read data.<br />
octave_value read_data;<br />
<br />
// Read a plain ASCII matrix from data file.<br />
std::ifstream in_file_stream (file_name, std::ios::binary);<br />
read_mat_ascii_data (in_file_stream, file_name, read_data);<br />
in_file_stream.close ();<br />
<br />
// Convert read data to numerical array (matrix).<br />
NDArray A = read_data.array_value ();<br />
<br />
// Extract number of elements in matrix A.<br />
*numel = A.numel ();<br />
<br />
// Allocate memory to pointer to returned values.<br />
*data = (double*) malloc (A.numel () * sizeof (double));<br />
<br />
// Copy the content of matrix A to data structure Fortran can handle.<br />
memcpy (*data, A.fortran_vec (), A.numel () * sizeof (double));<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight>}}<br />
<br />
=== Header file ===<br />
<br />
{{Code|octave_file_io.h: header file with C interface to octave_file_io.cc|<syntaxhighlight lang="C" style="font-size:13px"><br />
#ifndef OCTAVE_FILE_IO_H<br />
#define OCTAVE_FILE_IO_H<br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int octave_load (const char* filename, const char* varname, double** data, int* numel);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
<br />
#endif<br />
</syntaxhighlight>}}<br />
<br />
<br />
=== Fortran Code ===<br />
<br />
{{Code|octave_file_io_example.f90|<syntaxhighlight lang="fortran" style="font-size:13px"><br />
program octave_file_io_example<br />
<br />
use iso_c_binding<br />
<br />
implicit none<br />
<br />
interface <br />
function octave_load (filename, varname, data, numel) bind(c, name="octave_load")<br />
<br />
use iso_c_binding<br />
implicit none<br />
<br />
integer(c_int) :: octave_load<br />
<br />
character(kind=c_char), intent(in) :: filename(*)<br />
character(kind=c_char), intent(in) :: varname(*)<br />
<br />
type(c_ptr), intent(out) :: data<br />
integer(c_int), intent(out) :: numel<br />
<br />
end function octave_load<br />
end interface<br />
<br />
integer(c_int) :: res <br />
type(c_ptr) :: data<br />
real(c_double), pointer :: fdata(:)<br />
integer(c_int) :: numel<br />
<br />
res = octave_load (c_char_'pippo.octxt' // c_null_char, c_char_'A' // c_null_char, data, numel)<br />
<br />
call c_f_pointer (data, fdata, (/numel/))<br />
<br />
write (*,*) fdata<br />
<br />
end program octave_file_io_example<br />
</syntaxhighlight>}}<br />
<br />
<br />
<br />
<br />
=== Compiling the code ===<br />
<br />
mkoctfile -I. octave_file_io.cc <br />
mkoctfile -I. --mkoctfile --link-stand-alone octave_file_io_example.f90 octave_file_io.o -o octave_file_io_example<br />
<br />
[[Category:Examples]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Fortran&diff=13244Fortran2020-07-13T04:58:40Z<p>Siko1056: /* C++ function */ Use file template.</p>
<hr />
<div>This page describes an example of how to call liboctave functions from a Fortran program.<br />
In the example we will load an Octave array from a file in Octave's native ASCII format,<br />
it consists of two steps:<br />
<br />
* write a C++ function with a C compatible interface and C linkage that reads a variable from an Octave ASCII file<br />
* write Fortran code using the "iso_c_binding" intrinsic module to call the C++ function<br />
<br />
=== C++ function ===<br />
<br />
{{File|octave_file_io.cc|C++ function to load a single matrix, stored in ASCII format, from a data file.|<syntaxhighlight lang="C++"><br />
// Octave header<br />
#include <octave/oct.h><br />
#include <octave/ls-mat-ascii.h><br />
<br />
// Custom header containing the C compatible interface<br />
#include <octave_file_io.h><br />
<br />
//! Load a single matrix, stored in ASCII format, from a data file.<br />
//!<br />
//! @param file_name name of the data file.<br />
//! @param data pointer to the read-in matrix stored as fortran vector<br />
//! (column-major order).<br />
//! @param numel number of elements in @p data.<br />
<br />
int octave_load (const char* file_name, double** data, int* numel)<br />
{<br />
// Define variable to hold the read data.<br />
octave_value read_data;<br />
<br />
// Read a plain ASCII matrix from data file.<br />
std::ifstream in_file_stream (file_name, std::ios::binary);<br />
read_mat_ascii_data (in_file_stream, file_name, read_data);<br />
in_file_stream.close ();<br />
<br />
// Convert read data to numerical array (matrix).<br />
NDArray A = read_data.array_value ();<br />
<br />
// Extract number of elements in matrix A.<br />
*numel = A.numel ();<br />
<br />
// Allocate memory to pointer to returned values.<br />
*data = (double*) malloc (A.numel () * sizeof (double));<br />
<br />
// Copy the content of matrix A to data structure Fortran can handle.<br />
memcpy (*data, A.fortran_vec (), A.numel () * sizeof (double));<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight>}}<br />
<br />
=== Header file ===<br />
<br />
{{Code|octave_file_io.h: header file with C interface to octave_file_io.cc|<syntaxhighlight lang="C" style="font-size:13px"><br />
#ifndef OCTAVE_FILE_IO_H<br />
#define OCTAVE_FILE_IO_H<br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int octave_load (const char* filename, const char* varname, double** data, int* numel);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
<br />
#endif<br />
</syntaxhighlight>}}<br />
<br />
<br />
=== Fortran Code ===<br />
<br />
{{Code|octave_file_io_example.f90|<syntaxhighlight lang="fortran" style="font-size:13px"><br />
program octave_file_io_example<br />
<br />
use iso_c_binding<br />
<br />
implicit none<br />
<br />
interface <br />
function octave_load (filename, varname, data, numel) bind(c, name="octave_load")<br />
<br />
use iso_c_binding<br />
implicit none<br />
<br />
integer(c_int) :: octave_load<br />
<br />
character(kind=c_char), intent(in) :: filename(*)<br />
character(kind=c_char), intent(in) :: varname(*)<br />
<br />
type(c_ptr), intent(out) :: data<br />
integer(c_int), intent(out) :: numel<br />
<br />
end function octave_load<br />
end interface<br />
<br />
integer(c_int) :: res <br />
type(c_ptr) :: data<br />
real(c_double), pointer :: fdata(:)<br />
integer(c_int) :: numel<br />
<br />
res = octave_load (c_char_'pippo.octxt' // c_null_char, c_char_'A' // c_null_char, data, numel)<br />
<br />
call c_f_pointer (data, fdata, (/numel/))<br />
<br />
write (*,*) fdata<br />
<br />
end program octave_file_io_example<br />
</syntaxhighlight>}}<br />
<br />
<br />
<br />
<br />
=== Compiling the code ===<br />
<br />
mkoctfile -I. octave_file_io.cc <br />
mkoctfile -I. --mkoctfile --link-stand-alone octave_file_io_example.f90 octave_file_io.o -o octave_file_io_example<br />
<br />
[[Category:Examples]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Fortran&diff=13243Fortran2020-07-13T04:57:17Z<p>Siko1056: /* C++ function */ Fix syntax highlight.</p>
<hr />
<div>This page describes an example of how to call liboctave functions from a Fortran program.<br />
In the example we will load an Octave array from a file in Octave's native ASCII format,<br />
it consists of two steps:<br />
<br />
* write a C++ function with a C compatible interface and C linkage that reads a variable from an Octave ASCII file<br />
* write Fortran code using the "iso_c_binding" intrinsic module to call the C++ function<br />
<br />
=== C++ function ===<br />
<br />
{{Code|octave_file_io.cc: C++ function to load a matrix from an ASCII file in Octave native format|<syntaxhighlight lang="C++"><br />
// Octave header<br />
#include <octave/oct.h><br />
#include <octave/ls-mat-ascii.h><br />
<br />
// Custom header containing the C compatible interface<br />
#include <octave_file_io.h><br />
<br />
//! Load a single matrix, stored in ASCII format, from a data file.<br />
//!<br />
//! @param file_name name of the data file.<br />
//! @param data pointer to the read-in matrix stored as fortran vector<br />
//! (column-major order).<br />
//! @param numel number of elements in @p data.<br />
<br />
int octave_load (const char* file_name, double** data, int* numel)<br />
{<br />
// Define variable to hold the read data.<br />
octave_value read_data;<br />
<br />
// Read a plain ASCII matrix from data file.<br />
std::ifstream in_file_stream (file_name, std::ios::binary);<br />
read_mat_ascii_data (in_file_stream, file_name, read_data);<br />
in_file_stream.close ();<br />
<br />
// Convert read data to numerical array (matrix).<br />
NDArray A = read_data.array_value ();<br />
<br />
// Extract number of elements in matrix A.<br />
*numel = A.numel ();<br />
<br />
// Allocate memory to pointer to returned values.<br />
*data = (double*) malloc (A.numel () * sizeof (double));<br />
<br />
// Copy the content of matrix A to data structure Fortran can handle.<br />
memcpy (*data, A.fortran_vec (), A.numel () * sizeof (double));<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight>}}<br />
<br />
=== Header file ===<br />
<br />
{{Code|octave_file_io.h: header file with C interface to octave_file_io.cc|<syntaxhighlight lang="C" style="font-size:13px"><br />
#ifndef OCTAVE_FILE_IO_H<br />
#define OCTAVE_FILE_IO_H<br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int octave_load (const char* filename, const char* varname, double** data, int* numel);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
<br />
#endif<br />
</syntaxhighlight>}}<br />
<br />
<br />
=== Fortran Code ===<br />
<br />
{{Code|octave_file_io_example.f90|<syntaxhighlight lang="fortran" style="font-size:13px"><br />
program octave_file_io_example<br />
<br />
use iso_c_binding<br />
<br />
implicit none<br />
<br />
interface <br />
function octave_load (filename, varname, data, numel) bind(c, name="octave_load")<br />
<br />
use iso_c_binding<br />
implicit none<br />
<br />
integer(c_int) :: octave_load<br />
<br />
character(kind=c_char), intent(in) :: filename(*)<br />
character(kind=c_char), intent(in) :: varname(*)<br />
<br />
type(c_ptr), intent(out) :: data<br />
integer(c_int), intent(out) :: numel<br />
<br />
end function octave_load<br />
end interface<br />
<br />
integer(c_int) :: res <br />
type(c_ptr) :: data<br />
real(c_double), pointer :: fdata(:)<br />
integer(c_int) :: numel<br />
<br />
res = octave_load (c_char_'pippo.octxt' // c_null_char, c_char_'A' // c_null_char, data, numel)<br />
<br />
call c_f_pointer (data, fdata, (/numel/))<br />
<br />
write (*,*) fdata<br />
<br />
end program octave_file_io_example<br />
</syntaxhighlight>}}<br />
<br />
<br />
<br />
<br />
=== Compiling the code ===<br />
<br />
mkoctfile -I. octave_file_io.cc <br />
mkoctfile -I. --mkoctfile --link-stand-alone octave_file_io_example.f90 octave_file_io.o -o octave_file_io_example<br />
<br />
[[Category:Examples]]</div>Siko1056https://wiki.octave.org/wiki/index.php?title=Fortran&diff=13242Fortran2020-07-13T04:56:44Z<p>Siko1056: /* C++ function */ Update function to work with Octave 5.2.0+</p>
<hr />
<div>This page describes an example of how to call liboctave functions from a Fortran program.<br />
In the example we will load an Octave array from a file in Octave's native ASCII format,<br />
it consists of two steps:<br />
<br />
* write a C++ function with a C compatible interface and C linkage that reads a variable from an Octave ASCII file<br />
* write Fortran code using the "iso_c_binding" intrinsic module to call the C++ function<br />
<br />
=== C++ function ===<br />
<br />
{{Code|octave_file_io.cc: C++ function to load a matrix from an ASCII file in Octave native format|<syntaxhighlight lang="CC"><br />
// Octave header<br />
#include <octave/oct.h><br />
#include <octave/ls-mat-ascii.h><br />
<br />
// Custom header containing the C compatible interface<br />
#include <octave_file_io.h><br />
<br />
//! Load a single matrix, stored in ASCII format, from a data file.<br />
//!<br />
//! @param file_name name of the data file.<br />
//! @param data pointer to the read-in matrix stored as fortran vector<br />
//! (column-major order).<br />
//! @param numel number of elements in @p data.<br />
<br />
int octave_load (const char* file_name, double** data, int* numel)<br />
{<br />
// Define variable to hold the read data.<br />
octave_value read_data;<br />
<br />
// Read a plain ASCII matrix from data file.<br />
std::ifstream in_file_stream (file_name, std::ios::binary);<br />
read_mat_ascii_data (in_file_stream, file_name, read_data);<br />
in_file_stream.close ();<br />
<br />
// Convert read data to numerical array (matrix).<br />
NDArray A = read_data.array_value ();<br />
<br />
// Extract number of elements in matrix A.<br />
*numel = A.numel ();<br />
<br />
// Allocate memory to pointer to returned values.<br />
*data = (double*) malloc (A.numel () * sizeof (double));<br />
<br />
// Copy the content of matrix A to data structure Fortran can handle.<br />
memcpy (*data, A.fortran_vec (), A.numel () * sizeof (double));<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight>}}<br />
<br />
=== Header file ===<br />
<br />
{{Code|octave_file_io.h: header file with C interface to octave_file_io.cc|<syntaxhighlight lang="C" style="font-size:13px"><br />
#ifndef OCTAVE_FILE_IO_H<br />
#define OCTAVE_FILE_IO_H<br />
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
int octave_load (const char* filename, const char* varname, double** data, int* numel);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
<br />
#endif<br />
</syntaxhighlight>}}<br />
<br />
<br />
=== Fortran Code ===<br />
<br />
{{Code|octave_file_io_example.f90|<syntaxhighlight lang="fortran" style="font-size:13px"><br />
program octave_file_io_example<br />
<br />
use iso_c_binding<br />
<br />
implicit none<br />
<br />
interface <br />
function octave_load (filename, varname, data, numel) bind(c, name="octave_load")<br />
<br />
use iso_c_binding<br />
implicit none<br />
<br />
integer(c_int) :: octave_load<br />
<br />
character(kind=c_char), intent(in) :: filename(*)<br />
character(kind=c_char), intent(in) :: varname(*)<br />
<br />
type(c_ptr), intent(out) :: data<br />
integer(c_int), intent(out) :: numel<br />
<br />
end function octave_load<br />
end interface<br />
<br />
integer(c_int) :: res <br />
type(c_ptr) :: data<br />
real(c_double), pointer :: fdata(:)<br />
integer(c_int) :: numel<br />
<br />
res = octave_load (c_char_'pippo.octxt' // c_null_char, c_char_'A' // c_null_char, data, numel)<br />
<br />
call c_f_pointer (data, fdata, (/numel/))<br />
<br />
write (*,*) fdata<br />
<br />
end program octave_file_io_example<br />
</syntaxhighlight>}}<br />
<br />
<br />
<br />
<br />
=== Compiling the code ===<br />
<br />
mkoctfile -I. octave_file_io.cc <br />
mkoctfile -I. --mkoctfile --link-stand-alone octave_file_io_example.f90 octave_file_io.o -o octave_file_io_example<br />
<br />
[[Category:Examples]]</div>Siko1056