I'm trying to get the gfortran compiler working in MATLAB on Windows to create mex files. Gfortran isn't supported, but the Intel Fortran compiler is, which leads me to believe that a Fortran compiler should be able to compile Fortran source using MATLAB libraries.
As detailed in my previous question, I get an "undefined reference" error for every symbol that should come from the MATLAB libraries. I thought this was an error with the preprocessor not getting invoked as suggested in a question on MathWorks Answers, but after looking into this problem some more I don't believe that's the problem since the errors refer to things like "mxisnumeric800" which is a substitution made in the fintrf.h header.
I checked the symbols exported from the required libraries, libmx.dll and libmex.dll, using dumpbin. The exported symbols include two that are close to mxisnumeric800:
Section contains the following exports for libmx.dll
...
1431 596 0009F200 MXISNUMERIC800
...
1747 6D2 000ABC24 mxIsNumeric_800
...
I can understand why mxIsNumeric_800 wouldn't be read as the same symbol due to the extra underscore, but does capitalization make a difference too?
The problem you are having is that Fortran is a case insensitive language. So if you have a subroutine foo:
subroutine foo(x)
real :: x
end subroutine foo
you could call it with any of the following:
call foo(x)
call FOO(x)
call fOo(x)
When you build an object file or library with this function, the symbol name will be compiler dependent. In case of Gfortran on a Linux system, it will always downcase the symbol name and add an underscore behind it such as
foo_
On Windows Systems it will behave differently (see here and here), and even different compilers will have different ideas.
So what now, what does this all mean?
This means that when you write a subroutine call like:
call mxIsNumeric_800(arg1, arg2, arg3)
Gfortran will attempt to link it against a symbol mxisnumeric_800_ and not the symbol you expect. In the past, this often resulted into ugly hacks which were very not-portable. Fortran 2003, addressed this issue in a clear way by introducing the BIND attribute. An attribute which allows the programmer to inform the compiler that this object should be handled as a non-Fortran object (cfr. Section 15.5 of the F2008 standard).
With this attribute, you can now define an interface that is fully understood by Fortran and that the compiler knows where to find the corresponding symbol with its respective case-sensitivity. Eg.
interface
subroutine mxisnumeric(arg1,arg2,arg3) BIND(C, NAME="mxIsNumeric_800")
use, intrinsic :: iso_c_binding
implicit none
real(c_float) :: arg1
integer(c_int) :: arg2
character(c_char) :: arg3
end subroutine mxisnumeric
end interface
Some more details can be found here.
Related
According to https://www.mathworks.com/help/matlab/apiref/mxisclass.html
the return of mxIsDouble for Fortran (also mxIsSingle and mxIsClass) is INTEGER*4.
Here are my questions:
Should the declaration of mxIsDouble be always
INTEGER*4 :: mxIsDouble ?
What if I declare it as
INTEGER :: mxIsDouble
or
LOGICAL :: mxIsDouble ?
It is said that INTEGER*4 is not standard and should be replaced by kind. How should I do it? I know that INTEGER(KIND=4) is incorrect. In addition, why does mex continue to use such a nonstandard feature?
Background: I got these questions when writing a MATLAB interface for some Fortran legacy code. I am working on a 64 bit PC with Linux, yet I am aiming at writing portable mex files.
Thank you very much!
You should use INTEGER*4 because that is what matches the MATLAB API doc, regardless of it being non-standard. Don't use INTEGER because that might compile to a 64-bit integer depending on your settings and won't match the library function. Remember, you are linking to an already compiled library function that returns a 32-bit integer ... you are not recompiling the mxIsDouble function. E.g.,
INTEGER*4, external :: mxIsDouble
I think it highly unlikely MATLAB will ever change these functions to return anything other than a 32-bit integer, but I suppose you could create your own type for this so that the INTEGER*4 only appears at one place in your code.
In MATLAB, you can declare a function dependency with:
%#function myExtraFunctionName
Doing so tells MATLAB that myExtraFunctionName is required by the script or function to operate, even if it's called by an eval statement or some other method that the various dependency checkers or compilers can't figure out.
I have several files that load in .mat or other data files that are required for the script to run, and I would like to include them in a similar manner so that when I run a dependency check with, say fList = matlab.codetools.requiredFilesAndProducts, it will find these data files as well. Ultimately what I would like to be able to do is generate the list of files and pass it to zip to archive every file required to run a given script or function, including data files.
Trying to find any documentation on this feature is challenging because the MATLAB help won't let you just type in %# and searching for %#function just searches for function. Google does the same thing: "hash percent function" returns lots of information on hash tables, "%#function matlab" strips out the important characters, and "declare matlab function" "declare matlab function dependency" turns up nothing useful. I don't remember where I encountered this syntax, so I don't even know if this is a documented feature or not.
I have two questions:
Can someone point me to documentation on this syntax along with some clues as to what keywords I should be using to search?
Can this be used to declare dependencies other than m-files and, if not, how can I go about doing that?
%#function is a pragma directive that informs MATLAB Compiler that the specified function will be called indirectly using feval, eval, or the like.
This is important because the static code analyzer will not be able to detect such dependencies on its own. For instance the name of the function could be stored in a string as in:
fcn = 'myFunction';
feval(fcn)
As far as I know, this is only used by the MATLAB Compiler, nothing else.
There are other similar pragmas. For example MATLAB Coder has %#codegen compiler directive.
I don't have any answer, but maybe you can use this website:
http://www.symbolhound.com/
It let you do search using symbols.
In the Fortran program, is it possible to read an expression including the variables ?
For example, the input file is （if necessary, we can change the input form of the expression,e.g.,the binary form）,
2(a-4b)
It should be noted that the input expression has a very simple form and it only contains integer or fraction or some variables,like the following in the list,
{0,232,-2/5a,3a-b,b/9}
Here 2a means 2*a
The Fortran program is
Program test
implicit none
real(kind=8)::a,b,exp
a=10.
b=3.
! open file and read the input expression
! that is, exp=2*(a-4*b)
write(*,*) exp ! we can get exp=-4.0
end program
For the complicated expressions, it is obviously not a good idea for Fortran. I just want to know, in this simple input expression case, is it possible to find a better way ?
A site with tests of three expression evaluators in Fortran is http://www.angelfire.com/ab5/extensao/report.htm . Only the link to the "Brazilian" one works.
There is also a Sourceforge project fparser http://fparser.sourceforge.net/ .
Fortran cannot do this unless you write code that can parse the arbitrary expression, substitute and solve, which is a bit of work (see the comment below for details). Fortran is compiled and there is no way to load source on the fly, compile and run it, which is essentially what you are asking. You might look into a language such as Lisp where doing this is should be somewhat trivial. Likewise any scripted language will have facilities to evaluate code, which can do what you are asking.
In Python we have the del statement for deleting variables.
E.g:
a = 1
del a
What the equivalent of this in Lisp?
(setq foo 1)
;; (del foo) ?
In Common Lisp.
For symbols as variables:
CL-USER 7 > (setf foo 42)
42
CL-USER 8 > foo
42
CL-USER 9 > (makunbound 'foo)
FOO
CL-USER 10 > foo
Error: The variable FOO is unbound.
See:
MAKUNBOUND (defined)
SLOT-MAKUNBOUND (defined)
FMAKUNBOUND (defined)
Python names reside in namespaces, del removes a name from a namespace. Common Lisp has a different design, one much more sympathetic to compiling efficient code.
In common lisp we have two kinds of "variables." Lexical variables account for the majority of these. Lexical variables are analogous to a C local. At runtime a lexical variable usually is implemented as a bit of storage (on the stack say) and the association with it's name is retained only for debugging purposes. It doesn't really make any sense to talk about deleting lexical variables in the sense python uses because the closest analogy to python's namespace that exists for lexical variables is the lexical scope, and that purely an abstraction used by the spec and the compiler/evaluator.
The second variable kind of "variable" in CL are "global" symbols. Symbols are very rich data structures, much richer than a label in python. They can have lots of information associated with them, a value, a printed name, their "home" package, a function, and other arbitrary information stored in a list of properties. Most of these are optional. When you use a name in your source code, e.g. (+ X 3), that name X will usually denote a lexical symbol. But failing that the compiler/evaluator will assume you want the value of the "global" symbol. I.e. you effectively wrote (symbol-value 'X) rather than X. Because of typos, programming conventions, and other things some decades ago the compilers started complaining about references to "global" symbols in the absence of a declaration that signaled that the symbols was intended to be a "global." This declaration is known as "special." Yes it's a stupid bit of nomenclature. And worse, special variables aren't just global they also have a very useful feature known as dynamic binding - but that's another topic.
Symbols that are special are almost always declared using defvar, defparameter, or defconstant. There is a nearly mandatory coding convention that they are spelled uniquely, i.e. *X* rather than X. Some compilers, and most developers, will complain if you deviate from that convention.
Ok. So now we can get back to del. Special variables are denoted with a symbol; and this is analogous to how in python variables are denoted with a name. In python the names are looked up in the current namespace. In Common Lisp they are looked up in the current package. But when the lookup happens differs. In python it's done at runtime, since names can by dynamically added and removed as the program is running. In Common Lisp the names are looked up as the program is read from a file prior to compiling it. (There are exceptions but let's avoid thinking about those.)
You can remove a symbol from a package (see unintern). But this is an rare thing and is likely to just make your brain hurt. It is a simple operation but it get's confusing around the edges because the package system has a small dose of clever features which while very helpful take a bit of effort to become comfortable with. So, in a sense, the short answer to your question is that for global symbols the unintern is the analogous operation. But your probably doing something quite exceptional (and likely wrong) if your using that.
While what #Ben writes is true, my guess is that what you are looking for is makunbound, not unintern. The former does not remove the symbol from the obarray (for Emacs Lisp) or package (for Common Lisp). It just removes its symbol-value, that is, its value as a variable. If you want the behavior that trying to get the variable value results in a not-bound (aka void) error, then try makunbound.
I am not contradicting the previous answers but adding.
Consider that Lisp has garbage collection. As you know, you get a symbol defined in many ways: setf, defvar, defparameter, make-symbol, and a lot of other ways.
But how do you get a clean system? How do you make sure that you don't use a variable by mistake? For example, you defined abc, then later decided you don't want to use abc. Instead you want an abc-1 and an abc-2. And you want the Lisp system to signal error if you try to use abc. If you cannot somehow erase abc, then the system won't stop you by signalling "undefined" error.
The other answers basically tell you that Lisp does not provide a way to get rid of abc. You can use makunbound so that the symbol is fresh with no value assigned to it. And you can use unintern so that the symbol in not in any package. Yet boundp will tell you the symbol still exists.
So, I think that as long as no other symbol refers to abc, garbage collection will eventually get rid of abc. For example, (setf pt-to-abc abc). As long as pt-to-abc is still bound to the symbol abc, abc will continue to exist even with garbage collection.
The other way to really get rid of abc is to close Lisp and restart it. Doesn't seem so desirable. But I think that closing Lisp and starting fresh is what actually gets rid of all the symbols. Then you define the symbols you want.
You probably usually want makunbound, because then, the system will signal error if you try to add the value of abc to something else because abc won't have any value. And if you try to append abc to a string, the system will signal error because abc has no string. Etc.
i have a problem to using a dll fortran in matlab.
i couldn't use a dll ,that is built by fortran, in matlab. i use "loadlibrary" instruction in matlab but the error is related to header files.
what is header files??
please give me more information to load a dll fortran in matlab and call it.
Rather than try to use a dll file directly I suggest you re-build it using Matlab's MEX functionality. Yes, a mex file is a dll and you can build dlls outside Matlab and use them successfully, it's a lot easier, for a beginner such as I guess you to be, to use MEX. One way in which it is easier is that, if you build a mex file, the system won't ask you for a header file which is, as you know, a rather foreign concept to a Fortran programmer. Another way in which MEX will make your life easier is that you can then call the function exposed by the dll directly from Matlab's command line, without loadlibrary.
Study the Matlab documentation on MEX files, pay particular attention to how to integrate Fortran this way.
Without seeing your header file and the command line you're using in MATLAB, it's hard to help you too much here. You might reference the documentation in MATLAB which request that you pass two arguments to loadlibrary, the second being the header file with function signatures. I am guessing you are not providing this second argument.
You need to provide a header file that defines each of the named functions in the Fortran DLL that you'll be calling. For instance, if your DLL contains a function named sum that sums two double precision variables, like:
function sum(a,b) result(sum)
real(kind=2), intent(in) :: a, b
real(kind=2) :: sum
sum = a + b
end function
Then your header will need to contain something like:
double sum(double*a, double*b);
But don't forget to decorate this with the name mangling specific to your Fortran compiler. For instance, if sum was in a module named foo, and you compiled with gfortran, then you will need something like:
double __foo_MOD_sum(double*a, double*b);
There are a lot of other cases, but that's the gist of it.