Scala Saturday – Vector.splitAt

Vector.splitAt splits a vector into two parts at the index you specify. The first part ends just before the element at the given index; the second part starts with the element at the given index. Some examples will help:

Some Examples

The most obvious use case is bisecting a vector, i.e., splitting it into two (nearly) equal parts. To do that, half the length, and use it as your splitting index:

val xs = Vector(1,2,3,4,5,6)
val mid = xs.length / 2 // 3
val (left, right) = xs splitAt mid
// left: Vector[Int] = Vector(1, 2, 3)
// right: Vector[Int] = Vector(4, 5, 6)

But what happens if your vector contains an odd number of elements? No sweat! Because of the way integer division works, the quotient length ÷ 2 is truncated. In other words, the left vector will always have one less element than the right vector:

val xs = Vector(1,2,3,4,5)
val mid = xs.length / 2 // 2
val (left, right) = xs splitAt mid
// left: Vector[Int] = Vector(1, 2)
// right: Vector[Int] = Vector(3, 4, 5)

Of course, you don’t have to cut the thing in half. You can split it anywhere:

val xs = Vector(1,2,3,4,5)
val (left, right) = xs splitAt 1
// left: Vector[Int] = Vector(1)
// right: Vector[Int] = Vector(2, 3, 4, 5)

Or …

val xs = Vector(1,2,3,4,5)
val (left, right) = xs splitAt 4
// left: Vector[Int] = Vector(1, 2, 3, 4)
// right: Vector[Int] = Vector(5)

What happens if you split at index 0?

val xs = Vector(1,2,3,4,5)
val (left, right) = xs splitAt 0
// left: Vector[Int] = Vector()
// right: Vector[Int] = Vector(1, 2, 3, 4, 5)

Ah, the left vector is empty! That’s because Vector.splitAt starts the right vector at the given index. There’s nothing before the given index, so the only thing left to return for left is an empty vector.

The reverse happens if you split at the length: The right vector is empty while the left vector contains the entire input vector:

val xs = Vector(1,2,3,4,5)
val (left, right) = xs splitAt 5
// left: Vector[Int] = Vector(1, 2, 3, 4, 5)
// right: Vector[Int] = Vector()

But what happens if you try to split at an index greater than the length?

val xs = Vector(1,2,3,4,5)
val (left, right) = xs splitAt 6
// left: Vector[Int] = Vector(1, 2, 3, 4, 5)
// right: Vector[Int] = Vector()

Well, that’s interesting. So then, if you split at any index greater than the length of the input vector, the left contains the input vector while the right vector is empty.

You get the reverse if you split on a negative number:

val xs = Vector(1,2,3,4,5)
val (left, right) = xs splitAt -1
// left: Vector[Int] = Vector()
// right: Vector[Int] = Vector(1, 2, 3, 4, 5)

Merge Sort with Vector.splitAt

You can use Vector.splitAt in performing a merge sort. Vector.splitAt is, admittedly, a pretty small piece of the puzzle. Merge sort is a divide-and-conquer algorithm, and Vector.splitAt just performs the divide part. Nevertheless it comes in handy for that part.

Speaking of which, start by using Vector.splitAt to define a bisect function that splits a vector in half:

def bisect[A](xs: Vector[A]) = {
  val mid = xs.length / 2
  xs splitAt mid
}

A merge sort breaks a vector down into single-element (or empty) vectors and then puts them back together, sorting the elements of each block as it combines them. Start with the merge function that puts the blocks back together after you’ve broken them down:

def merge(left: Vector[Int], right: Vector[Int]) = {
  @tailrec
  def mergeWith(l: Vector[Int], r: Vector[Int], acc: Vector[Int]): Vector[Int] = {
    (l.isEmpty, r.isEmpty) match {
      // If either side is empty, just add
      // the non-empty side to the accumulator.
      case (true, _) => acc ++ r
      case (_, true) => acc ++ l

      // Compare the head elements, and add
      // the lesser head value to the
      // accumulator. Then call recursively.
      case _ =>
        val lh = l.head
        val rh = r.head
        val (next, l2, r2) =
          if (lh < rh) (lh, l.tail, r)
          else (rh, l, r.tail)
        mergeWith(l2, r2, acc :+ next)
    }
  }

  mergeWith(left, right, Vector[Int]())
}

Now mergeSort can use bisect and merge to break down the vector and then merge it back together:

def mergeSort(as: Vector[Int]): Vector[Int] =
  as match {
    case Vector() => as
    case Vector(a) => as
    case _ =>
      val (l, r) = bisect(as)
      merge(mergeSort(l), mergeSort(r))
  }

val xs:  = Vector(43,48,3,23,28,6,25,43,16)
val sorted: Vector[Int] = mergeSort(xs)
// sorted: Vector[Int] = 
//   Vector(3, 6, 16, 23, 25, 28, 43, 43, 48)

A quick announcement: I’ve got some instructional material to develop. Unfortunately it’s going to take up a fair amount of my time. This is probably the last Scala Saturday post for a little while, but I hope to pick back up in a month or two.

F# Friday – Array.splitAt

