I have a Fortran 95 code that I want to compile to a Python library using f2py. In a matter of fact I've already done it, and it works beautifully. Does the resulting .pyd (.so) depend on numpy after compilation? Could it be used without numpy installation and are they some other options to embed the needed parts inside the final library so it has no dependencies?
I am considering this to be a library accompanying a commercial product and I want the end user to have as little as possible to install on his system, so suggesting to my future customers to install numpy does not suit me. I've searched extensively for an answer, but I cannot seem to find one.
In case it is not possible, could you please refer me to a dependence free way to wrap Fortran code using Python.
I'm afraid there is no way of doing this without numpy, as f2py internally produces numpy dependencies.
Does your code need to be FORTRAN? If it could be C/C++ there might be a chance to get around dependencies, check out chapter 7 of this book for more insights on that.
On the website fortran90.org, there are sections dedicated to the Fortran C interface. While it is of course possible to use NumPy, plain C interfacing using iso_c_binding is certainly possible. And it is part of the standard!
See Interfacing with C and the following sections. The link refers to calling C from Fortran but is directly relevant nonetheless. The next section uses Cython for calling Fortran from Python "à la C" but uses NumPy. The part using ctypes uses no NumPy.
Note: you need a Fortran 2003 compiler. Fortran 95 code is of course legal Fortran 2003 so you can just add the wrapper/interface part to your code.
Related
I'm in the process of learning Cython and I wasn't able to find a direct answer to this. Also please bear with me as my understanding of C is limited as of now. As far as I understand, with the cythonize command, .pyx files are converted to C, and are compiled to platform-specific libraries (.so / .pxd). My questions are:
If .pyx files are fully converted to C, does it mean that these generated extensions are no longer dependent on python runtime after compilation?
Assuming the same host architecture, can these generated extensions be loaded into other languages, eg. via Java's JNI? If so, are there any hello world examples on this?
Cython extensions are fully C, but they heavily use the Python C API. This means they can't be run independent of libpython (and usually the Python standard library). However it is possible to load libpython into other languages and then use a Cython extension. Also bear in mind that anything you import within Cython is not compiled but needs to be available for import.
I don't plan to answer this fully, but both ImageJ (in Java) and Julia do support Python interoperability layers and do Cython extensions would work there. You're much better off searching for "Python-Java interoperability layer" than trying to create your own way of using Cython specifically.
I'm trying to wrap my head around the Python ecosystem and parts of it aren't making complete sense to me so far.
I'm coming from the Java world and when I want to make use of, say JUnit, I simply add the JUnit jar to my classpath and that's pretty much it. If I want to be nice to my users I can also easily bunch together all my dependencies into a single jar, so that all that they need to do is install a Java Runtime get a hold of my jar.
Reading through the SciPy installation guide I can't find an explanation for why all this is really necessary. And how is this ever going to work at deployment time? It's like JUnit asked me to install a new JRE just for them.
SciPy has parts written in C that require compilation for the specific platform it's being deployed too.
How can SciPy be fast if it is written in an interpreted language like Python?
Actually, the time-critical loops are usually implemented in C or
Fortran. Much of SciPy is a thin layer of code on top of the
scientific routines that are freely available at
http://www.netlib.org/. Netlib is a huge repository of incredibly
valuable and robust scientific algorithms written in C and Fortran. It
would be silly to rewrite these algorithms and would take years to
debug them. SciPy uses a variety of methods to generate “wrappers”
around these algorithms so that they can be used in Python. Some
wrappers were generated by hand coding them in C. The rest were
generated using either SWIG or f2py. Some of the newer contributions
to SciPy are either written entirely or wrapped with Cython.
Source: http://www.scipy.org/scipylib/faq.html#id12
On Linux, SciPy and NumPy libraries’ official releases are source-code
only. Installing NumPy and SciPy from source is reasonably easy;
However, both packages depend on other software, some of them which
can be challenging to install, or shipped with incompatibilities by
major Linux distributions. Hopefully, you can install NumPy and SciPy
without any software outside the necessary tools to build python
extensions, as most dependencies are optional
Source: http://www.scipy.org/scipylib/building/linux.html
I have a numerical library in FORTRAN (I believe FORTRAN IV) and I want to convert it to Python code. I want real source code that I can import on any Python virtual machine --- Windows, MacOS-X, Linux, Android. I started to do this by hand, but there are about 1,000 routines in the library, so that's not a reasonable solution.
Such a tool exists for Fortran to Lisp, or Fortran to C, or even Fortran to Java. But you will never have a Fortran to Python tool, for a simple reason: unlike Fortran, Lisp or C, Python does not have GOTO [1]. And there are many GOTOs in Fortran (especially Fortran IV) code. Even if there is a theorem by Jacopini stating that you can emulate GOTO with structured programming, it's far too cumbersome to implement a real (and efficient) language conversion tool.
So not only will you need to translate the code of 1000 routines, but you will also need to understand each algorithm, with all its imbricated gotos, and translate the algorithm into a structured program before writing it in Python. Good luck!
Hey, why do you think a wrapper is bad? Windows, OSX, and Linux all have Fortran and C [2] compilers and good wrappers!
For C (not your language here, but f2c may be an option), there is SWIG, and Fortran has f2py, now integrated with numpy. SWIG has some support for Android.
By the way, instead of converting to "pure" Python, you can use NumPy: NumPy capabilities are similar to Fortran 90 (see a comparison here), so you may consider first translating your programs to F90 for a smoother transition. There seems to be also a Numpy on Adnroid. And in case you need NumPy on 64-bit Windows, there are binaries here.
If you decide to use wrappers, gfortran runs on Linux (simply install from distribution packages), Windows (MinGW), and Android.
If you go along that line, don't forget you compile FIV code, so there is the usual "one-trip loop" problem (usually a compiler option is fine). You will probably have also to manually convert some old, non-standard statements, not found in modern compilers.
You have also, obviously, the option to switch your project language to Lisp or Java...
[1] You may ask: but if GOTO is the problem, how come there is a Fortran to Java tool? Well, it uses tricks with the JVM, which has internally the GOTO instruction. There is also a GOTO in Python bytecode (look for JUMP here), so there may be something to investigate here. So my previous statement is wrong: there may be a Fortran to Python tool, using bytecode tricks like in Java. But it remains to develop, and the availability of good libraries (like NumPy, matplotlib, pandas...) makes it unnecessary, to say the least.
I wrote a translator that converts a subset of Fortran into Python (and several other languages). It is only compatible with a small subset of Fortran, but I hope it will still be useful.
The translator can parse this Fortran function:
LOGICAL function is_greater_than(a, b)
real,intent(in) :: a
real,intent(in) :: b
is_greater_than = a<b
end function is_greater_than
...and translate it into this Python function:
def is_greater_than(a,b):
return a<b
Is it possible to import arbitrary modules in cython, compile them to shared object files and then use them in python 3.1?
The reason for this is, that I am writing an extension for the program "blender", which has an internal python 3.1 interpreter. But i would also like to make use of some python-modules which are not ported to 3.x, yet
I have specifically numpy in my mind (but also some other libraries). I have a module, which makes use of numpy. As I want to redistribute that module, I don't want poeple to install numpy on their machines. would that work?
In principle, I believe it's possible. Cython works by translating Python-like code to C code. That code can be compiled for either Python 2 or Python 3 (it uses C preprocessor statements to change which code is used).
The bad news is that it will only work for extensions written in Python-like code that Cython can translate. You can't use Cython on extensions written in C, like Numpy.
The good news is that, at least for Numpy, you shouldn't have to. Since version 1.5, Numpy supports Python 3. There's a binary available for Windows; on other systems, you might have to work out how to compile the code yourself.
Check your Python documentation, the section "Python/C API Reference Manual" describes in detail how to do it.
EDITED:
So what you want is porting a 2.x lib to 3.x. That's a big work to do.
If the solution your wished exists. Python 2.x should have been eliminated by now.
Sure there is a 2to3 tool. But a Python lib written by C is not applicable in this way.
So, you may follow the instruction in the "Python/C API Reference Manual" to port the lib to 3.x or just wait.
A researcher has created a small simulation in MATLAB and we want to make it accessible to others. My plan is to take the simulation, clean up a few things and turn it into a set of functions. Then I plan to compile it into a C library and use SWIG to create a Python wrapper. At that point, I should be able to call the simulation from a small Django application. At least I hope so.
Do I have the right plan? Are there are any serious pitfalls that I'm not aware of at the moment?
One thing to remember is that the MATLAB compiler does not actually compile the MATLAB code into native machine instructions. It simply wraps it into a stand-alone executable or a library with its own runtime engine that runs it. You would be able to run your code without MATLAB installed, and you would be able to interface it with other languages, but it will still be interpreted MATLAB code, so there would be no speedup.
Matlab Coder, on the other hand, is the thing that can generate C code from Matlab. There are some limitations, though. Not all Matlab functions are supported for code generation, and there are things you cannot do, like change the type of a variable on the fly.
I remember that I was able to wrap a MATLAB simulation into a DLL file and then call it from a Delphi application. It worked really well.
I'd also try ctypes first.
Use the MATLAB compiler to compile the code into C.
Compile the C code into a DLL.
Use ctypes to load and call code from this DLL
The hardest step is probably 1, but if you already know MATLAB and have used the MATLAB compiler, you should not have serious problems with it.
Perhaps try ctypes instead of SWIG. If it has been included as a part of Python 2.5, then it must be good :-)