из "очерди" на списках имеет класс сложности O(1)...O(N), а на массивах O(1). В чём же заключается оптимизированность?
== В List.map например гарантированно List.rev вызовится на всех N.
и при чём тут List.map?
== Очередь (как и стек) в ФП решаются прекрасно
если признаком прерасного являются костыли и дополнительный оверхэд, то да
== Я так понимаю, что опыта реализации сего чуда у автора этих строк не было.
let a = ResizeArray<int>() // очередь
a.Insert(0,1) // put
let x = a.[a.Count-1] // pop
a.RemoveAt(a.Count-1)
== Это банально больно, если не иметь соответствующей квалификации
это больно, если мозги отравлены - легко запутаться в вышеприведенном коде.
== Я что-то не припомню, чтобы мои преподы с пеной у рта доказывали, что стеки гавно, массив форевер
Сомнительные авторитеты твои преподы. Насколько я знаю, 90% "преподов" "программирования" - идиоты, 9% - патологические кретины. И то, что они доказывают, вовсе не является аксиомой не зависимо от наличия пены у рта. Если препод не догоняет, что динамический массив - это есть и стек, и очередь - то препод однозначно профнепригоден ))
Увидев мое желание прекратить беседу, решил полную чушь протолкнуть? > иными словами "выталкивании" из "очерди" на списках имеет класс сложности O(1)...O(N), а на массивах O(1). В чём же заключается оптимизированность? Т.е. то что на массивах добавление элемента имеет O(1..N) тебя не смущает? Оптимизированность в том, что для каждого элемента это происходит не более одного раза в отличии от реализации на массиве, следовательно полное прохождение элемента от начала до конца будет условно стоить O(2), т.е. O(1). > и при чём тут List.map? Притом, что при такой трактовке как у тебя им вообще нельзя пользоваться. Ибо там тоже есть List.rev с суммарным объемом в N, т.е. "оверхэд". > если признаком прерасного являются костыли и дополнительный оверхэд, то да Костылей ты все еще не показал. Дополнительного оверхэда, кроме, о ужас!, хранения дополнительных ссылок, я пока не увидел. > let a = ResizeArray<int😠) // очередь > a.Insert(0,1) // put > let x = a.[a.Count-1] // pop > a.RemoveAt(a.Count-1) Ты вообще понял, что написал? Ты в курсе что твой a.Insert(0,1) имеет сложность O(N)? O(N), а не O(1..N)! Это не считая того, что это нихера не иммутабельная структура. > это больно, если мозги отравлены - легко запутаться в вышеприведенном коде. Ты умудрился запутаться в вышеприведенном коде. А ты еще ничего иммутабельного не сделал. > Сомнительные авторитеты твои преподы. Насколько я знаю, 90% "преподов" "программирования" - идиоты, 9% - патологические кретины. И то, что они доказывают, вовсе не является аксиомой не зависимо от наличия пены у рта. Если препод не догоняет, что динамический массив - это есть и стек, и очередь - то препод однозначно профнепригоден )) В данный момент "патологический кретином" и "идиотом" выставляешь себя ты. То что динамический массив можно юзать как стек и очередь нихрена не значит, что он для этого будет эффективен. Возможно, ты путаешь динамический массив с Deque (хотя почему я должен думать за тебя, если ты даже не потрудился нормально прочитать мои замечания?), которую можно юзать вышеуказанным способом, и которая часто реализуется на динамическом массиве. 1. Динамический массив имеет: O(1..N) за вставку в конец, O(N) за вставку в начале, О(1) за удаление в конце (O(1..N) если экономим память), O(N) за удаление в начале. 2. Двунаправленная очередь на динамическом массиве: O(1..N) за вставку в конец, O(1..N) за вставку в начале, О(1) за удаление в конце (O(1..N) если экономим память), O(1) за удаление в начале (O(1..N) если экономим память). 3. Стек на основе массива: O(1..N) за вставку, O(1) за извлечени. 4. Стек на основе списка: O(1) за вставку, О(1) за извлечение. 5. Очередь на основе массива: O(1..N) за вставку, O(1) за извлечение. 6. Очередь на основе двух стеков (на основе списков): O(1) за вставку, O(1..N) за извлечение, причем из-за "одноразовости" переноса стека для большинства задач считается как O(1). Здесь основная претензия - это размазанность структуры данных по куче, что ввиду ссылочных данных уже не так критично. Я не знаю, что за универ тебя выпустил, и что за работодатель тебя нанял, но такое незнание матчасти в сочетании с непомерным гонором должны были вывести тебя в маргиналы еще во времена школьной скамьи. Продолжать дальнейшее обсуждение технической составляющей не буду, ибо с моей точки зрения в данном вопросе ты профан и тебе надо идти на викиконспекты зубрить теорию. Однако, терпеть незаслуженные оскорбления в адрес уважаемых мною людей не собираюсь. У меня есть претензии к современности познаний моих преподов (по прикладным предметам), но уж тот материал, что они дают, они знают на достаточном уровне (разумеется есть исключения).
> Насколько я знаю, 90% "преподов" "программирования" - идиоты, 9% - патологические кретины.
Обсуждают сегодня