Rust: क्लैंप RFC के लिए ट्रैकिंग समस्या

कृपया ध्यान दें: इसने सर्वो और पाथफाइंडर को तोड़ दिया।

cc @rust-lang/libs, यह min / max समान मामला है, जहां पारिस्थितिकी तंत्र पहले से ही clamp नाम का उपयोग कर रहा था, और इसलिए इसे जोड़ने से अस्पष्टता पैदा हुई है। . यह प्रति सेवर नीति के टूटने की अनुमति है, लेकिन फिर भी यह डाउनस्ट्रीम दर्द का कारण बन रहा है।

मंगलवार को ट्राइएज बैठक के लिए नामांकन।

इस बीच कोई विचार?

मैं इस पर @bluss के साथ

restrict
clamp_to_range
min_max (क्योंकि यह न्यूनतम और अधिकतम के संयोजन की तरह है।)
ये काम कर सकते हैं। क्या हम यह निर्धारित करने के लिए क्रेटर का उपयोग कर सकते हैं कि वास्तव में clamp का प्रभाव कितना बुरा है? clamp कई भाषाओं और पुस्तकालयों में अच्छी तरह से पहचाना जाता है।

अगर हमें लगता है कि हमें नाम बदलने की आवश्यकता हो सकती है, तो शायद पीआर को तुरंत वापस करना सबसे अच्छा है, और फिर क्रेटर आदि के साथ अधिक सावधानी से परीक्षण करें। @Xaeroxe , उसके लिए?

ज़रूर। मैंने पहले कभी क्रेटर का उपयोग नहीं किया है, लेकिन मैं सीख सकता हूं।

@Xaeroxe आह क्षमा करें, मेरा मतलब था कि पीआर को जल्दी से वापस करना। (मैं आज छुट्टी पर हूं इसलिए आपको काम पर रखने में मदद करने के लिए @BurntSushi या @alexcrichton जैसे libs पर किसी और की आवश्यकता हो सकती है)।

मैं अभी पीआर तैयार कर रहा हूं। अपनी छुट्टी पर मज़े करो!

पीआर तैयार https://github.com/rust-lang/rust/pull/44438

क्या clamp_to_range(min, max) clamp_to_min(min) और clamp_to_max(max) (अतिरिक्त दावे के साथ कि min <= max ) से बना हो सकता है, लेकिन उन कार्यों को स्वतंत्र रूप से भी कहा जा सकता है?

मुझे लगता है कि विचार एक RFC को अनिवार्य करता है।

मुझे कहना होगा कि हालांकि मैं 6 महीने के लिए एसटीडी लाइब्रेरी में 4 लाइन फ़ंक्शन प्राप्त करने पर काम कर रहा हूं। मैं एक तरह से घिसा हुआ हूं। वही फ़ंक्शन 2 दिनों में num में विलीन हो गया और यह मेरे लिए काफी अच्छा है। अगर कोई और वास्तव में इसे एसटीडी पुस्तकालय में चाहता है, तो आगे बढ़ें, लेकिन मैं इसके लिए और 6 महीने के लिए तैयार नहीं हूं।

मैं इसे फिर से खोल रहा हूं ताकि @aturon का पिछला नामांकन अब भी दिखाई दे.

मुझे लगता है कि या तो इसे लिखित रूप में जाना चाहिए या भविष्य में लोगों के समय को बर्बाद करने से बचने के लिए क्या बदलाव किए जा सकते हैं, इस पर मार्गदर्शन अद्यतन किया जाना चाहिए।

यह शुरू से ही बहुत स्पष्ट था कि यह उसके द्वारा किए गए टूट-फूट का कारण बन सकता है। व्यक्तिगत रूप से, मैंने इसकी तुलना ord_max_min जिसने चीजों का एक समूह तोड़ दिया:

• https://github.com/rust-lang/rust/pull/42496
• https://github.com/bluss/petgraph/issues/153
• https://github.com/rust-lang/rust/issues/43667
• https://github.com/rust-lang/rust/issues/43657
• https://github.com/rust-lang/rust/issues/43665
• https://github.com/rust-lang/rust/issues/43682
• https://github.com/rust-lang/rust/issues/43680
• https://github.com/apasel422/tree/issues/23
• https://github.com/dche/glm-rs/pull/21
• (शायद अधिक, लेकिन वे ट्रैकिंग समस्या से जुड़े थे)

और उस पर प्रतिक्रिया थी "फ़ंक्शन Ord::min जोड़ा गया [...] libs टीम ने आज फैसला किया कि यह टूटना स्वीकार किया गया है"। और वह एक अधिक सामान्य नाम के साथ एक TMTOWTDI सुविधा थी, जबकि clamp पहले से ही एक अलग रूप के तहत एसटीडी में मौजूद नहीं था।

यह मेरे लिए, व्यक्तिपरक रूप से, लगता है कि यदि यह आरएफसी वापस कर दिया गया है, तो वास्तविक नियम यह है कि "आप मूल रूप से Iterator को छोड़कर, एसटीडी में लक्षणों पर नए तरीके नहीं डाल सकते हैं"।

आप वास्तव में वास्तविक प्रकारों पर भी नई विधियां नहीं डाल सकते हैं। उस स्थिति पर विचार करें जहां किसी के पास एसटीडी में एक प्रकार के लिए "विस्तार विशेषता" थी। अब एसटीडी इस प्रकार की एक वास्तविक विधि के रूप में प्रदान की गई विस्तार विशेषता को लागू करता है। तब यह स्थिर हो जाता है, लेकिन यह नई विधि अभी भी एक फीचर फ्लैग के पीछे है। संकलक तब शिकायत करेगा कि विधि एक फीचर ध्वज के पीछे है और इसका उपयोग स्थिर टूलचेन के साथ नहीं किया जा सकता है, बजाय इसके कि संकलक पहले की तरह विस्तार विशेषता की विधि को चुनता है और इस प्रकार स्थिर संकलक पर टूट-फूट का कारण बनता है।

यह भी ध्यान देने योग्य है: यह सिर्फ एक मानक पुस्तकालय समस्या नहीं है। मेथड कॉल सिंटैक्स पारिस्थितिकी तंत्र में कहीं भी ब्रेकिंग परिवर्तनों को शुरू करने से बचना वास्तव में कठिन बनाता है।

(मेटा) बस मेरी टिप्पणी को यहां

अगर हम सहमत हैं कि #44438 उचित है,

1. हमें इस पर पुनर्विचार करने की आवश्यकता हो सकती है कि क्या गारंटी-प्रकार-अनुमान-टूटना जैसे वास्तव में XIB के रूप में अवहेलना किया जा सकता है।

   वर्तमान में टाइप अनुमान परिवर्तन को RFCs 1105 और 1122 द्वारा स्वीकार्य माना जाता है क्योंकि कोई व्यक्ति किसी प्रकार को बाध्य करने के लिए हमेशा UFCS या अन्य तरीकों का उपयोग कर सकता है। लेकिन समुदाय वास्तव में #42496 ( Ord::{min, max} ) के कारण होने वाले टूट-फूट को पसंद नहीं करता है । इसके अतिरिक्त, #41336 ( T += &T का पहला प्रयास) 8 प्रकार के अनुमान प्रतिगमन के कारण "बस" बंद कर दिया गया था।

2. जब भी हम कोई विधि जोड़ते हैं, तो यह सुनिश्चित करने के लिए एक गड्ढा होना चाहिए कि नाम पहले से मौजूद नहीं है।

   ध्यान दें कि अंतर्निहित विधियों को जोड़ने से अनुमान विफलता भी हो सकती है - #41793 अंतर्निहित विधियों को जोड़ने के कारण हुआ {f32, f64}::from_bits , जो डाउनस्ट्रीम विशेषता में ieee754::Ieee754::from_bits विधि के साथ विरोध करता है।

