3 ms·

> most programmers are really bad at […] mathematics. I wouldn't be so sure. Many of us got into programming to flee what we often call "mathematics". But th

> most programmers are really bad at […] mathematics. I wouldn't be so sure. Many of us got into programming to flee what we often call "mathematics". But the stuff we learned in school is quite different from actual mathematics (rote application of recipes, and tedious exercises, mostly). I'm pretty sure we can teach maths to those traumatised programmers. Just don't utter the "M" word so they don't recoil in horror. Monoids for instance are a deeply mathematical, yet very simple concept. And useful too: want to do map-reduce? make sure your binary operation is associative (meaning, make sure your stuff is a monoid), or you won't be able to parallelise your reduce step.

AstralStorm 9y ago
And you made the mistake here just as I expected. Map-reduce does not require associativity as long as you know the order of the operation execution. (Or error due to operation reordering is bounded and acceptable.) You break the assumption any time you use floating point math. Then you've added a property to an operation that does not require it. Many "math types" like to do such things to simplify proofs and there you end up with variations of spherical cow results, either in applicability or performance.
- loup-vaillant 9y ago
  > Map-reduce does not require associativity as long as you know the order of the operation execution. Good luck knowing that order when using a magic map-reduce to parallelise things for you. > You break the assumption any time you use floating point math. You're just nitpicking here. Either I care about the non-associativity, and I have to control the ordering of the reduce operation (the best one might be a parallel bottom-up merge), or I don't care, and I'll be using -ffast-math already.
  - AstralStorm 9y ago
    It is not nitpicking. Either a property is true or it not. This is exactly the point article author is making when resisting design pattern ambiguity. If you cheat you will get invalid results sooner than later. Essentially bugs. Sometimes trivial, sometimes a billion dollar rocket explodes. If you use math name but lie about it is even worse than if you don't use the concept at all. For example a String despite what author says is not a Monoid in almost all languages as catenation (operation +) is not strictly associative. (Because memory allocation is different!) Yet he does this mistake...
    - loup-vaillant 9y ago
      Hey, you brought up floating points. I talked about monoids, not floating points. I don't even make the assumption you say I break when I use floating points. Of course floating points aren't a monoid, let alone a group or a field. > catenation (operation +) is not strictly associative. (Because memory allocation is different!) What the hell are you talking about? The ordering of operation influences the address of the result? Who ever cares about that? Even in C, you don't rely on the value of such addresses —only their uniqueness. > Yet he does this mistake... Step down your high horse.

AstralStorm 9y ago

And you made the mistake here just as I expected. Map-reduce does not require associativity as long as you know the order of the operation execution. (Or error due to operation reordering is bounded and acceptable.) You break the assumption any time you use floating point math. Then you've added a property to an operation that does not require it. Many "math types" like to do such things to simplify proofs and there you end up with variations of spherical cow results, either in applicability or performance.

loup-vaillant 9y ago
> Map-reduce does not require associativity as long as you know the order of the operation execution. Good luck knowing that order when using a magic map-reduce to parallelise things for you. > You break the assumption any time you use floating point math. You're just nitpicking here. Either I care about the non-associativity, and I have to control the ordering of the reduce operation (the best one might be a parallel bottom-up merge), or I don't care, and I'll be using -ffast-math already.
- AstralStorm 9y ago
  It is not nitpicking. Either a property is true or it not. This is exactly the point article author is making when resisting design pattern ambiguity. If you cheat you will get invalid results sooner than later. Essentially bugs. Sometimes trivial, sometimes a billion dollar rocket explodes. If you use math name but lie about it is even worse than if you don't use the concept at all. For example a String despite what author says is not a Monoid in almost all languages as catenation (operation +) is not strictly associative. (Because memory allocation is different!) Yet he does this mistake...
  - loup-vaillant 9y ago
    Hey, you brought up floating points. I talked about monoids, not floating points. I don't even make the assumption you say I break when I use floating points. Of course floating points aren't a monoid, let alone a group or a field. > catenation (operation +) is not strictly associative. (Because memory allocation is different!) What the hell are you talking about? The ordering of operation influences the address of the result? Who ever cares about that? Even in C, you don't rely on the value of such addresses —only their uniqueness. > Yet he does this mistake... Step down your high horse.