Skip to content

Instantly share code, notes, and snippets.

View mschuwalow's full-sized avatar

Maxim Schuwalow mschuwalow

  • LiveIntent
  • Germany
View GitHub Profile
@VictorTaelin
VictorTaelin / implementing_fft.md
Last active November 12, 2024 09:06
Implementing complex numbers and FFT with just datatypes (no floats)

Implementing complex numbers and FFT with just datatypes (no floats)

In this article, I'll explain why implementing numbers with just algebraic datatypes is desirable. I'll then talk about common implementations of FFT (Fast Fourier Transform) and why they hide inherent inefficiencies. I'll then show how to implement integers and complex numbers with just algebraic datatypes, in a way that is extremely simple and elegant. I'll conclude by deriving a pure functional implementation of complex FFT with just datatypes, no floats.

@quelgar
quelgar / typed_errors.md
Last active January 16, 2024 09:36
Every Argument for Static Typing Applies to Typed Errors

Every Argument for Static Typing Applies to Typed Errors

Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.

An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.

Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty

@snoyberg
snoyberg / abonimable-snoyman.rs
Created December 2, 2020 15:05
Playing with GATs, transformers, and more
#![feature(generic_associated_types)]
#[allow(dead_code)]
trait Functor {
type Unwrapped;
type Wrapped<B>: Functor;
fn map<F, B>(self, f: F) -> Self::Wrapped<B>
where
F: FnMut(Self::Unwrapped) -> B;
  1. def hash(a: A): Int makes me sad. What about hashing to 64 bits or SL2 Fp?
  2. def MapHash[A, B: Hash]: Hash[Map[A, B]] is a bit odd. Why not A: Hash?
  3. reflexiveLaw + symmetryLaw + transitivityLaw is too weak for "equality". This defines a general equivalence relationship only.
  4. val AnyEqual: Equal[Any] is worrisome, considering all the resolution bugs!
  5. val DoubleEqual: Equal[Double] should be implemented using java.lang.Double.doubleToRawLongBits.
  6. A combintation of [trait Ord[-A] extends Equal[A]](https://github.com/zio/zi
@573
573 / default.nix
Last active September 16, 2020 16:31
Running integration tests the nix way #howto
{ pkgs ? import <nixpkgs> {} }: {
test = pkgs.nixosTest ./test.nix;
}
@edmundsmith
edmundsmith / writeup.md
Created July 7, 2019 20:47
Method for Emulating Higher-Kinded Types in Rust

Method for Emulating Higher-Kinded Types in Rust

Intro

I've been fiddling about with an idea lately, looking at how higher-kinded types can be represented in such a way that we can reason with them in Rust here and now, without having to wait a couple years for what would be a significant change to the language and compiler.

There have been multiple discussions on introducing higher-ranked polymorphism into Rust, using Haskell-style Higher-Kinded Types (HKTs) or Scala-looking Generalised Associated Types (GATs). The benefit of higher-ranked polymorphism is to allow higher-level, richer abstractions and pattern expression than just the rank-1 polymorphism we have today.

As an example, currently we can express this type:

@JoeyBurzynski
JoeyBurzynski / 55-bytes-of-css.md
Last active November 4, 2024 07:33
58 bytes of css to look great nearly everywhere

58 bytes of CSS to look great nearly everywhere

When making this website, i wanted a simple, reasonable way to make it look good on most displays. Not counting any minimization techniques, the following 58 bytes worked well for me:

main {
  max-width: 38rem;
  padding: 2rem;
  margin: auto;
}
@iravid
iravid / zio-with-alpakka-kafka.scala
Created March 18, 2019 21:10
ZIO with Alpakka Kafka
import akka.actor.ActorSystem
import akka.kafka.ConsumerMessage.CommittableMessage
import akka.kafka.scaladsl.Consumer
import akka.kafka.{ ConsumerSettings, Subscriptions }
import akka.stream.ActorMaterializer
import akka.stream.scaladsl.{ Keep, Sink => AkkaSink }
import org.apache.kafka.common.serialization.StringDeserializer
import scalaz.zio._
import scalaz.zio.stream.Sink
import scalaz.zio.interop.reactiveStreams._
@jdegoes
jdegoes / fpmax.scala
Created July 13, 2018 03:18
FP to the Max — Code Examples
package fpmax
import scala.util.Try
import scala.io.StdIn.readLine
object App0 {
def main: Unit = {
println("What is your name?")
val name = readLine()
import re
import os
import glob
import pandas as pd
import matplotlib.pyplot as plt
from collections import OrderedDict
fig_size = [12, 9]