Array.splitAt splits an array into two parts at the index you specify. The first part ends just before the element at the given index; the second part starts with the element at the given index. Some examples will help:

Some Examples

The most obvious use case is bisecting an array, i.e., splitting it into two (nearly) equal parts. To do that, half the length, and use it as your splitting index:

let xs = [|1;2;3;4;5;6|]
let mid = xs.Length / 2 // 3
let left, right = xs |> Array.splitAt mid
// val left : int [] = [|1; 2; 3|]
// val right : int [] = [|4; 5; 6|]

But what happens if your array contains an odd number of elements? No sweat! Because of the way integer division works, the quotient length ÷ 2 is truncated. In other words, the left array will always have one less element than the right array:

let xs = [|1;2;3;4;5|]
let mid = xs.Length / 2 // 2
let left, right = xs |> Array.splitAt mid
// val left : int [] = [|1; 2|]
// val right : int [] = [|3; 4; 5|]

Of course, you don’t have to cut the thing in half. You can split it anywhere:

let xs = [|1;2;3;4;5|]
let left, right = xs |> Array.splitAt 1
// val left : int [] = [|1|]
// val right : int [] = [|2; 3; 4; 5|]

Or …

let xs = [|1;2;3;4;5|]
let left, right = xs |> Array.splitAt 4
// val left : int [] = [|1; 2; 3; 4|]
// val right : int [] = [|5|]

What happens if you split at index 0?

let xs = [|1;2;3;4;5|]
let left, right = xs |> Array.splitAt 0
// val left : int [] = [||]
// val right : int [] = [|1; 2; 3; 4; 5|]

Ah, the left array is empty! That’s because Array.splitAt starts the right array at the given index. There’s nothing before the given index, so the only thing left to return for left is an empty array.

The reverse happens if you split at the length: The right array is empty while the left array contains the entire input array:

let xs = [|1;2;3;4;5|]
let left, right = xs |> Array.splitAt 5
// val left : int [] = [|1; 2; 3; 4; 5|]
// val right : int [] = [||]

But what happens if you try to split at an index greater than the length?

let xs = [|1;2;3;4;5|]
let left, right = xs |> Array.splitAt 6
// System.InvalidOperationException: The input sequence has an insufficient number of elements.
//    at Microsoft.FSharp.Collections.ArrayModule.SplitAt[T](Int32 index, T[] array)
//    at <StartupCode$FSI_0063>.$FSI_0063.main@()

Oops! Well, I guess you shouldn’t do that. So then, just be sure to split at an index that is no greater than the length of the array. You likewise get an exception if you attempt to split at a negative index value.

Merge Sort with Array.splitAt

You can use Array.splitAt in performing a merge sort. Array.splitAt is, admittedly, a pretty small piece of the puzzle. Merge sort is a divide-and-conquer algorithm, and Array.splitAt just performs the divide part. Nevertheless it comes in handy for that part.

Speaking of which, start by using Array.splitAt to define a bisect function that splits an array in half:

let bisect xs =
    let mid = (xs |> Array.length) / 2
    xs |> Array.splitAt mid

A merge sort breaks an array down into single-element (or empty) arrays and then puts them back together, sorting the elements of each block as it combines them. Start with the merge function that puts the blocks back together after you’ve broken them down:

let merge left right =
    let rec mergeWith l r acc =
        match l, r with
        // If either side is empty, just add
        // the non-empty side to the accumulator.
        | ([||], a) | (a, [||]) ->
            Array.append acc a

        // Compare the head elements, and add
        // the lesser head value to the
        // accumulator. Then call recursively.
        | _ ->
            let lh = l |> Array.head
            let rh = r |> Array.head
            let next, l', r' =
                if lh < rh
                then lh, l |> Array.tail, r
                else rh, l, r |> Array.tail
            Array.append acc [|next|]
            |> mergeWith l' r'
        
    [||] |> mergeWith left right

Now mergeSort can use bisect and merge to break down the array and then merge it back together:

let rec mergeSort =
    function
    | [||] -> [||]
    | [|x|] -> [|x|]
    | xs -> 
        let l, r = bisect xs
        merge (mergeSort l) (mergeSort r)
    
let xs = [|43; 48; 3; 23; 28; 6; 25; 43; 16|]
let sorted = mergeSort xs
// val sorted : int [] = 
//   [|3; 6; 16; 23; 25; 28; 43; 43; 48|]

A quick announcement: I’ve got some instructional material to develop. Unfortunately it’s going to take up a fair amount of my time. This is probably the last F# Friday post for a little while, but I hope to pick back up in a month or two.

Scala Saturday – Stream.groupBy

Sometimes you have a collection of items that you want to group according to some common property or key. Stream.groupBy can do that job for you. It takes that collection and returns a map keyed to that grouping key. The value for each key is the sequence of all the items that fall into that group.

That’s a little hard to follow. So what’s it useful for?

Well, maybe you need to group a list of names by initial. No sweat:

val names = Stream(
  "Rehoboam",
  "Abijah",
  "Asa",
  "Jehoshaphat",
  "Jehoram",
  "Ahaziah")

