но может есть еще идеи

зато с ним даже кастомный графстейдж не нужен, statefulMapConcat и вперед

да очередь (приоритетная) мож заиспользуй и все

ну у меня есть идея с буфером

брать из стрима где наименьший next

сколько стримов то?

100-1000

а какой тип элементов?

брать из стрима где наименьший next

тогда общая производительность будет на уровне самого медленного стрима, может это и нормально при каких-то условиях...

тогда общая производительность будет на уровне самого медленного стрима, может это и нормально при каких-то условиях...

ну как бы иначе у тебя не будет гарантий получения сортированного стрима на выходе. причем тебе нужно именно дожидаться, чтобы был слот с данными от каждого стрима прежде чем выбирать)

подтверждаю!

но может там стримы генерятся без IO

тогда бэк прэша всех уравняет как-то

Насколько нужно знать java чтобы писать на scala? В частности spark- пайплайны.

Насколько нужно знать java чтобы писать на scala? В частности spark- пайплайны.

достаточно знать скалу: если ты знаешь скалу, ты знаешь джаву

да очередь (приоритетная) мож заиспользуй и все

хорошая же идея. Берёшь из всех стримов по одному элементу засовываешь в кучу. Достаёшь верхний. Считываешь из стрима, которому он принадлежал и снова в кучу запихиваешь

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

Насколько нужно знать java чтобы писать на scala? В частности spark- пайплайны.

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

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

приорити куеуе с фиксед сайз по кол-ву стримов может работать ощутимо медленнее, чем просто фиксед сайз массив(по айтему на стрим) и поиск мин-макса в нем перебором. каждый сам решает насколько для него это критично)

приорити куеуе с фиксед сайз по кол-ву стримов может работать ощутимо медленнее, чем просто фиксед сайз массив(по айтему на стрим) и поиск мин-макса в нем перебором. каждый сам решает насколько для него это критично)

возможно, но нужен пруф оф консепт) ни раз с жвм убеждался что иногда проверить бывает полезно

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

Это здорово, конечно. В общем, щупать java для этих целей не нужно?

приорити куеуе с фиксед сайз по кол-ву стримов может работать ощутимо медленнее, чем просто фиксед сайз массив(по айтему на стрим) и поиск мин-макса в нем перебором. каждый сам решает насколько для него это критично)

имеешь ввиду что если постоянно самому искать мин/макс, это может быть быстрее чем приорити очередь?

Это здорово, конечно. В общем, щупать java для этих целей не нужно?

не нам тебе советовать каких женщин щупать. секса у тебя все равно будет в избытке

просто мне сложно представить как это может произойти

линейная сложность, все дела

а у приорити будет сколько?

лог (колво очередей) * колво элементов?

log n при вставке

вот правда когда достаешь тоже поидее log n

потести, вот о чем я

вдруг в твоеем кейсе будет быстрее а вдруг и нет

ага, сенк

вот правда когда достаешь тоже поидее log n

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

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

нее!

не линкед

а кто мешает сделать приорити кью на массиве?

он и есть на массиве же

там хип макс или хип мин на массиве

не линкед

да ладно? переставляет чтоли? я бы на линкеде сделал и обрезал бы)

Артур ты попал

да мне наоборот интересно

да ладно? переставляет чтоли? я бы на линкеде сделал и обрезал бы)

так ты когда отрежешь, тебе же перестраивать надо

так ты когда отрежешь, тебе же перестраивать надо

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

ну так как у тебя к следующему-то разу вверку минимум будет ? )

для того чтобы binary heap проперти сохранялось

как проще сделай сначал

упрешься в произодительность колхозить будешь

ну или пока будешь делать просто поймешь почему это медленно

хотя быть может так как я описал никто не делает и все сразу реализуют оптимальные решения ?

хотя быть может так как я описал никто не делает и все сразу реализуют оптимальные решения ?

сперва на бумажке, потом пруф оптимальности, и только потом код

как иначе-то?

хотя быть может так как я описал никто не делает и все сразу реализуют оптимальные решения ?

