Ну и печально, конечно, что всё не так оптимально как могло бы быть. Вот в Haskell вроде тоже есть большие целые произвольной длины, но они гораздо быстрее.
Объясните мне причины запрета мата. Что в СМИ, что в правилах того же Хабра. Это же просто набор букв с определённым смыслом. Их запрещают, появляются эвфемизмы с тем же самым смыслом, но разрешённые. Получается, что запрещают не смысл высказывания, а лишь его форму: определённый набор букв. Это всё выглядит как неразумное первобытное табу, смысла которого никто не понимает, но все свято его соблюдают.
Если необходим индекс, его всегда можно изящно добавить в одну строчку, просто построив список пар с помощью функции zip (не силён в JS, не знаю местных аналогов).
map (\(element, index) -> ...) $ zip elements [0..]
Из простых атомарных частей (map, zip, генераторы) очень легко строить абстракции любой сложности, на какие только воображения хватит. Зачем все возможные варианты пытаться уместить в одной сложной функции – совершенно не понятно.
1) Фильмы в Netflix со всеми метаданными образуют граф. При этом фильмов немного и граф небольшой, в графовую базу его смысла складывать нет. Поэтому они держат его в памяти процесса и, используя самописные алгоритмы на графах, быстро и эффективно отвечают на запросы.
2) Для поиска похожих фильмов удобно использовать граф, где рёбрами будут метаданные и скоры из различных моделей. На таком графе затем запускается процедура оптимизации, считающая степень похожести.
3) Ансамбли деревьев решений – мощные алгоритмы машинного обучения, но скорость предсказаний у них оставляет желать лучшего. Поэтому мы пишем компилятор таких деревьев в нативный код. Для этого, естественно, в памяти необходимо построить некое абстрактное представление таких деревьев, которое затем может быть оптимизировано и скомпилировано.
Как тут поможет односвязный список? Вам придётся его эмулировать на имеющихся стандартных типах, что даст только оверхэд на эмуляцию.
Можно эмулировать, можно и не эмулировать.
@dataclass(frozen=True)
class Node:
next: 'Node'
value: T
Проверка на исключение циклов — это к алгоритмам, а не к структурам данных.
Алгоритмы и структуры данных настолько тесно связаны, что говорить о них отдельно совершенно не имеет смысла.
Графы и деревья в условиях скриптовых языков точно так же будут записаны через структуры Hash\Map.
Ну почему же? Я вот так всегда деревья записываю:
@dataclass(frozen=True)
class Node:
left_child: 'Node'
right_child: 'Node'
value: T
это точно не является типичной задачей для фронтенда\веба.
Человек спросил про Python / JavaScript, а не про фронтенд. В статье тоже ничего конкретно про фронтенд. Мы же с вами не фронтендщиков обсуждаем, а программирование в целом. И в программировании довольно часто появляются задачи, связанные с графами и деревьями. В backend и data science особенно.
Например, зачем мне на python или javascript знать как организовывать связанные списки(за исключением саморазвития и расширения кругозора)?
Во-первых, как я уже упомянул, чтобы понимать как наиболее эффективно использовать структуры данных для реализации алгоритмов. Знать границы применимости, уметь предсказывать поведение кода на низком уровне.
Во-вторых, иногда и на высоком уровне приходится использовать базовые структуры данных. Реальная продуктовая задачка: для подготовки данных необходимо применить цепочку преобразований. Элемент a заменить элементом b, элемент b элементом c, элемент h элементом g и т.д. Для каждого элемента цепочка преобразований образует односвязный список. А цепочки эти комбинируются из различных источников и, чтобы исключить ошибку, перед применением необходимо проверить их на валидность – удостовериться, что в них нет циклов. А если есть, то либо целиком откинуть такую цепочку, либо поднять информативную ошибку.
Ни одна стандартная структура данных Python здесь не поможет, библиотек для такой фигни никто не станет писать. Но, понимая структуру данных и зная алгоритм, можно за 5 минут накидать его в несколько строк.
И это простейший пример. Гораздо чаще возникают деревья и графы.
Ну и зря :)
Теперь есть.
PyCharm же всё автоматически добавляет, зачем ещё какую-то магию городить?
А есть ещё средний, медианный, перцентили. Из которых можно извлечь гораздо больше информации.
Начинающим такой подход противопоказан.
А куда?
...
Очень интересно, спасибо!
Ну и печально, конечно, что всё не так оптимально как могло бы быть. Вот в Haskell вроде тоже есть большие целые произвольной длины, но они гораздо быстрее.
Объясните мне причины запрета мата. Что в СМИ, что в правилах того же Хабра. Это же просто набор букв с определённым смыслом. Их запрещают, появляются эвфемизмы с тем же самым смыслом, но разрешённые. Получается, что запрещают не смысл высказывания, а лишь его форму: определённый набор букв. Это всё выглядит как неразумное первобытное табу, смысла которого никто не понимает, но все свято его соблюдают.
Если необходим индекс, его всегда можно изящно добавить в одну строчку, просто построив список пар с помощью функции
zip(не силён в JS, не знаю местных аналогов).Из простых атомарных частей (
map,zip, генераторы) очень легко строить абстракции любой сложности, на какие только воображения хватит. Зачем все возможные варианты пытаться уместить в одной сложной функции – совершенно не понятно.Думаю, автору просто не повезло. Пересказ другого сериала набрал +129, например.
Просто все нормальные языки реализуют
map :: [a] -> (a -> b) -> [b], а JS зачем-то решил отличиться. Поэтому и странный.Об опечатках нужно писать в личку. На хабре эта возможность даже автоматизирована: необходимо выделить ошибочное место и нажать Ctrl + Enter.
Ну я опечатался, там
y in xsдолжно быть.Пожалуй.
Три примера из моей области:
1) Фильмы в Netflix со всеми метаданными образуют граф. При этом фильмов немного и граф небольшой, в графовую базу его смысла складывать нет. Поэтому они держат его в памяти процесса и, используя самописные алгоритмы на графах, быстро и эффективно отвечают на запросы.
2) Для поиска похожих фильмов удобно использовать граф, где рёбрами будут метаданные и скоры из различных моделей. На таком графе затем запускается процедура оптимизации, считающая степень похожести.
3) Ансамбли деревьев решений – мощные алгоритмы машинного обучения, но скорость предсказаний у них оставляет желать лучшего. Поэтому мы пишем компилятор таких деревьев в нативный код. Для этого, естественно, в памяти необходимо построить некое абстрактное представление таких деревьев, которое затем может быть оптимизировано и скомпилировано.
Можно эмулировать, можно и не эмулировать.
Алгоритмы и структуры данных настолько тесно связаны, что говорить о них отдельно совершенно не имеет смысла.
Ну почему же? Я вот так всегда деревья записываю:
Человек спросил про Python / JavaScript, а не про фронтенд. В статье тоже ничего конкретно про фронтенд. Мы же с вами не фронтендщиков обсуждаем, а программирование в целом. И в программировании довольно часто появляются задачи, связанные с графами и деревьями. В backend и data science особенно.
Но ведь лучше это явно понимать.
Python
Во-первых, как я уже упомянул, чтобы понимать как наиболее эффективно использовать структуры данных для реализации алгоритмов. Знать границы применимости, уметь предсказывать поведение кода на низком уровне.
Во-вторых, иногда и на высоком уровне приходится использовать базовые структуры данных. Реальная продуктовая задачка: для подготовки данных необходимо применить цепочку преобразований. Элемент a заменить элементом b, элемент b элементом c, элемент h элементом g и т.д. Для каждого элемента цепочка преобразований образует односвязный список. А цепочки эти комбинируются из различных источников и, чтобы исключить ошибку, перед применением необходимо проверить их на валидность – удостовериться, что в них нет циклов. А если есть, то либо целиком откинуть такую цепочку, либо поднять информативную ошибку.
Ни одна стандартная структура данных Python здесь не поможет, библиотек для такой фигни никто не станет писать. Но, понимая структуру данных и зная алгоритм, можно за 5 минут накидать его в несколько строк.
И это простейший пример. Гораздо чаще возникают деревья и графы.
После собеседования даём тестовое и потом смотрим корреляцию результатов и присланного кода.
Честные эксперименты проводить, конечно же, очень дорого.
Поиск в списке – O(n). Для проверки принадлежности нужно использовать множество, дающее амортизированную O(1).