將字符串轉換為數字，反之亦然

Question

將字符串轉換為等效數字的復雜性是什么，反之亦然？ 它是否會根據編程語言而改變？

從表面上看，需要遍歷整個字符串以將其轉換為數字，因此它是O（n） ，還是使用了一些類型轉換？

當我寫一個程序檢查一個給定的數字是否是回文時，就會出現這種疑問。 一種方法是將數字除以基數（此處為10），累加數字，並將它們放在一起。 示例：309/10 = rem（9），30/10 = rem（0），3/10 = rem（3）。 我們得到903。

我采用的另一種方法是將這個數字轉換成一個字符串，因為字符串有大量的成員函數來分割，反轉等，所以代碼更短更清晰，但這是最好的方法嗎？

Answer 1

數字字符串是以位置表示法格式化的數字 - 因此需要考慮每個數字的值乘以基數的冪，以便將數字轉換為二進制格式。

所以是的，這是一個O（N）操作，因為隨着更多數字的添加，運行時間會線性增加。 但是，在實踐中，N可能受到語言支持的任何數值數據類型的限制（例如int32_t，int64_t）。 但是如果使用任意精度數字類型（某些語言，如Python，默認使用）那么數字的數量沒有限制（顯然除了可用內存）。

Answer 2

要轉換為數字，您必須始終讀取所有數字。 所以它至少是O(n) 。

現在做一些像（偽代碼）

a = 0
foreach digit in string
do
   a = 10 * a + digit
end

是O(n) 。 所以復雜性是O(n)

Answer 3

C＃和C / C ++在表示（可能的）數值的字符串中沒有任何特殊信息。 因此，他們需要在轉換時逐位解析字符串。

但是，位數是有限的，所以我們只有O（1）：轉換時間是有界限的（通常是最大數字的轉換）。 對於32位int，轉換必須考慮最多10個十進制數字（可能還有一個符號）。

從字符串轉換實際上也是O（1），因為在解析它時，僅考慮有限數量的字符（在32位int的情況下為10 + 1）就足夠了。

嚴格來說，我們不能將O -notation用於int-to-string轉換的情況，因為int的最大值是有界的。 無論如何，轉換所需的時間（在兩個方向上）都受到常數的限制。

正如@Charles所說，其他語言（Python）實際上可以使用任意精度數字。 對於解析這樣的數字，時間是O(number of digits) ，分別為兩次轉換的O(string length)和O(log(number)) 。 對於任意精度的數字，人們不能更快地做到這一點，因為對於兩次轉換，必須考慮每個數字。 對於有限精度數的轉換，應用相同的O(1)推理。 但是我自己並沒有在Python中分析解析，因此可能會使用效率較低的算法。

---

編輯：按照@Steve的建議，我檢查了在C / C ++和C＃中的解析跳過了初始的空格，所以string-> int轉換的時間實際上是O(input length) 。 如果已知字符串被修剪，則轉換再次為O(1) 。

Answer 4

我有理由相信，處理純數字運算符（在c ++和c＃中我認為它將是“％”模數運算符）如果編碼正確將會更有效，因為在某種程度上你必須檢查類似的功能（是如果你可以在不執行轉換的情況下做同樣的事情，那么在字符串和數字之間執行轉換只會增加操作的復雜性。

也就是說，我不擔心數字和字符串之間的轉換對性能的影響，因為與程序的大多數其他方面的性能影響相比，它可能是微不足道的。 數字類型限制為64位，這會對您計划解析的數字位數設置相對較低的上限，除非您正在實現/使用自定義編碼的大數字類型。

您不必擔心復雜性為O（n），其中n是數字的大小。 它更像是O（n），其中n是數字的位數（具有我提到的低上限）或（如另一個答復中所述）O（log（n）），如果n是數字的大小。 性能影響相對微不足道。

現在，如果按照你的建議，你對N沒有限制（這是不可能的，因為有2 GB的RAM，你只能存儲多達20億個數字的數字），那么我們可能需要更多地思考執行數學的性能運營商。 考慮這個大數字類型的“％”和“/”運算符的性能。 但后來才意識到，為了將數字轉換為字符串，無論如何它基本上都是使用相同的運算符。 再一次，如果你做對了，你就不能直接把它作為一個數字來處理。

Answer 5

如果您要將數字N轉換為字符串。 它需要O（log（N））與基數10.（如果除以10並保留余數）如果要轉換長度為N的字符串，則需要O（N）。 （如果你使用的算法會不斷增加你的數字10 ^（N）*數字（N））

如果你使用不屬於你的函數（假設是字符串），你只能期望它們更慢。