Да ,спасибо за совет ,Вы правы. Поставил бы лайк ,но достиг лимита уже( Понял ,что впредь нужно тщательнее подходить к объяснению принципов лежащих в основе решения.
Я подумал ,что Вы имели ввиду какие-то дополнительные расходы на хранение значений ,помимо самих значений в HashMap. А так да ,Вы правы ,оценка происходит из худшего случая ,при котором N - кол-во элементов в массиве ,а не фактическое кол-во пар в хешмапе.
Пример ,боюсь ,что не приведу. А необходимость в том ,чтобы научиться проходить алгоритмические секции собеседований. Я хотел привести свою модель рассуждений при решении подобных задач. Не без косяков ,конечно))
Да ,спасибо за совет ,Вы правы. Поставил бы лайк ,но достиг лимита уже( Понял ,что впредь нужно тщательнее подходить к объяснению принципов лежащих в основе решения.
отличный вариант! Заслуживает отдельного лайка)
Да ,смысла в этом действительно нет ,тк i + 1 будет всегда наибольшим. Недоглядел ,спасибо)
Согласен ,формулировка некорректная. Буду работать над этим в будущем. "Кол-во единиц и нулей совпадает" здесь гораздо понятнее прозвучало бы
Я подумал ,что Вы имели ввиду какие-то дополнительные расходы на хранение значений ,помимо самих значений в HashMap. А так да ,Вы правы ,оценка происходит из худшего случая ,при котором N - кол-во элементов в массиве ,а не фактическое кол-во пар в хешмапе.
Пример ,боюсь ,что не приведу. А необходимость в том ,чтобы научиться проходить алгоритмические секции собеседований. Я хотел привести свою модель рассуждений при решении подобных задач. Не без косяков ,конечно))
Удачи в изучении! Сам нахожусь в процессе)
Согласен ,но обычно затраты памяти берут условно при оценке алгоритма ,в данном случае оценка сводится к кол-ву элементов в хешмапе.
Здесь имел ввиду кол-во нулей ,просмотрел этот момент