Hi All, There's a PR [1] for adding bounded linear least squares that's close to being able to merge. scipy.optimize.bounded_lstsq If you have any specific comments about the PR, etc. Please speak up. Thanks, Skipper https://github.com/scipy/scipy/pull/3137
On Mon, Mar 17, 2014 at 2:03 PM, Skipper Seabold <jsseabold@gmail.com> wrote:
Hi All,
There's a PR [1] for adding bounded linear least squares that's close to being able to merge.
scipy.optimize.bounded_lstsq
If you have any specific comments about the PR, etc. Please speak up.
Thanks,
Skipper
I guess I have a question. Does anyone have an option on the best way forward for the Fortran 90 code? We have to stick to Fortran 77 code, unfortunately, so my options are to either fix the code incrementally for F77 or ... ? What do people think about using f2c to generate and include C code? I've never done this before, and I assume it comes with its own can of worms. Skipper
Skipper Seabold <jsseabold@gmail.com> wrote:
I guess I have a question. Does anyone have an option on the best way forward for the Fortran 90 code? We have to stick to Fortran 77 code, unfortunately, so my options are to either fix the code incrementally for F77 or ... ?
It is basically undoable. Do you know Fortran 77 that well? I learned Fortran 90 about 20 years ago. I couldn't write valid Fortran 77 even if I wanted to — even though I am fluent in Fortran 90. And that is probably the case for most scientists that use Fortran today. If you tried, you would even have to change loops into gotos. Good luck on that... Coding Fortran 77 in 2014 is not worth the effort.
What do people think about using f2c to generate and include C code? I've never done this before, and I assume it comes with its own can of worms.
This will not help you out. f2c is a Fortran 77 compiler. f2c and g77 was written by the same person (as one-man projects), and they basically do the same except for what they emit (C or machine code, respectively). The original f77 compiler was a shell script that invoked f2c and system cc. g77 came along because pointer aliasing prevented C compilers from doing certain optimizations (e.g. register allocation). With a modern C compiler it is probably better to use f2c than the g77 compiler, but it will still be inferior to modern Fortran compilers (gfortran, ifort, absoft). Sturla
On Tue, Mar 18, 2014 at 3:25 AM, Sturla Molden <sturla.molden@gmail.com>wrote:
Skipper Seabold <jsseabold@gmail.com> wrote:
I guess I have a question. Does anyone have an option on the best way forward for the Fortran 90 code? We have to stick to Fortran 77 code, unfortunately, so my options are to either fix the code incrementally for F77 or ... ?
It is basically undoable. Do you know Fortran 77 that well?
I learned Fortran 90 about 20 years ago. I couldn't write valid Fortran 77 even if I wanted to -- even though I am fluent in Fortran 90. And that is probably the case for most scientists that use Fortran today.
If you tried, you would even have to change loops into gotos. Good luck on that...
Coding Fortran 77 in 2014 is not worth the effort.
What do people think about using f2c to generate and include C code? I've never done this before, and I assume it comes with its own can of worms.
This will not help you out.
f2c is a Fortran 77 compiler.
f2c and g77 was written by the same person (as one-man projects), and they basically do the same except for what they emit (C or machine code, respectively). The original f77 compiler was a shell script that invoked f2c and system cc. g77 came along because pointer aliasing prevented C compilers from doing certain optimizations (e.g. register allocation). With a modern C compiler it is probably better to use f2c than the g77 compiler, but it will still be inferior to modern Fortran compilers (gfortran, ifort, absoft).
Wasn't there a Cython project for wrapping Fortran? IIRC, it had the opposite problem, it could wrap newer versions of Fortran but couldn't hack Fortran 77. Chuck
On Tue, Mar 18, 2014 at 3:48 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Tue, Mar 18, 2014 at 3:25 AM, Sturla Molden <sturla.molden@gmail.com>wrote:
Skipper Seabold <jsseabold@gmail.com> wrote:
I guess I have a question. Does anyone have an option on the best way forward for the Fortran 90 code? We have to stick to Fortran 77 code, unfortunately, so my options are to either fix the code incrementally for F77 or ... ?
It is basically undoable. Do you know Fortran 77 that well?
I learned Fortran 90 about 20 years ago. I couldn't write valid Fortran 77 even if I wanted to -- even though I am fluent in Fortran 90. And that is probably the case for most scientists that use Fortran today.
If you tried, you would even have to change loops into gotos. Good luck on that...
Coding Fortran 77 in 2014 is not worth the effort.
What do people think about using f2c to generate and include C code? I've never done this before, and I assume it comes with its own can of worms.
This will not help you out.
f2c is a Fortran 77 compiler.
f2c and g77 was written by the same person (as one-man projects), and they basically do the same except for what they emit (C or machine code, respectively). The original f77 compiler was a shell script that invoked f2c and system cc. g77 came along because pointer aliasing prevented C compilers from doing certain optimizations (e.g. register allocation). With a modern C compiler it is probably better to use f2c than the g77 compiler, but it will still be inferior to modern Fortran compilers (gfortran, ifort, absoft).
Wasn't there a Cython project for wrapping Fortran? IIRC, it had the opposite problem, it could wrap newer versions of Fortran but couldn't hack Fortran 77.
And a bit of googling turns up fwrap, which stalled before completion. The current advice seems to be to use ISO_C_BINDING and then Cython. Chuck
On Tue, Mar 18, 2014 at 5:55 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Tue, Mar 18, 2014 at 3:48 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Mar 18, 2014 at 3:25 AM, Sturla Molden <sturla.molden@gmail.com>wrote:
Skipper Seabold <jsseabold@gmail.com> wrote:
I guess I have a question. Does anyone have an option on the best way forward for the Fortran 90 code? We have to stick to Fortran 77 code, unfortunately, so my options are to either fix the code incrementally for F77 or ... ?
It is basically undoable. Do you know Fortran 77 that well?
I learned Fortran 90 about 20 years ago. I couldn't write valid Fortran 77 even if I wanted to -- even though I am fluent in Fortran 90. And that is probably the case for most scientists that use Fortran today.
If you tried, you would even have to change loops into gotos. Good luck on that...
Coding Fortran 77 in 2014 is not worth the effort.
What do people think about using f2c to generate and include C code? I've never done this before, and I assume it comes with its own can of worms.
This will not help you out.
f2c is a Fortran 77 compiler.
f2c and g77 was written by the same person (as one-man projects), and they basically do the same except for what they emit (C or machine code, respectively). The original f77 compiler was a shell script that invoked f2c and system cc. g77 came along because pointer aliasing prevented C compilers from doing certain optimizations (e.g. register allocation). With a modern C compiler it is probably better to use f2c than the g77 compiler, but it will still be inferior to modern Fortran compilers (gfortran, ifort, absoft).
Wasn't there a Cython project for wrapping Fortran? IIRC, it had the opposite problem, it could wrap newer versions of Fortran but couldn't hack Fortran 77.
And a bit of googling turns up fwrap, which stalled before completion. The current advice seems to be to use ISO_C_BINDING and then Cython.
That works pretty well, but it doesn't solve the fundamental problem of using Fortran 90 on Windows (https://github.com/scipy/scipy/issues/2829). Warren Chuck
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Tue, Mar 18, 2014 at 6:04 PM, Warren Weckesser <warren.weckesser@gmail.com> wrote:
That works pretty well, but it doesn't solve the fundamental problem of using Fortran 90 on Windows (https://github.com/scipy/scipy/issues/2829).
... which is kind of absurd, right? Not that I'm in a position to do anything about it but marvel.
Skipper Seabold <jsseabold@gmail.com> wrote:
On Tue, Mar 18, 2014 at 6:04 PM, Warren Weckesser <warren.weckesser@gmail.com> wrote:
That works pretty well, but it doesn't solve the fundamental problem of using Fortran 90 on Windows (https://github.com/scipy/scipy/issues/2829).
... which is kind of absurd, right? Not that I'm in a position to do anything about it but marvel.
See https://groups.google.com/forum/m/#!topic/numpy/BnZESkA4TdQ It seems the original problem was that David did not know "how to link C and Fortran" into one executable. However: http://stackoverflow.com/questions/2096519/from-mingw-static-library-a-to-vi... Because of this, MSVC should ba able to link with libgfortran.a and object files from gfortran, but we might need to rename then to .lib and .obj. Another option is to hack f2py so that gfortran is used as linker when MSVC is used as C compiler. gfortran know what do do with object files from MSVC. Sturla
Charles R Harris <charlesr.harris@gmail.com> wrote:
And a bit of googling turns up fwrap, which stalled before completion. The current advice seems to be to use ISO_C_BINDING and then Cython.
That is the only portable way of wrapping Fortran, but it requires a Fortran 2003 compiler.
Charles R Harris <charlesr.harris@gmail.com> wrote:
Wasn't there a Cython project for wrapping Fortran? IIRC, it had the opposite problem, it could wrap newer versions of Fortran but couldn't hack Fortran 77.
f2py can wrap Fortran 90. Not in a portable way, but it knows the ABI of all major compilers. I prefer to use ISO_C_BINDING and Cython or ctypes myself (usually ctypes). David Cournapeau claims there is a stability issue when using gfortran and MSVC on Windows, due to the "MinGW run-time". Thus g77 is used to build the official binaries. I don't understand how using g77 is any better, as it creates code which depends on the MinGW run-time too. If David means that libgfortran depends on msvcrt.dll, that might be the case, but we are not going to share any CRT resources between Python and Fortran. Unless f2py does something very strange, Python and Fortran are isolated worlds with respect to CRT calls. I have used gfortran together with Python for my own code on Windows and never seen any of these stability issues. Calling ACML from gfortran will segfault though. Perhaps that is what he means? (Not sure why, but we are not foing to do that.) I need perhaps to better understand what the problem is... Could anyone enlighten me? If we could use gfortran instead of g77, it would be unproblematic to use Fortran 90/95 or even a subset of Fortran 2003/2008. In that case it would just be a matter of shaping up the Fortran 90 code. Sturla
participants (4)
-
Charles R Harris -
Skipper Seabold -
Sturla Molden -
Warren Weckesser