अलगाववाद बचाव की मुद्रा में है

"Isomorphism" आधुनिक गणित की मूल अवधारणाओं में से एक है। हास्केल और सी # में ठोस उदाहरणों का उपयोग करते हुए, मैं न केवल गणितज्ञों (किसी अस्पष्ट गणितीय प्रतीकों और शर्तों का उपयोग किए बिना) के लिए सिद्धांत की व्याख्या नहीं करूंगा, लेकिन मैं यह भी दिखाऊंगा कि इसे रोजमर्रा के अभ्यास में कैसे इस्तेमाल किया जा सकता है।

समस्या यह है कि सख्त समानता (उदाहरण के लिए, 2 + 2 = 4) अक्सर बहुत सख्त होती है। यहाँ एक उदाहरण है:

add :: (a, a) -> a add (x, y) = x + y 

 int Add(Tuple<int, int> pair) { return pair.Item1 + pair.Item2; } 

हालांकि, एक और है - ट्रिकियर और कई स्थितियों में एक ही कार्य को एक अर्थ में परिभाषित करने का अधिक व्यावहारिक तरीका है :

 add' :: a -> a -> a add' x = \y -> x + y 

 Func<int, int> Add_(int x) { return y => x + y; } 

स्पष्ट तथ्य के विपरीत कि किसी भी दो एक्स के लिए, वाई दोनों फ़ंक्शन हमेशा एक ही परिणाम देंगे, वे सख्त समानता को संतुष्ट नहीं करते हैं:

• पहला फ़ंक्शन तुरंत राशि लौटाता है (यानी, निर्यात के समय गणना करता है),
• जबकि दूसरा फ़ंक्शन एक और फ़ंक्शन लौटाता है (जो अंत में राशि लौटाएगा - अगर कोई इसे कॉल करता है, तो निश्चित रूप से, अन्यथा कोई गणना नहीं की जाएगी: यह विलंबित गणना का एक उदाहरण है और यहां एक आइसोमॉर्फिज़्म भी है, जिसे मैं वापस करूंगा थोड़ी देर बाद)।

और यह "बहुत सख्त हो रहा है।"

समरूपतावाद "काफी सख्त" है; इसके लिए पूर्ण, सभी तरह की समानता की आवश्यकता नहीं है, लेकिन यह "एक निश्चित अर्थ में" समानता तक सीमित है, जो हमेशा एक विशिष्ट संदर्भ द्वारा निर्धारित होता है।

जैसा कि आप अनुमान लगा सकते हैं, ऊपर की दोनों परिभाषाएँ आइसोमॉर्फिक हैं। इसका मतलब ठीक-ठीक निम्नलिखित है: यदि उनमें से केवल एक ही मुझे दिया जाता है, तो दोनों मुझे स्पष्ट रूप से दिए जाते हैं: सभी समरूपता के लिए धन्यवाद - एक में दूसरे का दो-तरफ़ा कनवर्टर । थोड़ा सा प्रकार संक्षेप:

 curry :: ((a, b) → c) → a → b → c curry fxy = f (x, y), uncurry :: (a → b → c) → (a, b) → c uncurry f (x, y) = fxy 

 Func<TArg1, Func<TArg2, TRes>> Curry(Func<Tuple<TArg1, TArg2>, TRes> uncurried) { return arg1 => arg2 => uncurried(Tuple.Create(arg1, arg2)); } Func<Tuple<TArg1, TArg2>, TRes> Uncurry(Func<TArg1, Func<TArg2, TRes>> curried) { return pair => curried(pair.Item1)(pair.Item2); } 

... और अब किसी भी x, y के लिए :

 curry add $ x, y = uncurry add' $ (x, y) 

 Curry(Add)(x)(y) = Uncurry(Add_)(Tuple.Create(x, y)) 

 curry . uncurry = id uncurry . curry = id id x = x 

 Compose(Curry, Uncurry) = Id Compose(Uncurry, Curry) = Id, : T Id<T>(T arg) => arg; Func<TArg, TFinalRes> Compose<TArg, TRes, TFinalRes>( Func<TArg, TRes> first, Func<TRes, TFinalRes> second) { return arg => second(first(arg)); } ...  extension- (  Id   ): Curry.Compose(Uncurry) = Id Uncurry.Compose(Curry) = Id, : public static Func<TArg, TFinalRes> Compose<TArg, TRes, TFinalRes>( this Func<TArg, TRes> first, Func<TRes, TFinalRes> second) { return arg => second(first(arg)); } 

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

 toLazy :: a -> () -> a toLazy x = \_ -> a fromLazy :: (() -> a) -> a fromLazy f = f () 

 Func<TRes> Lazy(TRes res) { return () => res; } TRes Lazy(Func<TRes> lazy) { return lazy(); } 

यह समरूपता आस्थगित संगणना के परिणाम को संरक्षित करती है - यह "महत्वपूर्ण गुण" है, जबकि डेटा संरचनाएं भिन्न हैं।

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

PS यदि मैं देखता हूं कि लेख से लाभ हुआ है, तो मैं "अधिक सफल (सूक्ष्म) वास्तु समाधान" और "परीक्षण के लिए एक संशोधित दृष्टिकोण" के विषयों पर लौटूंगा।