val groupedByInitial = names.groupBy(_.head)
// groupedByInitial: Map[Char,Stream[String]] =
//   Map(
//     J -> Stream(Jehoshaphat, Jehoram),
//     A -> Stream(Abijah, Asa, Ahaziah),
//     R -> Stream(Rehoboam) )

And of course, if you want to sort those groups, convert the resulting map to a stream of tuples, and throw in a call to Stream.sortBy to sort by the first element in the tuple:

val groupedByInitialAndSorted =
  groupedByInitial.toStream.sortBy(_._1)
// val groupedByInitialAndSorted: Stream[(Char, Stream[String])] = 
//   Stream(
//     A -> Stream(Abijah, Asa, Ahaziah),
//     J -> Stream(Jehoshaphat, Jehoram),
//     R -> Stream(Rehoboam) )

Another example: Maybe you want to group some test scores according to grade. That is, all the students who scored in the 90s are grouped together, then all those scoring in the 80s, and so on:

case class TestScore(name: String, score: Int)

val grades = Stream(
  TestScore("Anna", 74),
  TestScore("Andy", 76),
  TestScore("Brenda", 70),
  TestScore("Bobby", 90),
  TestScore("Charlotte", 98),
  TestScore("Chuck", 83),
  TestScore("Deborah", 88),
  TestScore("Dan", 66),
  TestScore("Ellie", 80),
  TestScore("Ed", 61),
  TestScore("Frannie", 89),
  TestScore("Frank", 96) )

val grouped = grades.groupBy(_.score / 10 * 10)
// grouped: Map[Int,Stream[TestScore]] =
//   Map(
//     80 -> Stream(
//             TestScore(Chuck,83),
//             TestScore(Deborah,88),
//             TestScore(Ellie,80),
//             TestScore(Frannie,89) ),
//     70 -> Stream(
//             TestScore(Anna,74),
//             TestScore(Andy,76),
//             TestScore(Brenda,70) ),
//     60 -> Stream(
//             TestScore(Dan,66),
//             TestScore(Ed,61) ),
//     90 -> Stream(
//             TestScore(Bobby,90),
//             TestScore(Charlotte,98),
//             TestScore(Frank,96) )
//   )

You can take it another couple of steps to produce a histogram by counting the number of students in each group and sorting by the group key (i.e., grade level):

val histogram = grouped.map {
  case (grade, scores) => grade -> scores.length
}.toStream.sortBy(_._1).reverse
// histogram: Stream[(Int, Int)] =
//   Stream((90,3), (80,4), (70,3), (60,2))

One more example, and this one I borrowed from one of Steven Proctor’s Ruby Tuesday posts. You can find anagrams in a list of words by sorting the characters in each word and grouping on that:

val anagrams = Stream(
  "tar", "rat", "bar",
  "rob", "art", "orb"
).groupBy(_.sorted)
// anagrams: Map[String,Stream[String]] = 
//   Map(
//     abr -> Stream(bar),
//     art -> Stream(tar, rat, art),
//     bor -> Stream(rob, orb) )

F# Friday – Seq.groupBy

Sometimes you have a collection of items that you want to group according to some common property or key. Seq.groupBy can do that job for you. It takes that collection and returns a sequence of pairs. The first element of each pair is the grouping key; the second is the sequence of all the items that fall into that group.

That’s a little hard to follow. So what’s it useful for?

Well, maybe you need to group a list of names by initial. No sweat:

let names = 
    seq [ "Rehoboam"
          "Abijah"
          "Asa"
          "Jehoshaphat"
          "Jehoram"
          "Ahaziah" ]

let groupedByInitial =
    names
    |> Seq.groupBy (fun s -> s.[0])
// val groupedByInitial : seq<char * seq<string>> =
//   seq [ ('R', seq ["Rehoboam"])
//         ('A', seq ["Abijah"; "Asa"; "Ahaziah"])
//         ('J', seq ["Jehoshaphat"; "Jehoram"]) ]

And of course, if you want to sort those groups, throw in a call to Seq.sortBy to sort by the first element in the tuple:

let groupedByInitialAndSorted =
    names
    |> Seq.groupBy (fun s -> s.[0])
    |> Seq.sortBy fst
// val groupedByInitialAndSorted : seq<char * seq<string>> =
//   seq [ ('A', seq ["Abijah"; "Asa"; "Ahaziah"])
//         ('J', seq ["Jehoshaphat"; "Jehoram"])
//         ('R', seq ["Rehoboam"]) ]

Another example: Maybe you want to group some test scores according to grade. That is, all the students who scored in the 90s are grouped together, then all those scoring in the 80s, and so on:

type TestScore =
    { Name : string
      Score : int }

let grades = 
    seq [
        { Name = "Anna"; Score = 74 }
        { Name = "Andy"; Score = 76 }
        { Name = "Brenda"; Score = 70 }
        { Name = "Bobby"; Score = 90 }
        { Name = "Charlotte"; Score = 98 }
        { Name = "Chuck"; Score = 83 }
        { Name = "Deborah"; Score = 88 }
        { Name = "Dan"; Score = 66 }
        { Name = "Ellie"; Score = 80 }
        { Name = "Ed"; Score = 61 }
        { Name = "Frannie"; Score = 89 }
        { Name = "Frank"; Score = 96 }
    ]

