Abstract algebra for developers and people who hate math
poincare101.blogspot.com
poincare101.blogspot.com
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.
>(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.
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.
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
"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."
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.
Edit: OP stated he will edit the article to include more CS application.
I will present more applications and such in the next one.
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.
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.
Anyway, thanks!
This is the exact feeling I have and were it not for the HN comments, I would have closed it without actually reading the content.
But, I'll definitely do that in the next one and see what the response is.
> 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
I'll be doing more abstract algebra stuff, so, followers would be great :)
For a real CS example, see cryptography.
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.
i stopped reading after that.