3. जब डाउनस्ट्रीम क्रेट ने #![feature(clamp)] निर्दिष्ट नहीं किया, तो उम्मीदवार Ord::clamp कभी भी विचार नहीं किया जाना चाहिए (भविष्य के अनुकूल चेतावनी अभी भी जारी की जा सकती है) जब तक कि यह अद्वितीय समाधान न हो। यह "इंस्टा-ब्रेकिंग" नहीं नई विशेषता विधियों की शुरूआत की अनुमति देगा, लेकिन स्थिर होने पर समस्या अभी भी वापस आ जाएगी।

ऐसा लगता है कि हम बहुत बुरी जगह पर हैं यदि कोई भी तरीका जिसे लोग विस्तार विशेषता को परिभाषित करने के लिए पर्याप्त चाहते थे, मानक पुस्तकालय में कभी नहीं जोड़ा जा सकता है।

एक सामान्य विशेषता पर सामान्य विधि नामों का उपयोग करने के संबंध में अधिकतम/मिनट ने विशेष रूप से खराब स्थान मारा। इसे क्लैंप पर लागू करने की आवश्यकता नहीं है।

मैं अभी भी हां कहना चाहता हूं, लेकिन @sfackler क्या हमें वास्तव में एक विशेषता पर विधियों को जोड़ना है जो कि विभिन्न प्रकारों द्वारा सामान्य रूप से कार्यान्वित किया जाता है? हमें सावधान रहना होगा जब हम उन सभी प्रकार के एपीआई में जोड़ रहे हैं जो मौजूदा विशेषता में खरीदे गए हैं।

विशेषज्ञता आने के साथ हम विस्तार विधियों को एक विस्तार विशेषता में डालकर कुछ भी नहीं खोते हैं।

एक कष्टप्रद बात यह है कि यदि नई एसटीडी विधि आपके कोड को तोड़ती है: यह आपके द्वारा वास्तव में इसका उपयोग करने से बहुत पहले दिखाई देगी, क्योंकि यह अस्थिर है। इसके अलावा यह इतना बुरा नहीं है अगर संघर्ष एक ऐसी विधि के साथ है जिसका अर्थ समान है।

मुझे लगता है कि टूटने से बचने के लिए इस समारोह को एक अलग नाम देना एक बुरा समाधान है। हालांकि यह काम करता है, यह इस सुविधा का उपयोग करके किसी भी कोड की भविष्य की पठनीयता के लिए अनुकूलित करने के बजाय कुछ बक्से (जिनमें से सभी रात में चयन कर रहे हैं) को नहीं तोड़ने का अनुकूलन कर रहा है।

मुझे कुछ चिंताएँ हैं जिनमें से कुछ चिंता की बात नहीं हैं।

• नाम और छायांकन आदर्श नहीं है लेकिन यह काम करता है
• संख्यात्मक वैक्टर और मैट्रिसेस के लिए मुझे लगता है कि अधिकतम/मिनट/क्लैंप आदर्श नहीं हैं लेकिन इसे ऑर्ड का उपयोग न करके हल किया जाता है। Ndarray तत्ववार और सामान्य तर्क (स्केलर या सरणी) क्लैम्प करना चाहता है, लेकिन Ord का उपयोग हमारे या इसी तरह के पुस्तकालयों द्वारा नहीं किया जाता है। तो कोई चिंता नहीं।
• मौजूदा यौगिक प्रकार जो संख्यात्मक नहीं हैं: BtreeMap इस परिवर्तन के साथ एक विधि क्लैंप प्राप्त करेगा। क्या यह सामान्य रूप से समझ में आता है? क्या यह डिफ़ॉल्ट के अलावा इसके लिए उचित अर्थ लागू कर सकता है?
• मूल्य द्वारा कॉलिंग मोड प्रत्येक कार्यान्वयन में फिट नहीं होता है। फिर से, BtreeMap. क्या क्लैंप को 3 मानचित्रों का उपभोग करना चाहिए और उनमें से एक को वापस करना चाहिए?

यौगिक प्रकार

मुझे लगता है कि यह BtreeSet<BtreeSet<impl Ord>>::range जितना ही समझ में आता है। लेकिन ऐसे विशेष मामले हैं जो मददगार भी हो सकते हैं, जैसे Vec<char> ।

मूल्य द्वारा कॉलिंग मोड

जब यह आरएफसी में आया, तो जवाब सिर्फ गाय का इस्तेमाल था।

बेशक, भंडारण का पुन: उपयोग करने के लिए यह कुछ ऐसा हो सकता है:

    fn clamp<T>(mut self, low: &T, high: &T) -> Self
        where T: ?Sized + ToOwned<Owned=Self> + Ord, Self : Borrow<T>
    {
        assert!(low <= high);
        if self.borrow() < &low {
            low.clone_into(&mut self);
        } else if self.borrow() >= &high {
            high.clone_into(&mut self);
        }
        self
    }

कौन सा https://github.com/rust-lang/rfcs/pull/2111 कॉल करने के लिए एर्गोनोमिक बना सकता है।

कुछ दिनों पहले ट्राइएज के दौरान लिब्स टीम ने इस पर चर्चा की और निष्कर्ष यह था कि हमें यह देखने के लिए एक क्रेटर रन करना चाहिए कि इस बदलाव के लिए पूरे पारिस्थितिकी तंत्र में क्या दरार है। उसी के परिणाम तय करेंगे कि इस मुद्दे पर क्या कार्रवाई की जानी चाहिए।

भविष्य की कई संभावित भाषा सुविधाएँ हैं जिन्हें हम इस तरह के एपिस को जोड़ने में आसानी के लिए जोड़ सकते हैं जैसे कि निम्न-प्राथमिकता वाले लक्षण या अधिक स्वादिष्ट तरीके से विस्तार लक्षणों का उपयोग करना। हालांकि, हम इस तरह की प्रगति पर इसे अनिवार्य रूप से अवरुद्ध नहीं करना चाहते हैं।

क्या इस सुविधा के लिए कभी क्रेटर रन हुआ?

#48552 के विलय के बाद मेरी योजना clamp() पद्धति को पुनर्जीवित करने की है। हालांकि, इससे पहले RangeInclusive को स्थिर किया जा रहा है, जिसका अर्थ है कि रेंज-आधारित विकल्प अब विचार के लिए व्यवहार्य है (जो वास्तव में मूल प्रस्ताव है, लेकिन वापस ले लिया गया क्योंकि ..= इतना अस्थिर था 😄):

// Current
trait Ord {
    fn clamp(self, min: Self, max: Self) -> Self { ... }
}
assert_eq!(9.clamp(6, 7), 7);


// Alternative
trait Ord {
    fn clamp(self, range: RangeInclusive<Self>) -> Self { ... }
}
assert_eq!(9.clamp(6..=7), 7);

एक स्थिर RangeInclusive अन्य संभावनाओं को भी खोलता है, जैसे चीजों को इधर-उधर करना (जो ऑटोरेफ के साथ कुछ दिलचस्प संभावनाओं को सक्षम करता है, और नाम टकराव से पूरी तरह से बचा जाता है):

impl<T: Ord + Clone> RangeInclusive<T> {
    fn clamp(&self, mut x: T) -> T {
        if x < self.start { x.clone_from(&self.start); }
        else if x > self.end { x.clone_from(&self.end); }
        x
    } 
} 

    assert_eq!((1..=10).clamp(11), 10);

    let strings = String::from("aa")..=String::from("b");
    assert_eq!(strings.clamp(String::from("a")), "aa");
    assert_eq!(strings.clamp(String::from("aaa")), "aaa");

https://play.rust-lang.org/?gist=38def79ba2f3f8380197918377dc66f5&version=nightly

मैंने तय नहीं किया है कि क्या मुझे लगता है कि यह बेहतर है, हालांकि ...

यदि रेंज विधि के रूप में उपयोग किया जाता है तो मैं एक अलग नाम का उपयोग करूंगा।

निश्चित रूप से मैं इस सुविधा को बाद में जल्द से जल्द प्राप्त करने का आनंद लूंगा, कोई फर्क नहीं पड़ता।