let grouped = 
    grades
    |> Seq.groupBy (fun s -> s.Score / 10 * 10)
// val grouped : seq<int * seq<TestScore>> =
//   seq [
//     (70, seq [ {Name = "Anna"; Score = 74}
//                {Name = "Andy"; Score = 76}
//                {Name = "Brenda"; Score = 70} ] )
//     (90, seq [ {Name = "Bobby"; Score = 90}
//                {Name = "Charlotte"; Score = 98}
//                {Name = "Frank"; Score = 96} ] )
//     (80, seq [ {Name = "Chuck"; Score = 83}
//                {Name = "Deborah"; Score = 88}
//                {Name = "Ellie"; Score = 80}
//                {Name = "Frannie"; Score = 89} ] )
//     (60, seq [ {Name = "Dan"; Score = 66}
//                {Name = "Ed"; Score = 61} ] )
//   ]

You can take it another couple of steps to produce a histogram by counting the number of students in each group and sorting by the group key (i.e., grade level):

let histogram = 
    grouped
    |> Seq.map (fun pair -> 
                    let score = fst pair
                    let count = snd pair
                                |> Seq.length
                    score, count)
    |> Seq.sort
    |> Seq.rev
// val histogram : seq<int * int> =
//   seq [(90, 3); (80, 4); (70, 3); (60, 2)]

One more example, and this one has a little pitfall in it. I borrowed this one from one of Steven Proctor’s Ruby Tuesday posts. You can find anagrams in a list of words by sorting the characters in each word and grouping on that:

let anagrams =
    seq ["tar"; "rat"; "bar"; "rob"; "art"; "orb"]
    |> Seq.groupBy (fun word -> word |> Seq.sort)
// val anagrams : seq<seq<char> * seq<string>> =
//   seq [
//     (seq ['a'; 'r'; 't'], seq ["tar"])
//     (seq ['a'; 'r'; 't'], seq ["rat"])
//     (seq ['a'; 'b'; 'r'], seq ["bar"])
//     (seq ['b'; 'o'; 'r'], seq ["rob"])
//     (seq ['a'; 'r'; 't'], seq ["art"])
//     (seq ['b'; 'o'; 'r'], seq ["orb"])
//   ]

Well, that’s not what I expected. I expected “rat,” “tar,” and “art” to be grouped together, but they’re not. Thanks to the good folks on Stack Overflow, I know what the problem is now: seq is just an alias for a .NET IEnumerable. IEnumerables are not structurally equivalent. That is, two IEnumerable instances are not compared according to their contents. They are compared according to reference value. In other words, if two IEnumerables are not the very same instance, they are not equal.

In order to get Mr. Proctor’s example to work in F#, you have to add one more step to convert the grouping key, currently a seq, to something that is a type that supports structural equivalence, such as an array:

let anagrams =
    seq ["tar"; "rat"; "bar"; "rob"; "art"; "orb"]
    |> Seq.groupBy (fun word -> word 
                                |> Seq.sort 
                                |> Seq.toArray)
// val anagrams : seq<char [] * seq<string>> =
//   seq [
//       ([|'a'; 'r'; 't'|], seq ["tar"; "rat"; "art"])
//       ([|'a'; 'b'; 'r'|], seq ["bar"])
//       ([|'b'; 'o'; 'r'|], seq ["rob"; "orb"])
//   ]

Now, that’s better.

Scala Saturday – Code That Looks Like Math

Something that Scala and most other modern languages allow these days is variable names that contain what you might think of as non-traditional characters from the Unicode character set, e.g., Greek symbols such as π and τ. If you’re a C programmer, you have to settle for spelling out the name of the character:

const double PI = 3.141592654;
double delta = x1 - x2;

But that’s OK, right? What’s the difference, really? The value π is one thing: it’s a universally recognized constant. But even with the example delta above, don’t you want to name it something more descriptive, like marginOfError anyway?

Well, yes, many times instead of using the characters verbatim from your physics textbook …

val f = m * a

… you spell it out so that the code is clearer:

val force = mass * acceleration

Likewise, even though Scala allows you to write the following:

val ω = 2 * math.Pi * f

… it’s probably better practice to write …

val angularVelocity = 2 * math.Pi * frequency

What’s the point of this post then? Sure, you can use “special” characters in variable names, but so far, I’ve discouraged you from doing it!

Nevertheless there are times when it is appropriate. If you are coding up an algorithm that consists of a series of well-known equations in a certain field of study, and the more your code looks like those equations, the easier it is to check it against the literature.

Consider the following—a series of values and equations for converting latitude and longitude to universal polar stereographic (UPS) coordinates, a way of representing coordinates at the earth’s poles:

Values and equations for converting geodetic coordinates (latitude and longitude) into universal polar stereographic (UPS) coordinates
Converting Latitude and Longitude to Universal Polar Stereographic (UPS) Coordinates

