Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Brief Guide to a Few Algebraic Structures

argumatronic.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: A Brief Guide to a Few Algebraic Structures

#41

Post by mangamadaiyan »

dramaqueen wrote: post #8
jaddood wrote: post #7

Earlier quoted context omitted.

As mentioned, it should be pronounced "rung," but in any case, removing the i and suddenly making it a word and pronouncing it in a very unexpected way is really pretty stupid. I think, if one's really insisting on using "ring" but without the i, at least call it "rung" not "rng" so that its pronounciation is clear. If it's so important to have a "rng" instead of a "ring" then using its name in some example of its us…

Well, words, terms, notations and conventions come super cheap in math. You can call/denote "rng" anything you want. You just have to let your readers/interlocutors know about your conventions at the outset which is a standard practice in math anyway. For another thing, "r(u)ng" to me it's no different from writing "colonel" and reading it "kernel" (historical accident aside) :) There's also "lieutenant" which is pro…

Lieutenant is "Leftenant" in other parts of the world (those with a British connection, of course) as well.

Re: A Brief Guide to a Few Algebraic Structures

#42

Post by merijnv »

crimsonalucard wrote: post #36
merijnv wrote: post #30

Earlier quoted context omitted.

> I'm learning category theory to understand haskell better. I would consider myself a fairly expert Haskell programmer and I have (for fun/curiousity) spend some time reading up on/studying category theory and I can say, without a doubt or hesitation that if your goal is to either 1) understand Haskell better and/or 2) become better at writing Haskell, then studying category is a MAJOR waste of your time. I would ad…

Your insight is valuable and interesting. I'm certainly not an expert on Haskell and I'll take a look at your book recommendations. Thank you. I have to say though I can't agree with you on category theory yet. Especially the part about functors. The fmap for the functor f looks to me to be 100 percent the definition of the morhphism that maps arbitrary categories to the morphisms in functor f. The resource I am read…

> I'm curious as to your opinion on why the functor in Haskell only has a passing relationship to functors in category theory.

If we assume Hask, the universe of Haskell types and functions operating, is a category (which is hotly debated with some regularity, as there is no formal definition of Hask). Then the Functor class in Haskell really only describes one specific subset of functors: endofunctors on Hask (i.e. mapping objects (types) in Hask to objects in Hask).

This is a rather limited subset of all functors. You can also see this in the laws for example. You probably know the 2 functor laws "fmap id x = id x" and "fmap f . fmap g = fmap (f . g)", but Haskell's Functor is limited enough that these are actually redundant. In Haskell having a proof of just 1 functor law gives you the other one for free (as a free theorem, Wadler's "Theorems for Free!" is a good intro, and another paper. It basically covers "why is more generic code easier to reason about").

> The resource I am reading on category theory makes it seem highly relevant to Haskell and software design in general.

I'm not saying there aren't some useful ideas to be gleaned at both the superficial and deeper levels. The whole lawfulness of functors is great for being able to reason about code without knowing what it actually does, and all of lens is deeply inspired by category theory.

All of CT is about composition and reasoning about it, which we could certainly use more of in programming. So I encourage anyone curious to look into. I'm just trying to provide some nuance to the...enthusiastic overhyping of CT, because I don't want people to be scared away of wonderful tools and languages like Haskell, just because they think they're not smart enough to get all that fuzzy math :)

Re: A Brief Guide to a Few Algebraic Structures

#43

Post by antisemiotic »

merijnv wrote: post #42
crimsonalucard wrote: post #36

Earlier quoted context omitted.

Your insight is valuable and interesting. I'm certainly not an expert on Haskell and I'll take a look at your book recommendations. Thank you. I have to say though I can't agree with you on category theory yet. Especially the part about functors. The fmap for the functor f looks to me to be 100 percent the definition of the morhphism that maps arbitrary categories to the morphisms in functor f. The resource I am read…

