Comment by raverbashing

2 years ago

Wow big oooff

One thing I noticed is that min/max functions are tricky to use and it's easily to accidentally do the wrong thing, like in this case

Because you think "you want the minimum (that is, the number should be at least 8) of those numbers to be 8" then you slap min(). And you got it wrong. You should have used max()

5 comments

raverbashing

Reply
xanathar  2 years ago

After reading the article quickly, I'm not even sure there's a bug or not, the only thing that seems obviously wrong to me is the headline.

But that aside, I feel your pain around min() and max(). In my case, I feel the problem comes from language (I mean, the real life one): I speak Italian and in Italian the words for "at most" are "al massimo" (i.e. "at max") and the words for "at least" are "come minimo" (i.e. "as min") that is, the exact opposite of their mathematical meaning. I've taken an habit of reviewing 3 times any piece of code where I write "min" or "max" for this reason.

richrichardsson  2 years ago

It would have been more of a bug to set this value to minimum 8 on a system with fewer than 8 cores.

I appears the author has misunderstood exactly what was its purpose, and that setting this scaling factor unbound beyond 8 cores would have detrimental effects even if there are more cores available.

PhilipRoman  2 years ago

I don't think that's the case here, but yeah min and max can be a bit confusing to read. If your language allows adding methods or infix operators without performance overhead, I like to make something like this:

    x.atLeast(10).atMost(100)

Very easy to read in my opinion

  • masklinn  2 years ago

    I find the word “clamp” extremely satisfying for this concept, especially with optional named parameters in order to leave off one bound e.g. `x.clamp(low=10)` but it still works fine with both required and anonymous, it’s just a bit less convenient.