UPS coordinates consist of a hemisphere—either northern or southern—and two distance components, easting and northing, both in meters:

object Hemisphere extends Enumeration {
  type Hemisphere = Value

  val Northern = Value('N')
  val Southern = Value('S')

  def fromLatitude(lat: Double): Hemisphere =
    if (lat < 0) Southern else Northern
}

case class UniversalPolarStereographic(
    northing: Double,
    easting: Double,
    hemisphere: Hemisphere)

Now compare the code below to the equations from the literature above:

def latLonToUps(
    lat: Double, 
    lon: Double): UniversalPolarStereographic = {

  val hemisphere = Hemisphere.fromLatitude(lat)

  val φ = lat.abs
  val λ = lon
    
  val π = math.Pi

  val FN = 2000000.0
  val FE = 2000000.0

  val a = 6378137.0
  val f = 1 / 298.257223563

  val e_2 = f * (2 - f)
  val e = math.sqrt(e_2)
  val eOver2 = e / 2
  val Cₒ = ((2 * a) / math.sqrt(1 - e_2)) *
           math.pow((1 - e) / (1 + e), eOver2)
  val kₒ = 0.994
  val πOver4 = π / 4

  val esinφ = e * math.sin(φ)
  val φOver2 = φ / 2

  val tanZOver2 = 
    math.pow((1 + esinφ) / (1 - esinφ), eOver2) *
    math.tan(πOver4 - φOver2)
  val R = kₒ * Cₒ * tanZOver2
  val Rcosλ = R * math.cos(λ)
  val Rsinλ = R * math.sin(λ)

  val N = hemisphere match {
    case Hemisphere.Northern => FN - Rcosλ
    case Hemisphere.Southern => FN + Rcosλ
  }
  val E = FE + Rsinλ

  UniversalPolarStereographic(N, E, hemisphere)
}

It’s not perfect: you still cannot set numerators above denominators, for instance. But isn’t that easier to compare to the literature than if we had to write out RsinLambda or eSinPhi?

(Note: UPS coordinates are only valid for latitudes near the poles. For simplicity, the code above does not check to make sure that the input latitude falls within those bounds. I mean, it’s complex enough as it is for the sake of exemplifying the point of this post.)

(Note: I’m aware that some of the characters in the code don’t show up correctly on all browsers, e.g., the subscript “O” and perhaps the φ. I’m working to correct that. Nevertheless you should be able to use such symbols in your source code.)

F# Friday – Code That Looks Like Math

Something that F# and most other modern languages allow these days is variable names that contain what you might think of as non-traditional characters from the Unicode character set, e.g., Greek symbols such as π and τ. If you’re a C programmer, you have to settle for spelling out the name of the character:

const double PI = 3.141592654;
double delta = x1 - x2;

But that’s OK, right? What’s the difference, really? The value π is one thing: it’s a universally recognized constant. But even with the example delta above, don’t you want to name it something more descriptive, like marginOfError anyway?

Well, yes, many times instead of using the characters verbatim from your physics textbook …

let f = m * a

… you spell it out so that the code is clearer:

let force = mass * acceleration

Likewise, even though F# allows you to write the following:

let ω = 2.0 * Math.PI * f

… it’s probably better practice to write …

let angularVelocity = 2.0 * Math.PI * frequency

What’s the point of this post then? Sure, you can use “special” characters in variable names, but so far, I’ve discouraged you from doing it!

Nevertheless there are times when it is appropriate. If you are coding up an algorithm that consists of a series of well-known equations in a certain field of study, and the more your code looks like those equations, the easier it is to check it against the literature.

Consider the following—a series of values and equations for converting latitude and longitude to universal polar stereographic (UPS) coordinates, a way of representing coordinates at the earth’s poles:

Values and equations for converting geodetic coordinates (latitude and longitude) into universal polar stereographic (UPS) coordinates
Converting Latitude and Longitude to Universal Polar Stereographic (UPS) Coordinates

UPS coordinates consist of a hemisphere—either northern or southern—and two distance components, easting and northing, both in meters:

type Hemisphere = Northern | Southern
type UpdCoord =
    { Hemisphere : Hemisphere
      Easting : float
      Northing : float }

Now compare the code below to the equations from the literature above:

let latLonToUps (lat : float) (lon : float) =
    let hemisphere =
        if lat < 0.0
        then Southern
        else Northern

    let ϕ = abs lat
    let λ = lon

    let π = Math.PI

    let FN = 2000000.0
    let FE = 2000000.0

    let a = 6378137.0
    let f = 1.0 / 298.257223563

    let e_2 = f * (2.0 - f)
    let e = sqrt e_2
    let eOver2 = e / 2.0
    let Cₒ = ((2.0 * a) / sqrt (1.0 - e_2)) *
             (((1.0 - e) / (1.0 + e)) ** eOver2)
    let kₒ = 0.994
    let πOver4 = π / 4.0
    
    let esinϕ = e * (sin ϕ)
    let ϕOver2 = ϕ / 2.0

    let tanZOver2 = 
        (((1.0 + esinϕ) / (1.0 - esinϕ)) ** eOver2) *
        tan (πOver4 - ϕOver2)
    let R = kₒ * Cₒ * tanZOver2
    let Rcosλ = R * (cos λ)
    let Rsinλ = R * (sin λ)

    let N = match hemisphere with
            | Northern -> FN - Rcosλ
            | Southern -> FN + Rcosλ
    let E = FE + Rsinλ

    { Hemisphere = hemisphere
      Easting = E
      Northing = N }

