5 ms·

Map, Filter, Reduce in Fortran (2019)

76 points by azhenley 4y ago

adgjlsfhk1 4y ago
Am I missing something or does this implementation only work with integer functions. If you have to write your own mapreduce for every type, that kind of defeats the point.
- j_m_b 4y ago
  You're correct. However, you would create a library and make map an interface and create implementations for the types you need. e.g. https://github.com/wavebitscientific/functional-fortran/blob/master/src/functional.f90#L151 https://github.com/wavebitscientific/functional-fortran/blob...
- rpep 4y ago
  That’s common to all typed languages and is the motivation behind generics/templates which allow you to write once and provide specialisation where necessary. In older C and Fortran libraries it wasn’t unusual to have to compile a library multiple times to support different input types - FFTW does this for example. Often there’s some macro magic with a variable injected at build time to determine the type.
  - msla 4y ago
    > That’s common to all typed languages It isn't. Haskell, for example, has a type system expressive enough to encode concepts such as "a function which takes an array of elements of any type (fixed at compile time) and another function which operates on elements of the type that array is composed of and returns an array of elements of that unnamed type" and it has a type system with fewer holes than any Algol-derived language's (Ada, C, Pascal) type system has.
    - User23 4y ago
      Algol 60’s type system has fewer holes than most Algol-derived languages.
      - msla 4y ago
        > Algol 60’s type system has fewer holes than most Algol-derived languages. And this can be a mixed blessing. If an inexpressive type system has few or no holes, it becomes a straitjacket where you can't write the kinds of perfectly well-defined functions you need because the type system can't express them. The classic pathological example is how Standard Pascal couldn't express the concept of a function which took an arbitrary-size array, but the example so common it's typically overlooked is how it's impossible in many Algol-derived languages to write one function to compare two numbers instead of having to write four or five such functions, especially if you're unwilling to let the type system hole of automatic integral and floating-point size promotion potentially introduce odd bugs. Haskell's type system is strong and fairly expressive, with language extensions to make it more expressive. (This does not change the fact type systems typically express the wrong things, but this post is long enough already.)
    - Volt 4y ago
      You should literally continue reading the rest of the sentence.
      - msla 4y ago
        Haskell doesn't have generics or templates, it has an expressive type system.
        tpoacher 4y ago
        "Expressive Type System" without context is just a buzzword. In this particular context, it simply means that Haskell allows for types to be parameterised, which is a different way of saying it allows for generic types.
- enriquto 4y ago
  There are not too many types to begin with. Ints and floats and that's pretty much it.
  - marshallward 4y ago
    True but every kind is considered a type.
- gylterud 4y ago
  Fortran will get generics soon(ish).
sheepscreek 4y ago
The more I read about Fortran the more fascinated I become with it. Its treatment of arrays is similar to Pandas/Numpy. The performance is close to C without any optimizations. Without the pointer laden complexity and gotchas that come with C/C++.
- tomrod 4y ago
  String parsing is a bit rough, but otherwise Fortran is much better than Matlab -- and Matlab was written in the 1990s to be "Fortran for the 90s". Numpy enabled scientific computing folks to leave Matlab (and some, Fortran) to adopt Python. I took a coin flip in grad school to decide whether to focus on Python and Fortran. Python won the flip, but I've always loved Fortran generally.
  - Jtsummers 4y ago
    MATLAB originated earlier than the 90s, and was not "Fortran for the 90s". That's a weird ahistorical view of things.
- ktpsns 4y ago
  Modern Fortran has a number of attractive features. Parallel programming (Co-arrays) is another gem of recent Fortran versions. Concise syntax conforming with traditional numerics makes it still a good domain specific language of choice. In my opinion, Julia is a good successor of Fortran. In my opinion it behaves as a child of Python/Numpy and Fortran ;-)
- deleted 4y ago
  [deleted]
- TheRealKing 4y ago
  Actually, it is the other way around. Pandas/NumPy were inspired by the Fortran syntax. Fortran's treatment of optional arguments are also great. Arbitrary array indexing (0-based, 1-based, negative-based) is a bliss.
  - 4y ago
deleted 4y ago
[deleted]
TchoBeer 4y ago
Modern Fortran is a really nice language, I have a lot of fun with it. Wish that map filter reduce were more standard parts of the compilers, but I guess it wouldn't be Fortran if new standards didn't take a decade to get good compiler support.
- deleted 4y ago
  [deleted]

