People who hate math aren't going to be inspired by a collection of axioms and equations. Nor are they likely to be wowed by the examples of matrices and vectors. Some examples from geometry, or permutations, might be more likely to teach the concepts.
People who know something about math are going to spot several errors in the presentation. For example, the reals with multiplication don't form a group, since 0 has no multiplicative inverse.
Not an error, but a subtlety: the collection of axioms here says that the group has a right identity and right inverses. It's later assumed that the identity is also a left identity (in the proof of uniqueness). This is true, as it happens, but it's not entirely obvious. The usual presentation of groups has two-sided identities and inverses up-front.
Actually, the alternative axiom set of a right identity, but left inverses, has models that are not groups. An example is a left zero semigroup, where ab = a for all a and b. We have right identity (ae = a; no problem) and left inverses (for all a, there exists b such that ba = e; yes, just take b = e). This isn't a group! (OK, unless it has only one element.)
Maybe this illustrates an interesting point for developers: the axiomatic approach is like having a common interface for some class of objects, and it's helpful to be able to reason about them without knowing the details of how they're implemented. But reasoning about the expressive power of different interfaces or specifications can be horribly difficult. The Robbins conjecture (about the equivalence of two axiom sets for Boolean algebra) was open from 1933 to 1996 - and proved in an automated theorem prover, no less.
> People who hate math aren't going to be inspired by a collection of axioms and equations.
So true. My favorite quotation on this subject (admittedly, there aren't that many):
"Many a graduate student has come to grief when they discover, after a decade of being told they were "good at math," that in fact they have no real mathematical talent and are just very good at following directions. Math is not about following directions, it's about making new directions...It would be bad enough if the culture were merely ignorant of mathematics, but what is far worse is that people actually think they do know what math is about - and are apparently under the gross misconception that mathematics is somehow useful to society!...In any case, do you really think kids even want something that is relevant to their daily lives? You think something practical like compound interest is going to get them excited? People enjoy fantasy, and that is just what mathematics can provide - a relief from daily life, an anodyne to the practical workaday world."
- Paul Lockhart
Also relevenat, by the same author:
"You don't start with definitions, you start with problems. Nobody ever had an idea of a number being "irrational" until Pythagoras attempted to measure the diagnonal of a square and discovered that it could not be represented as a fraction. Definitions make sense when a
point is reached in your argument which makes the distinction necessary. To make definitions without motivation is more likely to cause confusion."
Are you also going to fix the assertion that matrices form a group under multiplication? (They don't: not all matrices have inverses. The general linear group is what you are probably looking for.) It's a bit embarrassing that of your three examples of groups, only one is actually a group...
>(like, matrix multplication isn't commutative, that means: A∗B≠B∗A when B and A are matrices)
You want to say something like "A∗B isn't necessarily equal to B∗A when B and A are matrices." Neither A∗B≠B∗A nor A∗B=B∗A are true in general when A and B are matrices.
I think that your last point is a worthy tie-in to the developer's world.
For example, for those who use C# or Java regularly: groups, Abelian groups, and integers under addition are roughly analogous to the Enumerable interface, the List interface, and the ArrayList class.
Obviously they serve different purposes, but their role in their respective professions is approximately the same. Groups appear all over the place in math, and the Enumerable interface is baked right into the for(each) loop. Abelian groups add commutativity to general groups, and the List interface adds indexing and insertion to Enumerables. Meanwhile integers/ArrayLists are basically the go-to concrete implementation that mathematicians/programmers default to when it comes to Abelian groups/lists.
That analogy works excellently until you consider the implementation of these things, and then its a complete mess because there are side effects all over the place, except in languages like haskell.
I hate to be negative but the title is misleading. There is no way any of this will appeal to people who hate math. A reader who 'hates math', implies that they have very little background in set theory and would be hard-pressed to define a Venn diagram. I am such a person and I couldn't get past the first definitions, although I tried. I need more background knowledge, and asking that I read a hefty Wikipedia article to get up to speed isn't going to cut it.
I'm sure the content is good, and for people who already know what the symbols mean, you've probably done a great job of making it meaningful but the title should be - 'Abstract algebra revisited for serious students of abstract algebra' or something like that.
Agreed. I understand what this article presented, but in no way was this any different or better than how this material was presented to me in college. At least in school I could go bug the professor after class to explain to me why I didn't get it.
I guess so. Basically, I wanted it to be for people who had learned SOME math in college, but had really hated the experience, and wanted something different.
Nice read, and nice example of specialization: Simply putting "for developers" in the title surely helped this article get so high on HN, though there's no application of computer science or programming to make the article more tailored for developers. I don't want to sound snarky by any means, as I did genuinely enjoy the article, but it's neat to see marketing 101 in action: Simply picking and acknowledging an audience(developers) made the reception of the article so much stronger.
Edit: OP stated he will edit the article to include more CS application.
My favorite section is where he gives the context of how abstract algebra came about in the 19th century. It connects the theoretical with real world problem, which makes it far more interesting.
Agreed! I took a few math major classes as a freshman, but my professors never took the time to give this aerial view. Now the value in these generalizations makes perfect sense.
I don't hate math but don't quite getting what I can do with this knowledge to develop something new or different from what I would develop without it. Please help with enlightenment?
The thing is, to make any advances in mathematics (since it is such an old subject with large advancements and abstractions already made), you can't really make much progress in math per se, but, it really gives you a much better understanding how things like classes and type systems work, and in general makes you a better programmer.
I will present more applications and such in the next one.
An admirable attempt, but -- the formatting and the grammar are distracting detractors from the content.
For anyone who is serious about learning abstract algebra but lacking mathematical background (i.e. an analysis course under the belt), consider the book "Abstract Algebra" by Dummit and Foote. It's at the undergraduate level (so it goes through the motions of rigor that research math texts often omit), and well presented. A more advanced, terse and elegant, text would be Hershtein's Topics in Algebra.
Nice content! Thanks for putting it in more easy words.
If I could give you a suggestion, a better way of showing it could be better. Like some slides, or colors. Something that made more friendly to read. Although the content is good, scanning it do not made me want to read right way.
I don't think either of these things will provide a solution that the above is looking for. The problem is with the layout of your content and the fact that write like a math professor. I imagine you scare a lot of people off with a ton of math symbols at the opening, maybe leave that for later, or explain it all in plain English instead of using symbols.
You should probably use symbols after an "in plain english" description. I'm not too sure what the solution is, but the content was good once I decided to actually read it.
To confuse the issue further, I very much appreciated the format. I've found it much easier to get a better understanding of things like this when it's well-written text instead of slides. Slides that try to stand alone without supporting text (either spoken or written) tend to present a collection of facts without adequately explaining the concepts behind the facts (or the slides contain way too much text).
> And, the problem was, mathematics was losing its "connectivity", all these new algebras had little to no connection to each other, and it was very difficult to make progress in a few of these algebras at once.
I went through 6 upper division abstract algebra classes without one professor providing this background. It's quite obvious once I read it, which is what makes it an amazing motivation.
There were some formatting notations that didn't display--mostly superscripts that displayed in-line
As a As a current student in Abstract Algebra, this was really refreshingly simple to look at . Thanks fro a greatly simplified teaser to show other people!
Sorry, but OOP has virtually nothing to do with abstract algebra. Your whole post is about proving that something belongs to a general class and using the properties of a general class, and making such a vague analogy is completely contrary to that.
Properly-done OOP is all about abstraction and reasoning. You're taking a set of concepts (business concepts, technical concepts, etc) and building a (hopefully) consistent model of how those concepts relate to each other. Included in this model is a deep understanding of the operations that can be performed on the model you've come up with. If you've done a good job about specifying the abstraction, you end up with a system that is easy to reason about. "If I do this, this will happen."
This is, in essence, the same thing you're doing with abstract algebra; you're looking at common behaviours of different systems, and building up a consistent model that works for all of them, including the operations that you can do. The underlying details may be different for vector addition and matrix multiplication, but, using abstract algebra, you can reason about the behaviour in the same way.
Good OOP has the same effect.
Um. I did. If you read on, I did explain what a closure was. If you don't get it, the concept is pretty simple, if you have two elements in a set S, and you apply the group operation on them, then the result must be in set S for the set in question to be a group.
People who know something about math are going to spot several errors in the presentation. For example, the reals with multiplication don't form a group, since 0 has no multiplicative inverse.
Not an error, but a subtlety: the collection of axioms here says that the group has a right identity and right inverses. It's later assumed that the identity is also a left identity (in the proof of uniqueness). This is true, as it happens, but it's not entirely obvious. The usual presentation of groups has two-sided identities and inverses up-front.
Actually, the alternative axiom set of a right identity, but left inverses, has models that are not groups. An example is a left zero semigroup, where ab = a for all a and b. We have right identity (ae = a; no problem) and left inverses (for all a, there exists b such that ba = e; yes, just take b = e). This isn't a group! (OK, unless it has only one element.)
Maybe this illustrates an interesting point for developers: the axiomatic approach is like having a common interface for some class of objects, and it's helpful to be able to reason about them without knowing the details of how they're implemented. But reasoning about the expressive power of different interfaces or specifications can be horribly difficult. The Robbins conjecture (about the equivalence of two axiom sets for Boolean algebra) was open from 1933 to 1996 - and proved in an automated theorem prover, no less.