It’s not perfect: you still cannot set numerators above denominators, for instance. But isn’t that easier to compare to the literature than if we had to write out RsinLambda or eSinPhi?

(Note: UPS coordinates are only valid for latitudes near the poles. For simplicity, the code above does not check to make sure that the input latitude falls within those bounds. I mean, it’s complex enough as it is for the sake of exemplifying the point of this post.)

(Note: I’m aware that some of the characters in the code don’t show up correctly on all browsers, e.g., the subscript “O” and perhaps the φ. I’m working to correct that. Nevertheless you should be able to use such symbols in your source code.)

One final example of something that F# allows you to do that no other language to my knowledge allows: using single-quote marks in variable names. Why would you ever want to do such a thing? One example is derivatives. In calculus, a prime (′) indicates a first derivative, and a double prime (″) indicates the second derivative. The following is how you could represent kinematics calculations:

let x = x0 + (v * t) + (0.5 * a * (t ** 2.0))
let x' = v + (a * t)
let x'' = a

Another case I’ve seen is when you have a value or function that is closely associated with another value/function in some obvious way. If they are in close proximity to each other, it doesn’t make sense to come up with wholly different names. Consider this factorial function:

let factorial n =
    let rec factorial' n acc =
        if n <= 0 
        then acc
        else factorial' (n - 1) (n * acc)
    
    factorial' n 1

The inner function does the work. The outer function is just an interface to the inner function. All the factorial does is to make the initial call factorial' with a little bit of setup. The factorial function is a nice interface for the user of the function; the factorial' name indicates to developers that it is doing the heavy lifting.

Scala Saturday – Array.last and Array.lastOption

Last week, we looked at List.headOption. If you don’t need the first item in a list, but rather the last item, the counterpart of List.head is List.last. Likewise, the counterpart of List.headOption is List.lastOption.

Recall the code example from last week:

case class Salesman(name: String, sales: BigDecimal)

def findTopSalesman (salesmen : List[Salesman]) = {
  salesmen.filter { _.sales >= 10000 }
          .sortBy { -_.sales } // descending
          .headOption
}

val sales = List(
  Salesman("Joe Bob", 9500),
  Salesman("Sally Jane", 18500),
  Salesman("Betty Lou", 11800),
  Salesman("Sammy Joe", 6500)
)

val top = findTopSalesman(sales)
// top: Option[Salesman] = 
//   Some(Salesman(Sally Jane,18500))

The List.sortBy call (highlighted above) sorts the sales records in a descending fashion so that the first record is the top salesman. What if it makes more sense to you to sort the records in an ascending fashion and take the last record? With List.lastOption, you can:

case class Salesman(name: String, sales: BigDecimal)

def findTopSalesman (salesmen : List[Salesman]) = {
  salesmen.filter { _.sales >= 10000 }
          .sortBy { _.sales } // ascending
          .lastOption
}

val sales = List(
  Salesman("Joe Bob", 9500),
  Salesman("Sally Jane", 18500),
  Salesman("Betty Lou", 11800),
  Salesman("Sammy Joe", 6500)
)

val top = findTopSalesman(sales)
// top: Option[Salesman] = 
//   Some(Salesman(Sally Jane,18500))

This is a trivial example: I mean, you can sort the records however you wish; they’re your records! But what if you receive the recordset from elsewhere—an API that is outside your control, for instance—and it is already sorted in an ascending fashion. It is probably better to accept the recordset as is and just take the last item rather than to sort it again. Which brings me to another couple of other points …

This post claims to be about Array.last and Array.lastOption. Why all the talk about List.lastOption?

First, as you have probably noticed already, just about any method available on one sequential collection is available on them all. That is, if there’s a List.last, for example, then there’s also a Seq.last, an Array.last, and a Stream.last.

Second, I want to point out a potential pitfall of using last and lastOption. Both the size and type of the collection can affect the performance of your program or even crash it.

Arrays give you O(1) access to their elements. (In case you’re not familiar with it, that’s called “Big O notation.” It’s a way of expressing how long an algorithm takes to execute.) That is, arrays give you nearly instant access to any element—first, last, somewhere in the middle—doesn’t matter.

Lists and sequences, on the other hand, give you O(n) access to their elements. That is, the more items in the list/sequence, the longer it takes to get to the one you want because the machine always has to start at the first element and iterate through every single one until it gets to the one you want. No big deal if there are only 100 elements, but if there are 10,000,000 elements, fetching the last element will take a while.

Furthermore, streams can be infinite. If you call Stream.last or Stream.lastOption on an infinite sequence, your program will crash:

