I need to use the CobraToolbox for a course and I am wondering if it is compatible with Octave.
Even googling for this doesn't return much results..
Thanks in advance
Unless someone has published their results, you can't know without trying it. However, there is a very high likelihood that it will work on Octave, here's what Jordi has to say on this issue answering this question.
I am new to Octave and was wondering if it is possible to use matlab
toolboxes in Octave?
It depends on what you mean by "Matlab toolbox". If you mean the code
that came with Matlab, it's probably a license violation to use it
with Octave, assuming you can compile it for Octave when it's
necessary to compile.
If you mean free code out there you found on the internet that was
written for Matlab, it is likely it will work on Octave. Just try it.
If you need to compile mex files, the "mkoctfile --mex" command may be
of use.
If you want to have a rough equivalent of the Matlab toolboxes in
Octave, try the Octave-Forge packages:
My personal experience is that Octave has become extremely good at accepting Matlab code. I would hazard a guess that any time you spend setting up Octave and this toolbox will be worth it. Even the MEX files appear to have a portability mechanism. Unless they are using some very specific features like addpref for toolbox persistent data, it will slide right into Octave. Even if they are using the prefs, it could be modified to live in Octave.
Related
I have a couple questions about adding options/switches (with and without parameters) to procedures/commands. I see that tcllib has cmdline and Ashok Nadkarni's book on Tcl recommends the parse_args package and states that using Tcl to handle the arguments is much slower than this package using C. The Nov. 2016 paper on parse_args states that Tcl script methods are or can be 50 times slower.
Are Tcl methods really signicantly slower? Is there some minimum threshold number of options to be reached before using a package?
Is there any reason to use parse_args (not in tcllib) over cmdline (in tcllib)?
Can both be easily included in a starkit?
Is this included in 8.7a now? (I'd like to use 8.7a but I'm using Manjaro Linux and am afraid that adding it outside the package manager will cause issues that I won't know how to resolve or even just "undo").
Thank you for considering my questions.
Are Tcl methods really signicantly slower? Is there some minimum threshold number of options to be reached before using a package?
Potentially. Procedures have overhead to do with managing the stack frame and so on, and code implemented in C can avoid a number of overheads due to the way values are managed in current Tcl implementations. The difference is much more profound for numeric code than for string-based code, as the cost of boxing and unboxing numeric values is quite significant (strings are always boxed in all languages).
As for which is the one to use, it really depends on the details as you are trading off flexibility for speed. I've never known it be a problem for command line parsing.
(If you ask me, fifty options isn't really that many, except that it's quite a lot to pass on an actual command line. It might be easier to design a configuration file format — perhaps a simple Tcl script! — and then to just pass the name of that in as the actual argument.)
Is there any reason to use parse_args (not in tcllib) over cmdline (in tcllib)?
Performance? Details of how you describe things to the parser?
Can both be easily included in a starkit?
As long as any C code is built with Tcl stubs enabled (typically not much more than define USE_TCL_STUBS and link against the stub library) then it can go in a starkit as a loadable library. Using the stubbed build means that the compiled code doesn't assume exactly which version of the Tcl library is present or what its path is; those are assumptions that are usually wrong with a starkit.
Tcl-implemented packages can always go in a starkit. Hybrid packages need a little care for their C parts, but are otherwise pretty easy.
Many packages either always build in stubbed mode or have a build configuration option to do so.
Is this included in 8.7a now? (I'd like to use 8.7a but I'm using Manjaro Linux and am afraid that adding it outside the package manager will cause issues that I won't know how to resolve or even just "undo").
We think we're about a month from the feature freeze for 8.7, and builds seem stable in automated testing so the beta phase will probably be fairly short. The list of what's in can be found here (filter for 8.7 and Final). However, bear in mind that we tend to feel that if code can be done in an extension then there's usually no desperate need for it to be in Tcl itself.
Does anyone ever succeeded in installing MAtConvNet under Octave ?
If so could you please let me know the steps to proceed ?
thanks and regards
Arno
I was just looking into this issue myself. I have reached a point in researching this where I feel the issues are too complicated for my own project and are not worth my time trying to finish running down. However, if someone else is determined to track this down, hopefully this information will help.
The basic problem comes down Octave only compiling to support 32-bit architectures even if you use the 64-bit installer. If you want Octave to support 64-bit, you need to compile from source using the appropriate compiling options. The other details are as follows.
MatConvNet appears to require a 64-bit system to compile.
http://www.vlfeat.org/matconvnet/mfiles/vl_compilenn/
MatConvNet detects system architecture in in the mex_cuda_config function in vl_compilenn.m:
https://github.com/vlfeat/matconvnet/blob/master/matlab/vl_compilenn.m
Octave's computer function is not a perfect analog to Matlab's function, so the mex_cuda_config function in vl_compilenn.m would need to be modified or Octave's computer function would need to be updated. More specifically, the computer function's handling of the 'arch' argument needs to be changed.
There may be other issues, but this is where I would start if I had the time to invest in trying to track this down.
At first I was excited about working on open development projects for Octave related to implementing programs heavy in mathematics and physics, such as delaunayTriangulation class, but after talking to a few octave maintainers I have come to the sad conclusion that Octave will be complete after classdef is complete, at which point physics or mathematician like programmers will no longer be needed to build new functionality to Octave. Is this true?
I have followed your thread on the Octave maintainers mailing list and I think you have misunderstood this quite badly.
Once classdef gets implemented, the problems won't be solved, quite the contrary. It will allow for many problems to be solved, which can't be done just yet in a Matlab compatible way. There are 2 things here:
you may have felt that there's no problems left to solve after seeing many suggestions of libraries that already solve the problem. That doesn't mean they will be used. Even if licensing allows it, there comes a point where having to "reshape" the data in Octave into whatever form the other library uses it, is just too much and a native interface is preferred. This is specially true in Octave because it's mostly written in the Octave language which allows for users to participate in its development.
Even if an external library is used in the end, remember that "the devil is in the details". Implementing an interface between Octave and an external library is not a trivial problem.
When classdef is complete, the work will start, not finish. And classdef is already working on the development version, so if you are interested in those classes, you could start implementing them there and they'd be released with the next version. To continue development of classdef, Octave needs that people it, so that it's problems can be found. And the delaunayTriangulation class requires classdef. It looks like a great pair, that should be developed together.
After quite a bit of searching and trying different things, I am stumped on how to get mym to work (as found here: http://sourceforge.net/projects/mym/). I was wondering if anyone has a very simple list of actions needed to get this to work. I think my main trouble is installing zlib. I don't understand how to actually install it or work with it. I have tried to use Microsoft Visual C++ Express 2010 but then only the debug versions are compiled. That means when I try to use the mex function in matlab it gives me the error:
Error: Could not detect a compiler on local system
which can compile the specified input file(s)
I just don't understand the process and everywhere I look it says something different. I have tried multiple versions of each all of the programs involved and nothing seems to work. Any help would be greatly appreciated.
Do:
mex -setup
from the command line to define your compiler on your system. Once you do that then Matlab will correctly locate the compiler and build the mex libraries it needs.
See:
http://www.mathworks.com/help/matlab/matlab_external/building-mex-files.html
I've started a project(developer text editor) in a interpreted language(Tcl/Tk) and another with Perl(both are open-source), but with some time, when it gets in a Beta version, I will need to distribute it for the users(developers of course), but I want to know some things about this:
It's possible to compile it to a executable?
How?
Can I compile for other platforms?
Or in this case it's better to use a compiled language or a interpreted?
Is usual things like this?
In the users machine, he will need to have Tcl/Tk or Perl?
Both Tcl and Perl can be compiled into executables. For windows, there's perl2exe and perlcc for systems running UNIX style operating systems. As for Tcl, there is freewrap and starpacks.
If you're just doing this for the benefit of a single executable, and eliminating the need for installing Perl and other dependencies, then there's no real reason you can't do this. It's quite a nice method for testing your application without having to constantly compile, though defeats the point of using an interpreted language in the first place.
Also take a look at The Simplest Steps to Converting TCL TK to a Stand Alone Application, this page is also useful, How can I compile Tcl type scripts into binary code
The usual and common way for such scripts is to distribute the source. A binary would only work on some very specific systems but Tcl/Tk/Perl runs on so many systems, so that would be a really big restriction for no real reason. It also helps other developers more to reuse your scripts in some good way. In most cases, even when somebody could execute your binary, it wouldn't be of much help without the source.