वर्तमान स्थिति क्या है?
मुझे ऐसा लगता है कि आम सहमति है, कि रेंज इन्क्लूसिव में क्लैंप जोड़ना एक बेहतर विकल्प हो सकता है।
तो किसी को आरएफसी लिखना है?

इस बिंदु पर शायद एक पूर्ण RFC की आवश्यकता नहीं है। बस एक निर्णय जो वर्तनी का चयन करना है:

1. value.clamp(min, max) (आरएफसी का यथावत पालन करें)
2. value.clamp(min..=max)
3. (min..=max).clamp(value)

विकल्प 2 या 3 आसान आंशिक क्लैंपिंग की अनुमति देगा। तुम कर सकते हो value.clamp(min..) या value.clamp(..=max) , बिना विशेष की जरूरत clamp_to_start या clamp_to_end तरीकों।

@egilburg : हमारे पास पहले से ही वे विशेष विधियां हैं: clamp_to_start max और clamp_to_end min : पलक:

हालांकि संगति अच्छी है।

@egilburg Rust प्रत्यक्ष ओवरलोडिंग का समर्थन नहीं करता है। आपके सुझाव के साथ काम करने के लिए विकल्प 2 के लिए हमें RangeInclusive , RangeToInclusive और RangeFrom लिए लागू की गई एक नई विशेषता की आवश्यकता होगी, जो काफी भारी वजन महसूस करती है।

मुझे लगता है, वह विकल्प 3 सबसे अच्छा विकल्प है।

1 या 2 कम से कम आश्चर्यजनक हैं। मैं 1 के साथ रहूंगा क्योंकि स्थानीय कार्यान्वयन को एसटीडी के साथ बदलने के लिए बहुत सारे कोड कम होंगे।

मुझे लगता है कि हमें या तो _all_ the range* प्रकार या उनमें से _none_ का उपयोग करने की योजना बनानी चाहिए।

बेशक, जैसी चीजों के लिए कठिन है कि Range के लिए की तुलना में RangeInclusive । लेकिन (0.0..1.0).clamp(2.0_f32) => 0.99999994_f32 बारे में कुछ अच्छा है।

@kennytm तो अगर मैं विकल्प 3 के साथ एक पुल अनुरोध
या आप इस बारे में क्या सोचते हैं कि आगे कैसे बढ़ना है?

@EdorianDark इसके लिए हमें @

मुझे व्यक्तिगत रूप से विकल्प 2 पसंद है, केवल RangeInclusive । जैसा कि उल्लेख किया गया है "आंशिक क्लैंपिंग" पहले से ही min और max ।

मैं @SimonSapin से सहमत रहूंगा । विकल्प 3 के साथ, मैं संभवतः फ़ंक्शन का उपयोग नहीं करूंगा क्योंकि यह मुझे पीछे की ओर लगता है। अन्य भाषाओं/पुस्तकालयों में क्लैंप के साथ @kennytm ने पहले सर्वेक्षण किया था , 7 में से 5 (स्विफ्ट और क्यूटी को छोड़कर) में पहले मूल्य है, फिर श्रेणी।

क्लैंप अब फिर से मास्टर में है!

मैं खुश हूं, हालांकि मैं अभी भी यह पता लगाने की कोशिश कर रहा हूं कि ऐसा क्या बदलाव आया जिसने इसे अब स्वीकार्य बना दिया, जबकि यह #44097 में नहीं था।

अब हमें #48552 के कारण एक चेतावनी अवधि मिल गई है, स्थिर होने से पहले ही तुरंत अनुमान को तोड़ने के बजाय।

यह बहुत अच्छी खबर है, धन्यवाद!

@kennytm मैं सिर्फ आपको #48552 बनाने के लिए किए गए @EdorianDark इसमें आपकी रुचि और इसे लागू करने के लिए धन्यवाद। इसे अंत में विलय होते देखना अद्भुत है।

https://rust.godbolt.org/z/JmLWJi

pub fn clamped(a: f32) -> f32 {
   a.clamp(0.,255.)
}

को संकलित करता है:

  vxorps xmm1, xmm1, xmm1
  vmaxss xmm0, xmm1, xmm0
  vmovss xmm1, dword ptr [rip + .LCPI0_0]
  vminss xmm0, xmm1, xmm0

जो बहुत बुरा नहीं है ( vmaxss और vminss का उपयोग किया जाता है), लेकिन:

pub fn maxmined(a: f32) -> f32 {
   (0f32).max(a).min(255.)
}

एक निर्देश कम उपयोग करता है:

  vxorps xmm1, xmm1, xmm1
  vmaxss xmm0, xmm0, xmm1
  vminss xmm0, xmm0, dword ptr [rip + .LCPI1_0]

क्या यह क्लैंप कार्यान्वयन के लिए निहित है, या एलएलवीएम अनुकूलन का सिर्फ एक विचित्रता है?

@kornelski clamp एक NAN को उस NAN को संरक्षित करने के लिए माना जाता है, जो कि maxmined नहीं करता है, क्योंकि max / min _non_- NAN ।

ऐसा कार्यान्वयन खोजना बहुत अच्छा होगा जो दोनों NAN अपेक्षाओं को पूरा करता हो और छोटा हो। और यह डॉक्टरों के लिए अच्छा होगा कि वे NAN से निपटने का प्रदर्शन करें। ऐसा लगता है कि मूल पीआर में कुछ थे:

https://github.com/rust-lang/rust/blob/b762283e57ff71f6763effb9cfc7fc0c7967b6b0/src/libstd/f32.rs#L1089 -L1094

@scottmcm https://github.com/rust-lang/rust/pull/59327 हो गया

यदि न्यूनतम या अधिकतम NaN है तो क्लैम्पिंग से घबराहट क्यों होती है? मैं दावे को assert!(min <= max) से assert!(!(min > max)) में बदल दूंगा, ताकि अधिकतम और न्यूनतम विधियों की तरह ही न्यूनतम या अधिकतम का कोई प्रभाव न पड़े।

क्लैम्प में min या max लिए NAN संभवतः प्रोग्रामिंग त्रुटि का संकेत है, और हमें लगा कि आईओ को अनक्लैंप किए गए डेटा को संभावित रूप से खिलाने के बजाय जल्द से जल्द घबराना बेहतर है। यदि आप ऊपरी या निचली सीमा नहीं चाहते हैं तो यह फ़ंक्शन आपके लिए नहीं है।

यदि आप ऊपरी या निचली सीमा नहीं चाहते हैं तो आप हमेशा INF और -INF का उपयोग कर सकते हैं, है ना? जो NaN के विपरीत गणितीय अर्थ भी रखता है। लेकिन ज्यादातर समय इसके लिए max और min का उपयोग करना बेहतर होता है।

@Xaeroxe कार्यान्वयन के लिए धन्यवाद।

शायद यह अगले संस्करण में जा सकता है, अगर यह स्थिर कोड तोड़ देगा?

एक बात जिस पर IMO अधिक विस्तार से विचार करने योग्य है, वह है f32 / f64 एकतरफा क्लैम्पिंग। ऐसा लगता है कि इस विषय पर चर्चा संक्षेप में हुई है लेकिन वास्तव में इस पर विस्तार से विचार नहीं किया गया है।