> I'm curious as to your opinion on why the functor in Haskell only has a passing relationship to functors in category theory. If we assume Hask, the universe of Haskell types and functions operating, is a category (which is hotly debated with some regularity, as there is no formal definition of Hask). Then the Functor class in Haskell really only describes one specific subset of functors: endofunctors on Hask (i.e.…

>If we assume Hask, the universe of Haskell types and functions operating, is a category (which is hotly debated with some regularity, as there is no formal definition of Hask).

Isn't the consensus that "Hask is a category as long as you wave your hands profusely and pretend that exceptions and non-terminating functions never happen"?

Re: A Brief Guide to a Few Algebraic Structures

#44

Post by BoiledCabbage »

mcphage wrote: post #39
joker3 wrote: post #38

Earlier quoted context omitted.

It's somewhat confusing to see it this way the first time, but it's absolutely the right way to think about these structures. It's better to do the work to get used to it early on.

It's the right way to think about the structures, sure. But when you want to look up the laws for what makes something a Ring, for instance, having them all in 1 place instead of having to jump between: Monoid, Semigroup, Group, Abelian Group, Quasiring, Nearring, and Ring. (And some of those laws occur twice, for different operators) makes it a lot more useful as a reference document.

That's like saying when implementing a function you shouldn't call another fn, you should copy and paste its implementation so you don't have to flip to another location in the code.

The right way is to learn what the function means so you can set see calls to it and know what it does.

Re: A Brief Guide to a Few Algebraic Structures

#45

Post by mcphage »

BoiledCabbage wrote: post #44
mcphage wrote: post #39

Earlier quoted context omitted.

It's the right way to think about the structures, sure. But when you want to look up the laws for what makes something a Ring, for instance, having them all in 1 place instead of having to jump between: Monoid, Semigroup, Group, Abelian Group, Quasiring, Nearring, and Ring. (And some of those laws occur twice, for different operators) makes it a lot more useful as a reference document.

That's like saying when implementing a function you shouldn't call another fn, you should copy and paste its implementation so you don't have to flip to another location in the code. The right way is to learn what the function means so you can set see calls to it and know what it does.

The purpose of the site is to be:

> So, that’s the intent of this post – to be that fast reference to the kinds of algebraic structures I care about.

I learned these structures in the early 90s; I don’t need to be told the right way to learn them. However, a “fast reference” would be useful.

Re: A Brief Guide to a Few Algebraic Structures

#46

Post by srean »

mcphage wrote: post #45
BoiledCabbage wrote: post #44

Earlier quoted context omitted.

That's like saying when implementing a function you shouldn't call another fn, you should copy and paste its implementation so you don't have to flip to another location in the code. The right way is to learn what the function means so you can set see calls to it and know what it does.

The purpose of the site is to be: > So, that’s the intent of this post – to be that fast reference to the kinds of algebraic structures I care about. I learned these structures in the early 90s; I don’t need to be told the right way to learn them. However, a “fast reference” would be useful.

For arithmetic properties and definitions do you suggest tracing them right to Peano axioms ?

Re: A Brief Guide to a Few Algebraic Structures

#47

Post by wsxcde »

hackernews7899 wrote: post #28
wsxcde wrote: post #13

Is there a good textbook that covers these? I am primarily interested in a computer science perspective to these algebraic structures.

Check out “Seven Sketches in Compositionality“ by Spivak and Fong. You can find a free copy provided by the authors online. It is an introductory book to applied category theory.

This was a great recommendation, thanks!

Re: A Brief Guide to a Few Algebraic Structures

#48

Post by mcphage »

srean wrote: post #46
mcphage wrote: post #45

Earlier quoted context omitted.

The purpose of the site is to be: > So, that’s the intent of this post – to be that fast reference to the kinds of algebraic structures I care about. I learned these structures in the early 90s; I don’t need to be told the right way to learn them. However, a “fast reference” would be useful.

For arithmetic properties and definitions do you suggest tracing them right to Peano axioms ?

If the page had arithmetic structures, then obviously yes. Groups don’t include those properties, which is why they are not listed, and that is a very important distinction.
Post reply on HN