Comments (14)
I would also try to stick with Fortran and C for the beginning. Not only can it be a reference implementation, but hopefully also a good example of what modern Fortran code should look like.
from stdlib.
I would also prefer to rely on modern Fortran and use C-bindings to system-related functionality whenever needed.
from stdlib.
I agree that the reference implementation should use Fortran as much as possible. If there are cases where it cannot be used, then it will highlight a critical limitation of the language, and allow the issue to be handed to the standards committee.
But certainly other implementations, say from vendors, should not feel obliged to use Fortran.
from stdlib.
Having just said that, I would like to hear your opinions on are we willing to wrap any F77 code with modern interfaces? I can guess the opinion of @jacobwilliams already 😝
I suspect that at some point, we will end up refactoring some old Fortran routines (the first two examples that come to my mind are the good ol' zeroin
and fmin
functions).
from stdlib.
@ivan-pi I will die a little inside for every fixed-format Fortran file that gets added. 🤣
But, yes, my preference would be to modernize any old code. At a bare minimum, convert any fixed-form to free-form style. The library should be an example of what good, modern Fortran code should look like. And I already have modernized versions of zeroin
and fmin
!
from stdlib.
Related to this is what dependencies we can have. In #10 we will have to depend on a LAPACK implementation. The reference Lapack is in pure Fortran, but we want to be able to link to optimized implementations such as OpenBLAS and MKL. The same with FFT (#21), we can use FFTPACK (Fortran), but we should also allow linking with other implementations such as MKL or FFTW.
from stdlib.
I agree, the general principle we could take:
- Implement anything we can in Fortran;
- Defer to C for things that we have to;
- Any other language and tool, think and discuss hard and long why it's needed
I can't think of what we'd need C++ for, unless we were writing a Fortran interface to an existing C++ library.
I think this also touches on build systems discussed in #2. Adding a foreign language tool or library increases the complexity of the project (both for us and for users) by more than just the sum of the parts.
from stdlib.
Agreed. Regarding C, what do we need to use C for besides #19? For example in #21 there are Fortran implementations, so we do not need C there.
I think we might need C to implement low level system dependent access to files, processes, etc. as suggested in #14 (comment).
from stdlib.
As of right now only #19 is looking in that direction. If a POSIX proposal is more seriously considered, that may still be just a set of interfaces with iso_c_binding
, so still Fortran.
from stdlib.
Related to this is what dependencies we can have. In #10 we will have to depend on a LAPACK implementation. The reference Lapack is in pure Fortran, but we want to be able to link to optimized implementations such as OpenBLAS and MKL. The same with FFT, we can use FFTPACK (Fortran), but we should also allow linking with other implementations such as MKL or FFTW.
Something to keep in mind with FFTW is that it is under the GPL (very unusual for a library). Therefore, if we provide a wrapper able to link against it, it is very important that this be optional so non-GPL software can still use it. Or we could just license all of stdlib
under GPL, which I wouldn't object to but I suspect most others will ;)
from stdlib.
Something to keep in mind with FFTW is that it is under the GPL (very unusual for a library). Therefore, if we provide a wrapper able to link against it, it is very important that this be optional so non-GPL software can still use it. Or we could just license all of
stdlib
under GPL, which I wouldn't object to but I suspect most others will ;)
Yes. The plan is to only depend on MIT or BSD licensed libraries by default. Then we can have optional wrappers for other libraries like MKL or FFTW, and since they are optional, and stdlib works perfectly fine without them, we can keep our MIT license for stdlib.
from stdlib.
@milancurcic even in #19 it looks like we'll probably stay in Fortran. So why don't we try hard to stay in Fortran and see if that works for us. That would make things very simple. If we cannot do that, then let's revisit.
from stdlib.
@marshallward good point. I think this stdlib can act as a reference implementation, like the reference Lapack implementation (in Fortran). Then vendors can provide more optimized versions and they do not need to use Fortran, as long as they provide the same API.
from stdlib.
@ivan-pi I think the answer is that for the API, we should use modern Fortran API (modules, assumed-shape arrays, etc.). How things are actually implemented underneath do not matter as much --- we can start with F77, then refactor later if needed. In fact, vendors might provide their own optimized implementations in other languages.
from stdlib.
Related Issues (20)
- Hashtable write error on exit HOT 7
- use stdlib_math, only : gcd HOT 4
- The file src/stdlib_hashmap_chaining.f90 and two others are set as executable HOT 1
- Support for I/O of standard formats HOT 10
- Memory mapped features HOT 9
- Add `.gitignore` to `stdlib-fpm` deployment for generated test files HOT 1
- hash_functions test fails on i386: `Segmentation fault - invalid memory reference`
- Request to upgrade Intel-classic compiler in macOS CI
- Add `library` configuration to `stdlib-fpm`
- Massive slow down in docs generation HOT 4
- Unexpected performance of hash maps HOT 8
- python preprocessor HOT 11
- add topic tags `lapack`, `blas`, `linear-algebra` HOT 1
- Improve descriptions of rotm, rotmg, stdlib_srotm, stdlib_srotmg
- Don't repeat names of procedures in descriptions
- stdlib_io_npy, FPM and Rank > 4 HOT 5
- Missing documentation for `LAPACK`-related functions HOT 6
- Adding the logarithmic derivative of the gamma function (digamma) to stdlib_specialfunctions_gamma HOT 1
- example_starts_with prints logical results as binary
- Nonstandard forward reference to 'lk' is not allowed in the same specification part causes compilation errors HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stdlib.