# clamp / median / range

DevFeed: [clamp / median / range](<https://devfeed.tech/articles/clamp-median-range-36218.md>)

Original publisher: [Read original article](<https://dotat.at/@/2025-07-02-cmp.html>)

Published: 2025-07-02T01:33:08Z

Content type: article

Language: en

Sources: [Tony Finch's blog](<https://devfeed.tech/sources/tony-finch-s-blog.md>)

Topics: [Programming](<https://devfeed.tech/topics/programming.md>), [Code](<https://devfeed.tech/topics/code.md>), [function](<https://devfeed.tech/topics/function.md>), [syntax](<https://devfeed.tech/topics/syntax.md>), [iteration](<https://devfeed.tech/topics/iteration.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [comparison](<https://devfeed.tech/tags/comparison.md>), [function](<https://devfeed.tech/tags/function.md>), [languages](<https://devfeed.tech/tags/languages.md>), [sequence](<https://devfeed.tech/tags/sequence.md>), [syntax](<https://devfeed.tech/tags/syntax.md>)

## AI overview

The article explores stylistic conventions for comparison operators, including chained comparisons, ordering values from least to greatest, and arranging clamp arguments to match that order. It then considers median-of-three implementations that are insensitive to argument order and proposes a speculative range syntax for pattern matching, iteration, and slicing.

## Source excerpt

Here are a few tangentially-related ideas vaguely near the theme of comparison operators. comparison style clamp style clamp is median clamp in range range style style clash? comparison style Some languages such as BCPL, Icon, Python have chained comparison operators, like if min <= x <= max: ... In languages without chained comparison, I like to write comparisons as if they were chained, like, if min <= x && x <= max { // ... } A rule of thumb is to prefer less than (or equal) operators and avoid greater than. In a sequence of comparisons, order values from (expected) least to greatest. clamp style The clamp() function ensures a value is between some min and max, def clamp(min, x, max): if x < min: return min if max < x: return max return x I like to order its arguments matching the expected order of the values, following my rule of thumb for comparisons - and the description of what clamp() does. (I used this flavour of clamp() in my article about GCRA.) But I seem to be unusual in this preference, based on a few examples I have seen recently. clamp is median Last month, Fabian Giesen pointed out a way to resolve this difference of opinion: A function that returns the median of three values is equivalent to a clamp() function that doesn't care about the order of its arguments. This version is written so that it returns NaN if any of its arguments is NaN. (When an argument is NaN, both of its comparisons will be false.) fn med3(a: f64, b: f64, c: f64) -> f64 { match (a <= b, b <= c, c <= a) { (false, false, false) => f64::NAN, (false, false, true) => b, // a > b > c (false, true, false) => a, // c > a > b (false, true, true) => c, // b <= c <= a (true, false, false) => c, // b > c > a (true, false, true) => a, // c <= a <= b (true, true, false) => b, // a <= b <= c (true, true, true) => b, // a == b == c } } When two of its arguments are constant, med3() should compile to the same code as a simple clamp(); but med3()'s misuse-resistance comes at a small cost when t