I have installed Octave 3.6.1 along with packages including "signal 1.1.2" but when i run a simple example of "sigmoid_train" function an error appears "sigmoid_train function is undefined".
Can any body tell me what is the problem?
The problem is that you didn't load the signal package. When you type pkg list you can find which ones are loaded by an asterisk in front of their names. Load a package with pkg load signal.
Having to load a packages is that thing that many users coming from Matlab find strange but if you compare with other languages, such as Python, Perl, or C++, would you expect them to import, use, or #include every libraries available in the system by default? See Octave's FAQ for more details.
If you want a package to be loaded automatically by default, the recommended action is to add the line pkg load signal to your ~/.octaverc file.
Finally, you have just started with Octave, you should had installed Octave 3.8.1.
Related
I have installed package image via pkg install -forge image and after tons of warnings (I am using clang as a C compiler, yeah, I know...) it finished installing.
I then loaded the package with ordinary pkg load image and Octave did not complain. But when I typed help viscircles to get some help on the function, Octave behaved like there was no package image, meaning it returned
>> help viscircles
error: help: the 'viscircles' function belongs to the image package
from Octave Forge but has not yet been implemented.
Please read <http://www.octave.org/missing.html> to learn how you can
contribute missing functionality.
Now I executed the pkg list to see if the package was indeed installed and loaded and yes, it was (there was an asterisk next to image package, which indicates that the certain package is loaded).
I decided to unload all packages and so I did. Now, before loading image again, I executed help viscircles again, but this time I got the next error:
>> help viscircles
error: help: the 'viscircles' function belongs to the image package
from Octave Forge which you have installed but not loaded. To load the
package, run 'pkg load image' from the Octave prompt.
Interesting... I loaded the package again and same problem as before. I also downloaded the package manually and reinstalled it, same problems.
And yes, I have Octave 4.0.2, the requirements for image 2.6.2 is version 4.0.0+.
The function viscircles is on development versions of the image package only. It is not part of the current release, version 2.6.2 which you have installed.
The error message:
>> help viscircles
error: help: the 'viscircles' function belongs to the image package
from Octave Forge which you have installed but not loaded. To load the
package, run 'pkg load image' from the Octave prompt.
means that the function is not part of Octave and if it is to exist at all, it will be on the image package. It doesn't mean that the image package will actually have it, only that it belongs to it. The error message you get after loading the package:
>> help viscircles
error: help: the 'viscircles' function belongs to the image package
from Octave Forge but has not yet been implemented.
Please read <http://www.octave.org/missing.html> to learn how you can
contribute missing functionality.
tells you the issue. The function viscircles is not implemented on that version of the package.
You can get it from the mercurial repository of the image package though at 75df28049249. Not sure if it will work on Octave 4.0 though.
Situation
I work with Ubuntu 14.04. I am building GNU Octave 4.2.1 from source with GNU 6.3.0. This version of Octave is quite new, but I see the issue arising also when trying to compile older Octave releases (down to 3.8.1).
I configure the build of Octave with
${sourcedir}/configure --prefix=/opt/octave/4.2.1 \
--with-java-homedir=/usr/lib/jvm/default-java \
--with-java-libdir=/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server
Issue
The compilation is successful but the undesired warning shows up
configure: WARNING: ARPACK library found, but does not seem to work properly; disabling eigs function
I would rather like to have the eigs() function in place.
Information
I have built ARPACK-ng myself with the same compiler. All tests in the test suite (make check) are passed. The environment variables LD_LIBRARY_PATH and PKG_CONFIG_PATH point to the ARPACK library directory as intended. The configure file of Octave recognizes that location correctly, as seen before.
Besides, I get the same message if I compile Octave in another computer where ARPACK is installed natively (libarpack2 and libarpack2-dev version 3.1.5-2). It does not change a thing if I also install the related extra libraries libarpack++2c2a and libarpack++2-dev using the package repository. So the issue appears to be independent of the origin of the ARPACK files.
The part of the configure.ac file of Octave that throws this error is
### Check for ARPACK library.
save_LIBS="$LIBS"
LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS"
OCTAVE_CHECK_LIB([arpack], ARPACK,
[ARPACK not found. The eigs function will be disabled.],
[],
[dseupd],
[Fortran 77], [don't use the ARPACK library, disable eigs function],
[warn_arpack=
OCTAVE_CHECK_LIB_ARPACK_OK(
[AC_DEFINE(HAVE_ARPACK, 1, [Define to 1 if ARPACK is available.])],
[warn_arpack="ARPACK library found, but does not seem to work properly; disabling eigs function"])])
LIBS="$save_LIBS"
The farthest I go in tracing back the issue is that the subroutine OCTAVE_CHECK_LIB_ARPACK_OK issuing the warning lives in the file ${octave_source}/m4/acinclude.m4. It is written in m4 language, which I don't know
Question
Is it possible to understand why ARPACK 'does not seem to work properly'?
Is there any workaround for this?
Is this a false alarm or a bug?
I tried to use the tree package for TCL but I'm unable to find any documentation at all. When trying to run the examples from http://tcllib.sourceforge.net/doc/struct_tree.html, i get the error
can't find package struct::tree
Can anyone tell me how to include it in tcl 8.5?
The struct::tree package is part of Tcllib.
If you are using ActiveTcl, doing a teacup update (possibly with elevated permissions, depending on how you installed) will download a copy. I don't know whether all Linuxes have Tcllib done as an appropriate system package, but Debian does. Otherwise, there's a download link in on the main Tcllib page; Tcllib works just fine as a bunch of .tcl files that you include with your application code.
I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.
I want to interact with a MySQL database from Matlab.
I found a mysql "library" for matlab here and the same on mathworks.
I followed the instructions to compile the library and the compilation seems to be successful. I get a mex32 file at the end. Only, the instructions on the first page refer to a Dll that I need to use (I guess that a Dll was supposed to be generated).
I am not familiar with the mex compiler or with compiling external modules for Matlab.
Am I missing something trivial? Where is the Dll supposed to be?
Thanks.
The reference to the dll is obsolete.
When you compile a mex function on Windows, you compile it as a dll (not an .exe). Thus, compiled mex functions used to have the extension .dll. Mex-functions with .dll extensions still work, but there is a warning that this might stop being the case in the future.
When 64-bit Windows arrived, TheMathWorks needed a way that people were to be able to compile the same mex-function for both Win32 and Win64, thus they changed the extension to .mexw32 and .mexw64, respectively. Apparently, they did not update the documentation completely.
I'd recommend using java to connect MATLAB and MySQL (or any other db if required).
The java database connector is simple to set up. I built a simple java class to connect to the database - see previous posting for a crude but working solution.
The MATLAB code works as indicated
% include java class
import Jam.ConnectToDatabase
% set up database connection info
userName='myName';
userPassword='myPassword';
databaseUrl='jdbc:mysql://glnd2818898.internal.net/2000';
% create java class instance and open connection to the database
ctd = ConnectToDatabase;
ctd.openConnection(userName, userPassword, databaseUrl)
Once the connection is open I can then use the java methods to submit SQL queries, create tables, insert data etc. I'd never used java before but I downloaded Netbeans and I was away.
OK, here is the solution to my problem.
The compilation does generate a mex32 file (32 is because I compiled it under a 32bit systme). You can check the output file of the compilation by running mexext. So apparently a mex32 file is a compiled version of the C file.
Once I placed the file in a directory that is in the Matlab's path it worked.
I guess the reference to the Dll in the link I provided is either obsolete or wrong.