3 ms·

Maybe you should start implementing other PRNGs then across various package management systems and programming languages to promote your cause? If you keep ign

Maybe you should start implementing other PRNGs then across various package management systems and programming languages to promote your cause? If you keep ignoring 90% of my opinion then I don't wanna discuss this with you anymore either. I never said MT is superior, it's what you implied.

stouset 2y ago
Better PRNGs are widespread and available in literally every developer ecosystem. This isn’t the ‘90s. If PCG isn’t available for yours, it is trivial to reimplement. typedef struct { uint64_t state; uint64_t inc; } pcg32_random_t; uint32_t pcg32_random_r(pcg32_random_t* rng) { uint64_t oldstate = rng->state; // Advance internal state rng->state = oldstate \* 6364136223846793005ULL + (rng->inc|1); // Calculate output function (XSH RR), uses old state for max ILP uint32_t xorshifted = ((oldstate >> 18u) ^ oldstate) >> 27u; uint32_t rot = oldstate >> 59u; return (xorshifted >> rot) | (xorshifted << ((-rot) & 31)); } That’s it. That’s the whole thing.
- cookiengineer 2y ago
  You are aware that you don't need to mansplain the implementation to me, right? My argument, from the beginning, was about maintainability from a company's perspective. Also you do realize I am not a user of MT, right?
  - stouset 2y ago
    > My argument, from the beginning, was about maintainability from a company's perspective. Better mansplaining than gaslighting I suppose. Your argument, from the beginning, was (quoted in full): “Reproducibility, on both client and server side. Easy to implement in pretty much all scripting and programming languages.” None of your actual original argument, nor what you’re now claiming it was, nor the ones inbetween hold water. It’s reproducible like every non-CS PRNG. It’s not simple, or simpler than alternatives. It doesn’t strike a “balance” between simplicity and being cryptographic (which is frankly a really weird thing to say; being cryptographic isn’t a spectrum). It’s not CS, and so it competes against the modern alternatives which are strictly simpler. I mean I’m genuinely sorry that that you’re misinformed here, but that’s on you to reconcile. What’s the point in dying on this hill? > You are aware that you don't need to mansplain the implementation to me, right? If we’re being blunt and rude, it seems pretty obvious you did need this. > Also you do realize I am not a user of MT, right? In what way is this relevant?
    - cookiengineer 2y ago
      Seeing your comment has been edited (again) at least 10 times the last 15 minutes, changing your argument, structure and content a lot that you want to criticize...the only thing I have left for you is this: If you learn to argue in echo chambers, you won't grow on a personal level. That's not how the real world works, and not in any job profession. Nobody in their right mind will say "you won that argument" if the opponent posts the implementation code as an argument that is supposed to win over the "lack of maintainability" argument before that. If you don't understand why there are package managers in the first place, then maybe you should ask someone _why_ they are so successful? I hope you learn to love the embedded development world, because you, right now, seem to be very unhappy in it. Otherwise you wouldn't be so enraged over a very simple argument like this one. I wish you the best. Maybe at some point in the future you will learn to differ critique on a subject from critique on a personal level. This was never a personal attack, and I thought I made that very clear. If you interpreted this as a personal attack, then I guess I am sorry? I won't change my previous comment because I think that is unfair behavior. The argument MT vs PRNG XYZ will never be won with implementation code as "proof that it is really better". I am not sure you understand that. There is no point in "dying on this hill". Opinions change over time, there is never a right or wrong, ever, which will persist. _Everything_ is a tradeoff. If you still think that, you haven't been coding long enough to see how much worse your own code was when you were younger. Implementations change, bugs are found, problems are discovered and fixed, knowledge changes. Just look at the PIKE/SIKE fiasco the last years. The only thing that persists is the constant maintenance burden. And I don't want to have to maintain a randomizer, because it's the most unnecessary thing to maintain with the most collateral damage if it's ignored.
      - stouset 2y ago
        I’m not enraged, I’m just baffled that someone would come in to a conversation, state things that are wrong, then dig in their heels rather than say “ah yeah I see”. And then keep changing what their “original argument” was in a thread where you can literally scroll up to see what it was. And sorry for the edits, it’s usually not a problem since the time delta between a reply and and it being read it is usually large. I’m just never satisfied with what I’ve written, so I edit until I am. Maybe day I’ll learn to do that before I post. > This was never a personal attack, and I thought I made that very clear. You were the one that brought a personal attack into the conversation. Sucks to be on the receiving end, yeah? > The argument MT vs PRNG XYZ will never be won with implementation code as "proof that it is really better". I am not sure you understand that. It sure as hell is a convincing argument that it’s simpler to implement than MT. > If you still think that, you haven't been coding long enough to see how much worse your own code was when you were younger. 25 years in to my career, thanks. I regularly think this about code I wrote last week. I’m missing the relevance. > knowledge changes It does. I used to be a fan of MT in the nineties when I was young. It sounded cool and it wowed with a huge period stamped on the tin. I updated my knowledge as time passed. > And I don't want to have to maintain a randomizer, because it's the most unnecessary thing to maintain with the most collateral damage if it's ignored. Nobody is asking you to. You’re the one that jumped in to defend MT as a reasonable choice. It isn’t. Progress has happened and this hasn’t been true for a very long time.

stouset 2y ago

Better PRNGs are widespread and available in literally every developer ecosystem. This isn’t the ‘90s. If PCG isn’t available for yours, it is trivial to reimplement. typedef struct { uint64_t state; uint64_t inc; } pcg32_random_t; uint32_t pcg32_random_r(pcg32_random_t* rng) { uint64_t oldstate = rng->state; // Advance internal state rng->state = oldstate \* 6364136223846793005ULL + (rng->inc|1); // Calculate output function (XSH RR), uses old state for max ILP uint32_t xorshifted = ((oldstate >> 18u) ^ oldstate) >> 27u; uint32_t rot = oldstate >> 59u; return (xorshifted >> rot) | (xorshifted << ((-rot) & 31)); } That’s it. That’s the whole thing.

cookiengineer 2y ago
You are aware that you don't need to mansplain the implementation to me, right? My argument, from the beginning, was about maintainability from a company's perspective. Also you do realize I am not a user of MT, right?
- stouset 2y ago
  > My argument, from the beginning, was about maintainability from a company's perspective. Better mansplaining than gaslighting I suppose. Your argument, from the beginning, was (quoted in full): “Reproducibility, on both client and server side. Easy to implement in pretty much all scripting and programming languages.” None of your actual original argument, nor what you’re now claiming it was, nor the ones inbetween hold water. It’s reproducible like every non-CS PRNG. It’s not simple, or simpler than alternatives. It doesn’t strike a “balance” between simplicity and being cryptographic (which is frankly a really weird thing to say; being cryptographic isn’t a spectrum). It’s not CS, and so it competes against the modern alternatives which are strictly simpler. I mean I’m genuinely sorry that that you’re misinformed here, but that’s on you to reconcile. What’s the point in dying on this hill? > You are aware that you don't need to mansplain the implementation to me, right? If we’re being blunt and rude, it seems pretty obvious you did need this. > Also you do realize I am not a user of MT, right? In what way is this relevant?
  - cookiengineer 2y ago
    Seeing your comment has been edited (again) at least 10 times the last 15 minutes, changing your argument, structure and content a lot that you want to criticize...the only thing I have left for you is this: If you learn to argue in echo chambers, you won't grow on a personal level. That's not how the real world works, and not in any job profession. Nobody in their right mind will say "you won that argument" if the opponent posts the implementation code as an argument that is supposed to win over the "lack of maintainability" argument before that. If you don't understand why there are package managers in the first place, then maybe you should ask someone _why_ they are so successful? I hope you learn to love the embedded development world, because you, right now, seem to be very unhappy in it. Otherwise you wouldn't be so enraged over a very simple argument like this one. I wish you the best. Maybe at some point in the future you will learn to differ critique on a subject from critique on a personal level. This was never a personal attack, and I thought I made that very clear. If you interpreted this as a personal attack, then I guess I am sorry? I won't change my previous comment because I think that is unfair behavior. The argument MT vs PRNG XYZ will never be won with implementation code as "proof that it is really better". I am not sure you understand that. There is no point in "dying on this hill". Opinions change over time, there is never a right or wrong, ever, which will persist. _Everything_ is a tradeoff. If you still think that, you haven't been coding long enough to see how much worse your own code was when you were younger. Implementations change, bugs are found, problems are discovered and fixed, knowledge changes. Just look at the PIKE/SIKE fiasco the last years. The only thing that persists is the constant maintenance burden. And I don't want to have to maintain a randomizer, because it's the most unnecessary thing to maintain with the most collateral damage if it's ignored.
    - stouset 2y ago
      I’m not enraged, I’m just baffled that someone would come in to a conversation, state things that are wrong, then dig in their heels rather than say “ah yeah I see”. And then keep changing what their “original argument” was in a thread where you can literally scroll up to see what it was. And sorry for the edits, it’s usually not a problem since the time delta between a reply and and it being read it is usually large. I’m just never satisfied with what I’ve written, so I edit until I am. Maybe day I’ll learn to do that before I post. > This was never a personal attack, and I thought I made that very clear. You were the one that brought a personal attack into the conversation. Sucks to be on the receiving end, yeah? > The argument MT vs PRNG XYZ will never be won with implementation code as "proof that it is really better". I am not sure you understand that. It sure as hell is a convincing argument that it’s simpler to implement than MT. > If you still think that, you haven't been coding long enough to see how much worse your own code was when you were younger. 25 years in to my career, thanks. I regularly think this about code I wrote last week. I’m missing the relevance. > knowledge changes It does. I used to be a fan of MT in the nineties when I was young. It sounded cool and it wowed with a huge period stamped on the tin. I updated my knowledge as time passed. > And I don't want to have to maintain a randomizer, because it's the most unnecessary thing to maintain with the most collateral damage if it's ignored. Nobody is asking you to. You’re the one that jumped in to defend MT as a reasonable choice. It isn’t. Progress has happened and this hasn’t been true for a very long time.