I find that the fact that the functions min and max have the same name as the variables min and max increases cognitive load which makes it harder to think about it.
Next challenge: teach the optimizer to make that almost as fast as the min/max way ;-)
(You can’t reduce it to the min/max call because it also works if you accidentally pass a lower bound that’s larger than the upper bound. Worst-case, the above takes 3 comparisons, unless at least two of the inputs are constants)
You know what's great about that? The order of the arguments doesn't matter. So all the debate about "should it be num, min, max or min, num, max"- your solution does not care. Put them in any order you like!
You've redefined the problem from clamping a given value into picking the middle value from 3. This is a lovely way to re-interpret it.
I think the reason it's weird is that we might intuitively think of the "enforce a lower bound" function as taking two named arguments (lowerBound and inputValue) and the order of those two arguments mattering.
But of course, it turns out that the order of the arguments doesn't matter: applying a lowerBound of 5 to an inputValue of 100 turns out to be the exact same thing as applying a lowerBound of 100 to an inputValue of 5.
We know that the order of arguments doesn't matter for the Math.max function, so I think that's where the moment of incredulity comes from.
There was a young coder whose hacks
His manager often claimed lacked
The requisite clarity
For to clamp vars would he:
Math.min(Math.max(number, min), max);
I use ceil/floor (and make people use whenever I can) if something is going to happen when something hits the ceiling or drops to the floor. And avoid if it is just for clamping.
func helper(a float64, c chan float64){
time.Sleep(time.Duration(a) * time.Second)
c <- a
}
func clamp(a float64, min float64, max float64) float64 {
c := make(chan float64, 3)
go helper(a, c)
go helper(min, c)
go helper(max, c)
_, out, _ := <-c, <-c, <-c
return out
}
It gets a bit confusing when the order of arguments is different depending on the library. For instance, with std it's std::clamp(val, min, max), but with Qt it's qBound(min, val, max) (for some reason I think the order of arguments in qBound is more logical).
In Haskell, functions often take their arguments in the order that makes the most sense to partially apply. In this case, that would probably be clamp(min, max, val): supplying the first two arguments results in a reusable clamping function.
The expression Math.min(Math.max(num, min), max) is symmetric in min and num, so it doesn’t matter whether you interchange min and num (or, for that matter, max and num, but that is harder to see from that way to define the ‘clamp’ function)
It depends. (val, min, max) operates on a first argument, which is more logical as well. (min, max, val) allows range constants to be more visible if <val> is a lenghty expression. In more powerful languages like objective-c this has less sense, as you can always specify all arguments explicitly:
Which returns NSIntegerMax and sets the error variable if the range appears to be empty. The chance that max is NSIntegerMax is low, but if your data allows that, you can always put an additional shortcut before clamping.
if (min > max) {
error = [NSError errorWithDescription:@"min > max occured"];
return NO; // or equivalent
} else {
x = ...
}
// use x
> Modern C# has Math.Clamp() since .NET Core 2.0; too bad it’s not available in desktop edition of the runtime.
Huh, that’s good to know. It’s also in .net standard 2.1. A shame it wasn’t added to Framework 4.8 (which I guess is what you mean by "desktop edition of the runtime"?)
C++17 does have it... but it doesn't compile optimally. It compiles to something based on comparisons instead of the floating-point-specific operations. I tried this on a number of compiler combinations and didn't see anything that would emit min/max instructions for `std::clamp<double>`.
MS .NET framework. Unfortunately, for the last couple years it lags behind .NET core. Even 2 years old .NET core 2.1 is better in some regards than the latest desktop version 4.8.
I’ve been programming for living since 2000, but I don’t think that’s relevant. No reason not to use what’s available in standard libraries of whatever language you’re writing.
For example, C++ on AMD64 is very likely to compile std::clamp<double> into 2 instructions, minsd and maxsd. I’m not so sure about nested ternaries mentioned elsewhere in the comments.
I'd say the only way this would be better than min/max solution is that you can't accidentally flip it when writing the code - but IMO both suck at expressing intent, clamp reads unambiguously.
I find myself needing this most frequently in making graphics in R. The scales package has squish() with the same behavior:
squish(25, c(5, 10))
=> 10
squish(6, c(5, 10))
=> 6
squish(1, c(5, 10))
=> 5
If you don't provide the limits it defaults to c(0, 1). That's because this function exists to map to a 0-to-1 range for functions that then map the [0, 1] range to a color ramp.
True, nested ternaries can be hard to follow. And the excessive parentheses promote this way of looking at it.
OTOH I think chained ternaries can be simple and easy to understand.
Yes, they are the exact same thing in this case, but getting rid of those nested parens really helps, at least for me.
sarah180's example is a good illustration. I would change the order of the tests because it makes more sense to me to check the min before the max. I'd also make one minor formatting change, because I code in a proportional font and can't line things up in columns:
a < min ? min :
a > max ? max :
a
Maybe people think differently, but to me that is super easy to understand, and much better than the confusing Math.min/max stuff.
I would also wrap the whole thing inside a function:
function clamp( value, min, max ) {
return(
value < min ? min :
value > max ? max :
value
);
}
Now that it's inside a function, you could change the code to use if statements, or Math.min/max, or whatever suits your preferences.
I don't find this a whole lot easier to read to be honest. It seems like doing minification manually, when we have tools to do that for us. An if statement seems a lot clearer, and minifies well https://twitter.com/jaffathecake/status/1296423819238944768
Note that with modern branch predictors such optimizations may not actually be beneficial–ARM got rid of condition codes on all its instructions in the 64-bit version. (Plus, I assume they ran out of space to encode them.)
This is 3 branches. The Math method ends up with 4.
This is one of those cases where I think it is much more readable to just write the code than to puzzle over what Math.min(Math.max(min, num), max); might be doing.
if (num < min)
return min;
if (num > max)
return max;
return num;
That's how I'd write it. May not be super terse, but anyone that stumbles on this will know precisely what's happening without needing to take a few seconds to puzzle things out.
To me the danger of this kind of one liners is that if you use it 2 times somewhere, someone, at some point, will do the lazy refactor of “let’s put it into a function”.
int clamp (int value, int min, int max)
And that one liner inside. And now you have a double evaluation bomb waiting to go out on your codebase.
This is what I love about kotlin. The standard library has a good coverage of these kinds of problems and it is done in a simple an clean way. I had the same feeling with Python, the language got you cover with mundane tasks and you don't have to spend time researching libs that do it for you (or spend your time doing a clamp implementation + tests).
I haven't heard of any instances of Kotlin itself optimizing these things away, but the JVM may be able to do so during its various JIT passes. It's definitely not something you can necessarily rely on, though.
Luckily, these convenience methods are usually implemented as inline extension functions, so the whole thing will get inlined into the calling method, making JIT optimization more likely.
Readit News
I find the following easier to read :
(You can’t reduce it to the min/max call because it also works if you accidentally pass a lower bound that’s larger than the upper bound. Worst-case, the above takes 3 comparisons, unless at least two of the inputs are constants)
I did exactly this for my PhD!
https://chrisseaton.com/phd/
You've redefined the problem from clamping a given value into picking the middle value from 3. This is a lovely way to re-interpret it.
Math.max(lower_bound, Math.min(num, upper_bound))
Since i read right to left.
Deleted Comment
But of course, it turns out that the order of the arguments doesn't matter: applying a lowerBound of 5 to an inputValue of 100 turns out to be the exact same thing as applying a lowerBound of 100 to an inputValue of 5.
We know that the order of arguments doesn't matter for the Math.max function, so I think that's where the moment of incredulity comes from.
But "min(-, constant_x)" should be thought of as "at most constant_x" and similarly for max. Maybe there's a way to make it more expressive.
I sometimes mix up "min" as "take the minimum" rather than "take the larger given this minimum".
near get(), post(), and ajax()
// we alias at import
// to keep all the code short
min(max(number, min), max)
Deleted Comment
C++/17 has std::clamp() in <algorithm> header.
Modern C# has Math.Clamp() since .NET Core 2.0; too bad it’s not available in desktop edition of the runtime.
HLSL has clamp() intrinsic function, and a special version saturate() to clamp into [ 0 .. +1 ] interval.
The list of hard programming things is long; things that are trivially solved by a tool shouldn't be in the list.
Huh, that’s good to know. It’s also in .net standard 2.1. A shame it wasn’t added to Framework 4.8 (which I guess is what you mean by "desktop edition of the runtime"?)
https://www.godbolt.org/z/MKqTvE
huh?
For example, C++ on AMD64 is very likely to compile std::clamp<double> into 2 instructions, minsd and maxsd. I’m not so sure about nested ternaries mentioned elsewhere in the comments.
> Fout bij het maken van de databaseconnectie
squish(25, c(5, 10)) => 10
squish(6, c(5, 10)) => 6
squish(1, c(5, 10)) => 5
If you don't provide the limits it defaults to c(0, 1). That's because this function exists to map to a 0-to-1 range for functions that then map the [0, 1] range to a color ramp.
But it looks dead: https://github.com/rwaldron/proposal-math-extensions/issues/...
As someone mentioned in the thread, nested ternary is easier to interpret:
(a > max ? max : (a < min ? min : a))
OTOH I think chained ternaries can be simple and easy to understand.
Yes, they are the exact same thing in this case, but getting rid of those nested parens really helps, at least for me.
sarah180's example is a good illustration. I would change the order of the tests because it makes more sense to me to check the min before the max. I'd also make one minor formatting change, because I code in a proportional font and can't line things up in columns:
Maybe people think differently, but to me that is super easy to understand, and much better than the confusing Math.min/max stuff.I would also wrap the whole thing inside a function:
Now that it's inside a function, you could change the code to use if statements, or Math.min/max, or whatever suits your preferences.Deleted Comment
[1] https://web.stanford.edu/class/cs343/resources/superoptimize...
If I just say "sub d1, d2", of course I mean the whole register width, and not just 16 or 8 bits of it.
This is one of those cases where I think it is much more readable to just write the code than to puzzle over what Math.min(Math.max(min, num), max); might be doing.
That's how I'd write it. May not be super terse, but anyone that stumbles on this will know precisely what's happening without needing to take a few seconds to puzzle things out.Deleted Comment
It also has
andLuckily, these convenience methods are usually implemented as inline extension functions, so the whole thing will get inlined into the calling method, making JIT optimization more likely.