76 points by azhenley 4y ago

Am I missing something or does this implementation only work with integer functions. If you have to write your own mapreduce for every type, that kind of defeats the point.

j_m_b 4y ago
You're correct. However, you would create a library and make map an interface and create implementations for the types you need. e.g. https://github.com/wavebitscientific/functional-fortran/blob/master/src/functional.f90#L151 https://github.com/wavebitscientific/functional-fortran/blob...
rpep 4y ago
That’s common to all typed languages and is the motivation behind generics/templates which allow you to write once and provide specialisation where necessary. In older C and Fortran libraries it wasn’t unusual to have to compile a library multiple times to support different input types - FFTW does this for example. Often there’s some macro magic with a variable injected at build time to determine the type.
- msla 4y ago
  > That’s common to all typed languages It isn't. Haskell, for example, has a type system expressive enough to encode concepts such as "a function which takes an array of elements of any type (fixed at compile time) and another function which operates on elements of the type that array is composed of and returns an array of elements of that unnamed type" and it has a type system with fewer holes than any Algol-derived language's (Ada, C, Pascal) type system has.
  - User23 4y ago
    Algol 60’s type system has fewer holes than most Algol-derived languages.
    - msla 4y ago
      > Algol 60’s type system has fewer holes than most Algol-derived languages. And this can be a mixed blessing. If an inexpressive type system has few or no holes, it becomes a straitjacket where you can't write the kinds of perfectly well-defined functions you need because the type system can't express them. The classic pathological example is how Standard Pascal couldn't express the concept of a function which took an arbitrary-size array, but the example so common it's typically overlooked is how it's impossible in many Algol-derived languages to write one function to compare two numbers instead of having to write four or five such functions, especially if you're unwilling to let the type system hole of automatic integral and floating-point size promotion potentially introduce odd bugs. Haskell's type system is strong and fairly expressive, with language extensions to make it more expressive. (This does not change the fact type systems typically express the wrong things, but this post is long enough already.)
  - Volt 4y ago
    You should literally continue reading the rest of the sentence.
    - msla 4y ago
      Haskell doesn't have generics or templates, it has an expressive type system.
      - tpoacher 4y ago
        "Expressive Type System" without context is just a buzzword. In this particular context, it simply means that Haskell allows for types to be parameterised, which is a different way of saying it allows for generic types.
enriquto 4y ago
There are not too many types to begin with. Ints and floats and that's pretty much it.
- marshallward 4y ago
  True but every kind is considered a type.
gylterud 4y ago
Fortran will get generics soon(ish).

sheepscreek 4y ago

The more I read about Fortran the more fascinated I become with it. Its treatment of arrays is similar to Pandas/Numpy. The performance is close to C without any optimizations. Without the pointer laden complexity and gotchas that come with C/C++.

tomrod 4y ago
String parsing is a bit rough, but otherwise Fortran is much better than Matlab -- and Matlab was written in the 1990s to be "Fortran for the 90s". Numpy enabled scientific computing folks to leave Matlab (and some, Fortran) to adopt Python. I took a coin flip in grad school to decide whether to focus on Python and Fortran. Python won the flip, but I've always loved Fortran generally.
- Jtsummers 4y ago
  MATLAB originated earlier than the 90s, and was not "Fortran for the 90s". That's a weird ahistorical view of things.
ktpsns 4y ago
Modern Fortran has a number of attractive features. Parallel programming (Co-arrays) is another gem of recent Fortran versions. Concise syntax conforming with traditional numerics makes it still a good domain specific language of choice. In my opinion, Julia is a good successor of Fortran. In my opinion it behaves as a child of Python/Numpy and Fortran ;-)
deleted 4y ago
[deleted]
TheRealKing 4y ago
Actually, it is the other way around. Pandas/NumPy were inspired by the Fortran syntax. Fortran's treatment of optional arguments are also great. Arbitrary array indexing (0-based, 1-based, negative-based) is a bliss.
- 4y ago

deleted 4y ago

[deleted]

TchoBeer 4y ago

Modern Fortran is a really nice language, I have a lot of fun with it. Wish that map filter reduce were more standard parts of the compilers, but I guess it wouldn't be Fortran if new standards didn't take a decade to get good compiler support.

deleted 4y ago
[deleted]