in Code


Justin Le

Welcome! My name is Justin Le. I’m a PhD student at Chapman University in California, studying Computational Science & Applied Maths; I studied Physics and Computer Science at University of California, San Diego :)

This is just my weblog covering my various adventures in programming and explorations in the vast worlds of computation, physics, engineering, mathematics, and knowledge. Expect a healthy curiosity and an only slightly unhealthy obsession for finding new ways to marvel, wonder, and create. Join me if you wish!

Check out my most popular articles: Inside My World (Ode to Functor and Monad) and “IO Monad” Considered Harmful!

Recent Entries

  • Practical Dependent Types in Haskell 2: Existential Neural Networks and Types at Runtime

    We’re back to continue on our journey in using dependent types to write type-safe neural networks! In Part 1, we wrote things out in normal, untyped Haskell, and looked at red flags and general design principles that nudged us in the direction of adding dependent types to our program. We learned to appreciate what dependent types offered in terms of guiding us in writing our code, helping the compiler check our correctness, providing a better interface for users, and more.

    We also learned how to use singletons to work around some of Haskell’s fundamental limitations to let us “pattern match” on the structure of types, and how to use typeclasses to generate singletons reflecting the structure of types we are dealing with.

    (If you read Part 1 before the singletons section was re-written to use the singletons library, here’s a link to the section in specific. This tutorial will assume familiarity with what is discussed there!)

    All of what we’ve dealt with so far has essentially been with types that are fixed at compile-time. All the networks we’ve made have had “static” types, with their sizes in their types indicated directly in the source code. In this post, we’re going to dive into the world of types that depend on factors unknown until runtime, and see how dependent types in a strongly typed language like Haskell helps us write safer, more correct, and more maintainable code.

    This post was written for GHC 8 on stackage snapshot nightly-2016-06-28, but should work with GHC 7.10 for the most part. All of the set-up instructions and caveats (like the singletons-2.0.1 bug affecting GHC 7.10 users and the unreleased hmatrix version) are the same as for part 1’s setup.

    All of the code in this post is downloadable as a standalone source file so you can follow along!

    Read more … Comments

  • Practical Dependent Types in Haskell: Type-Safe Neural Networks (Part 1)

    It seems these days like programming with dependent types in Haskell (and its advantages) is moving slowly but steadily to the mainstream of Haskell programming. In the current state of Haskell education, dependent types are often considered topics for “advanced” Haskell users. However, I can foresee a day where the ease of use of modern Haskell libraries relying on dependent types forces programming with dependent types to be an integral part of normal intermediate (or even beginner) Haskell education.

    There are more and more and more and more great resources and tutorials and introductions to integrating dependent types into your Haskell every day. The point of this series is to show more some practical examples of using dependent types in guiding your programming, and to also walk through the “why” and high-level philosophy of the way you structure your Haskell programs. It’ll also hopefully instill an intuition of a dependently typed work flow of “exploring” how dependent types can help your current programs. The intended audience of this post is for intermediate Haskell programmers in general, with no required knowledge of dependently typed programming. I should also point out that I’m no expert — I’m still in the process of learning this all, myself :)

    The first project in this series will build up to a type-safe artificial neural network implementation with back-propagation training.

    Read more … Comments

  • Automatic Propagation of Uncertainty with AD

    This post and series is a walk-through of the implementation of my uncertain library, now on hackage!

    Some of my favorite Haskell “tricks” involve working with exotic numeric types with custom “overloaded” numeric functions and literals that let us work with data in surprisingly elegant and expressive ways.

    Here is one example — from my work in experimental physics and statistics, we often deal with experimental/sampled values with inherent uncertainty. If you ever measure something to be 12.3\,\mathrm{cm}, that doesn’t mean it’s 12.300000\,\mathrm{cm} — it means that it’s somewhere between 12.2\,\mathrm{cm} and 12.4\,\mathrm{cm}…and we don’t know exactly. We can write it as 12.3 \pm 0.1\,\mathrm{cm}. The interesting thing happens when we try to add, multiply, divide numbers with uncertainty. What happens when you “add” 12 \pm 3 and 19 \pm 6?

    The initial guess might be 31 \pm 9, because one is \pm 3 and the other is \pm 6. But! If you actually do experiments like this several times, you’ll see that this isn’t the case. If you tried this out experimentally and simulate several hundred trials, you’ll see that the answer is actually something like 31 \pm 7. (We’ll explain why later, but feel free to stop reading this article now and try this out yourself!1)

    Let’s write ourselves a Haskell data type that lets us work with “numbers with inherent uncertainty”:

    ghci> let x = 14.6 +/- 0.8
    ghci> let y = 31   +/- 2
    ghci> x + y
    46 +/- 2
    ghci> x * y
    450 +/- 40
    ghci> sqrt (x + y)
    6.8 +/- 0.2
    ghci> logBase y x
    0.78 +/- 0.02
    ghci> log (x**y)
    85.9 +/- 0.3

    1. You can simulate noisy data by using uniform noise distributions, Gaussian distributions, or however manner you like that has a given expected value (mean) and “spread”. Verify by checking the standard deviation of the sums!

    Read more … Comments

  • Blog Rewrite with Hakyll and Purescript

    It’s been almost a year since my last post! Things have been a bit hectic with research and related things, and with the unrelenting academia publishing cycle, any time I can get to write or explore has been a nice escape.

    Admittedly, I’ve also run into some friction updating my blog because it was a compiled web server with some delicate dependencies and required environment configuration to build/deploy. It was written/built at a time when a lot of the infrastructure we have now in the Haskell ecosystem either wasn’t there, or wasn’t mature. We didn’t have easy Heroku deployment, and we didn’t have great tools like stack to let us create reproducible builds. One of my first posts in 2013 was actually about hoops to jump through just to get a simple Heroku deployment. I’ve had to maintain a virtual machine just to compile and push changes!

    My blog was one of my first Haskell projects ever, and if I had started it now, in 2016, things would definitely be a bit different. By this point, it’s been long enough and the slight inconveniences have been building up enough that I thought it’d be time to sit down and finally migrate my “first large-ish Haskell project” and bring it into modern times, by using hakyll and purescript. Here are my thoughts and observations on how the migration went, with insight on Haskell migrations in general!

    My blog engine is open-source, and the source for this specific instance is up on github, for those interested in checking it out!

    Read more … Comments

  • Introducing the “Prompt” library

    Prompt: README / hackage / github

    Have you ever wanted to specify a computation involving some limited form of IO — like querying a database, or asking stdio — but didn’t want a computation in the IO monad, opening the entire can of worms that is arbitrary IO? Have you ever looked at complicated IO a you wrote last week at 4am and prayed that it didn’t launch missiles if you decided to execute it? Do you want to be able to run an effectful computation and explicitly say what IO it can or cannot do?

    Introducing the prompt library! It’s a small little lightweight library that allows you to specify and describe computations involving forms of effects where you “ask” with a value and receive a value in return (such as a database query, etc.), but not ever care about how the effects are fulfilled — freeing you from working directly with IO.

    data Foo = Foo { fooBar :: String
                   , fooBaz :: Int
                   } deriving Show
    
    -- ask with a String, receive a String as an answer
    promptFoo :: Prompt String String Foo
    promptFoo = Foo
            <$> prompt "bar"
            <*> fmap length (prompt "baz")

    Read more … Comments

  • mtl is Not a Monad Transformer Library

    mtl is not a monad transformer library — contrary to popular conception. I believe that this commonly spread myth is due in part to some rather peculiar branding choices (the name of the library) and in part to some historical accidents (mtl was, in the distant and pre-historic past, indeed a monad transformer library).

    What is mtl? It is a library of interfaces you can provide to your own types, in the form of typeclasses. It abstracts over different design patterns for different types, in the form of typeclasses. Just like Functor abstracts over “things that can be fmapped”. mtl provides typeclasses abstracting over many useful patterns that many types satisfy — patterns involving different sorts of “effects”.

    Read more … Comments

  • Fixed-Length Vector Types in Haskell, 2015

    Fixed-length vector types (vector types that indicate the length of the vector in the type itself) are one of the more straightforward applications of the “super-Haskell” GHC type extensions. There’s a lot of magic you can do with GHC’s advanced type mechanisms, but I think fixed length vectors are a good first step to beginning to understand several extensions, including (potentially):

    • ConstraintKinds
    • DataKinds
    • GADTs
    • KindSignatures
    • TypeFamilies
    • TypeOperators
    • OverloadedLists

    And using type system plugins. (And of course the usual UndecidableInstances etc.) We’ll be discussing two different ways to implement this — using type-level nats, and using the GHC.TypeLits model to actually be able to use numeric literals in your types. These things are seen in the wild like with the popular linear package’s V type.

    There are a few great tutorials/writeups on this topic, but many of them are from the time before we had some of these extensions, or only discuss a few. I hope to provide a nice comprehensive look about the tools available today to really approach this topic. That being said, I am no expert myself, so I would appreciate any tips/edits/suggestions for things that I’ve missed or done not-the-best :) This post has a lot of open questions that I’m sure people who know more about this than me can answer.

    Most of the code in this article can be downloaded and tried out, so follow along if you want!

    Read more … Comments

  • Unique sample drawing & searches with List and StateT — “Send more money”

    Nothing too crazy today, just a cute (basic/intermediate) haskell trick as a response to Mark Dominus’s excellent Universe of Discourse post on Easy exhaustive search with the list monad intended for people new or unfamiliar with haskell demonstrating the common “list monad as a constraint solver” approach that is standard fare for learning Haskell. I myself have literally done an entire series of blog posts on this usage.

    Mark’s use case however incorporates a bit of an extra pattern not typically discussed. The list monad is good for taking “independent samples” of things (looking at different samples from a list):

    ghci> do x <- "abc"
             y <- "abc"
             z <- "abc"
             return [x,y,z]
    ["aaa","aab","aac","aba","abb" ... ]

    However, what if you wanted to instead “draw” from a pool, and represent different drawings? Traditionally, the answer was something like:

    ghci> do x <- "abc"
             y <- filter (/= x) "abc"
             z <- filter (/= y) . filter (/= x) $ "abc"
             return [x,y,z]
    "abc","acb","bac","bca","cab","cba"]

    This is a little bit awkward…and it definitely gets a lot worse (O(n^2)) when you have more items. Also, it relies on an Eq constraint — what if our thing doesn’t have an Eq instance? And this also falls apart when our list contains duplicate items. If we had used "aabc" instead of "abc", the result would be the same — despite having more 'a's to pick from!

    Read more … Comments