4 ms·
> 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-reduc
by 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 agoIt 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 agoHey, 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.