ज्यादातर मामलों में, यदि एक तरफा क्लैंप का इनपुट NAN है, तो परिणाम के लिए क्लैम्पिंग सीमा होने की तुलना में NAN होना अधिक उपयोगी है। इसलिए, मौजूदा f32::min और f64::max फ़ंक्शन इस उपयोग के मामले के लिए अच्छी तरह से काम नहीं करते हैं। हमें एक तरफा क्लैंपिंग के लिए अलग फ़ंक्शन की आवश्यकता है। (जंग-संख्या/संख्या-लक्षण#122 देखें।)

मैं इसे क्यों लाता हूं इसका कारण यह है कि यह दो-तरफा clamp के डिजाइन को प्रभावित करता है, क्योंकि दो-तरफा और एक-तरफा क्लैंप के लिए एक सुसंगत इंटरफ़ेस होना अच्छा होगा। कुछ विकल्प हैं:

1. input.clamp(min, max) , input.clamp_min(min) , और input.clamp_max(max)
2. input.clamp(min..=max) , input.clamp(min..) , input.clamp(..=max)
3. input.clamp(min, max) , input.clamp(min, std::f64::INFINITY) , input.clamp(std::f64::NEG_INFINITY, max)

वर्तमान कार्यान्वयन के साथ ( min और max अलग f32 / f64 पैरामीटर के रूप में), हमें विकल्प 1 चुनना होगा, जो मुझे लगता है कि पूरी तरह से उचित है , या विकल्प 3, जो IMO बहुत अधिक क्रियात्मक है। हमें बस इस बात की जानकारी होनी चाहिए कि बलिदान को अलग clamp_min और clamp_max फ़ंक्शन जोड़ने पड़ रहे हैं या उपयोगकर्ता को सकारात्मक/नकारात्मक अनंत लिखने की आवश्यकता है।

यह भी ध्यान देने योग्य है कि हम प्रदान कर सकते हैं

impl f32 {
    pub fn clamp<T>(self, bounds: T) -> f32
    where
        T: RangeBounds<f32>,
    {
         // ...
    }
}

// and for f64

चूंकि f32 / f64 हम वास्तव में जानते हैं कि सामान्य Ord विपरीत, विशेष सीमाओं को कैसे संभालना है। बेशक, तब हम शायद Ord::clamp को बदलना चाहेंगे ताकि निरंतरता के लिए RangeInclusive तर्क लिया जा सके। ऐसा लगता है कि इस बात की प्रबल राय या तो दो तर्क या एक ही पसंद करते हैं, इस पर जिस तरह से नहीं किया गया था RangeInclusive के लिए तर्क Ord::clamp ।

यदि यह पहले से ही एक सुलझा हुआ मुद्दा है, तो कृपया मेरी टिप्पणी को खारिज करने के लिए स्वतंत्र महसूस करें। मैं इन चीजों को सिर्फ इसलिए उठाना चाहता था क्योंकि मैंने उन्हें पहले की चर्चा में नहीं देखा था।

ट्राइएज: नीचे दिए गए एपीआई वर्तमान में अस्थिर हैं और यहां इंगित करते हैं। क्या NaN से निपटने के अलावा अन्य मुद्दों पर विचार करना है? क्या यह Ord::clamp पहले NaN हैंडलिंग पर ब्लॉक किए बिना स्थिर करने लायक है?

```जंग
पब विशेषता क्रम: Eq + PartialOrd{
//…
एफएन क्लैंप (स्वयं, न्यूनतम: स्वयं, अधिकतम: स्वयं) -> स्वयं जहां स्वयं: आकार {...}
}
इम्प्ला f32 {
पब एफएन क्लैंप (स्वयं, न्यूनतम: एफ 32, अधिकतम: एफ 32) -> एफ 32 {...}
}
इम्प्ला f64 {
पब एफएन क्लैंप (स्वयं, न्यूनतम: एफ 64, अधिकतम: एफ 64) -> एफ 64 {...}
}

@SimonSapin मुझे व्यक्तिगत रूप से पूरी चीज़ को स्थिर करने में खुशी होगी

+1, यह एक पूर्ण आरएफसी के माध्यम से चला गया और मुझे नहीं लगता कि तब से कुछ भी सामग्री सामने आई है। उदाहरण के लिए, IRLO और RFC चर्चा में NaN प्रबंधन के बारे में विस्तार से बताया गया ।

ठीक है, यह काफी उचित लगता है।

@rfcbot fcp मर्ज

टीम के सदस्य @SimonSapin ने इसे मर्ज करने का प्रस्ताव दिया है। अगला चरण बाकी टैग की गई टीम के सदस्यों द्वारा समीक्षा है:

• [x] @Amanieu
• [ ] @किमुंडी
• [एक्स] @ साइमन सैपिन
• [एक्स] @ एलेक्सक्रिचटन
• [x] @dtolnay
• [ ] @sfackler
• [ ] @ नावों के बिना

वर्तमान में कोई चिंता सूचीबद्ध नहीं है।

एक बार जब अधिकांश समीक्षक स्वीकृति दे देते हैं (और अधिकतम 2 अनुमोदन बकाया हैं), तो यह अपनी अंतिम टिप्पणी अवधि में प्रवेश करेगा। यदि आपको कोई बड़ा मुद्दा मिलता है जिसे इस प्रक्रिया में किसी भी बिंदु पर नहीं उठाया गया है, तो कृपया बोलें!

टैग की गई टीम के सदस्य मुझे क्या आदेश दे सकते हैं, इस बारे में जानकारी के लिए

क्या x.clamp(7..=13) बनाम x.clamp(7, 13) बारे में कोई निर्णय लिया गया था? https://github.com/rust-lang/rust/issues/44095#issuecomment -533764997 उल्लेख करता है कि संभावित भविष्य के साथ निरंतरता के लिए पहला बेहतर हो सकता है f64::clamp ।

@ एम-कहां-से देखें चर्चा से शुरू https://github.com/rust-lang/rust/issues/44095#issuecomment -+४१,१४,५७,३१३ और भी https://github.com/rust-lang/rust/pull/ 58710#पुलअनुरोधसमीक्षा -207529970.

मैं कहूंगा कि यह काफी दुर्भाग्यपूर्ण समाधान है क्योंकि .min और .max अक्सर बग का कारण बनते हैं क्योंकि आप ऊपरी सीमा को निर्दिष्ट करने के लिए .min(...) का उपयोग करते हैं और .max(...) निर्दिष्ट करने के लिए निम्न परिबंध। यह अविश्वसनीय रूप से भ्रमित करने वाला है और मैंने इसके साथ बहुत सारे बग देखे हैं। .clamp(..1.0) और .clamp(0.0..) बस इतना स्पष्ट हैं।

@CryZe एक बहुत अच्छा बिंदु बनाता है: भले ही आप min = अपर बाउंड, मैक्स = लोअर बाउंड के साथ कभी गलती न करें, फिर भी आपको यह याद रखने के लिए मानसिक जिम्नास्टिक करना होगा कि किसका उपयोग करना है। आप जिस भी समस्या को हल करने का प्रयास कर रहे हैं, उस पर यह संज्ञानात्मक भार बेहतर ढंग से खर्च किया जाएगा।

मुझे पता है कि x.clamp(y, z) अधिक अपेक्षित है, लेकिन शायद यह नया करने का अवसर है;)

मैंने शुरुआती चरणों में रेंज के साथ काफी प्रयोग किए, और यहां तक ​​कि आरएफसी में कई महीनों की देरी भी की ताकि हम समावेशी रेंज के साथ प्रयोग कर सकें। (यह स्थिर होने से पहले शुरू किया गया था)

मैंने पाया कि फ्लोटिंग पॉइंट नंबरों पर एक्सक्लूसिव रेंज के लिए क्लैंप को लागू करना संभव नहीं था। केवल कुछ रेंज प्रकारों का समर्थन करना, लेकिन दूसरों को परिणाम के बारे में बहुत आश्चर्य नहीं हुआ, इसलिए भले ही मैंने आरएफसी को कई महीनों तक प्रयोग करने में देरी की, इस तरह से मैंने अंततः तय किया कि श्रेणियां समाधान नहीं थीं।

@m-ou-se #44095 (टिप्पणी) और #58710 (समीक्षा) से शुरू होने वाली चर्चा देखें।

संपादित करें: जैसा कि नीचे बताया गया है, पुल अनुरोध (#58710) में चर्चा में ट्रैकिंग मुद्दे की तुलना में डिजाइन निर्णय की अधिक चर्चा शामिल है। यह दुर्भाग्यपूर्ण है कि यहां इसका संचार नहीं किया गया था, जहां आमतौर पर डिजाइन चर्चाएं होती हैं, लेकिन इस पर चर्चा की गई थी।

केवल कुछ श्रेणी प्रकारों का समर्थन करना, लेकिन दूसरों को नहीं, एक परिणाम के बारे में बहुत आश्चर्यजनक था

जंग पहले से ही कुछ श्रेणियों को दूसरों की तुलना में अलग तरीके से मानता है (उदाहरण के लिए उन्हें पुनरावृत्ति के लिए उपयोग करना), इसलिए केवल कुछ श्रेणियों को clamp तर्क के रूप में अनुमति देना मेरे लिए बिल्कुल आश्चर्यजनक नहीं लगता है।

इसका सबसे उपयोगी विश्लेषण यहां दिया गया है: https://github.com/rust-lang/rfcs/pull/1961#issuecomment -302600351

@Xaeroxe केवल कुछ श्रेणी प्रकारों का समर्थन करता है, लेकिन दूसरों को परिणाम के बारे में बहुत आश्चर्य नहीं होता है

यदि आप उनके स्थिर होने से पहले इस बारे में सोच रहे थे, क्या समय और सामान्य उपयोग ने आपकी राय बदल दी है, या क्या आपको लगता है कि अभी भी ऐसा ही है?

मैं तर्क दूंगा कि अनन्य श्रेणियों को कभी भी फ्लोट के लिए लागू नहीं किया जाना चाहिए, क्योंकि उनके पास पूर्णांक के लिए अलग व्यवहार होगा (रेंज 0..10 में निचली बाउंड शामिल है और ऊपरी बाउंड को शामिल नहीं किया गया है, तो काल्पनिक सीमा 0.0...10.0 क्यों होनी चाहिए

@varkor लेकिन फिर इसे समीक्षा में एक टिप्पणी के बाद, ट्रैकिंग मुद्दे पर बिना किसी चर्चा के बदल दिया गया।

यह अत्यधिक टकराव के रूप में सामने आ सकता है, कुछ ऐसा प्रयास करें "जब मैंने बातचीत को देखा तो मुझे कोई ठोस तर्क नहीं मिला कि हमें श्रेणियों का उपयोग क्यों नहीं करना चाहिए, क्या कोई मुझे इसकी ओर इशारा कर सकता है?"।

मुझे संदेह है कि आप जिस तर्क की तलाश कर रहे हैं वह यहाँ है: https://github.com/rust-lang/rfcs/pull/1961#issuecomment -302600351

संपादित करें @Xaeroxe ने मुझे इसे हरा दिया :)

समय और सामान्य उपयोग ने आपकी राय बदल दी है

इस प्रकार अब तक ऐसा नहीं हुआ है, लेकिन श्रेणियां कुछ ऐसी हैं जिनका मैं अपने दैनिक कोडिंग में बहुत कम उपयोग करता हूं। मैं आंशिक श्रेणी समर्थन के साथ कोड उदाहरणों और मौजूदा एपीआई द्वारा राजी होने के लिए तैयार हूं। हालांकि, भले ही हम उस प्रश्न को हल कर लें, फिर भी कई अन्य उत्कृष्ट बिंदु हैं जिन्हें scottmcm RFC टिप्पणी में लाता है जिसे संबोधित करने की आवश्यकता है। उदाहरण के लिए, Step जितने प्रकार के Ord पर लागू नहीं किया गया है, क्या यह मामूली वाक्यात्मक परिवर्तन उन प्रकारों को खोने के लायक है? इसके अलावा, क्या गैर-समावेशी रेंज क्लैंप के लिए उपयोग का मामला है? जहां तक ​​मैं बता सकता हूं, किसी अन्य भाषा या ढांचे को अनन्य रेंज क्लैंप का समर्थन करने की आवश्यकता महसूस नहीं हुई, तो इससे हमें क्या लाभ होता है? एक संतोषजनक तरीके से लागू करने के लिए रेंज बहुत अधिक कठिन थे, और कई डाउनसाइड्स और कुछ लाभों के साथ आए।

अगर मैं इसे श्रेणियों का उपयोग करके कार्यान्वित यह ऐसा दिखाई देगा।

तो कुछ कारण हैं जो मुझे लगता है कि हमें इस दृष्टिकोण के साथ नहीं जाना चाहिए।

1. आवश्यक श्रेणियों का चयन एक नई विशेषता की आवश्यकता के लिए पर्याप्त उपन्यास है, और विशेष रूप से सबसे सामान्य श्रेणी, Range ।

2. हम पहले से ही आरएफसी प्रक्रिया में बहुत आगे हैं और इससे केवल एक चीज एसटीडी हासिल होती है जो .max() या .min() लिखने का एक और तरीका है। मैं वास्तव में प्रक्रिया की शुरुआत में आरएफसी को वापस सेट नहीं करना चाहता ताकि कुछ ऐसा लागू किया जा सके जो हम पहले से ही जंग में कर सकते हैं।

3. यह एक उपयोग के मामले को समायोजित करने के लिए फ़ंक्शन में होने वाली ब्रांचिंग की मात्रा को दोगुना कर देता है जिसे हम अभी भी सुनिश्चित नहीं कर रहे हैं। मैं इसे बेंचमार्क में दिखाने के लिए नहीं मिल सकता।

एक तरफा क्लैंपिंग संचालन की आवश्यकता

... इससे केवल एक ही चीज एसटीडी हासिल होती है, वह है .max() या .min() लिखने का एक और तरीका।

प्राथमिक बिंदु जो मैं बनाने की कोशिश कर रहा था वह यह है कि मैंने .min() / .max() बीच यह स्पष्ट समानता देखी है और एक तरफा क्लैंप चर्चा में कई बार आते हैं, लेकिन संचालन समकक्ष नहीं हैं फ्लोटिंग पॉइंट नंबरों के लिए जिस तरह से उन्हें संभालना चाहिए NAN ।

उदाहरण के लिए, input.max(0.) को ऋणात्मक संख्याओं को शून्य पर बंद करने के लिए एक व्यंजक के रूप में देखें। यदि input गैर- NAN , तो यह ठीक काम करता है। हालांकि, जब input है NAN , तो इसका मूल्यांकन 0. । यह लगभग कभी वांछित व्यवहार नहीं है; एक तरफा क्लैम्पिंग को NAN मानों को संरक्षित रखना चाहिए। ( यह टिप्पणी और यह टिप्पणी देखें।) अंत में, .max() दो संख्याओं में से बड़ी संख्या लेने के लिए अच्छी तरह से काम करता है, लेकिन यह एक तरफा क्लैंपिंग के लिए अच्छा काम नहीं करता है।

इसलिए, हमें फ्लोटिंग-पॉइंट नंबरों के लिए एकतरफा क्लैम्पिंग ऑपरेशन ( .min() / .max() ) की आवश्यकता है। अन्य लोगों ने गैर-अस्थायी-बिंदु प्रकारों के लिए भी एकतरफा क्लैम्पिंग संचालन की उपयोगिता के लिए अच्छे तर्क दिए। अगला प्रश्न यह है कि हम उन संक्रियाओं को कैसे व्यक्त करना चाहते हैं।

एक तरफा क्लैम्पिंग ऑपरेशंस को कैसे व्यक्त करें

.clamp() साथ INFINITY

दूसरे शब्दों में, एकतरफा क्लैम्पिंग ऑपरेशन न जोड़ें; बस उपयोगकर्ताओं को .clamp() का उपयोग INFINITY या NEG_INFINITY सीमा के साथ करने के लिए कहें। उदाहरण के लिए, उपयोगकर्ताओं को input.clamp(0., std::f64::INFINITY) लिखने के लिए कहें।

यह बहुत ही क्रियात्मक है, जो उपयोगकर्ताओं को गलत .min() / .max() का उपयोग करने के लिए प्रेरित करेगा यदि वे NAN हैंडलिंग की बारीकियों से अवगत नहीं हैं। इसके अतिरिक्त, यह T: Ord लिए मदद नहीं करता है, और IMO यह विकल्पों की तुलना में कम स्पष्ट है।

.clamp_min() और .clamp_max()

एक उचित विकल्प .clamp_min() और .clamp_max() विधियों को जोड़ना है, जिसके लिए वर्तमान में प्रस्तावित कार्यान्वयन में किसी भी बदलाव की आवश्यकता नहीं होगी। मुझे लगता है कि यह एक उचित दृष्टिकोण है; मैं केवल यह सुनिश्चित करना चाहता था कि हम जानते थे कि यदि हम वर्तमान में प्रस्तावित clamp कार्यान्वयन को स्थिर करते हैं तो हमें इस दृष्टिकोण का उपयोग करना होगा।

रेंज तर्क

एक अन्य विकल्प है clamp एक श्रेणी तर्क लें। @Xaeroxe ने इसे लागू करने का एक तरीका दिखाया है, लेकिन जैसा कि उन्होंने उल्लेख किया है, उस कार्यान्वयन के कुछ नुकसान हैं। कार्यान्वयन लिखने का एक वैकल्पिक तरीका वर्तमान में स्लाइसिंग को लागू करने के तरीके के समान है ( SliceIndex विशेषता)। यह उन सभी आपत्तियों को हल करता है जो मैंने चर्चा में देखी हैं, सिवाय श्रेणी प्रकारों के सबसेट और अतिरिक्त जटिलता के लिए कार्यान्वयन प्रदान करने की चिंता को छोड़कर। मैं मानता हूं कि यह कुछ जटिलता जोड़ता है, लेकिन आईएमओ .clamp_min() / .clamp_max() जोड़ने से कहीं ज्यादा खराब नहीं है। Ord , मैं कुछ इस तरह का सुझाव दूंगा:

pub trait Ord: Eq + PartialOrd<Self> {
    // ...

    fn clamp<B>(self, bounds: B) -> B::Output
    where
        B: Clamp<Self>,
    {
        bounds.clamp(self)
    }
}

pub trait Clamp<T> {
    type Output;
    fn clamp(self, input: T) -> Self::Output;
}

impl<T> Clamp<T> for RangeFull {
    type Output = T;
    fn clamp(self, input: T) -> T {
        input
    }
}

impl<T: Ord> Clamp<T> for RangeFrom<T> {
    type Output = T;
    fn clamp(self, input: T) -> T {
        if input < self.start {
            self.start
        } else {
            input
        }
    }
}

impl<T: Ord> Clamp<T> for RangeToInclusive<T> {
    type Output = T;
    fn clamp(self, input: T) -> T {
        if input > self.end {
            self.end
        } else {
            input
        }
    }
}

impl<T: Ord> Clamp<T> for RangeInclusive<T> {
    type Output = T;
    fn clamp(self, input: T) -> T {
        assert!(self.start <= self.end);
        let mut x = input;
        if x < self.start { x = self.start; }
        if x > self.end { x = self.end; }
        x
    }
}

इस पर कुछ विचार:

• हम विशिष्ट श्रेणियों के लिए कार्यान्वयन जोड़ सकते हैं जहां T: Ord + Step ।
• हम रख सकता है Clamp विशेषता रात-केवल, के समान SliceIndex विशेषता।

• f32 / f64 , हम कर सकते थे

  1. कार्यान्वयन को T: PartialOrd । (मुझे यकीन नहीं है कि clamp का वर्तमान कार्यान्वयन Ord बजाय PartialOrd । शायद मुझे चर्चा में कुछ याद आया? ऐसा लगता है कि PartialOrd पर्याप्त होगा।)

  2. या विशेष रूप से f32 और f64 लिए कार्यान्वयन लिखें। (यदि वांछित है, तो हम बाद में बिना किसी बदलाव के विकल्प i पर स्विच कर सकते हैं।)

  और फिर जोड़ें

  impl f32 {
    // ...
    fn clamp<B>(self, bounds: B) -> B::Output
    where
        B: Clamp<Self>,
    {
        bounds.clamp(self)
    }
  }
  
  impl f64 {
    // ...
    fn clamp<B>(self, bounds: B) -> B::Output
    where
        B: Clamp<Self>,
    {
        bounds.clamp(self)
    }
  }
  

• हम चाहें तो बाद में Clamp को f32 / f64 साथ विशेष श्रेणियों के लिए लागू कर सकते हैं। ( @scottmcm ने टिप्पणी की कि यह सीधा नहीं है क्योंकि std जानबूझकर f32 / f64 पूर्ववर्ती संचालन नहीं करता है। मुझे यकीन नहीं है कि std उन ऑपरेशनों में नहीं है; हो सकता है कि असामान्य संख्या के साथ समस्या हो? भले ही, इसे बाद में संबोधित किया जा सके।)

  यहां तक ​​कि अगर हम Clamp कार्यान्वयन को f32 / f64 साथ विशेष श्रेणियों के लिए नहीं जोड़ते हैं, तो भी मैं असहमत हूं कि यह बहुत आश्चर्यजनक होगा। जैसा कि @varkor बताते हैं, रस्ट पहले से ही Copy और Iterator / IntoIterator के उद्देश्य से विभिन्न रेंज प्रकारों को अलग तरह से व्यवहार करता है। (आईएमओ, यह std का एक मस्सा है, लेकिन यह कम से कम एक उदाहरण है जहां श्रेणी प्रकारों को अलग तरह से व्यवहार किया जाता है।) इसके अलावा, अगर किसी ने एक विशेष श्रेणी का उपयोग करने का प्रयास किया है, तो त्रुटि संदेश को समझना आसान होगा ( "विशेषता बाध्य std::ops::Range<f32>: Clamp<f32> संतुष्ट नहीं है")।

• मैंने भविष्य में और अधिक कार्यान्वयन जोड़ने के लिए अधिकतम लचीलेपन के लिए Output एक संबद्ध प्रकार बनाया है, लेकिन यह कड़ाई से आवश्यक नहीं है।

मूल रूप से, यह दृष्टिकोण हमें उतना ही लचीलापन देता है जितना हम विशेषता सीमाओं के संबंध में चाहते हैं। यह Clamp कार्यान्वयन के न्यूनतम उपयोगी सेट के साथ शुरू करना भी संभव बनाता है, और बाद में परिवर्तनों को तोड़े बिना अधिक कार्यान्वयन जोड़ना संभव बनाता है।

विकल्पों की तुलना

जैसा कि ऊपर बताया गया है, " .clamp() साथ INFINITY " दृष्टिकोण के काफी नुकसान हैं।

"मौजूदा .clamp " + .clamp_min() + .clamp_max() दृष्टिकोण के निम्नलिखित नुकसान हैं:

• यह अधिक क्रियात्मक है, उदाहरण के लिए input.clamp_min(0) बजाय input.clamp(0..) ।
• यह विशेष श्रेणियों का समर्थन नहीं करता है।
• हम भविष्य में .clamp() और कार्यान्वयन नहीं जोड़ सकते हैं (और विधियों को जोड़े बिना)। उदाहरण के लिए, हम u32 मान को u8 सीमा के साथ क्लैम्पिंग का समर्थन नहीं कर सकते, जो कि RFC चर्चा से अनुरोधित विशेषता है । उस विशेष उदाहरण को .saturating_into() फ़ंक्शन के साथ बेहतर ढंग से संभाला जा सकता है, लेकिन ऐसे अन्य उदाहरण भी हो सकते हैं जहां अधिक क्लैंपिंग कार्यान्वयन उपयोगी होंगे।
• एक तरफा क्लैंपिंग के लिए .min() , .max() , .clamp_min() , और .clamp_max() के बीच कोई भ्रमित हो सकता है। ( .clamp_min() साथ क्लैंपिंग .max() का उपयोग करने के समान है, और .clamp_max() साथ क्लैंपिंग .min() का उपयोग करने के समान है।) हम ज्यादातर नाम देकर इस मुद्दे से बच सकते हैं एक तरफा क्लैम्पिंग ऑपरेशन .clamp_lower() / .clamp_upper() या .clamp_to_start() / .clamp_to_end() बजाय .clamp_min() / .clamp_max() , हालांकि यह और भी अधिक क्रिया ( input.clamp_lower(0) बनाम input.clamp(0..) )।

रेंज तर्क दृष्टिकोण के निम्नलिखित नुकसान हैं:

• कार्यान्वयन .clamp_min() / .clamp_max() जोड़ने की तुलना में अधिक जटिल है।
• यदि हम विशिष्ट श्रेणी प्रकारों के लिए Clamp को लागू नहीं करने या न करने का निर्णय लेते हैं, तो यह आश्चर्यजनक हो सकता है।

रेंज तर्क दृष्टिकोण बनाम "मौजूदा .clamp " + .clamp_min() + .clamp_max() दृष्टिकोण पर मेरी कोई मजबूत राय नहीं है। यह एक सौदेबाजी है।

@Xaeroxe यह उपयोग के मामले को समायोजित करने के लिए फ़ंक्शन में होने वाली ब्रांचिंग की मात्रा को दोगुना कर देता है, हम अभी भी निश्चित नहीं हैं। मैं इसे बेंचमार्क में दिखाने के लिए नहीं मिल सकता।

हो सकता है कि अतिरिक्त शाखा को एलएलवीएम द्वारा अनुकूलित किया जाएगा?

एक तरफा क्लैंपिंग पर

क्योंकि क्लैम्पिंग दोनों पक्षों में समावेशी है, कोई केवल एक-तरफा क्लैम्पिंग व्यवहार प्राप्त करने के लिए बाएं/दाएं पर न्यूनतम/अधिकतम निर्दिष्ट कर सकता है। मुझे लगता है कि यह पूरी तरह से स्वीकार्य है, और यकीनन .clamp((Bound::Unbounded, Inclusive(3.2))) जहां कोई Range* प्रकार नहीं है जो वैसे भी फिट बैठता है:

x.clamp(i32::MIN, 10);
x.clamp(-f32::INFINITY, 10.0);

कोई पूर्ण हानि नहीं है, क्योंकि एलएलवीएम मृत पक्ष को दूर करने में मामूली रूप से सक्षम है: https://rust.godbolt.org/z/l_uBLO

रेंज सिंटैक्स अच्छा होगा, लेकिन clamp इतना बुनियादी है कि दो अलग-अलग तर्क ठीक और समझने में आसान हैं।

हो सकता है कि min / max NaN हैंडलिंग स्वयं ही तय की जा सकती है, उदाहरण के लिए f32 के अंतर्निहित तरीकों के कार्यान्वयन को बदलकर? या PartialOrd::min/max ? (एक संस्करण ध्वज के साथ, यह मानते हुए कि रस्ट libstd में चीजों को टॉगल करने का एक तरीका खोजने का प्रबंधन करता है)।

@scottmcm तुम बाहर की जाँच करनी चाहिए RangeToInclusive ।

इस पर और विचार करने के बाद मेरे साथ ऐसा हुआ है कि स्थिर हमेशा के लिए है, इसलिए हमें "आरएफसी प्रक्रिया को रीसेट करना" को बदलाव न करने का कारण नहीं मानना ​​​​चाहिए।

इसके लिए, मैं इसे लागू करते समय अपनी मानसिकता पर वापस जाना चाहता हूं। क्लैंप अवधारणात्मक रूप से एक सीमा पर संचालित होता है, इसलिए यह शब्दावली का उपयोग करने के लिए समझ में आता है कि रस्ट पहले से ही श्रेणियों को व्यक्त करने के लिए मौजूद है। वह मेरे घुटने के झटके की प्रतिक्रिया थी, और यह कई अन्य लोगों की प्रतिक्रिया प्रतीत होती है। तो आइए इस तरह से ऐसा न करने के तर्कों को फिर से दोहराएँ, और देखें कि क्या हम उनका खंडन कर सकते हैं।

• आवश्यक श्रेणियों का चयन एक नई विशेषता की आवश्यकता के लिए पर्याप्त उपन्यास है, और विशेष रूप से सबसे सामान्य श्रेणी, Range ।

  • @jturner314 द्वारा प्रदान किए गए नए कार्यान्वयन का उपयोग करके अब हमारे पास विशिष्ट श्रेणियों के लिए मूल्यों को सही ढंग से वापस करने के लिए विशिष्ट Range* प्रकारों पर अधिक सीमाएं जोड़ने की क्षमता है, जैसे Ord + Step । इसलिए, भले ही एक्सक्लूसिव रेंज क्लैम्प की अक्सर वास्तव में आवश्यकता नहीं होती है, हम वास्तव में रेंज की पूरी रेंज को यहां स्वीकार कर सकते हैं, बिना उन रेंज के इंटरफेस से समझौता किए, जिनमें ये तकनीकी सीमाएं नहीं हैं।

• हम केवल एक तरफा क्लैंपिंग के लिए इन्फिनिटी/न्यूनतम/अधिकतम का उपयोग कर सकते हैं।

  • यह सच है, और मेरी राय में यह परिवर्तन वास्तव में एक मजबूत जनादेश क्यों नहीं है, इसका एक बड़ा हिस्सा है। मुझे वास्तव में इसका केवल एक ही उत्तर मिला है, और वह यह है कि Range* सिंटैक्स में इस उपयोग के मामले के लिए कम वर्ण और कम आयात शामिल हैं।

अब जबकि हमने ऐसा न करने के कारणों का खंडन किया है, इस टिप्पणी में परिवर्तन करने के लिए किसी प्रकार की प्रेरणा का अभाव है, क्योंकि विकल्प समान दिखाई देते हैं। आइए परिवर्तन करने के लिए कुछ प्रेरणा खोजें। मेरे पास केवल एक कारण है, जो यह है कि इस धागे में आम राय यह है कि सीमा आधारित दृष्टिकोण भाषा के अर्थशास्त्र में सुधार करता है। न केवल समावेशी डबल एंडेड रेंज क्लैंप के लिए, बल्कि .min() और .max() जैसे कार्यों के लिए भी।

मैं उत्सुक हूं कि क्या इस विचार रेखा का अन्य लोगों के साथ कोई कर्षण है जो आरएफसी को स्थिर करने के पक्ष में हैं।

मुझे लगता है कि क्लैम्प को मौजूदा स्वरूप में ही छोड़ देना बेहतर होगा, क्योंकि यह अब अन्य भाषाओं से काफी मिलता-जुलता है।
जब मैंने अपने पुल अनुरोध #58710 पर काम किया तो मैंने रेंज आधारित कार्यान्वयन का उपयोग करने की कोशिश की।
लेकिन rust-lang/rfcs#1961 (टिप्पणी) ) ने मुझे आश्वस्त किया, कि यह मानक रूप में बेहतर है।

मुझे लगता है कि फ़ंक्शन पर #[must_use] विशेषता होना तर्कसंगत होगा, ताकि उन लोगों को भ्रमित न किया जा सके जो रस्ट न्यूमेरिक्स के काम करने के अभ्यस्त नहीं हैं। कहने का तात्पर्य यह है कि, मैं आसानी से किसी को निम्नलिखित (गलत) कोड लिखते हुए देख सकता था:

let mut x: f64 = some_number_source();
x.clamp(0.0, 1.0);
//Proceeds to assume that 0.0 <= x <= 1.0

सामान्य तौर पर, रस्ट अंकों के लिए (number).method() दृष्टिकोण लेता है (जबकि अन्य भाषाएं Math.Method(number) ), लेकिन इसे ध्यान में रखते हुए भी, यह एक तार्किक धारणा होगी कि यह number को संशोधित कर सकता है।

[must_use] विशेषता हाल ही में जोड़ी
@ ज़ेरॉक्स क्या आप रेंज आधारित क्लैंप के लिए कुछ लेकर आए हैं?
मुझे लगता है कि फ़ंक्शन जैसा कि अभी है, जंग के अन्य संख्यात्मक कार्यों के लिए सबसे उपयुक्त होगा और इसे फिर से स्थिर करना शुरू करना चाहेंगे।

इस समय मुझे रेंज आधारित क्लैंप के साथ जाने का कोई कारण नहीं दिख रहा है। हां, आइए 'मस्ट_यूज' विशेषता जोड़ें और स्थिरीकरण की दिशा में काम करें।

@SimonSapin @scottmcm क्या हम स्थिरीकरण प्रक्रिया को पुनः आरंभ कर सकते हैं?

जैसा कि @ jturner314 ने कहा, ऑर्ड के बजाय पार्टियलऑर्ड पर क्लैंप होना बहुत अच्छा होगा, इसलिए इसे फ्लोट्स पर भी इस्तेमाल किया जा सकता है।

हमारे पास पहले से ही इस मुद्दे में विशेष f32::clamp और f64::clamp है।

मैं यही करने की कोशिश कर रहा हूं:

use num_traits::float::FloatCore;

struct Foo<T> (T);

impl<T: FloatCore> Foo<T> {
    fn foo(&self) -> T {
        self.0.clamp(1, 10)
    }
}

fn main() {
    let foo = Foo(15.3);
    println!("{}", foo.foo())
}

खेल के मैदान से लिंक करें।

PartialOrd एक फ्लोट-ओनली विशेषता नहीं है। फ्लोट-विशिष्ट विधि होने से कस्टम PartialOrd प्रकारों के लिए क्लैंप उपलब्ध नहीं होता है।

वर्तमान कार्यान्वयन के लिए Eq , भले ही वह इसका उपयोग न करे।

PartialOrd साथ प्रमुख चिंता यह थी कि यह कमजोर गारंटी प्रदान करता है, जो बदले में क्लैंप की गारंटी को कमजोर करता है। उपयोगकर्ता चाहते हैं कि यह PartialOrd हो, मेरे द्वारा लिखे गए किसी अन्य फ़ंक्शन में रुचि हो सकती है https://docs.rs/num/0.2.1/num/fn.clamp.html

ये गारंटी क्या हैं?

एक काफी स्वाभाविक अपेक्षा यह है कि यदि x.clamp(a, b) == x तो a <= x && x <= b । इसकी गारंटी नहीं है PartialCmp जहां x या तो a या b साथ अतुलनीय हो सकता है।

अस्पष्ट रूप से याद किए गए clamp() तलाश में आज यहां आया और रुचि के साथ चर्चा को पढ़ा।

मैं मनमाने ढंग से श्रेणियों की अनुमति देने और कई नामित कार्यों के बीच एक समझौते के रूप में "विकल्प चाल" का उपयोग करने का सुझाव दूंगा। मुझे पता है कि यह कुछ के साथ लोकप्रिय नहीं है, लेकिन ऐसा लगता है कि वांछित अर्थशास्त्र को यहां अच्छी तरह से पकड़ना है:

#![allow(unstable_name_collisions)]

pub trait Clamp: Sized {
    fn clamp<L, U>(self, lower: L, upper: U) -> Self
    where
        L: Into<Option<Self>>,
        U: Into<Option<Self>>;
}

impl Clamp for f32 {
    fn clamp<L, U>(self, lower: L, upper: U) -> Self
    where
        L: Into<Option<Self>>,
        U: Into<Option<Self>>,
    {
        let below = match lower.into() {
            None => self,
            Some(lower) => self.max(lower),
        };
        match upper.into() {
            None => below,
            Some(upper) => below.min(upper),
        }
    }
}

#[test]
fn test_clamp() {
    assert_eq!(1.0, f32::clamp(2.0, -1.0, 1.0));
    assert_eq!(-1.0, f32::clamp(-2.0, -1.0, 1.0));
    assert_eq!(1.0, f32::clamp(2.0, None, 1.0));
    assert_eq!(-1.0, f32::clamp(-2.0, -1.0, None));
    assert_eq!(2.0, f32::clamp(2.0, -1.0, None));
    assert_eq!(-2.0, f32::clamp(-2.0, None, 1.0));
}

यदि यह में शामिल थे std एक कंबल कार्यान्वयन के लिए भी शामिल किया जा सकता T: Ord , जो चिंताओं के बारे में एक सामान्य उठाया कवर करेगा PartialOrd कार्यान्वयन।

यह देखते हुए कि उपयोगकर्ता कोड में clamp() फ़ंक्शन को परिभाषित करना वर्तमान में डिफ़ॉल्ट रूप से अस्थिर नाम टकराव के बारे में एक कंपाइलर चेतावनी उत्पन्न करता है, मुझे लगता है कि इस फ़ंक्शन के लिए "क्लैंप" नाम ठीक है।

मुझे लगता है, कि clamp(a,b,c) को वैसा ही व्यवहार करना चाहिए जैसा min(max(a,b), c) ।
चूंकि max और min को PartialOrd लिए लागू नहीं किया गया है और न ही clamp लिए लागू किया जाना चाहिए।
NaN मुद्दे पर पहले ही चर्चा हो चुकी

@EdorianDark मैं सहमत हूँ। न्यूनतम, अधिकतम को भी केवल पार्टियलऑर्ड की आवश्यकता होनी चाहिए।

@noonien min और max को Rust 1.0 से परिभाषित किया गया है और उन्हें Ord और f32 और f64 परिभाषा है।
इन समारोहों पर चर्चा करने के लिए यह सही जगह नहीं है।
यहां हम केवल इस बात का ध्यान रख सकते हैं कि min , max और clamp तुलनीय व्यवहार करें और आश्चर्यजनक रूप से नहीं।
संपादित करें: मुझे PartialOrd साथ स्थिति पसंद नहीं है और इसके बजाय float लागू करना होगा Ord , लेकिन 1.0 के बाद अब इसे बदलना संभव नहीं है।

यह अब लगभग डेढ़ साल से विलय और अस्थिर है। हम इसे स्थिर करने के बारे में कैसा महसूस करते हैं?

मुझे इसे स्थिर करना अच्छा लगेगा!

यदि clamp विधि नाम संघर्ष एक समस्या की तरह लगता है, तो मैंने https://github.com/rust-lang/rust/pull/66852#issuecomment -561667812 में एक बिंदु पर नाम समाधान बदलने का सुझाव दिया, और इससे मदद मिलेगी इसके साथ भी।

@Xaeroxe मुझे लगता है कि प्रक्रिया स्थिरीकरण पीआर जमा करना है और उस पर libs टीम की सहमति मांगना है। ऐसा लगता है कि t-libs अतिभारित है और गैर-fcped चीज़ों के साथ तालमेल नहीं रख सकता है।

ठीक है, क्या ऐसा किया https://github.com/rust-lang/rust/pull/77872

@matklad वास्तव में एक FCP प्रस्ताव पिछले साल https://github.com/rust-lang/rust/issues/44095#issuecomment -544393395 पर पहले ही शुरू हो चुका है, लेकिन यह अटका हुआ है क्योंकि एक शेष चेकबॉक्स है।

उस मामले में, मुझे लगता है कि किसी मुद्दे पर साल में एक बार पिंग किया जाना काफी सहनीय है।

@किमुंडी
@sfackler
@ नावों के बिना

https://github.com/rust-lang/rust/issues/44095#issuecomment -544393395 अभी भी आपके ध्यान की प्रतीक्षा कर रहा है

जब से FCP शुरू हुआ था तब से libs टीम काफी बदल गई है। क्या तुम सब बस एक नया शुरू करने के बारे में सोचते हैं FCP स्थिरीकरण पीआर में? ऐसा लगता है कि यहां शेष चेकबॉक्स की प्रतीक्षा करने में अधिक समय नहीं लगना चाहिए।

@LukasKalbertodt मेरे द्वारा ठीक है, क्या आपको इसे लात मारने का मन है?

यहाँ FCP रद्द करना, क्योंकि वह FCP अब स्थिरीकरण PR पर हुआ: https://github.com/rust-lang/rust/pull/77872#issuecomment -722982535

@fcpbot रद्द करें

उह

@rfcbot रद्द करें

@m-ou-se प्रस्ताव रद्द कर दिया गया।