// This sequence starts at one and just keeps going
val ns = Stream.from(1)
val notGood = ns.last
// java.lang.OutOfMemoryError: GC overhead limit exceeded

You don’t have to eschew last and lastOption. Just take into account what kind of collection you’re calling them on. Array.last and Array.lastOption are perfectly safe. (Well, do remember that Array.last throws an exception if the array is empty, but with regard to performance, it’s fine.) But before you call last or lastOption on a list or a stream, make sure you know how big it is, or you could, as they say, shoot yourself in the foot.

F# Friday – Array.last and Array.tryLast

Last week, we looked at List.tryHead. If you don’t need the first item in a list, but rather the last item, the counterpart of List.head is List.last. Likewise, the counterpart of List.tryHead is List.tryLast.

Recall the code example from last week:

type Salesman = { Name : string
                  Sales : decimal }
 
let findTopSalesman salesmen =
    salesmen
    |> List.filter (fun s -> s.Sales >= 10000M)
    |> List.sortBy (fun s -> -s.Sales) // descending
    |> List.tryHead

let sales =
    [
        { Name = "Joe Bob"; Sales = 9500M }
        { Name = "Sally Jane"; Sales = 18500M }
        { Name = "Betty Lou"; Sales = 11800M }
        { Name = "Sammy Joe"; Sales = 6500M }
    ]
 
let top = findTopSalesman sales
// val top : Salesman option = 
//   Some {Name = "Sally Jane";
//         Sales = 18500M;}

The List.sortBy call (highlighted above) sorts the sales records in a descending fashion so that the first record would be the top salesman. What if it makes more sense to you to sort the records in an ascending fashion and take the last record? With List.tryLast, you can:

type Salesman = { Name : string
                  Sales : decimal }
 
let findTopSalesman salesmen =
    salesmen
    |> List.filter (fun s -> s.Sales >= 10000M)
    |> List.sortBy (fun s -> s.Sales) // ascending
    |> List.tryLast

let sales =
    [
        { Name = "Joe Bob"; Sales = 9500M }
        { Name = "Sally Jane"; Sales = 18500M }
        { Name = "Betty Lou"; Sales = 11800M }
        { Name = "Sammy Joe"; Sales = 6500M }
    ]
 
let top = findTopSalesman sales
// val top : Salesman option = 
//   Some {Name = "Sally Jane";
//         Sales = 18500M;}

This is a trivial example: I mean, you can sort the records however you wish; they’re your records! But what if you receive the recordset from elsewhere—an API that is outside your control, for instance—and it is already sorted in an ascending fashion. It is probably better to accept the recordset as is and just take the last item rather than to sort it again. Which brings me to another couple of other points …

This post claims to be about Array.last and Array.tryLast. Why all the talk about List.tryLast?

First, one of the things the F# team did in F# 4.0 was to normalize the sequential collections modules. Now just about any function available in one sequential collection module is available in them all. That is, if there’s a List.last, for example, then there’s also a Seq.last and an Array.last.

Second, I want to point out a potential pitfall of using last and tryLast. Both the size and type of the collection can affect the performance of your program or even crash it.

Arrays give you O(1) access to their elements. (In case you’re not familiar with it, that’s called “Big O notation.” It’s a way of expressing how long an algorithm takes to execute.) That is, arrays give you nearly instant access to any element—first, last, somewhere in the middle—doesn’t matter.

Lists and sequences, on the other hand, give you O(n) access to their elements. That is, the more items in the list/sequence, the longer it takes to get to the one you want because the machine always has to start at the first element and iterate through every single one until it gets to the one you want. No big deal if there are only 100 elements, but if there are 10,000,000 elements, fetching the last element will take a while.

Furthermore, sequences can be infinite. If you call Seq.last or Seq.tryLast on an infinite sequence, your program will crash:

let init n = n + 1
// This sequence starts at one and just keeps going
let ns = Seq.initInfinite init
let notGood = ns |> Seq.last
// Unhandled Exception: System.InvalidOperationException: 
//   Enumeration based on System.Int32 exceeded 
//   System.Int32.MaxValue.

You don’t have to eschew last and tryLast. Just take into account what kind of collection you’re calling them on. Array.last and Array.tryLast are perfectly safe. (Well, do remember that Array.last throws an exception if the array is empty, but with regard to performance, they’re fine.) But before you call last or tryLast on a list or a sequence, make sure you know how big it is, or you could, as they say, shoot yourself in the foot.

Scala Saturday – List.headOption

Sometimes you need to get the first element of a list. No problem: List.head to the rescue, right? But what happens when you call List.head on an empty list?

val xs = List[Int]()
val h = xs.head
// java.util.NoSuchElementException: head of empty list

Well that’s not good. You could get around that little wart with this:

val xs = List[Int]()
val h = xs match {
  case h :: _ => h
  case Nil => -1
}

That’s not great. Alternatively, there’s this:

val xs = List[Int]()
val h = if (xs.isEmpty) -1 else xs.head
// h: Int = -1

Yeah, I’m not wild about those options either.

Speaking of options, what if you had a method that returns a None if you ask for the head of an empty list? If the list is not empty, it could return a Some containing the value of the head element. List.headOption does just that.

