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.
> 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.
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...
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.
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.