Ну там же копировали libc

что ты имеешь ввиду?

То и имею: весь std::net и std::io — тонкие обёртки над сисколами в стиле libc

лол, глянул что повыше уровнем — ноду, там тоже нет connect-а с таймаутом

https://github.com/yberreby/rust-tcp-connection-timeout/blob/master/src/lib.rs

https://github.com/yberreby/rust-tcp-connection-timeout/blob/master/src/lib.rs

оно под никсы

я помню на си убивал че-то используя системный вызов alarm(время в секундах). Но это был дикий костыль конечно, но так как надо было временно, можно было и покостылять

а возможность грохнуть свой трэд в раст добавить планируют?

т.е заспавнил и убил если надо

а возможность грохнуть свой трэд в раст добавить планируют?

есть фрейморки где это делать можно безболезнено? Ни в джаве, ни в дотнетах такого нет. В обоих случаях пишут что Thread.Kill делать не рекомендуется

а есть в rust'е что-нибудь подобное: public interface RangeMap<K extends Comparable,V> A mapping from disjoint nonempty ranges to non-null values. Queries look up the value associated with the range (if any) that contains a specified key. ?

чтоб потом map.put(1..5, "a") map.put(6..10, "b") и map.get(3) == "a"

есть фрейморки где это делать можно безболезнено? Ни в джаве, ни в дотнетах такого нет. В обоих случаях пишут что Thread.Kill делать не рекомендуется

Я помню свою первую лабу в универе, когда решил распаралелить, а огреб еще больше за Kill. Дорогая операция это очень.

а есть в rust'е что-нибудь подобное: public interface RangeMap<K extends Comparable,V> A mapping from disjoint nonempty ranges to non-null values. Queries look up the value associated with the range (if any) that contains a specified key. ?

звучит как что-то нишевое, делающееся руками за 10 мин

про 10 минут сильно сомневаюсь

ну не в расте у меня отнимало точно 10 минут поверх TreeMap а

хз. мне это видится как не малое количество всяких аспектов, что за 10 минут не накрутить

склеивать ренджи, выкусывать куски..

а возможность грохнуть свой трэд в раст добавить планируют?

Есть pthread_cancel в libc, но это не очень хорошая идея. Если тебе нужно завершить поток — сделай сигнальный oneshot канал для оповещение потока о том, что ему стоит умереть

хз. мне это видится как не малое количество всяких аспектов, что за 10 минут не накрутить

https://github.com/jneem/range-map

there's always a crate for it

Про трединг винды не знаю ничего совсем, в 10ке может и есть с WSL

https://github.com/jneem/range-map

pub fn get(&self, x: T) -> Option<&V> { self.elts // The unwrap is ok because Range<T>::partial_cmp(&T) never returns None. .binary_search_by(|r| r.0.partial_cmp(&x).unwrap())

:(

/// Runs in `O(log n)` time, where `n` is the number of mapped ranges.

pthread для винды есть, но есть ли биндинги под раст хз, нужно гуглить

/// Runs in `O(log n)` time, where `n` is the number of mapped ranges.

А как ты хотел?

magic.gif

pthread для винды есть, но есть ли биндинги под раст хз, нужно гуглить

погуглил я немножко... лучше пишите свои мегапараллельщину на чем нибудь другом :) на ерланге, например :P

Ты что-то имеешь против pthread?

Ты что-то имеешь против pthread?

ya?

ty

ty

ничего против не имею. И против раста ничего против не имею. Все равно он не лучше чем до-диез. Но проблема в том, что либ для pthread я не нашел. наткнулся на древнегреческие pthread онли линух. И еще там posix либы нашел, но вродь тоже 2015 года, и под линуз

magic.gif

но ведь... O(log n) - это оптимум, если о типе ключа ничего больше не известно...

Вот такая еще есть либа, для сейфодрочеров :) https://github.com/nix-rust/nix

https://github.com/afshinm/juggernaut

но ведь... O(log n) - это оптимум, если о типе ключа ничего больше не известно...

ну известно же что это рэндж

ну известно же что это рэндж

Да, известно, что это рэндж чего?

Например, это рэндж рациональных чисел, дай свою стратегию

Если ключ не является ренджем, то и log(n) сложно достичь

