Skip to content

Instantly share code, notes, and snippets.

View nikitaDanilenko's full-sized avatar

Nikita Danilenko nikitaDanilenko

View GitHub Profile
@nikitaDanilenko
nikitaDanilenko / Constraint check vs. foreign key constraints.md
Last active September 22, 2020 13:28
A warning about attempting to simulate foreign key constraints via constraint checks in PostgreSQL

Setting

The situation may occur that one has two tables, where the first one has a reference to the first one, but that reference cannot be expressed in terms of a foreign key constraint. One example may look as follows:

create table parent (id int not null, version int not null, description text not null);

alter table parent add constraint parent_pkey primary key (id, version);
@nikitaDanilenko
nikitaDanilenko / Boolean rules.md
Last active July 1, 2021 09:25
Boolean simplifications
  • if (a) false else b === !a && b
  • if (a) true else b === a || b
  • if (a) a else b === a || b
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta charset="UTF-8"/>
<title>Titel</title>
<script src='https://cdnjs.cloudflare.com/ajax/libs/Chart.js/2.7.3/Chart.bundle.min.js'></script>
<link rel='stylesheet' type='text/css' href='../style.css'/>
</head>
@nikitaDanilenko
nikitaDanilenko / traverse-query.md
Last active April 30, 2020 09:50
Traverse one, query the other

Occasionally, one may have an operation where one needs to combine two data structures, where the full traversal is linear in the number of elements in the structure, and a query operation is logarithmic (with an arbitrary base) in the number of elements in the structure. One use case for such a combination is the definition of an intersection of maps as in Scala, where there is currently no general merge operation for this case.

The question

If we traverse one structure while querying the other - is it cheaper (in terms of complexity) to traverse the larger one or the smaller one?

@nikitaDanilenko
nikitaDanilenko / Average is not a foldr.md
Last active August 29, 2015 14:20
Not every list function is expressible using foldr.

A short while ago I was contemplating the question, whether every list function is expressible in terms of an application of foldr. The restriction is that there has to be exactly one application of foldr and no additional workarounds. For example, creating an intermediate pair of results and returning just one of its components or preprocessing the input list [a] to a more enriched form [(a, b)] are not allowed.

Baltasar Trancón Widemann has pointed out that this is not the case and that the avg function that computes the average of a given list is a counterexample. This short text proves why this is the case.

The function we wish to define is

avg :: Fractional a =&gt; [a] -&gt; Maybe a
@nikitaDanilenko
nikitaDanilenko / catas.hs
Last active August 29, 2015 14:19
Kurze Form der allgemeinen Katamorphismenfaltung.
import Data.Foldable ( Foldable, foldMap )
import Data.Function ( on )
import Data.Monoid ( Monoid ( .. ) )
type Algebra f a = f a -> a
newtype Mu f = Fix ( f (Mu f) )
inject :: f (Mu f) -> Mu f
inject = Fix
{-# OPTIONS_CYMAKE -X TypeClassExtensions #-}
import Constraint ( andC )
validDigits :: [Int]
validDigits = [0 .. 9]
solveWith :: [Int] -> [Int]
solveWith vds | digits =:= zipWith numberOfIn vds (repeat digits) = digits where
digits = [unknown' | _ <- vds]