A
Если в будущем окажется, что выбрал не ту модель данных – штош, придется переписать код (скорее всего в одном файле)
Size: a a a
2020 January 10
ST
Alish
Где pt-x, pt-y я бы просто написал (let [[x y] ...] где-нибудь на верхнем уровне и be done with it, как говорится
если работаешь только с одной из координат, то нет
и с точки зрения перформанса
и с точки зрения перформанса
ST
Alish
Если в будущем окажется, что выбрал не ту модель данных – штош, придется переписать код (скорее всего в одном файле)
да, и если апдейты векторов в алгоритме смешаны с апдейтами векторов (и мапок) в модели, то различать их в коде будет муторно
ST
Alish
С точки зрения перформанса тоже
как раз для перформанса писалось
(p 0) вместо (get p 0) 😊ST
как раз для перформанса писалось
(p 0) вместо (get p 0) 😊только в данном случае это было premature optimization
D
или вот ещё пример функций, для которых может возникнуть вопрос, зачем их вообще нужно выделять, они же такие простые https://github.com/serioga/advent-of-code-2019/blob/master/src/advent/day_03_1.clj#L106-L114
а они просто отражают выбранную абстракцию для преставления точки на координатной сетке
если рефакторить эту абстракцию, то замучаешься выковыривать соответствующие операции с векторами в коде
а они просто отражают выбранную абстракцию для преставления точки на координатной сетке
если рефакторить эту абстракцию, то замучаешься выковыривать соответствующие операции с векторами в коде
прям СИКП
AI
а не эффективнее для перформанса юзать что угодно джава-мутабельное вместо персистентных кложа-векторов?
D
@prepor имутабельность - говно? (или это был сарказм)
ST
а не эффективнее для перформанса юзать что угодно джава-мутабельное вместо персистентных кложа-векторов?
эффективнее, но сложнее
а на хакерранке многие задачи подобраны такие, что тебе нужно менять сложность алгоритма, возня с оптимизацией сложного алгоритма не приводит к решению задачи
так что на практике у стандартных векторов очень хорошая производительность
а на хакерранке многие задачи подобраны такие, что тебе нужно менять сложность алгоритма, возня с оптимизацией сложного алгоритма не приводит к решению задачи
так что на практике у стандартных векторов очень хорошая производительность
AR
D
IT высер
AR
IT высер
Там вроде обратный поинт был )
AI
не, если это не проект для себя а решение задачки на хакерранке лишь бы по времени прошло, то нет вопросов. просто удивила ловля блох с гет/без гет на фоне альтернативы юзать более подходящие структуры данных для хранения точек с координатами сразу
ST
а не эффективнее для перформанса юзать что угодно джава-мутабельное вместо персистентных кложа-векторов?
я одну задачу решал с использованием массивов
https://github.com/serioga/advent-of-code-2019/blob/master/src/advent/day_02_1.clj
понял, что в общем случае оно того не стоит
https://github.com/serioga/advent-of-code-2019/blob/master/src/advent/day_02_1.clj
понял, что в общем случае оно того не стоит
ST
не, если это не проект для себя а решение задачки на хакерранке лишь бы по времени прошло, то нет вопросов. просто удивила ловля блох с гет/без гет на фоне альтернативы юзать более подходящие структуры данных для хранения точек с координатами сразу
ну, вектор
а ловля блох — это у меня пунктик после бенчмарков разных способов доставания элементов из коллекций 😊
[x y] вполне себе подходит для начала, когда ещё непонятно, что подходит лучшеа ловля блох — это у меня пунктик после бенчмарков разных способов доставания элементов из коллекций 😊
ST
прям СИКП
ссылку можешь дать на соответствующее место в SICP?
D
ссылку можешь дать на соответствующее место в SICP?
DM
не работает некоторая фигня подскажите плиз
(defn as-temporal-query ^TemporalQuery [f]
(reify TemporalQuery
(queryFrom [_ arg] (f arg))))
(into-array ^TemporalQuery query)
(defn as-temporal-query ^TemporalQuery [f]
(reify TemporalQuery
(queryFrom [_ arg] (f arg))))
(into-array ^TemporalQuery query)
DM
не распознает по хинтам что это интерфейс ругацется
DM
уже везде хинтов напихал