Equational

Today some feel good code in Haskell: man :: Diagram B man =         circle 1.2 # center     ===         ((rotateBy (-0.1) (vrule 3)) ||| (vrule 3) ||| (rotateBy 0.1 (vrule 3))) # center     ===         ((rotateBy (-0.1) (vrule 3)) ||| (rotateBy 0.1 (vrule 3))) # center   which produces the following svg stick man: You need to call it like this: main = mainWith $ man

If you try to boil water in pyrex glass container, you may well see the water's temperature go past boiling point (100c/212F), because the smoothness of the glass is not providing any starting point for the boiling to start. Then if you take a wooden spoon and drop it in to the water... the boiling starts in an explosif manner, triggered by the spoon. Would it be right to say that the spoon caused the water to boil? Yes. Would it be right to say that heating the water caused it to boil? Also yes! Would it be right to say that choosing a glass container caused the water to boil explosively? Yes. Would it be right to say that dropping the spoon in caused the water to boil explosively? Also yes! The analogy here is that the wooden spoon is a single trader. Take lots of spoons, the first one that touches that water will cause it to boil. Would it be right to say that there was one trader that caused the flash crash? Just as much as that first wooden spoon makes that water boil. Should ...

I found myself explaining to my daughter that people will go a long way to explain why there is value in the products they have purchased, especialy relative to products they have not aquired. The hard reality is that to invest oneself is to blind oneself.  What happens is that because personal investments set us up to lose under certain scenarios, we will naturally think of how to avoid these scenarios. The thing is, having worked out how to minize loss, we have usually built a whole reasoning on what can happen, and what will not happen. The last thing that we want then is to be proven wrong. It is this avoidance to be proven wrong (among others)  that blocks us from revisiting certain scenarios. Indirectly, what happens is that we set up a subconscious barrier as an effort not to be proven wrong. This is very much black swan territory: events that do not happen often and surprize us in a bad way. But it is actually more than that, it is about being careful not to ac...

This video by Sydney Finkelstein is excellent. Here is the link: Think Again: Why Good Leaders Make Bad Decisions and How to Keep it from Happening to You Mentioned are four red flags in decision-making: Are your personal experiences misleading you? Is your personal self-interest clouding your thinking? Have you made a dangerous pre-judgment that you are locked into? Are inappropriate attachments pushing you in the wrong direction? These are very good! The tricky part is that to really understand them, you need need to have traveled the multiple sides of the human psyche, which many managers have not. All original content copyright James Litsios, 2015.

Spoofing is the act of generating orders to buy or sell something on an electronic market, but to then immediately cancel these orders in order not to trade. Spoofing is used to generate a burst of activity with the hope that it will cause other algorithmic trading systems to react in a sub-optimal manner, allowing the spoofer to follow through with profit making trading activity. Spoofing happens when you enter orders with no intention of letting those orders trade. Which is different from entering orders in to a market and to then cancel them because you have changed your mind. There is no change of mind in spoofing, and therefore it might be seen as a form of deception. Spoofing works because other trading systems are waiting to see certain market prices before they change their behavior. Spoofing can also slow down the market as it may overload the exchange’s network or matching engine, such a slowdown may put at disadvantage other market participants. The question is: is spoofin...

This post is about designing software with internal and external APIs that are robust to future changes. It is therefore about API compatibility, but more importantly it is about the compatibility of a full software design to changes. Not surprisingly, monads and comonads are part of the presented solution, as is a careful approach to use of types. I had a "aha" moment last year when I watched a video (by Timothy Baldridge) that showed how an AST for a Clojure compiler was fully based on key-value pairs (nested hash maps), therefore without typed structures nor classes, and was doing very well. The thing is, I have suffered enough times to get the types of the different phases of a compiler to fit together. Therefor the idea of giving up on types and just using key-value pairs, that can easily be added for each compiler phase, seemed really to be an attractive way to write a compiler. Key-value pairs, duck typing, and many "traditional" functional patterns (...