एल्गोरिथ्म समय विश्लेषण "इनपुट आकार" बनाम "इनपुट तत्व"

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

लगता है कि एल्गोरिथ्म के लिए इनपुट लंबाई बहुत तरह के डेटा और उस एल्गोरिथ्म पर निर्भर करती है जिसके बारे में आप बात कर रहे हैं।

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

यदि वर्णों के बजाय हमारे पास संख्या (उदाहरण के लिए पूर्णांक) है, तो कभी-कभी द्विआधारी प्रतिनिधित्व का उपयोग वर्णों के बजाय किया जाता है, इसलिए "इनपुट लंबाई" की गणना (इनपुट सेट में अधिकतम संख्या होने के नाते) के रूप में की जाती है। $N*log(L)$

अन्य समस्याएं भी हैं कि भले ही इनपुट सेट संख्याएं हों, वे "इनपुट लंबाई" को "निर्णय चर" के रूप में वर्णित करते हैं, इसलिए इनपुट एन के लिए सेट लंबाई की लंबाई के साथ इनपुट लंबाई है। बस एन (उदाहरण के लिए उपसमुच्चय), या इससे भी अधिक द्विआधारी स्थान मूल्यों की संख्या को जटिल करता है जो समस्या को बताता है (मुझे विश्वास है कि के समान ही है ) $0-2^{32}$ $N*log(L)$

इसलिए:

यह एल्गोरिथ्म पर निर्भर करता है?
प्रत्येक इनपुट लंबाई "संस्करण" का क्या मतलब है और कब उपयोग करना है
क्या कुछ नियम हैं जो मैं यह तय करने के लिए उपयोग कर सकता हूं कि किसका उपयोग करना है?

— यीशु सलास
स्रोत

जवाबों:

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

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

आपके "एबीसीड" उदाहरण का उपयोग करते हुए, यह सामान्य रूप से ऐसा होगा कि इनपुट के लिए हम जिस वर्णमाला का उपयोग करते हैं वह छोटा है, इसलिए वर्णों के प्रॉक्सी माप का उपयोग करते हुए भी , हम जानते थे कि ट्यूरिंग मशीन पर भी, हम परेशान कर सकते हैं, एक इनपुट एन्कोडिंग निर्दिष्ट करें जो कुछ एबोडेड फॉर्म में "एबीसीड" को परिवर्तित करेगा जिसकी लंबाई कुछ स्थिर लिए अधिकतम । एक स्थिर द्वारा यह विस्तार आमतौर पर हमारे स्पर्शोन्मुख विश्लेषण में कोई अंतर नहीं करेगा, क्योंकि हम नियमित रूप से निरंतर कारकों को छोड़ देते हैं। $5$ $5\times c$ $c$

एक अलग मामले में, हम अक्सर इनपुट ग्राफ के आकार को नापते हैं की संख्या से । स्पष्ट रूप से अगर हम मनमाने ढंग से बड़े रेखांकन निर्दिष्ट करना चाहते हैं, तो एन्कोडेड इनपुट का आकार केवल नहीं है - उदाहरण के लिए किनारों का क्या हुआ? हम क्या जानते हैं कि हम एक उचित एन्कोडिंग योजना का उपयोग कर सकते हैं जो बिट्स में ग्राफ का प्रतिनिधित्व करता है । यह निरंतर की तुलना में थोड़ा अधिक विस्तार है, लेकिन बहुत सारे दिलचस्प मामलों में, हम केवल बहुरूपताओं की एक विशिष्टता पर काम कर रहे हैं, और बहुपद कई तरीकों से अच्छी तरह से रचना करते हैं - विशेष रूप से, उदाहरण के लिए, यदि हम निर्धारित करते हैं कि हमारा चलने का समय जहाँ एक बहुपद है, तो हम जानते हैं कि कुछ बहुपद है $n$ $n$ $N = c\cdot n^{2}\log n$ $O(p(n))$ $p$ $p'$ such that $O(p(n)) = O(p'(N))$ , so when we move back to the formal measure of the input, we're still in polynomial time.

A place where this might fall down is when you are working with numbers. As a number with magnitude $m$ can be encoded in $n = O(\log m)$ bits, if our running time were $O(m)$ , this would be $O(2^{n})$ - exponential in the actual input size - which would make the magnitude $m$ a bad choice for a proxy for the input size if we wanted to talk about membership in $\mathcal{P}$ for example (when you come to Strongly- $\mathcal{NP}$ -complete and Weakly- $\mathcal{NP}$ -complete, remember this). On the other hand, if all we were interested in was decidability, then it would be a good enough proxy measure.

