Ваш анализ наихудшего случая кажется полностью правильным; Я не заметил никаких ошибок в этом, и я получаю тот же результат.
Ваш анализ в лучшем случае неверен; вы сказали, что в лучшем случае это O (1), но ваш l oop по списку meetings
всегда завершает n итераций, поэтому этот случай также принимает O ( n ) время Возможно, вы допустили ошибку, предполагая, что длина списка в лучшем случае равна 1 или даже 0; это не считается «случаем», потому что вам нужно рассмотреть семейство входов, параметризованных размером n , чтобы асимптотический c анализ имел смысл вообще.
Ваше пространство Анализ сложности также не является правильным. Ваш алгоритм создает две структуры данных: массив slots
имеет постоянный размер, а список condRange
также имеет постоянный размер, потому что он добавляется только к третьему l oop, который, как мы установили, делает O (1) операций, поэтому число операций add
в этом списке также равно O (1). Даже если этот список в конечном итоге будет иметь размер O ( n ), он является выходом алгоритма, поэтому любой правильный алгоритм должен будет создать список такого размера; обычно полезнее измерять сложность «вспомогательного» пространства, то есть пространства, используемого временными структурами данных, которые существуют только для внутренней работы алгоритма.
Существует одно предположение, которое было бы полезно явно указать, а именно: что собрания startTime
и endTime
всегда ограничены диапазоном от 0 до 16 (включительно), так что имеет смысл использовать в качестве индекса в slots
. Кстати, вам не нужно придумывать имя для константы c
, вы можете просто написать O (1) там.