val empty = List[Int]()
val nonempty = (9 to 17).toList

val nuthin = empty.headOption
// nuthin: Option[Int] = None

val sumthin = nonempty.headOption
// sumthin: Option[Int] = Some(9)

Now you can use Option.getOrElse on the result of a call to List.headOption in order to return a default value in the event of an empty list:

val empty = List[Int]()
val nonempty = (9 to 17).toList

val head = nonempty.headOption getOrElse -1
// head: Int = 9

val fallback = empty.headOption getOrElse -1
// fallback: Int = -1

Now when might you actually use something like this? Perhaps you want to determine the top salesman each day, but only if the salesman has reached a certain threshold, say, $10,000. You can filter out the salesmen who don’t reach the threshold, sort the list of salesmen according to end-of-day sales totals, and then try to take the head element. If no one makes the cut, then the filter operation returns an empty list, which ultimately yields a None.

case class Salesman(name: String, sales: BigDecimal)

def findTopSalesman (salesmen : List[Salesman]) = {
  salesmen.filter { _.sales >= 10000 }
    .sortBy { -_.sales } // descending
    .headOption
}

So then, if Monday’s sales are as follows, then no one gets the prize because no one has broken $10,000:

val monday = List(
  Salesman("Joe Bob", 9500),
  Salesman("Sally Jane", 8500),
  Salesman("Betty Lou", 9800),
  Salesman("Sammy Joe", 6500)
)

val mondayTop = findTopSalesman(monday)
// mondayTop: Option[Salesman] = None

On Tuesday, though, there are two contenders. Alas, there can be only one winner, and Sally Jane (who, ironically, is from British Columbia) takes the prize:

val tuesday = List(
  Salesman("Joe Bob", 9500),
  Salesman("Sally Jane", 18500),
  Salesman("Betty Lou", 11800),
  Salesman("Sammy Joe", 6500)
)

val tuesdayTop = findTopSalesman(tuesday)
// tuesdayTop: Option[Salesman] = 
//   Some(Salesman(Sally Jane,18500))

F# Friday – List.tryHead

Sometimes you need to get the first element of a list. No problem: List.head to the rescue, right? But what happens when you call List.head on an empty list?

let xs : int list = []
let h = xs |> List.head
// System.ArgumentException: The input list was empty.

Well that’s not good. You could get around that little wart with this:

let xs : int list = []
let h = if xs |> List.isEmpty 
        then -1
        else xs |> List.head
// val h : int = -1

That’s not great. Alternatively, there’s this:

let xs : int list = []
let h = match xs with
        | h :: _ -> h
        | [] -> -1
// val h : int = -1

Yeah, I’m not wild about those options either.

Speaking of options, what if you had a method that returns a None if you ask for the head of an empty list? If the list is not empty, it could return a Some containing the value of the head element. Another new method in F# 4.0 is List.tryHead, and it does just that.

let empty : int list = []
let nonempty = [9..17]

let nuthin = empty |> List.tryHead
// val nuthin : int option = None

let sumthin = nonempty |> List.tryHead
// val sumthin : int option = Some 9

Now you can use defaultArg on the result of a call to List.tryHead in order to return a default value in the event of an empty list:

let empty : int list = []
let nonempty = [9..17]

let head = defaultArg (List.tryHead nonempty) -1
// val head : int = 9

let fallback = defaultArg (List.tryHead empty) -1
// val fallback : int = -1

Now when might you actually use something like this? Perhaps you want to determine the top salesman each day, but only if the salesman has reached a certain threshold, say, $10,000. You can filter out the salesmen who don’t reach the threshold, sort the list of salesmen according to end-of-day sales totals, and then try to take the head element. If no one makes the cut, then the filter operation returns an empty list, which ultimately yields a None.

type Salesman = { Name : string
                  Sales : decimal }

let findTopSalesman salesmen =
    salesmen
    |> List.filter (fun s -> s.Sales >= 10000M)
    |> List.sortBy (fun s -> -s.Sales) // descending
    |> List.tryHead

So then, if Monday’s sales are as follows, then no one gets the prize because no one has broken $10,000:

let monday = 
    [
        { Name = "Joe Bob"; Sales = 9500M }
        { Name = "Sally Jane"; Sales = 8500M }
        { Name = "Betty Lou"; Sales = 9800M }
        { Name = "Sammy Joe"; Sales = 6500M }
    ]

let mondayTop = findTopSalesman monday
// val mondayTop : Salesman option = None

On Tuesday, though, there are two contenders. Alas, there can be only one winner, and Sally Jane (who, ironically, is from British Columbia) takes the prize:

let tuesday =
    [
        { Name = "Joe Bob"; Sales = 9500M }
        { Name = "Sally Jane"; Sales = 18500M }
        { Name = "Betty Lou"; Sales = 11800M }
        { Name = "Sammy Joe"; Sales = 6500M }
    ]

let tuesdayTop = findTopSalesman tuesday
// val tuesdayTop : Salesman option = 
//   Some {Name = "Sally Jane"; Sales = 18500M;}