My simple explanation of the Hidden Markov Model. Shared here: https://www.slideshare.net/katatunix/hidden-markov-model-67982915

This statement: Quote Little did they know that the universe is four dimensional and even the orbit of planets is an illusion produced when straight motion in a four dimensional space is projected into three dimensions (or something). immediately reminded me about projective geometry which is one of the most beautiful systems of mathematics. So the universe is 4D? I’m not sure. But if it was true then we could use the concepts of projective geometry to interpret something interesting.

Null is clearly evil. We as human tend to forget to check null, and boom… crash!!! Documentation may help, but again we still forget reading documents. Worse, not all documents are correct and up-to-date 100%. Even if we remember to do every null check, our code would be very messy. So what is the solution? Checked-exceptions can help but must be used with care otherwise nearly every function/method in our programs could throw checked-exceptions, and try/catch statements would appear everywhere.

Exceptions are a very common concept in most of languages nowadays. In this article we will discuss why exceptions are needed, checked vs. unchecked exceptions, and why C# doesn’t have checked exceptions. In the old days, defensive code were a mess Before exceptions were invented, defensive code had been overwhelmed with a lot of error checking and recovery from those errors, for example: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 void handle() { // style #1: error is embedded in the return value int errFoo = foo(); if (errFoo == -1) { // recovery and may return } // style #2: error is assigned to the output parameter unsigned int errBar; int value = bar(.

This article is about my personal explanation of the famous design patterns: Model View Controller (MVC), Model View Presenter (MVP), Presentation Model (PM), and Model View ViewModel (MVVM). Let’s start with Model. Model: the core of an application At the core of an application is a component called Model where business objects and use-case objects live. Normally, the outside world interacts with the Model by sending input to the use-case objects, these objects then manipulate the business ones and finally return output back to the outside world.

Builder Pattern and Factory Pattern are pretty similar in a way: both of them encapsulate the details of object-creation processes. However, in cases there are many complicated processes to create various representations of objects, and those processes share a common trait, Builder Pattern is the better choice. Let’s say we have two processes to build a house: Asian process and European one. We will start with Factory Pattern and gradually adapt it to Builder Pattern.