Если ключ не является ренджем, то и log(n) сложно достичь

Мы знаем, что ключ - рэндж

ну в моем случае это рендж uint'а

да на самом деле вы правы тут все, а я заморачиваюсь. log n это не плохо.

ну будет там 7-10 сравнений, да и похрен.

ну в моем случае это рендж uint'а

Ну ты можешь потратить много памяти и проиндексировать всё своими uint'ами. Возможно можно придумать под твои задачи более оптимальную структуру данных, но надо характер ключа поподробнее знать.

Мы знаем, что ключ - рэндж

Не, я о том, что если бы не было порядка, то поиск занимал мы O(n) в худшем случае. Поэтому замечание "но у меня же рендж" такое..

ну как нету. есть множество uint'ов , оно напилено (не полностью) на непересекающиеся отрезки которые мапятся в определенные значения

ну я и говорю что log n это не так уж и плохо

Ну в общем случае да, можно было бы задавать параметром типа бэкенд мэпу и искать со сложностью, предоставляемой ей

Тогда модно было бы до константы снизить для отдельных типов

Ну или до bitlen

Нет

О каких хешах мы говорим, если нам необходим порядок

это что угодно, имеющее интерфейс ordered map . Может быть и BTree и ATree, а может быть и prefix tree

Вот в последнем случае асимптотика лучше, чем O(log n * bitlen(t))

А bitlen(t) всегда неявно включается в асимтотику

prefix tree

log (n * |compare t|) только в случае, если нам о типе не известно ничего, кроме того, что он упорядочен

Да блин, я говорю, что для некоторых типов есть структуры, которые гарантируют O(1) worst case и порядок

В массиве по индексу )

P T R R E E F E I X —------ TRIE ______

И в мапах O(1) не в worst case

Да

Нет

Просто ты прочитал абзац, как в некоторых языках персистентные хэшмапы на нём реализуют

IntMap\IntSet в хачкеле

Олег хитрец, у radix трудоемкость не O(1)

Олег хитрец, у radix трудоемкость не O(1)

я же блин сказал, что O(bitlen(t))

Ну тогда ок)

но bitlen(t) неявно включается и в вычисление хеша и в сравнение

Так что хэшмапа и treemap не менее зависят от него в своих асимптотиках

Ну не обязательно в сравнении его юзать)

Ну не обязательно в сравнении его юзать)

Не очень понял. Есть алгоритмы, которым не обязательно целиком читать значение элементов, чтобы работать?

вот эту фразу я не могу понять. В какой мапе ключ - не конкретное значение? С другой стороны если ты в хешмапу складываешь строки неизвестной длины, какова будет сложность операций с ней?

Для того, чтобы вычислить хеш тебе придётся пробежаться по строке. Если мы говорим не у кукушкиной или подобной мапе, а о хеш-таблице со связными списками, тебе, возможно, придётся пробегаться по строчкам для сравнения при коллизии. Так что bitlen(t), который для стрингов ты в лучшем случае можешь мажорировать, очень даже входит в асимптотику

Для того, чтобы вычислить хеш тебе придётся пробежаться по строке. Если мы говорим не у кукушкиной или подобной мапе, а о хеш-таблице со связными списками, тебе, возможно, придётся пробегаться по строчкам для сравнения при коллизии. Так что bitlen(t), который для стрингов ты в лучшем случае можешь мажорировать, очень даже входит в асимптотику

Не обязательно бежать по строке, может у неё внутри уже вычисленный хэш)

В случае сравнения тебе возможно не придётся пробегаться по всей строке, если максимальный общий префикс небольшой длины. Однако возможно тебе придётся пробегаться по строке несколько раз для нескольких сравнений. В случае префиксной мапы, тебе придётся пробежаться по твой строке не более одного раза, и, возможно, не целиком, если максимальный общий префикс будет небольшой длины

Не обязательно бежать по строке, может у неё внутри уже вычисленный хэш)

1. Хотя бы раз, когда-то там в самом начале, тебе нужно по ней пробежаться. 2. Если это хэштаблица со связными списками, тебе нужно пробегаться для сравнения при коллизии

так так так, что почитать чтобы понимать как считать сложность алгоритма?

так так так, что почитать чтобы понимать как считать сложность алгоритма?

Кнута 😆