mikeizbicki

subhask

Haskell2015–2019

mikeizbicki / subhask

subhask

Type safe interface for working in subcategories of Hask

Explore on GitHub Read Hacker News discussions

5Distinct people

6Mentions

0Explicit recommenders

420GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Type safe interface for working in subcategories of Hask

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year6 dated mentions

Observed mentions: 2015-07-01 20:06:36 UTC to 2019-01-20 00:58:51 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	1	1	0
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	0	0	0
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	4	0	4
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	0	1

What Hacker News says

6 sources

jackpirate·Jan 20, 2019

I've done quite a lot of work trying to solve this problem in Haskell, and I'm of the opinion that current type system technology is not strong enough for real world machine learning. At the most basic level, the sizes of tensors are often not known until runtime, so some sort of dependent typing is necessary. Idris is currently the most practical dependently typed language, and it's missing a number of features that would be needed for machine learning work. For example, it only supports 64bit floating point operations, whereas 32bit ops are standard and the industry is moving to 16 bit and fewer ops. There's ways in Haskell to get most of the benefits of dependent typing, but they're pretty ugly. My subhask library [1] I think did a reasonable job for vector/matrix math, but once you get into higher order tensors everything becomes e

Read the rest

ither far too verbose or impossible to specify. For example, permuting the axes of a tensor takes roughly a full page of code, and it's not even properly type safe. At the bottom of the link [1], there's a list of type system features that I think would be necessary to add to Haskell before it has a chance of a good linear algebra system... but in all honestly, I'm not even convinced yet that a usable linear algebra system can even be implemented in a language with proper dependent types. [1] http://github.com/mikeizbicki/subhask

In OCaml bindings for PyTorch

LeanderK·Nov 7, 2017

well, there is always: https://github.com/mikeizbicki/subhask which provides more flexibility on the categories you are programming in.

In Functional Programming Jargon

tbenst·Oct 7, 2017

There's also a code base for GHC based on this work called Subhask. It's technically Haskell but replaces so much of the functor/monad hierarchy that it's effectively a different language. https://github.com/mikeizbicki/subhask

In Physics, Topology, Logic and Computation: A Rosetta Stone (2009) [pdf]

spott·May 24, 2017

> has poor support for numerical computing. The issue comes from being lazy by default. When you are writing lazy functional code, you essentially build up a system of thunks[0] that collapse to a value when you need it. This works great for abstractions like infinite lists, or essentially only paying for the value you need. Unfortunately, they are kind of expensive (I believe they are usually implemented as a tagged union, where they are either a value that is returned immediately or a pointer to another function or thunk) when you don't need the laziness. In any sort of numerical computing, you are usually dealing with enough values that you lose a lot of performance when dealing with these thunks. Working around this is doable with a bunch of strict annotations (so that these thunks are immediately collapsed to values), but that is

Read the rest

only half the battle: you still need to reduce the immutable function applications to a mutable version so you don't lose out by copying your values back and forth in memory, and you don't do a bunch of unnecessary calculations. All this requires "a sufficiently intelligent compiler" or a lot of compiler hints and peering into Core: the intermediate language of GHC. It isn't for the faint of heart. There have been a bunch of work on avoiding some of this: hmatrix[1] is a lapack and blas library for finally doing the calculations once you have reduced the graph, "subhask"[2] is a standard library for Haskell that attempts to add some support for basic numerical work and "numerical"[3] is a library that I believe is trying to make a well typed linear algebra library (I'm not sure if it is going to call into hmatrix/blas/lapack or not). The issue with a lot of this is that until there are good tools for this kind of thing, no-one does serious numerical programming in Haskell, and there are only a few people working on the tooling because there aren't that many people trying to do serious numerical programming in Haskell. (note: I'm not an expert in this, so don't depend on any of this for love or money. I'm sure someone will come along and tell me how I'm wrong.) [0] https://en.wikipedia.org/wiki/Thunk, https://wiki.haskell.org/Thunk [1] http://hackage.haskell.org/package/hmatrix [2] https://github.com/mikeizbicki/subhask [3] https://github.com/wellposed/numerical

In Grenade: Deep Learning in Haskell

jackpirate·May 24, 2017

Hi everyone, author of HLearn here :) This is a bit awkward for me as I've paused the development of HLearn and emphatically do not recommend anyone use it. The main problem is that Haskell (which I otherwise love) has poor support for numerical computing. I've tried developing an alternative standard library to improve the situation (https://github.com/mikeizbicki/subhask), but Haskell's type system isn't yet powerful enough to do what I want. I'm sure the type system will have the needed features in 5-10 years, and I'd rather wait and do it right. If you have any questions, I'd be happy to answer them.

In HLearn: A Machine Learning Library for Haskell (2013) [pdf]

dansan_2·Jul 1, 2015Submission

SubHask's automated testing of laws

2 points · Open discussion