Things to do with operators

There are four main aspects to Fortran operators:

• Working with built-in operators as is –We’ve been doing this throughout this book without hiccups. In fact, the tsunami simulator, and every other miniproject we’ve worked on so far, relied heavily on number crunching with built-in arithmetic operators. It’s no surprise, as that’s where Fortran really shines.
• Invoking a procedure using a custom operator –You can express a function or a subroutine that takes one or two input arguments as a custom unary or binary operator, respectively. This doesn’t unlock any special powers but may be used to make your code more concise and expressive.
• Redefining operators for built-in types –Fortran’s strong typing prohibits mixing numerical and character values, unlike, for example, JavaScript, where an expression such as 99 + "problems" is not only allowed but common. Redefining operators for existing built-in types allows a more flexible, weaker type system in Fortran.
• Custom operators for derived types –This is the big and powerful one that we’ll explore in the next chapter. As you build your derived types, such as the Person type from the previous chapter or the Field type from the tsunami simulator, defining built-in operators for these types will allow you to construct whole new sets of rules, essentially extending Fortran’s core syntax.

In this chapter, we’ll cover the built-in operators (item 1) in more detail, and we’ll learn how to express a function or subroutine as a custom operator (item 2). We’ve used built-in operators extensively since chapter 2 throughout the book but haven’t given much attention to what exactly operators are and how they work. Overriding a procedure with a custom operator is more syntactic sugar than anything else. That is, it doesn’t add any notable functionality but may make your code easier to read or write, or just prettier. A programmer’s happiness matters. Finally, we’ll touch on redefining operators for built-in types (item 3) in exercise 2 of this chapter. Custom operators for derived types (item 4), a powerful and interesting feature in their own right, we’ll defer until the next chapter.

Back to our weather data analysis app. When we implement the average and denan functions from listing 9.6 as custom operators, we’ll be able to express our main data loop as that shown in the following listing.

Listing 9.7 Applying custom operators to remove NaNs from and average the data

do n = 1, nm
  dataset = weather_data('data/processed/' // trim(cities(n)) // '.csv')
  temperature(n) = &                                      ❶
    .average. (.denan. dataset % temperature)             ❶
  humidity(n) = .average. (.denan. dataset % humidity)    ❶
  wind_speed(n) = &                                       ❶
    .average. (.denan. dataset % wind_speed)              ❶
  clear_sky(n) = .average. dataset % clear_sky            ❷
end do

❶ Applies .denan. first, .average. second

❷ We can omit the parentheses for a single unary operator.

Here, .average. and .denan. are custom operators with the same functionality as functions with the same name. The semantics didn’t change, only the syntax–we traded some parentheses for some periods. Note that .average. .denan. x (where x is the input array) is not a valid syntax. When chaining multiple unary operators, you must use parentheses to separate two operators. Binary operators don’t run into this issue, as they’re always separated by operands.