Monday, June 29, 2015

Tabular and Visual Representations of Data using Neo4J

Corporate and Employee Relationships
Both Graphical and Tabular Results

So, there are many ways to view data, and people may have different needs for representing that data, either for visualization (in a graph:node-edges-view) or for tabulation/sorting (in your standard spreadsheet view).

So, can Neo4J cater to both these needs?

Yes, it can.

Scenario 1: Relationships of owners of multiple companies

Let's say I'm doing some data exploration, and I wish to know who has interest/ownership in multiple companies? Why? Well, let's say I'm interested in the Peter-Paul problem: I want to know if Joe, who owns company X is paying company Y for whatever artificial scheme to inflate or to deflate the numbers of either business and therefore profit illegally thereby.

Piece of cake. Neo4J, please show me the owners, sorted by the number of companies owned:

RETURN p.ssn AS Owner, collect( as Companies, count(r) as Count 

Diagram 1: Owners by Company Ownership

Boom! There you go. Granted, this isn't a very exciting data set, as I did not have many owners owning multiple companies, but there you go.

What does it look like as a graph, however?

MATCH (o:OWNER)--(p:PERSON)-[r:OWNS]->(c:CORP)-[:EMPLOYS]->(p1) 
WHERE p.ssn in [2879,815,239,5879] 
RETURN o,p,c,p1

Diagram 2: Some companies with multiple owners

To me, this is a richer result, because it now shows that owners of more than one company sometimes own shares in companies that have multiple owners. This may yield interesting results when investigating associates who own companies related to you. This was something I didn't see in the tabular result.

Not a weakness of Neo4J: it was a weakness on my part doing the tabular query. I wasn't looking for this result in my query, so the table doesn't show it.

Tellingly, the graph does.

Scenario 2: Contract-relationships of companies 

Let's explore a different path. I wish to know, by company, the contractual-relationships between companies, sorted by companies with the most contractual-relationships on down. How do I do that in Neo4J?

RETURN as Contractor, collect( as Contractees, count(cc) as Count 

Diagram 3: Contractual-Relationships between companies

This is somewhat more fruitful, it seems. Let's, then, put this up into the graph-view, looking at the top contractor:

MATCH (p:PERSON)--(c:CORP)-[:CONTRACTS*1..2]->(c1:CORP)--(p1:PERSON) 
WHERE in ['YFB'] 
RETURN p,c,c1,p1

Diagram 4: Contractual-Relationships of YFB

Looking at YFB, we can see contractual-relationships 'blossom-out' from it, as it were, and this is just immediate, then distance 1 from that out! If we go out even just distance 1 more in the contracts, the screen fills with employees, so then, again, you have the forest-trees problem where too much data is hiding useful results with data.

Let's prune these trees, then. Do circular relations appear?

MATCH (c:CORP)-[:CONTRACTS*1..5]->(c1:CORP) WHERE in ['YFB'] RETURN c,c1

Diagram 5: Circular Relationship found, but not in YFB! Huh!

Well, would you look at that. This shows the power of the visualization aspect of graph databases. I was examining a hot-spot in corporate trades, YFB, looking for irregularities there. I didn't find any, but as I probed there, a circularity did surface in downstream, unrelated companies: the obvious one being between AZB and MZB, but there's also a circular-relationship that becomes apparent starting with 4ZB, as well. Yes, this particular graph is noisy, but it did materialize an interesting area to explore that may very well have been overlooked with legacy methods of investigation.

Graph Databases.


Saturday, June 20, 2015

Business Interrelations as a Graph

We look at a practical application of Graph Theory to take a complex representation of information and distill it to something 'interesting.' And by 'interesting,' I mean: finding a pattern in the sea of information otherwise obscured (sometimes intentionally) by all the overwhelming availability of data.

We'll be working with a graph database created from biz.csv, so to get this started, load that table into neo4j:

LOAD CSV WITH HEADERS FROM "file:///[...]/biz.csv" AS csvLine
MERGE (b1:CORP { name: csvLine.contractor })
MERGE (b2:CORP { name: csvLine.contractee })

MERGE (b1)-[:CONTRACTS]->(b2)

We got to a graph of business interrelations this past week (see, e.g.: showing who contracts with whom, and came to a pretty picture like this from the Cypher query:

MATCH (o:OWNER)--(p:PERSON)-[]->(c:CORP) RETURN o,p,c

diagram 1: TMI

That is to say: the sea of information. Yes, we can tell that businesses are conducting commerce, but ... so what? That's all well and good, but let's say that some businesses want to mask how much they are actually making by selling their money to other companies, and then getting it paid back to them. This is not an impossibility, and perhaps it's not all that common, but companies are savvy to watch dogs, too, so it's not (usually) going to be an obvious A -[contracts]-> B -[contracts] -> A relationship.

Not usually, sometimes you have to drill deeper, but if you drill too deeply, you get the above diagram which tells you nothing, because it shares too much information.

(Which you never want to do ... not on the first date, anyway, right?)

But the above, even though noisy, does show some companies contracting with other companies, and then, in turn being contracted by some companies.

So, let's pick one of them. How about company 'YPB,' for example? (Company names are changed to protect the modeled shenanigans)


diagram 2: tier 1 of YPB

So, in this first tier we see YPB contracting with four other companies. Very nice. Very ... innocuous. Let's push this inquiry to the next tier, is there something interesting happening here?


diagram 3: tier 2 of YPB

Nope. Or what is interesting is to see the network of businesses and their relationships (at this point, not interrelationships) begin to extend the reach. You tell your friends, they tell their friends, and soon you have the MCI business-model.

But we're not looking at MCI. We're looking at YPB, which is NOT MCI, I'd like to say for the record.

Okay. Next tier:


diagram 4: tier 3 of YPB

Okay, a little more outward growth. Okay. (trans: 'meh') How about the next tier, that is to say: tier 4?


diagram 5: tier 4 of YPB

So, we've gone beyond our observation cell, but still we have no loop-back to YPB. Is there none (that is to say: no circular return to YPB)? Let's push it one more time to tier 5 and see if we have a connection.


diagram 6: tier 5 with a (nonobvious) cycle of contracts

Bingo. At tier 5, we have a call-back.

But from whom?

Again, we've run into the forest-trees problem in that we see we have a source of YPB, and YPB is the destination, as well, but what is the chain of companies that close this loop. We can't see this well in this diagram, as we have so many companies. So let's zoom into the company that feeds money back to YPB and see if that answers our question.


diagram 7: cycle of contracts from YPB

Aha! There we go. By focusing our query the information leaps right out at us. Behold, we're paying Peter, who pays Paul to pay us back, and it's there, plain as day.

Now, lock them up and throw away the key? No. We've just noted a cyclical flow of contracts, but as to the legality of it, that is: whether it is allowed or whether this is fraudulent activity, there are teams of analysts and lawyers who can sink their mandibles into this juicy case.

No, we haven't determined innocence or guilt, but we have done something, and that is: we've revealed an interesting pattern, a cycle of contracts, and we've also identified the parties to these contracts. Bingo. Win.

The problem analysts face today is diagram 1: they have just too much information, and they spend the vast majority of their time weeding out the irrelevant information to winnow down to something that may be interesting. We were presented with the same problem: TMI. But, by using graphs, we were able to see, firstly, that there are some vertices (or 'companies') that have contracts in and contracts out, and, by investigating further, we were able to see a pattern develop that eventually cycled. My entire inquiry lasted minutes of queries and response. Let's be generous and say it took me a half-hour to expose this cycle.

Data analysts working on these kinds of problems are not so fortunate. Working with analysts, I've observed that:

  1. First of all, they never see the graph: all they see are spreadsheets,
  2. Secondly, it takes days to get to even just the spreadsheets of information
  3. Third, where do they go from there? How do they see these patterns? The learning curve for them is prohibitive, making training a bear, and niching their work to just a few brilliant experts and shunting out able-bodied analysts who are more than willing to help, but just don't see the patterns in grids of numbers
With the graph-representation, you can run into the same problems, but 
  1. Training is much easier for those who can work with these visual patterns,
  2. Information can be overloaded, leaving one overwhelmed, but then one can very easily reset to just one vertex and expand from there (simplifying the problem-space). And then, the problem grows in scope when you decide to expand your view, and if you don't like that expanse, it's very easy either to reset or to contract that view.
  3. An analyst can focus on a particular thread or materialize that thread on which to focus, or the analyst can branch from a point or branch to associated sets. If a thread is not yielding interesting results, then they can pursue other, more interesting, areas of the graph, all without losing one's place.
The visual impact of the underlying graph (theory) cannot be over-emphasized: "Boss, we have a cycle of contracts!" an analyst says and presents a spreadsheet requires explanation, checking and verification. That same analysis comes into the boss' office with diagram 7, and the cycle practically leaps off the page and explains itself, that, coupled with the ease and speed of which these cycles are explored and materialized visually makes a compelling case of modeling related data as graphs.

We present, for your consideration: graphs.

Models presented above are derived from various Governmental sources include Census Bureau, Department of Labor, Department of Commerce, and the Small Business Administration.

Graphs calculated in Haskell and stored and visualized in Neo4J

Friday, June 5, 2015

May 2015 1HaskellADay problems and solutions

May 2015
  • May 29th, 2015: The President of the United States wants YOU to solve today's #haskell problem Super-secret decoder ring sez:
  • May 28th, 2015: So, you got the for-loop down. Good. Now: how about the 'no'-loop. HUH? Ceci n'est pas un for-loop
  • May 27th, 2015: For today's #haskell problem we look at Haskell by Example and bow before the mighty for-loop! The for-loop solution. I count even. *groans
  • May 26th, 2015: TMI! So how to distinguish the stand-outs from the noise? Standard deviations FTW! for today's #haskell problem. First rule: don't lose!
  • May 25th, 2015: We look at monad transformers to help in logging for today's #haskell problem. Ooh! What does the log say? (that foxy log!) Ooh! Ouch! Bad investment strategy! Onto the next strategy!
  • May 22nd, 2015: Tomorrow's another day for today's #haskell problem #trading Huh! we get very similar returns as from previously essayed. Well, now we are confident of a more accurate model.
  • May 21st, 2015: For today's #haskell problem we talk of categories (not 'The'), so we need a cat-pic: LOL
    Is 'parfait' a Category? … If so, I would eat categories every day! 

  • May 20th, 2015: Let's view a graph as, well, a #neo4j-graph for today's #haskell problem Ooh! Pretty Graph(ic)s! 
  • May 19th, 2015: "Lemme put that on my calendar," sez the trader for today's #haskell problem So ... next Monday, is that a #trading day? #inquiringmindswanttoknow
  • May 18th, 2015: So, what, precisely, does a bajillion clams look like? We find out by doing today's #haskell problem #trading #clams Were those cherry clams? No: apple
  • May 15th, 2015: We learn that π is a Π-type in today's #haskell problem of co-constants (#typehumour) 'I' like how Id is the I-combinator
  • May 14th, 2015: Today's #haskell problem brings out the statistician in you that you didn't know you had. Hello, Standard Deviations! Wow, rational roots? Sure, why not? And: 'σ'? ... so cute!
  • May 13th, 2015: Today's #haskell problem teaches us that variables ... AREN'T! Well, if variables aren't, then they certainly do. Except in Haskell – A solution to this problem is posted at
  • May 12th, 2015: For Today's #haskell problem we look at values and their types, but NOT types and their values, please! *glares* taf, tof, tiff, tough solution today
  • May 11th, 2015: Hello, world! Haskell-style! -- A solution to this 'Hello, world!'-problem is posted at
  • Octo de Mayo, 2015: Strings not enumerable in Haskell? Balderdash! Today's #haskell problem Today we produce not only one, but two solutions to the enumerable-strings problem #haskell 
  • Septo de Mayo, 2015: When all your Haskell documentation is gone, whom do you call? The web crawler, SpiderGwen! to the rescue! 
    We CURL the HTML-parsing solution at
  • Sexo de Mayonnaise, 2015: @BenVitale Offers us a multi-basal ('basel'? 'basil'?) palindromic number-puzzle for today's #haskell problem
  • Cinco de Mayo, 2015: May the #maths be with you. Always. Today's #haskell problem, we learn that 5 is the 6th number. Happy Cinco de Mayo! Pattern-matching, by any other name, would still smell as sweet #lolsweet A solution to today's #haskell problem.
  • May 4th, 2015: "There is no trie, my young apprentice!" Today's #haskell problem proves Master Yoda wrong. FINALLY! So ... I 'trie'd ... *GROAN!* A solution to today's 'trie'ing #haskell problem 
  • May 1st, 2015: (Coming up to) Today's #haskell problem is 'slightly' more challenging than yesterday's problem (forall, anyone?) Existential Quantification, For(all) The Win!

Thursday, April 30, 2015

April 2015 1HaskellADay Problems and Solutions

April 2015
  • April 30th, 2015: "SHOW ME DA MONAY!" for today's #haskell problem 
    Simple? Sure! Solution? Yes.
  • April 29th, 2015: We take stock of the Stochastic Oscillator for today's #haskell problem #trading We are so partially stoched for a partial solution for the Stochastic Oscillator 
  • April 28th, 2015: Today's #haskell puzzle as a ken-ken solver a solution (beyond my ... ken) is defined at
  • April 27th, 2015: Rainy days and Mondays do not stop the mail, nor today's #haskell problem! The solution posted at … shows us view-patterns and how to spell the word 'intercalate'.
  • April 24th, 2015: Bidirectionally (map) yours! for today's #haskell problem A solution to this problem is posted at 
  • April 23rd, 2015: Today's #haskell problem looks impossible! So this looks like this is a job for ... KIM POSSIBLE! YAY! @sheshanaag offers a solution at .
  • April 22nd, 2015: "I need tea." #BritishProblems "I need clean data" #EveryonesPipeDream "Deletia" today's #haskell problem Deletia solution? Solution deleted? Here ya go!
  • April 21st, 2015: In which we learn about Tag-categories, and then Levenshtein distances between them for today's #haskell problem Okay, wait: is it a group of categories or a category of groups? me confused! A solution to today's #haskell at
  • April 20th, 2015: Today we can't see the forest for the trees, so let's change that A solution to our first day in the tag-forest ... make sure you're marking your trail with breadcrumbs!
  • April 17th, 2015: No. Wait. You wanted line breaks with that, too? Well, why didn't you say so in the first place? Have some curry with a line-breaky solution at
  • April 16th, 2015: "more then." #okaythen Sry, not sry, but here's today's #haskell problem: I can't even. lolz. rofl. lmao. whatevs. And a big-ole-blob-o-words is given as the solution for today's #haskell problem. It ain't pretty, but... there it is
  • April 15th, 2015: Poseidon's trident or Andrew's Pitchfork analysis, if you prefer, for today's #haskell problem
  • April 14th, 2015: Refining the SMA-trend-ride for today's #haskell problem. Trending and throttling doesn't ... quite get us there, but ... solution:
  • April 13th, 2015: In today's #haskell problem we learn zombies are comonadic, and like eating SMA-brains. Yeah. That. Hold the zombies, please! (Or: when $40k net profit is not enough by half!)
  • April 10th, 2015: Today's #haskell problem delivered with much GRAVITAS, boils down to: don't be a dumb@$$ when investing #KeepinItReal The SMA-advisor is REALLY chatty, but how good is it? TBD, but here's a very simple advisor: Backtesting for this strategy is posted at (or: how a not so good buy/sell strategy give you not so good results!)
  • April 9th, 2015: A bit of analysis of historical stock data for today's #haskell problem A solution to the SMA-analyses part is posted at 
  • April 8th, 2015: MOAR! MOAR! You clamor for MOAR real-world #haskell problems, and how can I say no? Downloading stock screens Hint: get the screens from a web service; look at, e.g.: A 'foldrM'-solution to this problem is posted at
  • April 7th, 2015: Looking at a bit of real-world #haskell for today's stock (kinda-)screen-scraping problem at Hint: perhaps you'd like to solve this problem using tagsoup? *GASP* You mean ... it actually ... works? A MonadWriter-y tagsoup-y Monoidial-MultiMap-y solution
  • April 6th, 2015: What do three men teaching all of high school make, beside today's #haskell problem? Tired men, of course! Thanks, George Boole! Three Men and a High School, SOLVED!
  • April 3rd, 2015: reverseR that list like a Viking! Rrrrr! for today's problem … #haskell Totes cheated to get you the solution used a library that I wrote, so, like, yeah, totes cheated! ;)
  • April 2nd, 2015: We're breaking new ground for today's #haskell problem: let's reverse lists... relationally. And tag-type some values After several fits and starts @geophf learns how to reverse a list... relationally and can count to the nr 5, as well
  • April 1st, 2015: Take a drink of today's #haskell problem: love potion nr9 because, after all: all we need is love, la-di-dah-di-da! A solution can be found au shaque d'amour posted at

Wednesday, April 1, 2015

March 2015 1HaskellADay Problems and Solutions

March 2015
  • March 31st, 2015: Today's #haskell exercise has us looking for a really big pandigital prime ... like: REALLY big. Maybe.
  • March 30th, 2015: A little math-problem to ease us into the week, suggested by @jamestanton 3 consecutive integers that are co-composed
  • March 27th, 2015: Today's #haskell problem is unification of multiple free variables We find this to be 'CoSimple.' 34 lines (and a new n-to-1 data mapping-type) defining not a 'CoSimple' unifier but now an 'UnSimple' one. Ugh!
  • March 26th, 2015: Unification is interesting! (Functional Unification paper) Let's look at the unification-problem for today's #haskell problem We define simple unification (of up to one free logic variable) in a module called unification.simple, oddly enough.
  • March 25th, 2015: In Old Norse, words end with 'R' (not all). For today's #Haskell problem, relations end with 'R' Where I learn to speak Old Norse with a slightly better accent: unifying lists with headR and tailR with unifyLists
  • March 24th, 2015: For today's #haskell problem we learn that 'kayso' is a word, and we edge a bit more toward pure relational calculus A solution to this relational-calculus problem that is defined over Data/Control logic modules:
  • March 23rd, 2015: WHO KNEW a chance meeting with @webyrd at the POPL06 would lead to today's #haskell problem? μBikini I mean: μKanren And the solution implies that monadic-list states are logic programming? Perhaps.
  • March 19th, 2015: We now learn signal spreads ... like ... margarine! for today's #haskell problem
  • March 18th, 2015: For today's #haskell problem we learn that Jupiter's moon Europa is made from Froyo, and custard! Mmmm!
  • March 17th, 2015: No quaternions were harmed in today's #haskell π-problem IN SPACE!
  • March 16th, 2105: In space, no one can here you scream "@NASA" (nor anything else for that matter. Today's #haskell problem
  • March 14th, 2015: Happy π day! A plain-text version of these NASA π-in-space puzzles are available at
  • March 13th, 2015: Okay, ladies and gentlemen, today, in honor of tomorrow being π day, let's take a #coercive #logic break and π it up!
  • March 12th, 2015: I wonder if the suitor's surname is Quine for today's #haskell problem #coercive #logic
  • March 10th, 2015: For today's #haskell problem, we wonder if Balikaya is Aharmanite or Mazdaysian #scheherazade #coercive #logic
  • March 9th, 2015: In which Iskandar is asked Kamar's Children's ages in Scheherazade's #haskell metapuzzle #coercive #logic 
  • March 6th, 2015: Champernowne's constant for today's #haskell problem Please let me know if you can NOT access this problem: I've marked it private as previous ones are being modified in place. DON'T DO THAT!  In which we show @geophf triumphs with brütish-forcisms for today's #haskell solution
  • March 5th, 2015: For today's #haskell problem, we ponder why they aren't calledLEFT-triangles. Is it a plot? Leftist triangles are subject to the (IO) State (monad) ... geddit? #sigh never mind anyway, solution: Or, put another way: in which we see @geophf can not have a function type that includes -> Int -> ... AND, we really need MapReduce here!
  • March 4th, 2015: Truncatable primes (11 in all) are asking to be solved in today's #haskell problem This @1HaskellADay problem turned into a _TWO_day solution! Worth it? Why, yes, after redesigning _TWO_ libraries!
  • March 3rd, 2015: There's more than a 1-in-a-million chance there are 'sum' double palindromic numbers in today's #haskell problem The solution was not too hard, M. Euler!
  • March 2nd, 2015: What-what! abcde * fghij is equal to ... well, something, it appears. and the prob1, prob2 winners are ... A solution to today's #haskell problem.

Sunday, March 1, 2015

February 2015 1HaskellADay Problems and Solutions

February 2015
  • February 27th, 2015: Let's put all our primes in a circle, shall we? Ah, how cute! Today's #haskell problem suggested by @jamestanton @bretthall defines a solution, with some analysis, at
  • February 26th, 2015: Okay, check this! Today's #haskell problem is as easy as 1, 2, 3! An easy as π solution is posted at ... mmm! π! But is it apple π or ... raspberry π? #couldntresist
  • February 25th, 2015: I'd like moccha sprinkles on my double capicua, please. No. Wait. Today's #haskell problem suggested by a tweet from @OnThisDayinMath
  • February 24th, 2015: Not satisfied with a simple square-from-square problem @BenVitale takes it up a notch and asks us to cube dat square! We have one solution out of 20k squares posted at : [(39204,39304)]
  • February 23rd, 2015: I hereby christen this week a fun-with-numb3rs week, and start us off by learning that 'easierest' is a word,, just like 'ginormous.' And the winner, wait! Ladies and gentlemen, we have MULTIPLE winners! Good thing the solution isn't the Lotto No, wait. The problem statement wasn't read carefully by the solution-poster. I blame that wicked, wicked @geophf! Bad geophf! Bad! ;)
  • February 20th, 2015: It's a #Borderlands2 Truxican Standoff for you to resolve in today's #haskell problem The solution is simple really: just a projection into a monad category in order to do some monoidal deduction is all!
  • February 19th, 2015: For today's #haskell problem we learn that 'AEKL' is a word in English (no, it's not, actually) A megalokaryocyte-solution is posted at (now, that's a common word ... NOT! ;)
  • February 18th, 2015: Instead of doing today's #haskell problem, let's go ice skating. No, let's do BOTH! Okay, a loquacious solution? garrulous? Yes. Once one cuts through all the attempts, it's a simple solution, too: ... and updated the solution with the monoidal guarantee-by-implication that the result is unique (instead of just hoping it is) #coercivelogic
  • February 17th, 2015: For today's #haskell problem we are asked to 'fix' our monetary problems (or the library, at least) Made Data.Monetary.USD a Fractional instance and eliminated floating point creep #haskell #money #precision 
  • February 16th, 2015: Getting a jump-start on the day with two really, really hard math problems for today's #haskell problem A solution in which we learn a baseball costs a nickel ... IN WHICH CENTURY?
  • February 13th, 2015: Today's SCARY #haskell problem comes by way of @OnThisDayinMath Tonight's late-night movie, Friday the 13th, part III as the solution to today's #haskell problem.
  • February 12th, 2015: Gurer ner gvzrf jura ... yeah. That. Today's #haskell problem, thanks to @KenKenPuzzle The solution shows us that it's INTENSE unscrambling words
  • February 11th, 2015: Change adds up quickly in today's #haskell problem So, but ... does that mean programming is like ... maths? Nah! A solution to today's #haskell problem
  • February 10th, 2015: The price of a letter (or of all letters of the alphabet) is the question for today's haskell problem. In the solution we learn the geophfmeister is down-low on the B.I.G. 323, yo!
  • February 9th, 2015: 'Oh, no!' ... just another Manic Monday ... AND today's #haskell problem Oh, noes! Mr. Bill! A solution to the oh, no!-problem.
  • February 6th, 2015: It's Friday! Friday! Hava #haskell problem on Friday! Fun-fun-fun! Lookin' forward to the weekend! Groovin' to aRebecca Black solution at
  • February 5th, 2015: Triangles and Squares as numbers for today's Haskell problem. A Triangulated-squares solution is provided by @bretthall at
  • February 4th, 2015: Three birds in the hand is better than today's #haskell problem an ornithologist's delight inspired by @KenKenPuzzle. The solution, using MultiMaps, PartitionedSets, and Arrows is (@geophf-obviously) "WOOT! WOOT! WOOT!"
  • February 3rd, 2015: We entertain a foolish attempt at a #haskell problem, and then we get serious with six sewing seamstresses A silly seamstress solution is posted at 
  • February 2nd, 2015: Today's #haskell exercise is all about the #SuperBowl! (No, it's not, but that makes for good copy), or 110, 210, ... The moral (and solution) to this story is: Don't eat cheerios seasoned with basil. Or something like that. Inspired by @bretthall solution, I expanded to include last-3-of-4 digits for solutions to bases 4,5,6 @jamestanton

Sunday, February 1, 2015

January 2015 1HaskellADay Problems and Solutions

January 2015
  • January 30th, 2015: Catted Prime Factors Today's answer shows us composed primes. No. Wait. Primes aren't composed, by definition, right? Well, anyway...
  • January 29th, 2015: For today's haskell problem we peace-out by making triangles, not war. And our solution: make my day, punk! ... with triangles (extra-spicy, please)! Bleh, our non-partial solution: no fun, no triangles! Can you fix it?
  • January 28th, 2015: Criss-cross; APPLESAUCE! ... butnot Christopher Cross for today's Haskell problem. Anndddd, safety first, or don't cross that yellow line! for today's solution.
  • January 27th, 2015: What's 'All in the Family'? Elegance is. Today's Haskell problem is about a little bit more elegance. And lines. And triangles. Our solution involves slopes and stuff ... from Elementary School. Remember?
  • January 26th, 2015: Just a simple counting-triangles problem using Data.Graph for today's #haskell problem In our solution we put the triangles into a  Graph, counting crows ... I meant: 'triangles.' 
  • January 23rd, 2015: A simple request on this fine Friday: solve the 'aug'mented matrix for today's #haskell problem Row-echelon solverSOLVED! (WOOT!s included for free!)
  • January 22nd, 2015: Row-echelon form; not solved yet, but PDC! ('pretty durn closer!') Aug! Our matrix has been row-echeloned! A solution for today's Haskell problem.
  • January 21st, 2015: Vectors are Num(bers), too ... adding two (same-length) vectors for today's Haskell problem ... and rollin' the vector-addition solution is posted at
  • January 20th, 2015: May I introduce Miss Abby Normal for today's Haskell problem? Vector normalization for reduced row-echelon form. NORM! A solution to today's Haskell problem is CHEERSfully posted at
  • January 19th, 2015: Oh, something new for today's #haskell problem? Well, then: how about a ... MATH PROBLEM! ... 'sorta' Eheh. We have a guest who decided to solve the problem: Þor (Thor). THOR SMASH! No. Wait. That's the Hulk. Never mind.
  • January 16th, 2015: Let it snow, let it snow, let it matrix-solver! for today's #haskell problem with (Ooh! Ooh!) pretty matrix pictures!
Picture. Terminal. Snowflake-matrix. BlinchtenLightzen.
  • January 15th, 2015: n, k, and b are all you need (oh, and the answers) for today's Haskell problem
  • January 14th, 2015: More fun with fractals for today's #haskell problem: plotting the Harriss Spiral
  • January 13th, 2015: Yesterday we did not learn about the (constructive?) truth of 2+2 = 4. Sorry. Today we try to equate two circled rows
  • January 9th, 2015: In which it is shown that snarkiness is unavoidable when @geophf presents a Mensa-puzzle for today's #haskell problem
  • January 8th, 2015: Cressida, a smart little girl (in fact: a Mensan), would like you to determine her age for today's #haskell problem
  • January 7th, 2015: Fibbing down-low on the fibs! for today's haskell problem
  • January 5th, 2015: I'm looking over a 4-leaf tuple/That I overlooked before! #haskell problem today: over definition for Lens-on-tuples A solution is 'overdefined' by @bretthall at
  • January 4th, 2015: It's a new year, and I've just woken up and smelled the Lens-coffee! Bob Marley welcomes you to the New Year with a #haskell problem about #lenses Sing with me! set _2 "love" (1, 2) A solution is offered by @bretthall at