Складність часу ітеративного рядка додавання насправді O (n ^ 2), або O (n)?

Я працюю над проблемою поза CTCI.

Третя проблема глави 1 дозволяє вам взяти такий рядок, як

'Mr John Smith '

і просить Вас замінити проміжні простори на %20:

'Mr%20John%20Smith'

Автор пропонує це рішення на Python, називаючи його O (n):

def urlify(string, length):
    '''function replaces single spaces with %20 and removes trailing spaces'''
    counter = 0
    output = ''
    for char in string:
        counter += 1
        if counter > length:
            return output
        elif char == ' ':
            output = output + '%20'
        elif char != ' ':
            output = output + char
    return output

Моє запитання:

Я розумію, що це O (n) з точки зору сканування фактичного рядка зліва направо. Але хіба рядки в Python не є незмінними? Якщо у мене є рядок і я додаю до нього ще один рядок за допомогою +оператора, чи не виділяє він необхідний простір, копіює над оригіналом, а потім копіює над доданим рядком?

Якщо у мене є колекція nрядків, кожна довжиною 1, то це займає:

1 + 2 + 3 + 4 + 5 + ... + n = n(n+1)/2

або час O (n ^ 2) , так? Або я помиляюся в тому, як Python обробляє додавання?

Як варіант, якщо ви хочете навчити мене риболовлі: як я можу знайти це для себе? Я не мав успіху в своїх спробах отримати офіційне джерело в Google. Я знайшов https://wiki.python.org/moin/TimeComplexity, але це не містить нічого в рядках.

У CPython, стандартній реалізації Python, є деталь реалізації, яка робить це, як правило, O (n), реалізоване в коді, цикл оцінки байт-коду викликає +або +=з двома рядковими операндами . Якщо Python виявляє, що лівий аргумент не має інших посилань, він закликає reallocспробувати уникнути копії, змінивши розмір рядка на місці. Це не те, на що вам коли-небудь слід покладатися, оскільки це деталь реалізації і тому, що якщо в reallocкінцевому підсумку потрібно часто переміщати рядок, продуктивність в будь-якому випадку погіршується до O (n ^ 2).

Без дивної деталі реалізації алгоритм має значення O (n ^ 2) через квадратичну кількість копіювання. Такий код мав би сенс лише в мові зі змінними рядками, як C ++, і навіть у C ++, який ви хотіли б використовувати +=.

Автор покладається на оптимізацію, яка трапляється тут, але не є явно надійною. strA = strB + strCяк правило O(n), робить функцію O(n^2). Однак досить легко переконатися, що це весь процес O(n), використовуючи масив:

output = []
    # ... loop thing
    output.append('%20')
    # ...
    output.append(char)
# ...
return ''.join(output)

У двох словах, appendоперація амортизується O(1) (хоча її можна зробити сильною O(1), попередньо розподіливши масив до потрібного розміру), зробивши цикл O(n).

І тоді joinце також O(n), але це нормально, тому що воно знаходиться поза циклом.

Я знайшов цей фрагмент тексту в розділі " Швидкість Python"> Використовуйте найкращі алгоритми та найшвидші інструменти :

Конкатенацію рядків найкраще робити, якщо ''.join(seq)це O(n)процес. На відміну від цього, використання операторів '+'або '+='може призвести до O(n^2)процесу, оскільки для кожного проміжного кроку можуть створюватися нові рядки. Інтерпретатор CPython 2.4 дещо пом’якшує цю проблему; однак, ''.join(seq)залишається найкращою практикою

Для майбутніх відвідувачів: Оскільки це питання CTCI, будь-яке посилання на вивчення пакету urllib тут не потрібне, зокрема, відповідно до OP та книги, це питання стосується масивів та рядків.

Ось більш повне рішення, натхнене псевдо @ njzk2:

text = 'Mr John Smith'#13 
special_str = '%20'
def URLify(text, text_len, special_str):
    url = [] 
    for i in range(text_len): # O(n)
        if text[i] == ' ': # n-s
            url.append(special_str) # append() is O(1)
        else:
            url.append(text[i]) # O(1)

    print(url)
    return ''.join(url) #O(n)


print(URLify(text, 13, '%20'))