Size: a a a

Clojure — русскоговорящее сообщество

2021 April 06

DL

Dmytro Lispyvnyi '(🌲... in Clojure — русскоговорящее сообщество
Dmitry Ivanov
А где ещё есть работа со сравнимыми условиями?
В смысле заниматься скучным говном?
источник

OR

Oleg Roshchupkin in Clojure — русскоговорящее сообщество
источник

DI

Dmitry Ivanov in Clojure — русскоговорящее сообщество
Спасибо!
источник

E

ETL in Clojure — русскоговорящее сообщество
Dmitry Ivanov
vector в Кложе - это ведь дерево?
Если кто-нибудь использовал Кложу для технического собеседования в FAGMAN , как правильно работать со сложностью в задачах с массивами? Правильно ли я понимаю, что доступ к элементу vec - логарифмический?
Persistent data structures все - дерево, но вектор, если сравнивать с ООП реализует семантику LIFO (читать - стэк).
источник

DI

Dmitry Ivanov in Clojure — русскоговорящее сообщество
ETL
Persistent data structures все - дерево, но вектор, если сравнивать с ООП реализует семантику LIFO (читать - стэк).
А map и set, получается, тоже на деревьях? Мне казалось, что при некоторых условиях можно получить плоскую HashMap и HashSet соответственно.
источник

PP

Pavel Peganov in Clojure — русскоговорящее сообщество
Dmitry Ivanov
vector в Кложе - это ведь дерево?
Если кто-нибудь использовал Кложу для технического собеседования в FAGMAN , как правильно работать со сложностью в задачах с массивами? Правильно ли я понимаю, что доступ к элементу vec - логарифмический?
Да, но там деревья, если ничего не путаю, по 32 элемента, так что логарифм там по основанию 32, который растёт ну очень небыстро
источник

PP

Pavel Peganov in Clojure — русскоговорящее сообщество
Dmitry Ivanov
А map и set, получается, тоже на деревьях? Мне казалось, что при некоторых условиях можно получить плоскую HashMap и HashSet соответственно.
Да и да. Достаточно маленькие упаковываются в один массив целиком (хотя они там не хэшсеты/хэшмапы).
источник

DI

Dmitry Ivanov in Clojure — русскоговорящее сообщество
Pavel Peganov
Да, но там деревья, если ничего не путаю, по 32 элемента, так что логарифм там по основанию 32, который растёт ну очень небыстро
Конечно, но асимптотически, логарифм, делённый на константу, остаётся логарифмом для формального анализа сложности.
источник

DI

Dmitry Ivanov in Clojure — русскоговорящее сообщество
Pavel Peganov
Да и да. Достаточно маленькие упаковываются в один массив целиком (хотя они там не хэшсеты/хэшмапы).
Спасибо. А достаточно маленькие - это, собственно, 32 элемента и меньше?
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Dmitry Ivanov
Конечно, но асимптотически, логарифм, делённый на константу, остаётся логарифмом для формального анализа сложности.
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Там в следующих статьях есть бенчмарки
источник

PP

Pavel Peganov in Clojure — русскоговорящее сообщество
Dmitry Ivanov
Спасибо. А достаточно маленькие - это, собственно, 32 элемента и меньше?
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
источник

DI

Dmitry Ivanov in Clojure — русскоговорящее сообщество
Огонь, спасибо!
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Т.е. в теории лукап по вектору O(1), но на практике это не так
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
короче разница видна только на громадных векторах. Ну и всегда есть нативные арреи java
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
скажем, если хранить 10М интов, то это лучше нативно делать
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Ivan Grishaev
короче разница видна только на громадных векторах. Ну и всегда есть нативные арреи java
Тут имхо основная суть в том что нет никакого O(1) на практике и в этом смысле log32(n) уже не так плохо выглядит как по началу кажется
источник