большинство из тех кто так делают, только думают что они занимаются оптимальным решением)

ну так как у тебя к следующему-то разу вверку минимум будет ? )

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

ну как, у тебя должна очередь обновиться же. Ты когда отрубил голову, ты берёшь последний элемент ставишь его в голову и просеиваешь вниз

ну как, у тебя должна очередь обновиться же. Ты когда отрубил голову, ты берёшь последний элемент ставишь его в голову и просеиваешь вниз

я веду речь о линкед приорити квае, а не о той реализации, что в ждк

я веду речь о линкед приорити квае, а не о той реализации, что в ждк

аа, это что-то мне неизвестное

аа, это что-то мне неизвестное

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

возможно имеется в виду просто очередь основанная на сортированном связном списке.

с линейной вставкой

аа, просто отсортирвоанный связный список с линейной вставкой и без кэш локалити?

аа, просто отсортирвоанный связный список с линейной вставкой и без кэш локалити?

ну конечно. я же вроде по русски писал - линкед приорити квае)

по русски не так же будет

по русски не так же будет

не учи отца сношаться)

ERROR: S client not available

в натуре

тогда общая производительность будет на уровне самого медленного стрима, может это и нормально при каких-то условиях...

эт с чего вдруг

у тебя в любом случае есть зависимость

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

хоть с буфером, хоть без

буфер тебе в этом тож не поможет

ну конечно. я же вроде по русски писал - линкед приорити квае)

это не приорити queue

это не куча. но priority queue

это не приорити queue

ну поставь сортед вместо приорити, если так больше нравится. ну ей богу, как малыши)

это не куча. но priority queue

да, точно

Скаланы, а посоветуйте _хороший_ чатик по блокчейнам. Не про ico и майнинг, а про всякий хардкорчик. Чтобы про про распредленщину, теорию игр и криптографию разговоры шли.

Скаланы, а посоветуйте _хороший_ чатик по блокчейнам. Не про ico и майнинг, а про всякий хардкорчик. Чтобы про про распредленщину, теорию игр и криптографию разговоры шли.

чатик этериума подойдет?

чатик этериума подойдет?

Не знаю.

Эфириумщики обычно про свое говорят. У них там особая кухня и экосистема.

Скаланы, а посоветуйте _хороший_ чатик по блокчейнам. Не про ico и майнинг, а про всякий хардкорчик. Чтобы про про распредленщину, теорию игр и криптографию разговоры шли.

хочешь заведу такой, только хз где аудиторию набрать :-)

хочешь заведу такой, только хз где аудиторию набрать :-)

Сразу же любителей помайнить поналезет

Сразу же любителей помайнить поналезет

бань сходу, но вежливо

Без авторитета такой чатик не стартануть

если такой делать, мне кажется нужно чтобы вход ток по инвайтам был, а то заходить туда будет с другими целями

@fomkin есть ли такие вообще? такие люди обычно на конфах тусят, и обычно уже друг друга знают, был же на фп конфе чувак из IOHK вот можно его спросить, он наверняка знает.

если такой делать, мне кажется нужно чтобы вход ток по инвайтам был, а то заходить туда будет с другими целями

надо криптопротокол входа придумать

надо криптопротокол входа придумать

proof-of-knowledge ?

можно говорит proof-of-anything и выглядеть умно )

изобретать анонимный блокчейн, чтобы общаться харей к фейсу

а еще есть proof-of-proofs-of-work PoPoW - очень название по королёву

ну все) лей воду в кислоту, а не наоборот

а еще есть proof-of-proofs-of-work PoPoW - очень название по королёву

это пять

Скаланы, а посоветуйте _хороший_ чатик по блокчейнам. Не про ico и майнинг, а про всякий хардкорчик. Чтобы про про распредленщину, теорию игр и криптографию разговоры шли.

@cryptoanarchy_ru

хох) но название все-таки майнерское)

в смысле блокчейн

в телеге проблемы с чатами про блочкейн

уже нет