Code Words

> but you now think the algorithms that might get you okay results on Kaggle competitions can be used to predict a child's future crimes

Do you think anything can be used to predict crimes? Can you imagine any fair application of justice that doesn't boil down to an algorithm?

Sentencing guidelines are an algorithm. It's literally a table on page 3[0]. Do you think sentencing guidelines, which were invented to address unfairness in the justice system like this guy's work was, are unfair?

What alternative do you propose? Case-by-case judgements? Even if you could find me a model judge, be honest: the judge probably uses something that boils down to an algorithm to be just.

> brilliant proxy for race

Suppose we only used variables with a low correlation to race. Or we decorrelate them from race somehow. Suppose error on the validation set increased. Would this be sufficient to make this system more just to you? Would a reasonable person think it is more just?

> Specific ML systems ("deep") can infer hidden variables such as race

Considering how scientific you are trying to be about your understanding of ML, you're being dishonest about how much ML systems can "infer hidden variables." There's strictly anecdotal evidence of "deep"ness inferring something hidden. We think GoogLeNet is seeing higher-order features, but then we show it a picture of a cat and it thinks it's looking at a paper towel.[1] You're overstating the power of these systems to serve your point,…

First of all, I'm sure the author knows more about git than I do, so I don't wanna come across as trying to lecture an expert. But I do feel that his main point misses the mark. It seems to be centered around the idea that a lot of reasonable people are surprised by things git won't let them do (or, more accurately, strongly advices against doing). The problem is that most of these things are only "reasonable" from the point of view of someone who hasn't thoroughly thought through what a DVCS has to do. A lot of the "reasonable" questions are raised from the point of view of "this is a tool for sharing changes to code". But that is just a nice side-effect of what a DVCS aims to do – it is not the goal.

I too have had to clean up git mistakes of collaborators for years, almost all of them rooted in a misunderstanding of what git does, or carelessness (amplified by git's arguably less-than-stellar naming conventions). But is there really any chance that any DVCS will be "easy" (or "not too hard") for someone who hasn't thought about and internalized what the goal of a DVCS is? It seems a bit like a person who only ever spreads butter complaining that knives are needlessly sharp.

PS: My greatest success rate at converting people from "just hammer git commands until my code is on GitHub" to actually understanding what problem git tries to solve, and how to interact with it, has been from Mary Cook's wonderful Git from the inside out…

This would be more useful and more upvoteable if you had provided some text for context.

TLDR: If you interpret sum types as + and product types (tuples/structs/objects) as *, type definitions can be read as polynomials. Recursive type definitions, like for linked lists, can be read as recurrence equations. If you do some calculus over these things and compute the derivative of these type formulas, you get back something meaningful: The formula corresponding to the type's Zipper (https://en.wikipedia.org/wiki/Zipper_(data_structure)), a data structure for efficiently traversing and modifying functional data structures.

I like Chris Taylor's series of posts on this topic, as well as this shorter one: https://codewords.recurse.com/issues/three/algebra-and-calculus-of-algebraic-data-types/

I have written a small python library to read info directly from the .git folder (without using the git executable): https://github.com/spapas/python-git-info/

Decoding the pack files was notoriously difficult, probably there are still cases that I don't handle properly. The packfile is a really complex/messy format and in the top of that it lacks any proper documentation!

This article explains a lot of the concepts very good but doesn't go into implementation details (where the big snakes are). Another great resource for unpacking packfiles is this post: https://codewords.recurse.com/issues/three/unpacking-git-packfiles and of course reading the source code of other git clients.

Unfortunately it seems that the official packfile format documentation is the git source code :|

Some related links (specifically that they perform "high school" algebra on types):

- Seven trees in one [0], a paper showing a bijection between binary trees and seven-tuples of binary trees.

- The algebra of algebraic data types [1] discusses Taylor expansions of data types.

- Differentiation of higher-order types [2] is commenting on OP's paper.

I used to be really interested in type theory, but haven't had as much time to explore it, but over the years I've saved these links (and the one posted).

[0]: https://arxiv.org/pdf/math/9405205.pdf

[1]: https://codewords.recurse.com/issues/three/algebra-and-calculus-of-algebraic-data-types

[2]: http://conal.net/blog/posts/differentiation-of-higher-order-types

While I don't know the history of the term "algebraic data type", I do know that the algebraic structure of ADTs is much deeper than what this article presented. For instance this structure supports some limited notion of a derivative[1]! And purely algebraic manipulation of ADT "equations" can actually be used to generate some non-obvious results [2]. So I think it's probably wrong to say that ADTs were just "given a name that sounds mathematical".

1. https://codewords.recurse.com/issues/three/algebra-and-calculus-of-algebraic-data-types
2. http://www.math.lsa.umich.edu/~ablass/7trees.pdf