As some of you know, I’ve been writing a book (to be published by CRC Press/Chapman & Hall and released in late 2014) for the past year and a half. It’s one of those books that spans multiple disciplines so is both unique and also niche. In essence it’s a manifesto of sorts on using functional programming for mathematical modeling and analysis, which is based on my R package lambda.r. It spans the lambda calculus, traditional mathematical analysis, and set theory to 1) develop a mathematical model for the R language, and 2) show how to use this formalism to prove the equivalence of programs to their underlying model. I try to keep the book focused on applications, so I discuss financial trading systems, some NLP/document classification, and also web analytics.

The book started off as a more practical affair, but one thing that I’ve learned through this process is how to push ideas to the limit. So now it delves into quite a bit of theory, which makes it a more compelling read. In some ways it reminds me of ice climbing, where you’re scaling a waterfall and really pushing yourself in ways you didn’t think possible. Three chapters into the process, and it’s been that same combination of exhilarating challenge that results in conflicting thoughts racing through your head: “Holy crap — what am I doing?!” versus “This is so fun — wheeeee!” versus “I can’t believe I did it!”

That said, this book pushes some new territory. Many of the ideas are experimental and provisional. The proofs probably could use some work. So in the spirit of openness I’m looking to share my thoughts and get feedback from the general community on the ideas within the pages. Issues I already know about include:

- Images need to be cleaned up. Some are in color, others need to be scaled
- Some proofs are incomplete. Their absence shouldn’t impact the content
- Some examples need to be completed. Again, it shouldn’t impact the overall reading of the material.

Read the draft: Rowe – Modeling data with functional programming. Any comments are greatly appreciated.

0.000000
0.000000

### Like this:

Like Loading...

*Related*

EN

said:Only had a moment to look at the first few pages but it looks very interesting. And what a great thing to put the manuscript online! Just a quick erratum note: in table 1.1, when a function includes a square term, it is rendered as a “hat” over the 2, rather than ^2. The same problem likely exists in other places…

Paul Courtney

said:Actually, I have generally seen the ^ used prior to the exponent, as in 100=10^2. If you could point out and example of the hat being used over the 2 I would appreciate learning about other notations!

Cheers,

Paul Courtney

Brian Lee Yung Rowe

said:Actually he’s saying that the caret is being rendered as a hat over the numeral as opposed to being a literal caret. That’s due to bad LaTeX on my part.

Brian Lee Yung Rowe

said:Thanks that looks like a LaTeX fail on my part.

Paul Courtney

said:Thanks, looks like I misunderstood his comment.

Seth Roberts

said:I think you need more motivation for all that abstraction. One way to do this would be to have an example right at the start. 1. here is some data. 2. here is an old way of modelling it. 3. here is a new way of modelling it you can learn from this book.

Brian Lee Yung Rowe

said:Thanks for this. The question in my mind is whether an upfront case study to illustrate the advantage of this approach can be appreciated without the theory. Certain aspects I think can be demonstrated with basic exposition and diagrams, but the true power is seeing how the concepts tie together. In essence what I’m trying to get across is that the tools of functional programming are the tools of mathematics.

John Quarto-vonTivadar

said:except you can’t get that point across if someone decides not to buy/read the book. Seth’s comment addresses the needs of more than half the population who do *not* process along the lines of “ahha! great theory! now I’m ready for some example to clear up details” but rather as “You’re asking me to invest X days reading this book. Can’t you make a case for what’s in it for me, concretely, in less than 15 minutes?”

I recall a fascinating book that came out 10 or so years ago (on personality types and how we process information), entitled “I’m not crazy, I’m just not you.”

Brian Lee Yung Rowe

said:That’s only partially true, as my students won’t have a choice :) Seriously though, this is a fair point. Perhaps I’ll post some examples on the blog to see which ones (and which approaches) resonate with people the most.

gwern

said:And in the other direction, one could use some motivation for why R. As a long-time Haskeller, my reaction to hearing ‘functional programming in R’ is not ‘why functional programming?’ but ‘why on earth are you doing functional programming *in R*?’

Brian Lee Yung Rowe

said:You could say the same thing about “why object-oriented programming in R?”, which is the predominant paradigm for writing larger applications in R. If you are just doing exploratory data analysis, then a programming paradigm isn’t really necessary, although even here you’ll see that the language of mathematics overlaps with functional programming by quite a bit. I will discuss this point further in my book as apparently it is not immediately obvious to people.

Justin Rising

said:I’ve been looking forward to this ever since you first mentioned it, so I’m pretty excited to see the draft and I’ll be reading it over the next few weeks.

Brian Lee Yung Rowe

said:Thanks for the kind words. Looking forward to the feedback.

Ilya

said:Mmmm, I skimmed through it and while the theory is nice, it’d be amazing if it were illustrated within the context of examples. As someone who just has a master’s degree and finds the whole format of endless equation, theorem, proof, corollary format very difficult to follow, it’d be fantastic if the theory could be stepped through with an example in both math and code, the way more…digestible…texts do it. Otherwise, I feel like I’d just be skimming right past the math, and going straight to the code.

John Quarto-vonTivadar

said:more errata: in section 1.2.1 the equation x^2+3x+10 should be x^2+3x-10 (MINUS 10!) if you want the factors to be (x-2) and (x+5) as the rest of the algebraic division implies

on another note: it’d be nice to be able to sign-up to a mailing list that will let us know when new versions of the book become available. I’m worried I will forget about it.

Brian Lee Yung Rowe

said:Re: mailing list, great idea. Let me talk to my editor and see if he has something for this purpose. Otherwise I’ll figure something else out.

Robert Young

said:Since it was, and still seems to be, that the application of mechanistic methods, e.g. GBM, to human decision making led to The Great Recession (“house prices have risen, so they always will!!”), perhaps some words (in the Preface?) defining when and why such quant methods are appropriate. Methods which conjure such a collapse are wanting of something, don’t you think?

Some folks in the quant field have voiced mea culpa, while others have j’accuse to their fellow quants.

John Quarto-vonTivadar

said:I wish I knew what this meant in English.

Robert Young

said:It means that quants, as a whole, crashed the global economy using models which asserted that today was mostly like yesterday, and tomorrow will be mostly like today. CDOs were perfect, and we’ll all buy more.

ken jarrad

said:I’d like to submit errata and questions about parts of the book I don’t understand. I see that some errors are already noted so is there a list? Can I send an email to the author?

Brian Lee Yung Rowe

said:Ken, Feel free to email me at rowe@zatonovo.com for any errata and questions. Looking forward to the comments. Brian