So while there's no stated rule for picking a proxy measure for the input size, the requirement is that the expansion or contraction of the proxy size compared to the input size should be compatible with what you're trying to prove. As a rule of thumb, constant factor changes almost never matter, small polynomial factors are normally fine and work for most of the basic theory that you see, large polynomial factors might still work in for theory, but can be a nasty surprise in practice, and exponential amounts of change are normally way too extreme.

— Luke Mathieson
स्रोत

Thanks for the answer. Really interesting the part you talk about the selection of the right proxy to talk about membership in P or NP for the input, that could be a complete new question! Besides that, and coming back to the former question. Which one in your opinion would be then the best proxy for an algorithm that its input is a set of integers? I guess Maybe it will depend on the algorithm? I see 3 potential options: N (being the length of the set) N*Log(L) (L being the max value) and Log(Sum(set)).

— Jesus Salas

@JesusSalas, it definitely can depend on what you do with them, but

N \log L

$N\log L$ would be the simplest "close enough to the TM encoding" answer, but it can still be interesting to look at the running time in terms of

N

$N$ , or maybe

N

$N$ and the magnitude of the largest number - of course this is just

2^{\log L}

$2^{\log L}$ , but sometimes it can be easier to analyse things with non-obvious measures.

— Luke Mathieson

This covers the bases but there are some inaccuracies. Representing "abcde" on a Turing machine doesn't take

5 c

$5c$ characters: it takes five characters if you choose the right alphabet. And you don't need

c n^{2} \log n

$cn^2\log n$ bits to represent an

n

$n$ -vertex graph: the adjacency matrix is exactly

n^{2}

$n^2$ bits.

— David Richerby

Maybe when to use N or N log L could depend on the cost for the algorithm to operate on each input element. I guess that if we have an assumption that the algorithm use constant time to do its work on each input element independently of its size in bits (and this is not abused), then N is probably the right one, resulting in O(N). In the other hand if the input element size in bits increase the operation cost then N log L seems more accurate as the we should express in the upper bound what properties from the input are involved in growth

— Jesus Salas

@DavidRicherby yes, if you get to choose the alphabet it takes

5

$5$ symbols, but this is just where

c = 1

$c=1$ , if for other reasons we have a different alphabet, say binary, seeing as it's much more useful to be able to say we can encode everything in binary without loss of generality, then

c = \log_{2} 5

$c = \log_{2}5$ , but it's easy, and interesting to see that it's relatively easy to do it with any not-insane alphabet within a constant factor of

5

$5$ . Also, true, you may not need

O (n^{2} \log n)

$O(n^{2}\log n)$ bits, but it is a pretty robust upper bound that can deal with both normal encodings.

— Luke Mathieson

It depends on your model of computation and also on the unfortunately sometimes on the algorithm itself.

If your model of computation is a Turing machine, then the size of the input is the number of cells occupied by the input. So if your input is $ababcd$ then the input has length 6.
If your model is the RAM then the size of the input is the number of registers/memory cells where the input initially stays. This might be misused since you could technically write the whole input in one register. However then computations are more costly if you use the logarithmic costs model.
If your model of computation is a word-RAM, then you also count the memory cells, but they can only store $w$ -bit integers, for $w$ being a parameter of your model.

However many algorithms are not measured with respect to the "actual" input size. Then you have to carefully look, what the statement of the analysis refers to.

Often you have a implicit assumption with the problem. When saying that it takes $O(n\log n)$ time to sort $n$ items then you assume that two items can be compared in $O(1)$ time. Of course if you sort, say $n$ very long strings, then this might not be true.
For conventional reasons you measure sometimes with respect to a different parameter of the input. For example matrix multiplication is typically analyzed for multiplying two $n\times n$ matrices.

Some rule: Use whatever you want, but make it clear in the statement of the result. So just say what $n$ exactly is, if there is a chance of misunderstanding.

— A.Schulz
स्रोत

Say what

n

$n$ is regardless of whether there's a chance of misunderstanding! "The algorithm runs in time

O (n^{3})

$O(n^3)$ " is meaningless if

n

$n$ hasn't been defined, even if "

n

$n$ is the length of the input" is the only sane guess.

— David Richerby